mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH 3/4] use exact types for the [U]INTXX_C macros
Date: Wed, 3 Dec 2014 09:47:01 -0500	[thread overview]
Message-ID: <20141203144701.GJ4574@brightrain.aerifal.cx> (raw)
In-Reply-To: <1417602004.4936.1233.camel@eris.loria.fr>

On Wed, Dec 03, 2014 at 11:20:04AM +0100, Jens Gustedt wrote:
> Am Dienstag, den 02.12.2014, 19:01 -0500 schrieb Rich Felker:
> > On Tue, Dec 02, 2014 at 10:37:54PM +0100, Jens Gustedt wrote:
> > > These are DR 209 and 456
> > > 
> > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_209.htm
> > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1892.htm#dr_456
> > 
> > I don't see where your interpretation is clear from these. DR 209
> > added the text I cited. It's not clear what the change made to
> > 7.18.4.1 is (I don't have the old text in front of me) so perhaps you
> > could shed some light on why you think it requires the odd types.
> 
> I also only have the corrected version in front, but I vaguely
> remember that the change was from types [u]intXX_t to [u]int_leastXX_t
> because the macros are supposed to exist, even if the corresponding
> [u]intXX_t doesn't.
> 
> > DR 456 just seems to state that DR 209 already adequately handled the
> > situation and that no further change is needed.
> 
> exactly, furthermore they add
> 
>    The committee believes that DR209 is still appropriate in that
>    "compiler magic" must be used for the implementation of these
>    macros. The committee does not consider this a defect.
> 
> The part about the compiler magic is completely senseless when
> supposing that the constants promote.
> 
> In addition, from discussion on the WG14 mailing list I see that
> people there expect the macros to resolve to the unpromoted type when
> used in _Generic.

If you have access to discussions that aren't public, could you try to
get the GCC folks in on them? GCC's stdint.h agrees with my
interpretation and I don't think it's useful to flip back and forth
between interpretations or make more incompatible ones. We should be
aiming to get a real understanding of what the intended requirement
is, whether there's consensus on implementing that, and what needs to
be done to get things right. Obviously my preference is to keep things
the way GCC and musl is doing, but if WG14 would spell out explicitly
that this is wrong (and hopefully get GCC and others to listen), I'm
fine with changing it.

> And isn't all of this just the purpose of these macros? If we'd
> suppose they promote, standard literals to denote the constants would
> mainly suffice: they already do the right thing for narrow types,
> namely promotion.

No, consider things like UINT64_C(42). Simply using 42 or 42U would
have the wrong type, which matters for passing arguments to variadic
functions that expect uint64_t, use with sizeof, etc.

Of course you could just cast, as in (uint64_t)42, but that loses the
"promotions" aspect of the macros. I don't see why the macros would
even exist if this were the intent, since casts work just as well if
not better. The added value of the macros is that they give you the
right promoted type when it matters, but of course you could also get
this via something like +(uint8_t)42, so IMO the macros are utterly
useless and there's no reason for any code to be using them or
depending on which behavior they have.

Rich


      parent reply	other threads:[~2014-12-03 14:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-25 14:50 Jens Gustedt
2014-12-02 18:03 ` Rich Felker
2014-12-02 19:20   ` Jens Gustedt
2014-12-02 19:44     ` Rich Felker
2014-12-02 21:37       ` Jens Gustedt
2014-12-03  0:01         ` Rich Felker
2014-12-03 10:20           ` Jens Gustedt
2014-12-03 13:21             ` Szabolcs Nagy
2014-12-03 14:17               ` Jens Gustedt
2014-12-03 14:50                 ` Rich Felker
2014-12-03 14:47             ` Rich Felker [this message]

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=20141203144701.GJ4574@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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 NNTP newsgroup(s).