[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141203144701.GJ4574@brightrain.aerifal.cx>
Date: Wed, 3 Dec 2014 09:47:01 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 3/4] use exact types for the [U]INTXX_C macros
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
