Um, no. Fron n869 6.8.4.1 (The if statement) paragraph 2 (semantics)
In both forms, the first substatement is executed if the expression compares unequal to 0. In the else form, the second substatement is executed if the expression compares equal to 0.
There is no typecasting. Until C99, there is no boolean type. Even in C99, values of type _Bool are promoted (to int in most cases) before any operators can be applied. E.g., given
_Bool b;
if (b != 0)
The value of b is first promoted to int (by the usual arithmetic conversions) before being compared to (the int constant) 0. Even with
if (b != (_Bool)0)
The zero is cast to _Bool, which is then promoted to int. In all cases, the result of the != operator has type int.
The issue isn't the # of lines, but the readability and flow. It's *EASY* to miss a question mark. It 'aint easy to miss the above even though it's more verbose.
As one who integrates code from 4 different groups around the world (a total of 30 engineers), I'll show you quite a few who would completely blow that statement.
Never said it was hard to comprehend. I said it was easy to miss. Burying a question mark in the middle of an expression is just a bad idea.
From the current C standard ANSI/ISO/IEC 9899-1999:
6.3.1.2 Boolean type § 1
When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1.
6.5.3.3 Unary arithmetic operators § 5
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).
6.5.8 Relational operators § 6
Each of the operators < (less than), > (greater than), = (greater than or equal to) shall yield 1 if the specified relation is true and 0 if it is false.89) The result has type int.
6.5.9 Equality operators § 3
The == (equal to) and != (not equal to) operators are analogous to the relational operators except for their lower precedence.90) Each of the operators yields 1 if the specified relation is true and 0 if it is false. The result has type int. For any pair of operands, exactly one of the relations is true.
6.5.13 Logical AND operator § 3
The && operator shall yield 1 if both of its operands compare unequal to 0; otherwise, it yields 0. The result has type int.
6.5.14 Logical OR operator § 3
The || operator shall yield 1 if either of its operands compare unequal to 0; otherwise, it yields 0. The result has type int.
The boolean type _Bool was added in the 1999 revision, but the rest has been the same since Kernighan and Ritchie published the first edition of "The C Programming Language", i.e. long before the first C standard.
It's clear that one of the values should be 0 because testing for zero is virtually always a fast operation in machine code. Whether you choose 0 for TRUE or FALSE is a matter of taste.
A language that emphasized other things than speed and simplicity might choose to interpret anything other than 0 or (say) 1 as an invalid state and deal with it as such, but that is not in the C philosophy.
With C you *can* write legitimate warning-free stuff like: c += a = ++a == b++;
It might even make sense (at the time).
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
You can write lots of legitimate code that looks strange, but this one is not legitimate, it invokes undefined behaviour. The example statement updates the variable ``a'' twice without an intervening sequence point.
From ANSI/ISO/IEC 9899-1999:
6.5 Expressions § 2
2 Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.70)
70) This paragraph renders undefined statement expressions such as i = ++i + 1; a[i++] = i; while allowing i = i + 1; a[i] = i;
No. Even the C compiler isn't required to make sense of it.
Well, you can write it, and it need not generate a diagnostic, but it's not legitimate. It invokes undefined behavior. The variable a is modified twice between sequence points.
However,
c += d = ++a == b++;
would work to illustrate your point. And as you say, might even make sense at the time, though it wouldn't get through my code review without at least one, and most likely two sets of parentheses...
Good point. One would need to add a "," in there to make it valid C. I was under the (mistaken) impression that "==" was guaranteed to provid a sequence point (as || and && do).
(It does happen to compile without warnings and do what you'd expect with a few compilers I tried it on, FWTF*T*W- NM). Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
NO it isn't. Any non-zero value is true. 0xF0 is "true". Doing a 1's compliment on that results in 0x0F: also true. Using 1's compliment to impliment "!" is quite simply NOT C.
--
Grant Edwards grante Yow! Where's th' DAFFY
at DUCK EXHIBIT??
visi.com
If we replace "==" with "||", it would put a sequence point at the end of the first operand to "||".
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Or we could just write readable code and leave the games at the door with the "most obtuse C code" competition every year. Really guys, writing obscure code does not make it run faster, in fact, often just the reverse.
I've seen for{} loops written where all the processing occurs in the () section and nothing in the {} brackets - Who the heck is that code for? It sure isn't for the poor sot that has to support it!
Look at your architecture, write your code the way your processor works and stop trying to play "stump the chump" with the compiler. With embedded work, you'll often get better performance and smaller code size.
IMO, DLC
: :>In article , :>Spehro Pefhany wrote: :>
:>> >> c += a = ++a == b++; :>
:>> Good point. One would need to add a "," in there to make it valid C. :>> I was under the (mistaken) impression that "==" was guaranteed to :>> provid a sequence point (as || and && do). :>
:>That would not help. Placing a sequence point at ``=='' does :>not insert a sequence point between the ``a ='' and ``++a'' :>in ``a = ++a''.
: If we replace "==" with "||", it would put a sequence point at the end : of the first operand to "||".
: Best regards, : Spehro Pefhany : -- : "it's the network..." "The Journey is the reward" : snipped-for-privacy@interlog.com Info for manufacturers:
formatting link
: Embedded software/hardware/analog Info for designers:
formatting link
--
============================================================================
* Dennis Clark dlc@frii.com www.techtoystoday.com *
* "Programming and Customizing the OOPic Microcontroller" Mcgraw-Hill 2003 *
============================================================================
I though that was the document that everyone was quoting? What other document is the C standard (except perhaps the 9899:1990 which many compilers still use)
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org
The document known as n869 is a committee draft of the ISO/IEC 9899:1999 standard document. The n869 draft was created early in 1999 and was available for a while from the C standards working group as a free download. Several changes were made between the n869 draft and the final standard.
Some people still quote from the obsolete n869, perhaps because it can be downloaded from the net (not officially), they like to create confusion, or are too poor to spend, IIRC, US$14 to buy the real document.
The 9899:1990 is no longer current and has been retracted. It consisted of:
This is correct except that BSI has made ISO/IEC 9899 TCOR2 (technical corrigendum 2, 1996) available again simply because a lot of compilers still work to is and are not moving to C99. Also there are quite a few standards that still reference C90 specifically. As many of these are in the embedded, safety critical and high integrity areas companies are required to have copies of the base standards.
AFAIK there are currently only 2 compilers claiming C99 compliance anyway.
However any one who starts quoting a committee draft is asking for trouble!!
Regards Chris /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org
The reason for making the ISO/IEC 9899:1990 series available again was that the current C++ standard refers to 9899:1990. That does not make it a valid C standard, only an apendix to the C++ standard. :-)
That is why it was made available again. It has still been superseeded by the 9899:1999 standard.
True. There is a reason why it was removed from the website run by the working group.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.