I have code written under the CCS 'C' Compiler to run on a PIC microcontroller.

Code Extract:

-------------------------------
char a,b,c;
-------------------------------
c = ( a == b );
-------------------------------

It also uses this syntax in "Function Calls" thus:

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

===========================================

Question:

What does this mean as my Hi-Tech 'C' Compiler doesn't understand it either?

===========================================

Harvey Twyman
About Me: http://www.Twyman.org.uk/CV

===========================================

Harvey Twyman wrote:
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:

<return type> function(char);
....
function (a == b);
....
<return type> 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?

On 23 Oct 2003 08:51:13 -0700, Harvey Twyman wrote:

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 ncherry@comcast.net
http://home.comcast.net/~ncherry/ (Text only)
http://linuxha.sourceforge.net/ (SourceForge)
http://hcs.sourceforge.net/ (HCS II)

In article <6d32c0e5.0310230751.cf14f13@posting.google.com> , Harvey Twyman wrote:

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??
visi.com

Grant Edwards <grante@visi.com> wrote:
: In article <6d32c0e5.0310230751.cf14f13@posting.google.com> , 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

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

On Thu, 23 Oct 2003 18:08:15 +0000 (UTC), the renowned
buddy.spaminator.smith@ieee.org.invalid wrote:

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"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

Spehro Pefhany <speffSNIP@interlogdotyou.knowwhat> wrote:

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

buddy.spaminator.smith@ieee.org.invalid wrote in
news:bn97mf$9gp$1@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.

--
- Mark ->
--

On 23 Oct 2003 16:03:25 GMT, garykato@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.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

Mark A. Odell <nospam@embeddedfw.com> wrote:

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

Mark A. Odell <nospam@embeddedfw.com> wrote:

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

"Jack Klein" <jackklein@spamcop.net> wrote in message
news:<323hpvgbn1fh990pdu04popvlcvned4of7@4ax.com>. ..

I always use:

#define FALSE 0

#define TRUE (!FALSE)

Tanya

Harvey Twyman wrote:


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

On Fri, 24 Oct 2003 13:54:46 +0930, the renowned "tanya"
<tanya.anne@bigpond.com> wrote:

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

buddy.spaminator.smith@ieee.org.invalid wrote:

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 (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

buddy.spaminator.smith@ieee.org.invalid wrote:

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

Paul Burke <paul@scazon.com> wrote in
news:bnalf2$ut6qj$1@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;

--
- Mark ->
--

"tanya" <tanya.anne@bigpond.com> wrote in
news:bna9lk$1ij$1@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?

--
- Mark ->
--

Mark A. Odell <nospam@embeddedfw.com> wrote:

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