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

Completely standard. See ISO7185 (standard) and ISO10206 (extended, but compatible with ISO7185). Unfortunately the most popular "Pascal" provider, Borland, did not adhere to the specifications.

about

Of course, you're entirely correct. At the same time, C has been around a long time, and has enough flexibility to allow programmers several ways to get the same task done. It's not surprising that C has developed some quirky idioms over the years.

One can complain about the idioms, or one can be happy that the language allows programmers that much freedom of expression. There's a reason the Pascal/Ada family isn't more widely used.

At the same time, there's probably such a thing as too much freedom of expression - I've had to maintain some extremely disgusting Perl code in my time. In general I just commented the old stuff out and rewrote it in a less idiomatic style.

Kelly

Is that why Borland was wildly popular while "standard" Pascal was an also-ran?

Kelly (ducking)

The C standard makes it clear that !0 is always 1. Why are you trying to avoid relying on the C standard in this matter?

Every C compiler believes, no *knows*, that !0 is 1 in all cases. No exceptions.

This rather lengthy thread just humbly reminds us that "I don't understand it" doesn't necessarily mean "It's badly written".

To go a bit further, just because we don't understand something, doesn't mean that this thing is wrong. Just because it took us hundreds of thousands of years to figure out that the Earth was round, doesn't mean that it should have been flat instead, to save us all some sweating.

And would you be so kind as to quote the corresponding ISO paragraph?

"tanya" wrote in news:bni50t$a11$ snipped-for-privacy@newshost.mot.com:

Unless you are using a nonstandard C compiler, then, by definition, FALSE is 0, and TRUE is 1. Yes, other nonzero values will be treated as true in a conditional test, but, the valye that a boolean expression must return is either 0 or 1. This is by definition of ANSI standard C. Any C compiler you used that did differently was not ANSI C.

This rather lengthy thread just humbly reminds us that "I don't understand it" doesn't necessarily mean "It's badly written".

To go a bit further, just because we don't understand something, doesn't mean that this thing is wrong. Just because it took us hundreds of thousands of years to figure out that the Earth was round, doesn't mean that it should have been flat instead, to save us all some sweating.

"Neil Bradley" wrote in news: snipped-for-privacy@corp.supernews.com:

if (a) statement else statement

This is four lines that I must parse.

lval = cond ? !0 : 0;

This is one line that the brain easily "chunks" in one pass.

I simply disagree with your statement of how many passes it takes to comprehend something as fundamental as the the ternary operator.

Regards.

For relational operators:

For equality operators:

HTH

Similarly you might ask why there are so many Windows systems out there, or why non standards compliant C systems have not survived. Borland supplied something that was cheap, convenient, and fast. It would have been no harder to also make it compliant, but they didn't, probably for marketing (a la MS) reasons. At any rate, this is completely OT here.

Depends what you mean by "type check." For example, given your definition:

BOOL b;

BOOL read() { BOOL retval; retval = 42; return retval; }

int test() { BOOL b; b = read(); return b; }

must compile successfully, and test must return 42. There is nothing wrong with this code as far as the standard is concerned.

The compiler, however, is free to complain about anything it wants to. A clever compiler might recognize that 42 is outside the defined enumerated range for BOOL, and might complain about it. But it's not required to do so. And it can't refuse to compile it.

C99 defines a new type, _Bool, that does what you really want. The standard header stdbool.h typedefs this as "bool" and defines the new keywords "true" and "false".

Regards,

-=Dave

Grant Edwards wrote in news:3f99ae7e$0$41284$ snipped-for-privacy@newsreader.visi.com:

Only if we _know_ our C compiler is compliant to the latest spec. Many compilers, especially 8 bit embedded compilers, evaluate to 0 or

-1, not 0 or 1.

Jeff.

Latest spec??? You must be joking!

Quoting from "The C Programming Language", (c) 1978:

Section 2.6 Relational and Logical operators:

The unary negation operator ! converts a non-zero or true operand into 0, and a zero for false operand into 1.

Section 7.6 Relational operators

The operators < (less than), > (greater than), = (greater than or equal to) all yeild 0 if the specified relations is false and 1 if it is true.

Section 7.7 Equality operators

The == (equal to) and != (not equal to) operators are exactly analogous to the reltional operators except for their lower precedence. (Thus a

What in the world are you talking about, man? The 1/0 thing goes back to the very genesis of C- Kernighan & Ritchie..

K&R 2.6

"By definition, the numeric value of a relational or logical expression is 1 if the relation is true, and 0 if the relation is false."

Best regards, Spehro Pefhany

You left out the operator in question (logical negation, "!"). In n869, thats 6.5.3.3p5:

The result of the logical negation operator ! is 0 if the value of its operand compares unequal to 0, 1 if the value of its operand compares equal to 0. The result has type int. The expression !E is equivalent to (0==E).

Regards,

-=Dave

Yes, and for a simple reason: negation. It's easy to negate a boolean value with a 'NOT' instruction.

NOT 0 = (FF...)FFh = -1

Although, for optimisation reasons, a boolean "true" can be anything that is not 0, not necessarily -1. Might prove useful in some cases.

Not only that, but even on the latest C compiler, any non-zero integer will be treated as a "true" boolean value, which makes the standard a little incongruent in my opinion.

For instance, 'if (a + b)' will be a 'true' condition if a != -b. Of course, (a + b) can be any value, and not just 0 or 1.

Which is why I say: either you use a boolean type, in which case you know what to expect, or you use an integer type. Mixing the two can be a bit confusing.

'a == b' evaluates to a boolean type. But using a boolean value as an integer is kinda risky. That's my opinion. That's why expressions like 'c = (a == b)' are perfectly ok in my eyes, but stuff like 'c = (a == b) + d' is not.

What really happens though is that "a+b" is an integer, and the expression wants a boolean. The computer then applies builtin integer-to-boolean conversion rules with no typecasting required. Ie, "5" is not a boolean value, but it is trivally cast to a boolean.

This is analogous to adding a 'char' to an 'int'; the char is trivially converted to an int before the addition is done.

Can you name one? I can't. And I use some weird ones...

I'm not sure what your point is here.

If you want all 1's, use the bitwise negation operator (~) rather than the logical negation operator. But there are other dangers. Note that !2 == !1, but ~2 != ~1. That's one reason why we have both logical and bitwise flavors of & and |.

If you're talking about assembly language efficiency, it depends on the underlying processor architecture. It's nearly or exactly as efficient to use XOR with 1.

it find to where know you Forth, want you If.

The committee had two choices: Have a single "true" value and everything else is "false", or have a single "false" value and everything else is "true." I think they made the right choice, especially in the face of existing C implementations. You may disagree.

More often, this feature is used in an expression like "if (mask & 0x18)" which will be "true" if either (or both) bits 3 and

In C, the result of a relational or logical operator has type int. There's no mixing. Unless you count the promotion of a _Bool to an int in the usual integer promotions...

Not in C.

Cute. I wouldn't recommend it, but it's perfectly clear. I haven't seen anybody advocate that sort of code, however...

Regards,

-=Dave