On Thu, 24 May 2007, Matthew Saltzman wrote:
> On Wed, 23 May 2007, Les wrote:
>
> > On Wed, 2007-05-23 at 18:45 -0500, Michael Hennebry wrote:
> >
> >> On Wed, 23 May 2007, Mike McCarty wrote:
> >>
> >>> Michael Hennebry wrote:
> >>>> On Wed, 23 May 2007, George Arseneault wrote:
> >>> On big-endian machines, they can. For example, with two's complement
> >>> arithmetic on a big-endian machine,
> >>>
> >>> printf("%d\n",-2);
> >>>
> >>> does not result in
> >>>
> >>> -2
> >>
> >> It should.
> >> printf, declared or not, will look for an int and get it.
> >>
> >> printf("%u\n", -2);
> >> is more interesting.
> >> We might be in the domain of nasal demons.
> >> printf("%u\n", (unsigned)-2);
> >> Is legal, but rather obviously will not print "-2\n".
> >> It will probably print something even regardless of endianness.
>
> It will definitely print *something*. The question is, can you guarantee
> what it will print.
It is guaranteed to print 2**n-2 for some n>=16 .
Value conversion from signed to unsigned is defined.
Unsigned variable addition and subtraction is modulo 2**n .
An unsigned variable can have values in the range 0..2**n-1
The aforementioned value conversion is done modulo 2**n-1+1=2**n .
> It's not addressed directly in the FAQ, but I believe it's possible to
> prove that (unsigned) -2 must be the two's complement representation of -2
> in however many bits make up an int. I know there was some controversy
> about that when the standard was being developed. In any case, I don't
> know of any modern machine that doesn't represent negative integers in
> two's complement.
> >>>> Printing (int)sizeof(typename) will distinguish some types.
> >>>> Note that short, int and long usually only have two distinct sizes.
> >>>> It's allowed, but rare, for all the arithmetic types to have size 1.
>
> Or for them all to have different sizes.
Yup.
> >>> Note that what you suggest works because sizeof(.) for integer
> >>> types is going to be a small number. The only portable means
> >>
> >> For small read <=16.
> >>
> >>> of displaying an unsigned integer of unknown size is
> >>>
> >>> printf("Thing = %ul\n",(unsigned long int)Thing);
> >>>
> >>> For "rare" read "no known implementation". Since long int
> >>> is required to be at least 32 bits, that would require
> >>> that char be at least 32 bits.
> >>
> >> And double has to be more.
>
> How do you get that? (Not saying you're wrong...)
Sorry about the lack of clarity.
I meant more than 32.
> >> My recollection is that there was a
> >> Cray compiler that had 64-bit chars.
> >> Anyone know for sure?
> >
> > sizeof generally returns size in bytes or words (depending on how the
> > implementer read the spec) I have never seen it return words.
>
> sizeof(char) == 1 is guaranteed by the standard. There's no reference to
> "bytes", but it is commonly accepted that the char type is a byte. It's
> possible to have chars that are not eight bits, but I can't think of a
> modern machine that does that. There were some old machines (Honeywells?)
> that had six-bit bytes and 36-bit words.
Six-bit chars did not satisfy the standard.
> All this is based on my recollection of discussions in comp.lang.c and
> comp.std.c when the standard was under development.
>
> >
> > And the Cray stored 8 characters in 64 bits using ASCII coding a
> > LONG time ago. I had forgotten about that. I think that was the model
> > where you sat on the processing unit when you were at the console.
I just read of a CDC machine that had 60-bit chars.
That is not big enough for doubles though.
It's worth noting that the size of a char
is not just a function of a machine.
It's a function of the compiler.
There was a machine with 10-bit chars.
I suspect that it was the same CDC machine I just mentioned.
--
Mike hennebry@xxxxxxxxxxxxxxxxxxxxx
"Horse guts never lie." -- Cherek Bear-Shoulders
