"Al Balmer" <al******@att.neta écrit dans le message de news:
0s********************************@4ax.com...
On Fri, 14 Sep 2007 11:46:53 +0200, "Charlie Gordon"
<ne**@chqrlie.orgwrote:
>>>
Arithmetic isn't everything.
Arithmetic can by relied upon more readily than representation.
My point is that computers are used to do other things than
arithmetic. Masking a 16-bit register to 8 bits does not make it an
8-bit register.
What exactly do you call a register? I don't the C standard can help in
dealing with CPU registers or memory mapped I/O registers...
If your implementation gives you adequate control over these, and uint8_t
and uint16_t types are fit for this purpose, no problem.
But for implementing algorithms that require 2s-complement exact size 8, 16,
32 or 64 bits, it would be helpful if the Standard mandated the support of
the corresponding types. The commitee decided it was not helpful enough to
balance the extra work needed for weird platforms, so be it.
I don't quite agree with them, they did mandate long long, and floating
point arithmetics for all conforming platforms, that's more work than
supporting 2s complement 8/16/32 bits arithmetics on the rare if not
inexistent architectures that don't support it already.
I personally regret that it is not possible in C to describe actual data
structures stored in files with more precision. I would want to tell the
compiler about endianness, alignment and representation and have it generate
the best code for the target architecture. Code that deals with memory
mapped files, device driver I/O space, Graphics chips, would be so much more
readable.
--
Chqrlie.