Thread: Why so..

Originally Posted by joybanerjee39

it works fine with my pelles c !

Fascinating. A difference in version, perhaps?

Originally Posted by CommonTater

However... the code itself is probably what the picky police here would call "undefined behaviour" since you are messing with the root pointer to a string...

I think the behaviour is well defined. b is merely a pointer to a char, like any other. Incrementing it then decrementing it is not a problem. Undefined behaviour would come if we attempted to modify what b pointed to, but that does not happen here. Futhermore, there are three separate statements, so there is no problem with doing too much within consecutive sequence points.

EDIT:

Originally Posted by juice

Thanks... Its working now.. I wonder what was wrong.

Maybe you have discovered an optimisation bug in your version of Pelles C.

Originally Posted by CommonTater

However... the code itself is probably what the picky police here would call "undefined behaviour" since you are messing with the root pointer to a string...

Aside from the lack of return (which I think is allowed in C99), there's nothing undefined here. Rightly, laserlight's example is the most idiomatic, with it's use of return 0 and const.

Originally Posted by juice

whats wrong with "Max. speed"

It could be - as CommonTater noted, I am just speculating - that with optimisations enabled, Pelles C makes some assumptions about a pointer to the first character of a string literal that do not hold if the pointer is modified, under certain circumstances. This would be consistent with that warning #2238 since a negative index is out of bounds. It would also be consistent with the output that you saw since "junk" memory often contains zeroes, so you could be printing a "null character" that is just before the character at index 0 of the string literal.

Originally Posted by CommonTater

However... the code itself is probably what the picky police here would call "undefined behaviour" since you are messing with the root pointer to a string...

I don't think the standard has any conception of "root pointer", so this should not be UB. Trying to move this:

Code:

char b[]="asdf";

would an error tho, since b is not a true lvalue.

Originally Posted by CommonTater

Please don't do that.... you aren't helping!

If by speculating so that we are aware of the possibility that we are looking at a certain variety of compiler bug is not helping, then I am afraid that none of us are helping

Originally Posted by CommonTater

This is not an opportunity to trash on Pelles C

Err... compilers are programs written by humans. Humans err, thus bugs are to be expected, so no, if it is genuine, and thus far it looks like it, identifying a bug is not tantamount to trashing Pelles C.

Yes, I know that you are a fan of Pelles C, but notice that I am taking this cautiously too because I expect bugs in a reputable compiler to be rare, hence I am calling it speculation whereas I could take the current evidence at face value and declare with certainty that there is a compiler bug.

EDIT:

Originally Posted by CommonTater

You appear to have stumbled into an optimization bug in Pelles C.
I am trying to write code to fully demonstrate the problem and will
forward a report directly to Pelle about it.

You are speculating too! Refer to my code in post #9 for a program that will "fully demonstrate the problem", if juice's observation is correct.

IMO, Saying that the compiler makes incorrect assumptions about pointers to the beginning of a string is speculation. Saying that the compiler has a bug is not. Neither are trashing the compiler.