Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!bloom-beacon!bloom-picayune.mit.edu!news
From: scs@adam.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: How come << falls through at 16 on a 32-bit integer?
Summary: no prototypes for printf
Message-ID: <1991Apr14.003724.8979@athena.mit.edu>
Date: 14 Apr 91 00:37:24 GMT
References: <11004@uwm.edu>
Sender: news@athena.mit.edu (News system)
Reply-To: scs@adam.mit.edu
Organization: Thermal Technologies, Inc.
Lines: 43

In article <11004@uwm.edu> markh@csd4.csd.uwm.edu (Mark William Hopkins) writes:
> Why am I getting 0 for output here when unsigned long's are 32 bits with the
> Quick C Version 2.5 compiler?
> *    unsigned long M = 34;
> *    printf("%08x\n", M << 16);

The short answer, which we'll be seeing numerous repetitions of
over the next few days, is that M << 16, being a long, must be
printed with %lx (or, of course, %08lx in this example).

I've noticed that this question has been much more frequent since
ANSI-style function prototypes started coming into widespread
use.  Prototypes are not a crutch (though it's easy and tempting
to use them as one); it's important to understand that prototypes
do not take care of the types of all function call arguments
everywhere, and that the programmer must therefore remember to
think about argument type when required.  In particular,
prototypes never act on the variable arguments in a variable-
length argument list, such as the arguments following the format
string of a printf-style function.

(It has always been easy to forget that the printf format string
is virtually always interpreted only at run-time, and that the
programmer is therefore responsible for carefully matching
argument types to %-format specifiers.  Some versions of lint
will do a static check of printf arguments and format strings, as
long as the format strings are simple compile-time constants, as
they usually are.)

> This is a compiler bug, according to my understanding of the Quick C manual
> and C language.

Not to criticize you, but any time *anyone's* understanding of
the language doesn't match the behavior of the compiler, prompting
a cry of "compiler bug!", it's usually the "understanding" that's
at fault.  (Sadly, compilers do occasionally have bugs, so a rule
like "always believe the compiler" must not be applied religiously.
As learn(1) sagely points out, "Occasionally lessons are incorrect...
Such lessons may be skipped with the `skip' command, but it takes
some sophistication to recognize the situation.")

                                            Steve Summit
                                            scs@adam.mit.edu