Question About Strange 'C' Code Syntax ( Well strange to me anyway )

The equality operator, "==", compares two values and returns a int value of 1 if they are the same and 0 if different. This is standard C that should be in any implementation. I suggest getting a C reference book for these and similar questions.

When used with a function that takes type char, the result of (a==b), of type int, is converted to the type defined by the prototype. If you don't have a prototype in scope when the function is invoked, then later define it, as implied by your use and declaration of "function" above, you may get an error for redeclaration of the function with different parameter type. To fix the problem, declare the prototype before use:

function(char); ... function (a == b); ... function (char x) { ... }

where you explicitly specify the return type -- void, char, int, whatever.

Thad

The statment is equivalent to:

if (a ==b) c = TRUE; // TRUE is non-zero, usually 1 or -1 else c = FALSE; // FALSE should be zero

I'm guessing your C compiler probably is giving you some sort of warning about type compatability?

I think this is the best translation I can think of:

if(a == b) { c = 1; // true } else { c = 0; // false }

If your C compiler doesn't understand that code then the comiler is broken, and you should get your money back. That's plain vanilla standard C that's been legal for 20+ years.

Grant Edwards wrote: : In article , Harvey Twyman wrote: : :> c = ( a == b ); : :> function ( a == b ); : :> What does this mean as my Hi-Tech 'C' Compiler doesn't understand it either? : : If your C compiler doesn't understand that code then the comiler is broken, : and you should get your money back. That's plain vanilla standard C that's : been legal for 20+ years. :

I would agree with the poster who suggested that he probably hasn't prototyped the function...

Another, more correct way to do this is:

function((char) a==b);

or char a,b,c;

c = (char) (a ==b); /* If a and b are equal, c is one. else, c is zero */ function(c); /* one should also use better variable names.... */

That will implicitly cast the int 'a==b' to char. I'm not entirely sure 'a==b' is an int. it might be an unsigned int, or a short, or.... more than likely that's compiler specific, but doesn't really matter :)

However, this is bad code, and should be either well commented or replaced with something more readable.

--buddy

It is supposed to (according to ISO/IEC 9899:1999 (E)) be an int, of value 0 or 1, so there is no explicit casting required to char. One of those funny PIC compilers (CCS?) has 8 bit ints, which is deeply wrong, but there ya go..

Best regards, Spehro Pefhany

: : It is supposed to (according to ISO/IEC 9899:1999 (E)) be an int, of : value 0 or 1, so there is no explicit casting required to char. One of : those funny PIC compilers (CCS?) has 8 bit ints, which is deeply : wrong, but there ya go.. :

Not required, but the compiler will probably generate a warning without it.

I believe in writing code that passes 'lint' with flying colors... :)

(I also tend to use gcc -Wall -pedantic when compiling for x86/etc architectures)

ttyl,

--buddy

snipped-for-privacy@ieee.org.invalid wrote in news:bn97mf$9gp$ snipped-for-privacy@news-int2.gatech.edu:

It should not if it is legal C. E.g.

char *pMem = malloc(512);

should not cause a warning even if you "like" to write

char *pMem = (char *) malloc(512);

which is not good in C.

Be sure to add -O so -Wall can do more for you.

On 23 Oct 2003 16:03:25 GMT, snipped-for-privacy@aol.com (Gary Kato) wrote in comp.arch.embedded:

A true conditional always produces a value of 1 in C when that value is examined numerically. -1 is not an option.

:> Not required, but the compiler will probably generate a warning without :> it. : : It should not if it is legal C. E.g. : : char *pMem = malloc(512); : : should not cause a warning even if you "like" to write :

(after testing this, it appears you are correct, at least with GCC. it's still nicer to cast stuff explicitly (IMO... note that you MUST explicitly cast something into a (void *) pointer, a la realloc, etc.

ttyl,

--buddy

:> Not required, but the compiler will probably generate a warning without :> it. : : It should not if it is legal C. E.g. : : char *pMem = malloc(512); : : should not cause a warning even if you "like" to write :

(after testing this, it appears you are correct, at least with GCC. it's still nicer to cast stuff explicitly (IMHO)... note that you MUST explicitly cast something into a (void *) pointer, a la realloc, etc.

ttyl,

--buddy

I always use:

#define FALSE 0

#define TRUE (!FALSE)

Tanya

As others have pointed out, this is the same as

if(a==b) c = TRUE; // TRUE and FALSE are #defined elsewhere else c = FALSE;

But why did they write it like that? Perhaps they thought that, by writing it in terse language, the compiler would produce smaller code?

Is your Hi-Tech compiler designed for the original K&R C? That required functions like this:

function(x) char x; { ...}

Paul Burke

Perhaps so, but the expression (a == b) is an int with value 0 or 1 for conforming compilers. See 6.5.9 in ISO/IEC 9899:1999 (E).

Best regards, Spehro Pefhany

Wrong. The *only* case in C for which there's reason to cast something to (void *) explicitly is if you pass it as an argument to a function without a prototype --- which, in properly written C of these days, should only ever happen if it's part of a variable argument list, e.g. to printf().

Now, C++ would be different, but that shouldn't be a surprise to anybody who hasn't been brainwashed by all those stupid books into believing that there is a language called "C/C++" which you can program in.

Put together, these mean that cases of (void *) casts in code signal it is either disguised C++, bad C, archaic C, or a rather special case that should have been commented accordingly.

No. That's not more correct than anything --- it's the wrong approach to solving an apparent problem whose reason is either a broken compiler or a lack of prototype declaration. In other words, it's a hack, not a solution.

It's not compiler specific. It's an int by definition.

Paul Burke wrote in news:bnalf2$ut6qj$ snipped-for-privacy@ID-128611.news.uni-berlin.de:

How about because it is concise and clear? This is not an uncommon C idiom that we should all recognize. However, this particular case is exactly what the trinary operator is intended for, e.g.

c = a == b ? !0 : 0;

"tanya" wrote in news:bna9lk$1ij$ snipped-for-privacy@newshost.mot.com:

Silly. Since 0 is *always* evaluated as false and !0 is *always* evaluated as true why introduce manifest constants that risk undef/ifdef to another possible value?

: c = a == b ? !0 : 0;

Where's a good gun when i need it....

you should at LEAST use ( ) around that...

c = (a ==b ? 1 : 0), or even better... c = ( a == b ? TRUE: FALSE) , or maybe c = (0 == a ^b) /* HA HA, EVEN MORE EVIL! */

hm... more evil: c = a; c ^=b;

Of course, i personally love the ternary operator. It's one of the more useful constructs that beginners have trouble using. I use it quite often, and don't consider it to be obfuscating at all.

--buddy