Thread: tertiary comparison

>I can't think of any strictly 'bad' value for a char
That's because you really won't see it on a two's complement architecture. Imagine a machine that uses a binary representation where there are two distinct representations for zero. When viewed as signed char, you can't tell the difference between the bit patterns of negative zero and positive zero. One of those zeros could be a trap representation. The solution on such an architecture would be to use unsigned char where the bit patterns are easily distinguished.

>I feel like I'm in school, and the teacher just made a mistake that she's trying to cover up
Yet you aren't really sure if that's the case or the teacher is just good at playing you. In truth, I wasn't expecting you to notice. But I was hoping you would so that I could give the speech about striving for excellence that I had been keeping in reserve for just such an occasion.

>>you really won't see it on a two's complement architecture
I've heard of one's complement before...

>>you can't tell the difference between the bit patterns of negative zero and positive zero. One of those zeros could be a trap representation.
*lightbulb goes on* So how would trap representations be used? Or are they just an unwanted sideeffect?

>>Yet you aren't really sure if that's the case or the teacher is just good at playing you.
Of course not. If I knew she was playing me, that would take all the satisfaction out of it

>>the speech about striving for excellence that I had been keeping in reserve for just such an occasion.
Lesson #2: Always have a backup plan. I'll remember that too

Originally Posted by bithub

Yes you can. C++ would complain about doing that, but C wouldnt.

No you can't:

C: A Reference Manual, 5th Edition
Page 137

5.3.1 Generic Pointers, pharagraph two:

Standard C introduces the type void * as a "generic pointer." It has the same repre-
sentation as type char * for compatibility twith older implementations, but the language
treats it differently. Generic poitners cannot be dereferenced with the * or subscripting
operators, nor can they be operands of addition or subtraction operators. Any pointer to an
object or incomplete type (but not to a function type) can be converted to type void * and
back without change. Type void * is considered to be neither an object pointer nor a func-
tion pointer.

I'm sure Prelude or someone will be along with the direct quote from the standard,
but this works for me.

Quzah.

Don't confuse "guaranteed by standard" with "my compiler does this"

Compiling your code like this, gets a warning

Code:

$ gcc -W -Wall -ansi -pedantic hello.c
hello.c: In function `main':
hello.c:11: warning: pointer of type `void *' used in arithmetic

>Internally they are represented the same (Just a pointer to a location in memory).
I challenge you to prove that this is the case on every possible system that supports C.

>If that's true does GCC not follow the standards then?
It depends on what switches you use to compile.

>plus there is always the exception which disproves the rule
Well, technically the rule is that function pointers aren't required to have the same representation as object pointers. But I think you get the point, so I'll lay off it.

>Just out of curiousity, why doesnt gcc use the C standards by default?
I have no idea. I would assume that it's because GCC tries to be a lot of things to a lot of people. And the majority of programs make good use of non-standard extensions. Of course there's the risk of somebody being raised to believe that the extensions are blessed by the language standard, and that's where problems arise.

>I've been guilty of that before
Me too. That's one reason why I'm so hard on people who use non-portable constructs out of habit. I've been there, got better, and realized how much easier programming is when you adhere to the standard as much as possible.