Re: [PATCH 3/4] use exact types for the [U]INTXX_C macros

[Szabolcs Nagy <nsz@port70.net>]

* Jens Gustedt <jens.gustedt@inria.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