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

[Jens Gustedt <jens.gustedt@inria.fr>]

[-- Attachment #1: Type: text/plain, Size: 3810 bytes --]

Hello,

Am Mittwoch, den 03.12.2014, 14:21 +0100 schrieb Szabolcs Nagy:
> * 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

yes, I agree that it doesn't make much sense, but then the rule
applies that a more specific constraint overrules a general one

> it would be much better if wg14 had a public discussion
> (similar to the austingroup mailing list) where such
> nonsense could be clarified

Agreed, but this doesn't seem possible. And I have to admit that I
don't read comp.std.c anymore, as well, because I simply found it
unbarable. I don't think the committee wouldn't be willing to move to
an open and unmoderated forum because of the noise and the insults.

I recently proposed to maintain a bugtracker, much as the Austin group
has. We'll see if I succeed in that.

> > 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

It should indeed.

But looking at the text for the MIN/MAX constants I didn't find it
much clearer, there, to know what happens if the corresponding type is
promoted. E.g is UCHAR_MAX signed or unsigned in the preprocessor? My
guess is that it is signed, because it should have the promoted type,
but that requirement comes after the text for the preprocessor, so I
am not sure.

(and yes it is unsigned if UCHAR_MAX is UINT_MAX :)

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 ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]