Pass-by-reference in C - downsides?

Question

Most high-level languages (Python, Ruby, even Java) use pass-by reference. Obviously, we don't have references in C, but we can imitate them using pointers. There are a few benefits to doing this. For example:

int findChar(char ch, char* in)
{
    int i = 0;
    for(i = 0; in[i] != '\0'; i++)
        if(in[i] == ch)
            return i;
    return -1;
}

This is a common C paradigm: catch an abnormal or erroneous situation by returning some error value (in this case, return -1 if the character is not in the string).

The problem with this is: what if you want to support strings more than 2^31 - 1 characters long? The obvious solution is to return an unsigned int but that won't work with this error value.

The solution is something like this:

unsigned int* findChar(char ch, char* in)
{
    unsigned int i = 0;
    for(i = 0; in[i] != '\0'; i++)
        if(in[i] == ch)
        {
            unsigned int index = (unsigned int*) malloc(sizeof(unsigned int));
            *index = i;
            return index;
        }
    return NULL;
}

There are some obvious optimizations which I didn't make for simplicity's sake, but you get the idea; return NULL as your error value.

If you do this with all your functions, you should also pass your arguments in as pointers, so that you can pass the results of one function to the arguments of another.

Are there any downsides to this approach (besides memory usage) that I'm missing?

EDIT: I'd like to add (if it isn't completely obvious by my question) that I've got some experience in C++, but I'm pretty much a complete beginner at C.

Answer 1

It is a bad idea because caller is responsible to free the index, otherwise you are leaking memory. Alternatively you can use static int and return its address every time - there will be no leaks, but function becomes non-reentrant, which is risky (but acceptable if you bear it in mind).

Much better would be to return pointer to char function finds, or NULL if it is not present. That's the way strchr() works, BTW.

Edited to reflect changes in original post.

Answer 2

1. The function needs to dereference the parameters, which takes more time than accessing the stack.
2. The pointers can be uninitialized, causing unexpected results.
3. There is no standard way to specify which pointer is for input, wich is for output and which is for both (there are extensions, and naming tricks, but it's still a matter).

Answer 3

In the specific example, you should use size_t as the return type: this is the data type that adequately represents how large strings can get on any system. I.e. you can't possibly have a string that is longer than a size_t can represent. Then, you can fairly safely use (size_t)-1 as an error indicator: realistically, you also cannot put a string with that size into memory, since you also need some address space for the code you are executing; it becomes a limitation of your API that such long strings would not be supported if they existed.

Your approach not only has the disadvantage using more memory, but also the disadvantage of being slower: the callee needs to malloc, the caller needs to free. Those are fairly expensive operations.

There is one other standard approach relevant here: errno. In case of an error indicator, you don't know what the error is. So in C, rather than using an out parameter, we typically put the error details into a global or thread-local variable.

Answer 4

The biggest downside is that it requires findChar()'s callers to free() the returned memory, or create a memory leak. You've reinvented the strchr() wheel poorly.

I also don't see why you're thinking that returning a pointer to unsigned int is such a big step forward. First, you could just return an unsigned int, if all you're after is the ability to return values up to 2^32 on a 32-bit machine instead of 2^31-1. Second, your stated goal is to avoid a problem with large strings. Well, what if you're on a 64-bit machine, where 'int' and 'unsigned int' remain 32 bits? What you really want here is a long, but returning pointers doesn't actually help here.

ELIDED BOGUS CRITICISM

Answer 5

Without the malloc, the position can be still a stack variable and you can use it in an if statement:

int findChar(char ch, char* in, int* pos)
{
    int i = 0;
    for(i = 0; in[i] != '\0'; i++) 
    {
        if(in[i] == ch) 
        {
            *pos = i;
            return 1;
        }
    }

    return 0;
}

Answer 6

I am not an expert, but I think a ton of small mallocs can cause problems. First, you have to take care of freeing the memory after the use of the value. Then you also have to deal with the fragmentation of the free memory. Passing as pointer is more suitable for complex structures.

Answer 7

I'd say the most severe downside to your code is that you use one return value to represent both a general failure and the result if successful.

While this is a common practice, it can lead to wierd scenarios when requirements change, just like the one you described. An alternative practice would be to separate the return values, i.e. something like this

int findChar(char ch, char const * const in, unsigned int * const index)
{
    if ( in != NULL && index != NULL)
    {
        unsigned int i;
        for(i = 0; in[i]; i++)
        {
            if(in[i] == ch)
            {
                *index = i;
                return EXIT_SUCCESS;
            }
        }
    }
    return EXIT_FAILURE;
}

...where the function return value tells you whether the function was successful or not, separately from the value of 'index'.

Then again, as fortran noted, there is no way to enforce whether the pointers are input values, output values, or both (i.e. modified inside the function).