[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141203000132.GA4574@brightrain.aerifal.cx>
Date: Tue, 2 Dec 2014 19:01:32 -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 Tue, Dec 02, 2014 at 10:37:54PM +0100, Jens Gustedt wrote:
> Am Dienstag, den 02.12.2014, 14:44 -0500 schrieb Rich Felker:
> > On Tue, Dec 02, 2014 at 08:20:01PM +0100, Jens Gustedt wrote:
> > > Am Dienstag, den 02.12.2014, 13:03 -0500 schrieb Rich Felker:
> > > > On Tue, Nov 25, 2014 at 03:50:06PM +0100, Jens Gustedt wrote:
> > > > > The C standard requires the exact types [u]int_leastXX_t for these
> > > > > macros in 7.20.4.1
> > > >
> > > > You've misread the standard, and I did too originally. This was fixed
> > > > in commit a591e0383a0a31ac94541846796b93fedc63a0c4. The relevant text
> > > > is (C99 7.18.4 or C11 7.20.4, paragraph 3):
> > > >
> > > > "Each invocation of one of these macros shall expand to an integer
> > > > constant expression suitable for use in #if preprocessing directives.
> > > > The type of the expression shall have the same type as would an
> > > > expression of the corresponding type converted according to the
> > > > integer promotions. The value of the expression shall be that of the
> > > > argument."
> > > >
> > > > In the text you're looking at:
> > > >
> > > > "The macro INTN_C(value) shall expand to an integer constant
> > > > expression corresponding to the type int_leastN_t. The macro
> > > > UINTN_C(value) shall expand to an integer constant expression
> > > > corresponding to the type uint_leastN_t. For example, if
> > > > uint_least64_t is a name for the type unsigned long long int, then
> > > > UINT64_C(0x123) might expand to the integer constant 0x123ULL."
> > > >
> > > > the "correspondence" referred to by "corresponding" should be
> > > > interpreted as the one via integer promotions in the above text I
> > > > cited.
> > >
> > > No, that doesn't seem to be the view of the committee on that
> > > issue. There is a ongoing DR on that and the consensus of the
> > > committee in the discussion seems to be that this is the required
> > > type, e.g to be usable in _Generic.
> > >
> > > The only ambiguity there seemed to be that they were convinced that
> > > this needs internal compiler magic to be achieved, which isn't the
> > > case.
> >
> > Do you have a citation for this?
>
> 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.
DR 456 just seems to state that DR 209 already adequately handled the
situation and that no further change is needed.
> > What on earth is the point of the
> > text I quoted about promoted types if your interpretation of the text
> > that follows is correct?
>
> That one just seems to be copied over from other parts, and you are
> right, in that case has no instantiation because all subsections are
> specialized.
Then why did DR 209 add it?
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.
