[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 02 Dec 2014 22:37:54 +0100
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 3/4] use exact types for the [U]INTXX_C macros
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
> 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.
Jens
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
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.
