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