public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Marc Espie <Marc.Espie@liafa.jussieu.fr>
To: Zack Weinberg <zack@blastula.phys.columbia.edu>,
	Marc Espie <Marc.Espie@liafa.jussieu.fr>
Cc: egcs@egcs.cygnus.com
Subject: Re: `quad' printf format specifier ?
Date: Sat, 06 Feb 1999 13:23:00 -0000	[thread overview]
Message-ID: <19990206222305.19585@liafa1.liafa.jussieu.fr> (raw)
In-Reply-To: < 199902061904.OAA02631@blastula.phys.columbia.edu >; from Zack Weinberg on Sat, Feb 06, 1999 at 02:04:00PM -0500

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.

> It really boils down to whether you think `long long' is an
> abomination or not.
I'm not familiar enough with C9X to have a definite opinion. All I know
is that both `long long' and C9X somewhat break portable old code, where
casting to long and using %ld to print values was enough to ensure
portability, which is precisely why I'm asking for guidance (I also have
heard that C9X confused some C++ related issues and what's going to come
out is currently thoroughly incompatible with the C++ standard, but this
is another issue).

I would very much like to know what's the exact status of stuff such as
atoq(), or printf("%qd").  Does it correspond to any current standard/draft,
or is it just a common extension that is supposed to work in a given way ?

If there is no actual standard to enforce, I fail to see how OpenBSD could
get it `wrong', and I'm mainly trying to keep current practice from breaking
without disturbing correct code.

-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'

WARNING: multiple messages have this Message-ID
From: Marc Espie <Marc.Espie@liafa.jussieu.fr>
To: Zack Weinberg <zack@blastula.phys.columbia.edu>,
	Marc Espie <Marc.Espie@liafa.jussieu.fr>
Cc: egcs@egcs.cygnus.com
Subject: Re: `quad' printf format specifier ?
Date: Sun, 28 Feb 1999 22:53:00 -0000	[thread overview]
Message-ID: <19990206222305.19585@liafa1.liafa.jussieu.fr> (raw)
Message-ID: <19990228225300.5TaXTQ41A9o5Dqu5Cok3L5ntbYtZckyH_XfzK2cJ9Zo@z> (raw)
In-Reply-To: <199902061904.OAA02631@blastula.phys.columbia.edu>

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.

> It really boils down to whether you think `long long' is an
> abomination or not.
I'm not familiar enough with C9X to have a definite opinion. All I know
is that both `long long' and C9X somewhat break portable old code, where
casting to long and using %ld to print values was enough to ensure
portability, which is precisely why I'm asking for guidance (I also have
heard that C9X confused some C++ related issues and what's going to come
out is currently thoroughly incompatible with the C++ standard, but this
is another issue).

I would very much like to know what's the exact status of stuff such as
atoq(), or printf("%qd").  Does it correspond to any current standard/draft,
or is it just a common extension that is supposed to work in a given way ?

If there is no actual standard to enforce, I fail to see how OpenBSD could
get it `wrong', and I'm mainly trying to keep current practice from breaking
without disturbing correct code.

-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'

  parent reply	other threads:[~1999-02-06 13:23 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <19990206133120.26761@liafa1.liafa.jussieu.fr>
1999-02-06 11:04 ` Zack Weinberg
     [not found]   ` < 199902061904.OAA02631@blastula.phys.columbia.edu >
1999-02-06 12:27     ` Alex Buell
1999-02-28 22:53       ` Alex Buell
1999-02-06 13:23     ` Marc Espie [this message]
1999-02-08  1:44       ` Andreas Schwab
1999-02-28 22:53         ` Andreas Schwab
     [not found]       ` < 19990206222305.19585@liafa1.liafa.jussieu.fr >
1999-02-08 20:51         ` Zack Weinberg
1999-02-28 22:53           ` Zack Weinberg
1999-02-28 22:53       ` Marc Espie
1999-02-28 22:53   ` Zack Weinberg
1999-02-08  9:25 Guillermo A. Loyola
     [not found] ` < 8C36CEF2AF34D211922D00A0C9D60A54020D0F@epimail.epigram.com >
1999-02-08 11:48   ` Alex Buell
     [not found]     ` < Pine.LNX.4.05.9902081436140.307-100000@lo-pc3035a.hitc.com >
1999-02-08 12:24       ` Jeffrey A Law
     [not found]         ` < 1997.918505244@hurl.cygnus.com >
1999-02-08 13:12           ` Alex Buell
     [not found]             ` < Pine.LNX.4.05.9902081606350.164-100000@lo-pc3035a.hitc.com >
1999-02-08 13:57               ` Joe Buck
1999-02-28 22:53                 ` Joe Buck
1999-02-08 14:00               ` Jeffrey A Law
1999-02-28 22:53                 ` Jeffrey A Law
1999-02-28 22:53             ` Alex Buell
1999-02-28 22:53         ` Jeffrey A Law
1999-02-28 22:53     ` Alex Buell
1999-02-28 22:53 ` Guillermo A. Loyola
1999-02-08 15:20 Ross Smith
1999-02-28 22:53 ` Ross Smith
1999-02-09  7:13 John Breen
     [not found] ` < 19990209150626.21275.qmail@hotmail.com >
1999-02-09  8:59   ` Alan Lehotsky
1999-02-10  8:02 Kaveh R. Ghazi
1999-02-28 22:53 ` Kaveh R. Ghazi
1999-02-10 11:33 Kaveh R. Ghazi
1999-02-28 22:53 ` Kaveh R. Ghazi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19990206222305.19585@liafa1.liafa.jussieu.fr \
    --to=marc.espie@liafa.jussieu.fr \
    --cc=egcs@egcs.cygnus.com \
    --cc=zack@blastula.phys.columbia.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).