Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.c
Subject: Re: bug? in turbo c++
Message-ID: <11971:Mar619:43:1491@kramden.acf.nyu.edu>
Date: 6 Mar 91 19:43:14 GMT
References: <MITCH.91Mar5134925@hq.af.mil> <1991Mar6.171424.17409@nntp-server.caltech.edu> <1991Mar6.173733.430@unhd.unh.edu>
Organization: IR
Lines: 28

In article <1991Mar6.173733.430@unhd.unh.edu> rg@msel.unh.edu (Roger Gonzalez) writes:
>     int     i;
>     long    j;
>     for (i = 0; i < 1000; i++, j = i*2)
>         printf("oh crud: %x %10d %x\r", i, j, i);
> The third number printed is always zero.  It corrects itself if the
> second formatting string is %10ld.

This makes perfect sense. On a low level, printf is expecting three
2-byte arguments; you fed it a 2-byte, a 4-byte, and another 2-byte. The
4-byte always has high word 0 since j is smaller than 65536. Numbers are
stored low-byte first on that machine. So the third 2-byte is 0.

If anything were done differently---a noncontiguous stack, or arguments
passed in registers, or a different word order, or whatever---you'd see
different results with the original code.

When you use %10ld, printf knows to expect a long for its second
argument.

> Will this
> behavior change to what my Unix cc fingers expect if I set it to K&R?

You mean ``to what my all-the-world's-a-VAX fingers expect.'' You have
to distinguish properly between ints and longs if you want your programs
to work on machines where int != long.

---Dan