macOS C is platform specific?

ChrisA said:

I just fixed an obvious bug in a C program

Code:

if ( 'R' == name[0] != 'R')

I changed the above to read

Code:

if ( 'R' != name[0])

But the odd thing was that it worked differently depending on the platform it was compiled on. What does the ANSI C standard say? Could the gcc compiler have "optimized" this? I'm using various versions of gcc depending on the OS. I caught the bug on a Solaris 8 using gcc v3. Very odd that I should see different behavior on different platforms

Click to expand...

The code you changed it to is correct C (at least as I have ever learned). The other one looks like old-style C, but doesn't make any sense. It is not really platfrom specific, but compiler specific. GCC compiles things differently than CC, gcc fixed some problems, while breaking some 'tricks' that programmers used.

C in general is not Platform specific, the compilers are, and have to do things differently for different platforms. So some things work on one platform, because of the age of the compiler, others don't because it is not implemented yet in another compiler. Same thing happens with the JVM, something will work on one platform, but won't on another because it hasn't had that piece implemented yet (common for programs written for JAVA Unix, and trying to run on Mac JAVA or Windows JAVA, even though Windows Java is done by the same company).

TEG

Since != and == have the same precedence, we have to fall back to their associativity. In this case, it's right to left. So if we parenthesized your original statement it would be:

So first, would be evaluated. This would evaluate to 0 or 1 (sorry, I don't have the standard in front of me. I know for false it would be 0, and believe very strongly that true will evaluate to 1).

So next, either:
or

would be evaluated. This is where it gets tricky. The compiler will have to make an implicit cast as a char literal and the result of a boolean operator are not the same type. If 0 or 1 are cast to a char, then you are comparing:
or

This will always be false. However, if 'R' was cast to a "logical" (this isn't a type, but the compiler might be filling in some gaps for you) it is non-zero, so it would evaluate to true/logical 1. So then you would have:
or

So now this expression will evaluate to false/0 if name[0] != 'R' is false/0 or true/1 if name[0] != 'R' is true/1. In this situation, the statements would collapse to:

which is what you intended in the first place. Another option that I won't suss out completely is the compiler implicitly casting 'R' to an int, which would be 82. This compared to 0 or 1 would always be false just as if 0 or 1 were cast to a char.

Since I don't have the standard available I can't say which is "correct", but it may not be specified so this may be up to the interpretation of the compiler. The only time you would have gotten what you wanted was if, for logicals, the compiler tried to enforce != 0 strictly.

Such is the shortfall of a language without a boolean type.

Sorry this couldn't be more definitive, but hopefully it's at least somewhat enlightening in terms of the possibilities for the compiler's behavior. If you really want to see what gcc is doing, hand it a -S switch. I would try to isolate the offending code to make the resulting ASM easier to read.

-Lee

TEG is on point here.

My 2 cents.....

This looks like an edited fragment that really 'said' something else in some previous version, more like

if ( 'R' == name[0] && x[0] != 'R' ) ....

Of course, I'm inventing a proposed array x here to suggest there must have been something else on the mind of the writer at some point, where different tests were involved, and the '&& x[0]' was deleted without finishing through the second 'R'.

Now, the construct you have makes little sense to the compiler, because by the time 'it gets to' (we tend to anthropomorphize the machine don't we) the !=, the result of the first comparison (the ==) is a boolean, which can't promote to a value that correctly compares against an 'R'. That is, no result from the == test CAN compare to an 'R', so it will always be "!= 'R'" no matter how the first test came out - it will be true or false, comparing to a binary 0 or 1 in most compilers, but it could never be an 'R'.

There was a time when bool was not a 'formal' type in C. We often used some macro BOOL defined as an unsigned int or int, but it wasn't a 'built in' type. It has since become one, and so on different compilers the 'understanding' of the compiler differs. In all cases the result of the first == test is true or false, but if the built in type CAN'T be a bool, because the compiler is older and doesn't really 'think' in bools, it might not warn and the behavior might be errant.

On more recent compilers you will be warned, depending on your verbose settings, about the problem with the promotion. This can happen between compiler versions on the same platform (in line with TEG's point).

I bother to go this far to make a summary point. Portability is more important now than ever before. Whatever software we make, it is likely we'll have more customers if we consider portability when we write, and this kind of realization is exactly the stuff you have to think about when portability comes up - just what is common among the platforms and compilers, and which compilers should be choose to help portability.