Date: Tue, 20 Jan 1998 20:53:41 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: ache@nagual.pp.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=) Cc: tlambert@primenet.com, current@FreeBSD.ORG Subject: Re: Nasty GCC bug? Message-ID: <199801202053.NAA25835@usr06.primenet.com> In-Reply-To: <Pine.BSF.3.96.980120224412.28008A-100000@lsd.relcom.eu.net> from "=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=" at Jan 20, 98 10:47:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> On Tue, 20 Jan 1998, Terry Lambert wrote: > > > What is happening is that the value is being sign-extended to int > > when it is pushed on the stack. > > It is absolutely no bug here, it is THE RULE. > > All types smaller than int promotes to int in any expression, and signed > types promotes _with_ sign extension. Function argument is an expression. I typed the wrong subject. My complaint was about how %02x worked with sign extended character values. As I pointed out, not doing the extension would break %d, and it's the fact that printf didn't know it was a character value that had been sign extended instead of an int value that was the bug. %x expects and int, %lx expects a long. There is not one that expects a short or a char. Also, my field width limits are being ignored. I kind of expected it to print out a field limit's worth of hex characters, starting at the lsb. The problem initially showed in a program that sscanf'ed into an int of %2x, assigned a character array valued to the int, and then tried to printf the char value to get back out what it scanned in. The resulting output not matching the input was unexpected, since it's sort of normal to expect that printf/scanf are inverse functions. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801202053.NAA25835>