[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 3 Dec 2014 14:21:55 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 3/4] use exact types for the [U]INTXX_C macros
* Jens Gustedt <jens.gustedt@...ia.fr> [2014-12-03 11:20:04 +0100]:
> 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
> >
> > 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.
>
i read dr 456 and even the meeting minutes when this came up
on comp.std.c
https://groups.google.com/forum/#!msg/comp.std.c/6wIA_XDhOwU/x_859JqaKBMJ
and it still does not make sense to me:
somehow 'type' of the expression is interpreted in
preprocessor context eventhough integer promotion
makes no sense there
and there is a clear contradiction between
"The type of the expression shall have the same type
as would an expression of the corresponding type converted
according to the integer promotions."
and
"The macro INTN_C(value) shall expand to an integer constant
expression corresponding to the type int_leastN_t."
the 'promotion' part is missing from the later and
neither says what to do with the types in the preprocessor
it would be much better if wg14 had a public discussion
(similar to the austingroup mailing list) where such
nonsense could be clarified
> 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.
>
> 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.
getting constants with unpromoted type makes sense,
but then the text should say that and have a separate
well defined requirement for the preprocessor
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.
