This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: `quad' printf format specifier ?
- To: Marc Espie <Marc dot Espie at liafa dot jussieu dot fr>
- Subject: Re: `quad' printf format specifier ?
- From: Zack Weinberg <zack at rabi dot columbia dot edu>
- Date: Mon, 08 Feb 1999 23:51:08 -0500
- cc: egcs at egcs dot cygnus dot com
On Sat, 6 Feb 1999 22:23:05 +0100, Marc Espie wrote:
>On Sat, Feb 06, 1999 at 02:04:00PM -0500, Zack Weinberg wrote:
>> It makes sense now. I can make a case for fixing gcc or for changing
>> your definition of quad_t:
>
>> - %qd is defined to print a 64 bit quantity, so if long is 64 bits,
>> then we shouldn't warn when %qd is used to print something with base
>> type long.
>Yes, this should make sense.
>
>> - but long isn't 64 bits everywhere, so portable code must use int64_t
>> and/or long long to get 64 bits reliably; therefore %qd and %lld
>> should warn when given something with base type long.
>Current definition of quad_t is encapsulated in machine/cdefs.h, or
>something like this, so this is not a portability issue.
>`quad_t' will be 64 bits, but the underlying `true' type may change...
>what's interesting for us is to get something sensible according to
>whether or not the current base type has the same size as the underlying
>type or not. I believe such portability warnings belong in the
>-ansi -pedantic class.
Both quad_t and %qd are BSD extensions, and they're intended to work
together as I understand it, so BSD should get to say what types gcc
accepts for %qd. It sounds like we should either accept any DImode
type, or just the quad_t typedef.
zw