OT: Language for the ages

[Eric J Korpela]

On 10/17/05, Fred Cisin <cisin at xenosoft.com> wrote:
>
> 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?


I guess I forgot that one. In that case you do use binary mode and use '\n'
for LF and '\r' for CR. But then again if you know what system you are
transporting to you can just do something like

char LF=10, CR=13;
char CRLF[]={10,13};


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


The ISO's rules, of course. The ISO standard is 16 years old now.

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


This has nothing to do with ASCII or anything else. One of the first things
you learn in C is that 'char' isn't really short for character. 'char' is
short for byte (aka the minimum readily addressable memory element). In C, a
char needs to be able to hold at least 127 unique values. A char might be 64
bits. A 12 bit char might hold three characters of a string on 12 bit
machine.

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


All ISO compliant ones do.

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


Also not ISO compliant. If you've got a 15 bit machine, an ISO C
implementation will probably have 30 bit integers and 45 bit longs.

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


Of course it can on a turing complete machine. But if there is and alternate
encoding it MUST be hidden from the programmer (again under the standard).
assert((x|-1) == -1) is not allowed to fail if x is an integral type.

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


Again, this is not compliant with the standard for the C language and
therefore not "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
>

I assume you meant addresses where you said "ints"? Actually you may be
correct on this one so long as pointer math works according to the standard.

Eric