OT: Language for the ages

[Fred Cisin]

On Mon, 17 Oct 2005, Eric J Korpela wrote:
> I'm not sure what you mean about CR-LF line endings being a problem for C.
> For text files the character '\n' returns the appropriate ending, whether it
> is CR-LF, CR, or LF. For binary files you shouldn't need to write carriage
> returns.

... and transferring a text file from one OS to another, . . .
does CR mean \n, or is it being used for overstrike?
does LF mean \n, or is it being used for formatted tables?
does CRLF mean \n, or is it double spacing?

> Integral types in C aren't difficult. They are just flexible, and because
> they are flexible, you need to know the rules.

"rules"???????
Who's rules?  K&R very strenuously avoids defining the sizes.

> A char needs to be able to hold at least 127 unique values which makes it at
ONLY IF YOU'RE USING ASCII

> least 7 bits with one allowed "non-unique" value (for example +0 and -0
> allowed to have different bit patterns but compare equal, or a value can be
> reserved for other purposes (signaling, I/O, etc)). That makes it a bit
> different from the other integral types which are required to behave in
> standard two's compliment fashion. Regardless of the number of bits or
> machine words used to store a char, the size of a char is 1
> (sizeof(char)==1). If you want to know the number of "bits" in a char,
> there's always the CHAR_BIT macro. Whether char is unsigned or signed is
          ^^^^^^
NOT all compilers have that macro.

> implementation dependent. If you need one or the other use "signed char" or
> "unsigned char".
>
> An int needs to hold at least 65536 unique values (-32768..32767) (16 bits).
NOT NECESSARILY.
There HAVE been implementations of 12, 14, 15 bits.

> I believe that it is required to be at least as large as a char. An unsigned
> long needs to be able to hold the values between 0 and 65535. Arithmetic
> must behave as if the numbers are stored as two's compliment [ (x | -1) ==
> -1 , (x & -1) == x ]

2's complEment (we're here to "complete" them, not to praise them) works
very nicely, but C CAN be implemented with alternate encodings.

> A long needs to be at least 32 bits and must the at least as large as an
> int.

NOT NECESSARILY.
24 bits for both int and long might not be a good idea, but it is still
"valid"

> The size of a pointer needs to be at least as large as an int.
IFF we assume that the number of possible ints is as large as an int

>  Pointers to
> one type are not necessarily convertable to pointers to another type,
> although all pointers can be cast to void *. Avoid converting pointers into
> integral types. Do pointer math on pointers.
... and miss out on the fun??