Overly helpful compiler

[kbw]

I've noticed that compilers sometimes attempt to fix common user errors.

For example, beginners are often confused by the confusing treatment of pointers and arrays.

void process(int*, size_t n);

void f(void)
{
    int array[20];
    process(&array, n);  // C and C++ compilers will often remove the &
}

Recently, I've noticed GCC corrects the following to a heap allocation:

const size_t BUFFER_SIZE = 4 * 1024 * 1024;

void f(const char* in)
{
    char buffer[BUFFER_SIZE];
    strcpy(buffer, in);
    // ...
}

And in GCC 4.8, I've noticed it translates sprintf to snprintf when it can determine the buffer size. For example:

void f(void)
{
    char buffer[4];
    sprintf(buffer, "Hello");
    // ...
}

Do you think the compiler should actually be silently fixing your code or should it just warn you?

[Oria]

I would prefer warnings. How can you learn otherwise?

[chrisname]

Definitely warnings.

[LB]

@first example: isn't that taking the address of the int array (aka the address of the first element in the array) and implicitly converting it to a pointer-to-int? I think that's normal behavior and not the compiler 'fixing' things. At least, for as much array/pointer interactivity I know, I think that's what is happening.

EDIT: first example doesn't even compile under clang++ (error message, not warning)

http://liveworkspace.org/code/3uGj3t$1

@second example: isn't that an optimization by the compiler? Or is it actually supposed to be wrong?

@third example: I agree this should be a warning. EDIT: I agree with Catfish below.

[Catfish3]

These shouldn't be warnings, they should be some sort of auto-improvement information e.g.:

1 2 3 4 5 6

void f(void) { char buffer[4]; sprintf(buffer, "Hello"); // ... }

info: example.cpp:4:5 using snprintf instead of sprintf

That said, how exactly did you find out about these, kbw?

[Catfish3]

@ LB: http://c-faq.com/aryptr/aryvsadr.html

[LB]

Thus the code shouldn't compile (and it doesn't for me in any compiler I tsted so far).

@kbw which compiler did you test the first snippet with? I cannot get any compiler to accept it.

[kbw]

I ran into the first snippet back in the 80s with PC C compilers with my code. I think they all try to fix address of array mistakes.

The others turned up in some project I've been asked to fix.

It's been increasingly frustrating dealing with tools that are not transparent.

[S G H]

L B wrote:

@first example: isn't that taking the address of the int array (aka the address of the first element in the array) and implicitly converting it to a pointer-to-int? I think that's normal behavior and not the compiler 'fixing' things. At least, for as much array/pointer interactivity I know, I think that's what is happening.

I don't think so...

Expand that code to this and tell me what you think:

int arraybuffer[20];
int * array = arraybuffer;
int ** parameter = &array;
int * in_the_function = parameter; // <--- int** to int* ?!? 

[LB]

That code snippet doesn't compile.

kbw wrote:

I ran into the first snippet back in the 80s with PC C compilers with my code.

Why are you using ancient nonstandard compilers?

[S G H]

L B wrote:

That code snippet doesn't compile.

And that's equivalent to the very first code, and that compiles...

kbw wrote:

I ran into the first snippet back in the 80s with PC C compilers with my code.

L B wrote:

Why are you using ancient nonstandard compilers?

kbw wrote:

I ran into the first snippet back in the 80s

:D

[LB]

@EssGeEich: what? The first code snippet doesn't compile either.

Also, I don't see why he's complaining about a problem from 30 years ago that doesn't even happen anymore.

[S G H]

L B wrote:

@first example: isn't that taking the address of the int array [...] and implicitly converting it to a pointer-to-int? I think that's normal behavior and not the compiler 'fixing' things.

Uhm? Did I mis-understand something?

[LB]

You mis-understood that I edited my post with an example showing I was wrong and forgot to cross that out.

[S G H]

Ahh ok then ^^