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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Question About Strange 'C' Code Syntax ( Well strange to me anyway )
writes
Quoted text here. Click to load it

You are wrong on this.

Quoted text here. Click to load it

Not at all. It is a valid C standard. It is just an obsolete standard.

Quoted text here. Click to load it

Yes. It was nothing to do with the C++ standard.

Quoted text here. Click to load it

Yes.


We agree on that.


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ snipped-for-privacy@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Question About Strange 'C' Code Syntax ( Well strange to me anyway )
Quoted text here. Click to load it


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),
    <= (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.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.

--
Göran Larsson     http://www.mitt-eget.com /

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

Quoted text here. Click to load it

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

Re: Question About Strange 'C' Code Syntax ( Well strange to me anyway )
On Sun, 26 Oct 2003 14:29:22 -0800, "Neil Bradley"

[...]
Quoted text here. Click to load it

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
--
Change is inevitable, progress is not.

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

Quoted text here. Click to load it

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

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

--
Linux Home Automation         Neil Cherry         snipped-for-privacy@comcast.net
http://home.comcast.net/~ncherry/ (Text only)
We've slightly trimmed the long signature. Click to see the full one.
Re: Question About Strange 'C' Code Syntax ( Well strange to me anyway )

Quoted text here. Click to load it



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                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
We've slightly trimmed the long signature. Click to see the full one.
Re: Question About Strange 'C' Code Syntax ( Well strange to me anyway )
:
:> 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

--
Remove '.spaminator' and '.invalid' from email address
when replying.


Re: Question About Strange 'C' Code Syntax ( Well strange to me anyway )
On Thu, 23 Oct 2003 18:08:15 +0000 (UTC), the renowned

Quoted text here. Click to load it

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's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Question About Strange 'C' Code Syntax ( Well strange to me anyway )

:
: 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


Re: Question About Strange 'C' Code Syntax ( Well strange to me anyway )
snipped-for-privacy@ieee.org.invalid wrote in

Quoted text here. Click to load 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

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

which is not good in C.
 
Quoted text here. Click to load it

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

--
- Mark ->
--

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

:> 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

--
Remove '.spaminator' and '.invalid' from email address
when replying.


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

:> 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

--
Remove '.spaminator' and '.invalid' from email address
when replying.


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

Quoted text here. Click to load it

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.
--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Question About Strange 'C' Code Syntax ( Well strange to me anyway )
Quoted text here. Click to load it

Your not going to get very far in embedded engineering if you keep using
that line. BTW which compiler do you know that are 9899:1999?

Embedded compilers do a lot of non standard things. Especially in the 8
bit areas.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ snipped-for-privacy@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Question About Strange 'C' Code Syntax ( Well strange to me anyway )
On Fri, 24 Oct 2003 17:51:38 +0100, the renowned Chris Hills

Quoted text here. Click to load it

I've gotten just about far enough, thanks. ;-)  The point is it's
"supposed" to be an int, from K&R I to present. It indeed probably is
a char in PIC compilers.  

Quoted text here. Click to load it

True, such as probably using a smaller scalar integral type, in this
case.

Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Question About Strange 'C' Code Syntax ( Well strange to me anyway )

Quoted text here. Click to load it


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.

Quoted text here. Click to load it

It's not compiler specific.  It's an int by definition.
--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

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

Quoted text here. Click to load it


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?

Quoted text here. Click to load it

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

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

Paul Burke


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

Quoted text here. Click to load it

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;

--
- Mark ->
--

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

: 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

--
Remove '.spaminator' and '.invalid' from email address
when replying.


Re: Question About Strange 'C' Code Syntax ( Well strange to me anyway )
snipped-for-privacy@ieee.org.invalid wrote in

Quoted text here. Click to load it

No need, ?: is near the bottom of the precedence barrel, == (much higher
in precedence) gets evaluated first, then the trinary goes to work,
finally the lowly assignment operator. Only the sequence operator (,) is
below assignment.

--
- Mark ->
--

Site Timeline