What's the object of this exercise?
sizeof(sizeof(foo)) is equal to sizeof(size_t),
which again is some value of type size_t.
If we're talking ISO/ANSI C (a reasonable assumption
by now, I think), size_t is guaranteed to at least be
unsigned. Converting an unsigned value to a
(signed int) if
sizeof size_t < sizeof (signed int)
isn't a problem. If,
sizeof size_t >= sizeof(signed int)
then the conversion isn't well-defined (but I don't
know of a C compiler that doesn't behave sensibly).
However, in your case the unsigned value that's
returned by the sizeof(sizeof(..)) won't run into
overflow problems when converting, so things would
be cool.
=> For practical purposes, the conversion is sane.
However, to ensure that it kicks in, you need to assign
it to an 'int' first before passing it in the printf
vararg. How a fprintf implementation snarfs elements
off of the 'va_list' is anyone's guess, but a fair one
is that it is format-string driven.
=> The behaviour of your program isn't well defined, but for
the same reason that "printf("%d\n", 1LL);" isn't (ignoring
the minor issue that long-longs really aren't std!)
--sigbjorn
Sven Panne <[EMAIL PROTECTED]> writes:
>
> My questions were:
> > What is the output of:
> >
> > #include <stdio.h>
> > int main(void) { printf("%d\n", sizeof(sizeof(int))); return 0; }
> >
> > Is this portable at all?
>
> There was only *one* reply yet (via personal email), and, alas, it
> was not correct... >:-)
>
> Quoting Harbison/Steele's "C: A Reference Manual":
>
> * 7.5.2 sizeof Operator
> [...] In ANSI C the result of sizeof has the unsigned integer
> type size_t defined in the header file stddef.h. Traditional C
> implementations often use int or long as the result type [...].
>
> * 11.2 NULL, ptrdiff_t, size_t, offsetof, wchar_t
> [...] The type size_t is the unsigned integral type of the result
> of the sizeof operator --- probably unsigned long; pre-ANSI
> implementations use the (signed) type int for this purpose. [...]
>
> Especially note the "fun" words like "often" or "probably". The
> program prints 4 on Intel and HP-PA. It prints 8 on Alpha, but this
> only by pure luck: %d expects an int (= 4 bytes) and was passed a
> size_t = unsigned long = 8 bytes. If Alpha had another byte order,
> it would have printed 0.
>
> To make things even more confusing, consider integral promotion:
>
> int i, j;
> i = j * sizeof(...);
>
> You could lose some of your bits during assignment here. I guess we
> will all have much fun when Intel/HP release their Merced processor...
>
> Cheers,
> Sven
> --
> Sven Panne Tel.:
> +49/89/2178-2235
> LMU, Institut fuer Informatik FAX :
> +49/89/2178-2211
> LFE Programmier- und Modellierungssprachen
> Oettingenstr. 67
> mailto:[EMAIL PROTECTED]
> D-80538 Muenchen
> http://www.informatik.uni-muenchen.de/~Sven.Panne
>
RE: Portability questions of the week :-)
Sigbjorn Finne (Intl Vendor) Fri, 16 Jul 1999 18:08:22 +0200 (MET DST)
- Portability questions of the week :-) Sven Panne
- Re: Portability questions of the week :... Sven Panne
- Sigbjorn Finne (Intl Vendor)
