Pascal Schmidt wrote in a message to Roy J. Tellason:

 PS> Hi Roy! :-)

 RJT> Not necessarily ASCII,  but whatever "char" is that's
native to the 
 RJT> platform you're running on.  If it was EBCDIC,  then they're 8-bit 
 RJT> characters.

 PS> I don't think there is any C compiler where a char has more or less
 PS> than 8 bits.

I wouldn't know about that,  but that wasn't the issue anyway,  you said
"7" bits,  which is what "ASCII" is.  Not the extended
character sets we all seem to be using these days,  ASCII.  :-)

 PS>> Anyway, if your code depends on it being one way or the other, make
 PS>> it explicit by using "signed char" or "unsigned
char".

 RJT> I just wish that some folks would _do_ that when they write 
 RJT> stuff,  instead of it being the default for whatever the case may 
 RJT> be.  Like using a "long" to represent the quantity of free space 
 RJT> on a hard drive.  That number is _never_ going to go negative,  
 RJT> so "unsigned" should be in there too,  but enough programmers 
 RJT> left it out (laziness? some other reason?) that >2G drives break 
 RJT> an awful lot of software.  Or did,  anyhow,  under dos for one 
 RJT> example.

 PS> That's one example where it is really critical. Most of the time it
 PS> doesn't really matter - it's not that often that you need the full
 PS> 32 bits of an int. For file sizes or free space on partition I'd
 PS> use a 64 bit variable anyway,  even 4 GB is two small for today's
 PS> systems.

Sure.  But my point is,  if you're dealing with a number that's _never_
going to go negative (because such a thing wouldn't make any sense) then
isn't it good practice to say so,  in the source code?

 PS> Note that the size of a long changes depending on the target CPU
 PS> (at least in gcc) - for 32 bit archs, a long is 32 bits (and an int
 PS> as well). For 64 bit archs, long is 64 bits and int is 32 bits.

Yep,  nothing's quite nailed down unless you start fiddling around with
sizeof and similar nonsense.  :-)

---