This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: sprintf %hi converion


On Fri, 29 Jun 2001, Matt Wimer wrote:

> Conversion of an int using %hi doesn't cast the va_arg (ap, int) to
> 'short int' like freebsd, solaris, and netbsd.  I'm guessing
> that this is a bug because it doesn't conform to the man pages
> which seem to be pretty definative.  This may not be in the
> posix spec but it seems everyone else deals with this bad input
> the same way.

See the appended comp.std.c messages.  The experts seem to differ in this
area; you could always bring it up again on comp.std.c, or elsewhere.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Article: 41281 of comp.std.c
Path: pegasus.csx.cam.ac.uk!server1.netnews.ja.net!fu-berlin.de!newscore.univie.ac.at!194.25.134.126.MISMATCH!newsfeed01.sul.t-online.de!t-online.de!newspeer.clara.net!news.clara.net!colt.net!pop-news-1.colt-telecom.nl!newsgate.cistron.nl!bullseye.news.demon.net!demon!news.demon.co.uk!demon!romana.davros.org!clive
From: "Clive D.W. Feather" <clive@on-the-train.demon.co.uk>
Newsgroups: comp.std.c
Subject: Re: printf %h and %hh formats
Date: Wed, 20 Sep 2000 20:02:14 +0100
Organization: Demon Internet
Message-ID: <P7+lGrK2mQy5EwP8@romana.davros.org>
References: <8qau43$ihv$1@pegasus.csx.cam.ac.uk>
Reply-To: "Clive D.W. Feather" <clive@demon.net>
NNTP-Posting-Host: romana.davros.org
X-NNTP-Posting-Host: romana.davros.org:194.217.240.35
X-Trace: news.demon.co.uk 969476969 nnrp-13:26099 NO-IDENT romana.davros.org:194.217.240.35
X-Complaints-To: abuse@demon.net
MIME-Version: 1.0
X-Newsreader: Turnpike Integrated Version 5.00 U <81yImECxEkLwWkbKTSiEkLA3nC>
Lines: 27
Xref: pegasus.csx.cam.ac.uk comp.std.c:41281

In article <8qau43$ihv$1@pegasus.csx.cam.ac.uk>, Joseph S. Myers
<jsm28@cam.ac.uk> writes
>Suppose CHAR_BIT is 8.  Consider the following program:
>
>       #include <stdio.h>
>       int
>       main(void)
>       {
>         printf("%hhu\n", 257);
>       }
>
>The argument 257 has type int which is the correct type from promotion
>of unsigned char, but the value 257 could not have arisen from passing
>an unsigned char argument.  Is the implementation required to convert
>the value 257 to unsigned char and print 1, or is the behavior
>undefined?

I would take the view that the implementation is required to convert it
to unsigned char (which in this case involves reduction modulo 256). Had
you put %hhd it would be implementation-defined (since the conversion
is) or a signal is raised.

-- 
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet       | Home: <clive@davros.org>
Fax: +44 20 8371 1037 | Thus plc             | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address


Article: 41287 of comp.std.c
Path: pegasus.csx.cam.ac.uk!server1.netnews.ja.net!fu-berlin.de!nntp.cs.ubc.ca!cyclone.bc.net!telocity-west!TELOCITY!newsrump.sjc.telocity.net!not-for-mail
Message-ID: <39C977D9.5A8F97F5@null.net>
From: "Douglas A. Gwyn" <DAGwyn@null.net>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
Newsgroups: comp.std.c
Subject: Re: printf %h and %hh formats
References: <8qau43$ihv$1@pegasus.csx.cam.ac.uk> <P7+lGrK2mQy5EwP8@romana.davros.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 8
X-Trace: OCC5b0F1dGhVc2VyIFRFTE9DSVRZLVJFQURFUlMgNv4uMTkyLjM1LjUgIEJlZCwgMjAgU2VwIDIw!JTAgMTk6NTA6xDggUERU
X-Abuse-Info: Please forward ALL headers when reporting abuse.
X-Complaints-To: abuse@telocity.net
NNTP-Posting-Date: Wed, 20 Sep 2000 19:50:38 PDT
Date: Wed, 20 Sep 2000 22:52:09 -0400
Xref: pegasus.csx.cam.ac.uk comp.std.c:41287

"Clive D.W. Feather" wrote:
> Joseph S. Myers <jsm28@cam.ac.uk> writes
> >         printf("%hhu\n", 257);
> I would take the view that the implementation is required to convert
> it to unsigned char

Another interpretation is that the program is not s.c. since it did
not provide an unsigned char argument.


Article: 41293 of comp.std.c
Path: pegasus.csx.cam.ac.uk!server1.netnews.ja.net!server5.netnews.ja.net!server3.netnews.ja.net!logbridge.uoregon.edu!cyclone.bc.net!telocity-west!TELOCITY!newsrump.sjc.telocity.net!not-for-mail
Message-ID: <39CA4DCA.82B858EB@null.net>
From: "Douglas A. Gwyn" <DAGwyn@null.net>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
Newsgroups: comp.std.c
Subject: Re: printf %h and %hh formats
References: <8qau43$ihv$1@pegasus.csx.cam.ac.uk> <P7+lGrK2mQy5EwP8@romana.davros.org> <39C977D9.5A8F97F5@null.net> <39C9EC69.5AD427A5@wizard.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 22
X-Trace: MjIgTnpBdXRoVXNlctdURUxPQ0lUWS1SRUFERVJTIDY0LjE5Mi4zNS416iBUaHUsIDIxIFNlZSAy!MDAwIDExOjAzOjMlIFBEVA==
X-Abuse-Info: Please forward ALL headers when reporting abuse.
X-Complaints-To: abuse@telocity.net
NNTP-Posting-Date: Thu, 21 Sep 2000 11:03:30 PDT
Date: Thu, 21 Sep 2000 14:04:58 -0400
Xref: pegasus.csx.cam.ac.uk comp.std.c:41293

James Kuyper wrote:
> "Douglas A. Gwyn" wrote:
> > Another interpretation is that the program is not s.c. since it
> > did not provide an unsigned char argument.
> ... [a bunch of irrelevant citations about argument promotion] ...
> I don't see how a conforming implementation would be allowed to
> distinguish between a printf() argument that gets promoted in
> accordance with the rules for a function with a variable number of
> arguments, and an argument that was already of the promoted type.

There is more to it than type; there is also value.  The spec for
hh says that the argument shall be of type char or unsigned char,
which imposes a requirement on the range of values.  If a program
does not provide a char but rather an int, it has invoked
undefined behavior *even when the value happens to lie within the
valid range for a char*.  Obviously the implementation will work
anyway in such a case, since within the fprintf implementation it
has exactly the same argument either way; however, it might *not*
work when the value exceeds that possible for a char, since the
fprintf implementation is allowed to assume that the program has
followed the specification.  My advice is to pass a char when a
char is required -- why else would you be using hh?


Article: 41291 of comp.std.c
Path: pegasus.csx.cam.ac.uk!server1.netnews.ja.net!fu-berlin.de!logbridge.uoregon.edu!sn-xit-03!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
From: James Kuyper <kuyper@wizard.net>
Newsgroups: comp.std.c
Subject: Re: printf %h and %hh formats
Date: Thu, 21 Sep 2000 07:09:29 -0400
Organization: Not Enough
Message-ID: <39C9EC69.5AD427A5@wizard.net>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,de,es,ru
MIME-Version: 1.0
References: <8qau43$ihv$1@pegasus.csx.cam.ac.uk> <P7+lGrK2mQy5EwP8@romana.davros.org> <39C977D9.5A8F97F5@null.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: newsabuse@supernews.com
Lines: 40
Xref: pegasus.csx.cam.ac.uk comp.std.c:41291

"Douglas A. Gwyn" wrote:
>
> "Clive D.W. Feather" wrote:
> > Joseph S. Myers <jsm28@cam.ac.uk> writes
> > >         printf("%hhu\n", 257);
> > I would take the view that the implementation is required to convert
> > it to unsigned char
>
> Another interpretation is that the program is not s.c. since it did
> not provide an unsigned char argument.


7.9.16.3:
"Synopsis
	#include <stdio.h>
	int printf(const char * restrict format, ...);
"

Therefore, 6.5.2.3p7 applies to the printf() call:
"If the expression that denotes the called function has a type that does
include a prototype ... The ellipsis notation in a function prototype
declarator causes argument type conversion to stop after the last
declared parameter. The default argument promotions are performed on
trailing arguments."

as is also suggested by 7.9.16.1p7 (describing fprintf(), but inherited
by the description of printf()):
"the argument will have been promoted according to the integer
promotions, but its value shall be converted to signed char or unsigned
char before printing"

According to 7.1.4p1, when using standard library functions:
"If an argument to a function has ... a type (after promotion) not
expected by a function with variable number of arguments, the behavior
is undefined."

I don't see how a conforming implementation would be allowed to
distinguish between a printf() argument that gets promoted in accordance
with the rules for a function with a variable number of arguments, and
an argument that was already of the promoted type.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]