1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

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

Discussion in 'Embedded' started by Harvey Twyman, Oct 23, 2003.

  1. Harvey Twyman

    tanya Guest

    But then you are assuming that TRUE == 1, which I was trying to avoid.

    Not that that is an unreasonable assumption (in most cases), but the #define
    version should work on any supposed C compiler, even if it believes that
    TRUE is -1.

    Kind regards,

    Tanya
     
    tanya, Oct 27, 2003
    #41
    1. Advertisements

  2. Harvey Twyman

    CBFalconer Guest

    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.
     
    CBFalconer, Oct 27, 2003
    #42
    1. Advertisements

  3. Harvey Twyman

    Kelly Hall Guest

    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
     
    Kelly Hall, Oct 27, 2003
    #43
  4. Harvey Twyman

    Kelly Hall Guest

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

    Kelly (ducking)
     
    Kelly Hall, Oct 27, 2003
    #44
  5. 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.
     
    Goran Larsson, Oct 27, 2003
    #45
  6. Harvey Twyman

    Guillaume Guest

    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.
     
    Guillaume, Oct 27, 2003
    #46
  7. Harvey Twyman

    Guillaume Guest

    Every C compiler believes, no *knows*, that !0 is 1 in all cases. No
    And would you be so kind as to quote the corresponding ISO paragraph?
     
    Guillaume, Oct 27, 2003
    #47
  8. Harvey Twyman

    Richard Guest

    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.
     
    Richard, Oct 27, 2003
    #48
  9. Harvey Twyman

    Guillaume Guest

    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.
     
    Guillaume, Oct 27, 2003
    #49
  10. [snip]
    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.
     
    Mark A. Odell, Oct 27, 2003
    #50
  11. Harvey Twyman

    Morris Dovey Guest

    For relational operators:

    6.5.8.6 Each of the operators < (less than), > (greater than), <=
    (less than or equal to), and >= (greater than or equal to) shall
    yield 1 if the specified relation is true and 0 if it is false.
    The result has type int.

    For equality operators:

    6.5.9.3 The == (equal to) and != (not equal to) operators are
    analogous to the relational operators except for their lower
    precedence. 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 these relations is true.

    HTH
     
    Morris Dovey, Oct 27, 2003
    #51
  12. Harvey Twyman

    CBFalconer Guest

    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.
     
    CBFalconer, Oct 27, 2003
    #52
  13. Harvey Twyman

    Dave Hansen Guest

    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
     
    Dave Hansen, Oct 27, 2003
    #53
  14. Harvey Twyman

    daworm Guest

    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.
     
    daworm, Oct 27, 2003
    #54
  15. 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), <= (less than or equal
    to), and >= (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<b == c<d is 1 whenever a<b and c<d have the same
    truth-value).
    They're broken or they're not C compilers. Take your pick.
     
    Grant Edwards, Oct 27, 2003
    #55
  16. 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
     
    Spehro Pefhany, Oct 27, 2003
    #56
  17. Harvey Twyman

    Dave Hansen Guest

    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
     
    Dave Hansen, Oct 27, 2003
    #57
  18. Harvey Twyman

    Guillaume Guest

    Only if we _know_ our C compiler is compliant to the latest spec.
    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.
     
    Guillaume, Oct 27, 2003
    #58
  19. 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.
     
    Darin Johnson, Oct 27, 2003
    #59
  20. Harvey Twyman

    Dave Hansen Guest

    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
    4 are set in "mask."
    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
     
    Dave Hansen, Oct 27, 2003
    #60
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.