Subject: Re: question about the casting in printf
To: None <tech-toolchain@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-toolchain
Date: 02/08/2007 11:00:37
> unsigned long long ull = 0x0000000100000003;	//MyLIB		FreeBSD	Linux
> printf(¿%Luâ¿, ull);				//4294967299	4294967299
> printf(¿%lu¿, ull);				//1		3	3
> printf(¿%lu¿, (unsigned long)ull);		//3		3	3

I'm not sure what happened to the double quotes in the printf calls;
they seem to have been characters with no Latin-1 equivalents (on
investigating the original, I see they were Unicode 0x201c and 0x201d,
directed left and right double quotes).  This will not work; C requires
the double quotes around strings to be undirected double quotes.
(Usually won't work, at least; while compilers that accept directed
double quote characters there might exist, I find it doubtful.)

Assuming that's just an artifact of including the code sample in the
email in a broken way....

> "ull" is a 8-byte value, if we want print it in unsigned long form,
> we will get "0x00000001" without the casting first, "0x00000003" if
> casting first.

This depends on the way your machine passes arguments and, for many
common argument-passing conventions, its endianness as well.  Based on
the output you describe, you appear to be talking about a big-endian
machine.

> I think the behavior is correct since argument type in va_arg() is
> unsigned long (because of "%lu"), it only handles first 4 bytes,

Yes (well, assuming 4-byte unsigned longs), but...

> so we will get "0x00000001" without casting first.

...the first 4 bytes of what?

Depending on how the C implementation passes arguments, it may not be
the first 4 bytes of the unsigned long long argument you passed.  Even
if it is, which 4 bytes are first depends on how arguments are passed,
and, usually, on the endianness of the machine.

> But why I can get "0x00000003" on FreeBSD/Linux platform!??  I don't
> understand.

If you're running on the same hardware, I can only assume it does
argument passing differently.

I don't see any point in worrying over why results you get differ when
you're doing things whose results are undefined (or
implementation-defined and you're comparing implementations which
define them in different ways).  I think the former is the case here,
though I'd have to check with a real C expert to be certain.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B