Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!sdcsvax!ucsdhub!hp-sdd!hplabs!hp-pcd!uoregon!omepd!mipos3!cadeos!pinkas
From: pinkas@cadeos.UUCP
Newsgroups: comp.lang.c
Subject: Re:  Long integers
Message-ID: <1023@mipos3.intel.com>
Date: Tue, 15-Sep-87 12:59:59 EDT
Article-I.D.: mipos3.1023
Posted: Tue Sep 15 12:59:59 1987
Date-Received: Sat, 19-Sep-87 05:24:56 EDT
References: <9266@brl-adm.ARPA>
Sender: nobody@mipos3.intel.com
Reply-To: pinkas@cadeos.intel.com (Israel Pinkas ~)
Organization: Corporate CAD, INTeL Corporation, Santa Clara, CA
Lines: 71

In article <9266@brl-adm.ARPA> moss@BRL.ARPA (Gary S. Moss (SLCBR-VL-V)) writes:
>George,
>	The format %ld is wrong when using the PRINTF family of functions.
>The reason for this is that integer arguments are *always* widened to LONG
>when passed in to a function, so the %d format is meant for LONGS.  This
>is also true for %f.  I am not certain, but pretty sure that I have gotten
>wrong behavior when using %ld in this context on certain hardware.
>
>	This is contrary to the SCANF family where you *need* the %ld because
>you are placing the result in an address whose type is not known to the
>function.
>
>~moss

Gary,

I believe that you are incorrect.  K&R (p146) states that:

"Each conversion specification is introduced by the character % and ended
by a conversion character.  Between th % and the conversion character there
may be:

...

    A length modifier l (letter ell), which indicates that the
    corresponding data item is a long rater than an int."

The default type for printf is int.  (We are talking about interger data
types here: short, int and long.)  Note that a short is promoted to an int
by rule 6.1 in Appendix A (p183), which states that shorts and chars are
promoted to ints in expressions.

Therefor, the only integer type parameters are int and long.  The %d
conversion corresponds to int and the %ld corresponds to long.  (The o, x,
u and c conversion characters all expent an int.  The e, f, and g
conversion characters all expect a double, as floats are promoted to
doubles by 6.2 (p184).  o, x, and u just treat the int as unsigned.  They
are allowed to as signed and unsigned entities are the same length.)

An interesting thing to note is that in the scanf family, the argument type
must correspond EXACTLY to the conversion character.  Thus, we have that d,
o, and x expect an int; h expects a short; c expects a char; f expects a
float; ld, lo, and lx expect a long; and lf expects a double.

(Some of the above may have been changed in the ANSI standard.  I don't
have my copy of the draft here to look it up.)

So we have that George was probably correct.  (I didn't see his posting.)

Incidentally, on a VAX, ints and longs are interchangeable.  So the l
spcifier is unnecessary for ints.  (It is still necessary for doubles,
though.)  On my IBM-PC, C compilers use 16 bit ints, keeping with the rule
that an int should be "the natural size for the machine, not smaller than a
short, not larger than a long."  So on my PC, I am more aware of int/long
incompatibilities like this.

-Israel

----------------------------------------------------------------------
Disclaimer: The above are my personal opinions, and in no way represent
the opinions of Intel Corporation.  In no way should the above be taken
to be a statement of Intel.

UUCP:	{amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!pinkas
ARPA:	pinkas%mipos3.intel.com@relay.cs.net
CSNET:	pinkas%mipos3.intel.com

---------
"You can do more with a kind word and a gun than with just a kind word"

			-Al Capone