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

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

[Jens Gustedt]

The C standard requires the exact types [u]int_leastXX_t for these
macros in 7.20.4.1
---
 arch/x86_64/bits/alltypes.h.in |  3 +++
 include/limits.h               |  1 +
 include/stdint.h               | 31 ++++++++++++-------------------
 3 files changed, 16 insertions(+), 19 deletions(-)

diff --git a/arch/x86_64/bits/alltypes.h.in b/arch/x86_64/bits/alltypes.h.in
index 2ce8e4a..aff4b8d 100644
--- a/arch/x86_64/bits/alltypes.h.in
+++ b/arch/x86_64/bits/alltypes.h.in
@@ -2,6 +2,9 @@
 #define _Int64 long
 #define _Reg long
 
+#define _INTEGER_C(T, X) ((T)+(X))
+#define _UINTEGER_C(T, X) ((T)+((X)+0ULL))
+
 TYPEDEF __builtin_va_list va_list;
 TYPEDEF __builtin_va_list __isoc_va_list;
 
diff --git a/include/limits.h b/include/limits.h
index f9805a1..fcb2071 100644
--- a/include/limits.h
+++ b/include/limits.h
@@ -3,6 +3,7 @@
 
 #include <features.h>
 
+/* The limits here must use the promoted types. */
 /* Most limits are system-specific */
 
 #include <bits/limits.h>
diff --git a/include/stdint.h b/include/stdint.h
index ad6aaea..8b91163 100644
--- a/include/stdint.h
+++ b/include/stdint.h
@@ -94,24 +94,17 @@ typedef uint64_t uint_least64_t;
 
 #include <bits/stdint.h>
 
-#define INT8_C(c)  c
-#define INT16_C(c) c
-#define INT32_C(c) c
-
-#define UINT8_C(c)  c
-#define UINT16_C(c) c
-#define UINT32_C(c) c ## U
-
-#if UINTPTR_MAX == UINT64_MAX
-#define INT64_C(c) c ## L
-#define UINT64_C(c) c ## UL
-#define INTMAX_C(c)  c ## L
-#define UINTMAX_C(c) c ## UL
-#else
-#define INT64_C(c) c ## LL
-#define UINT64_C(c) c ## ULL
-#define INTMAX_C(c)  c ## LL
-#define UINTMAX_C(c) c ## ULL
-#endif
+/* Macros defined here must use the exact types, not the promoted
+   ones. */
+
+#define INT8_C(c)  _INTEGER_C(int_least8_t, c)
+#define INT16_C(c) _INTEGER_C(int_least16_t, c)
+#define INT32_C(c) _INTEGER_C(int_least32_t, c)
+#define INT64_C(c) _INTEGER_C(int_least64_t, c)
+
+#define UINT8_C(c)  _UINTEGER_C(uint_least8_t, c)
+#define UINT16_C(c) _UINTEGER_C(uint_least16_t, c)
+#define UINT32_C(c) _UINTEGER_C(uint_least32_t, c)
+#define UINT64_C(c) _UINTEGER_C(uint_least64_t, c)
 
 #endif
-- 
1.9.1

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

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

IMO this part of the standard is horribly worded, and I would love to
get it improved, because this topic comes up again and again.

Rich

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

[Jens Gustedt]

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

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.

> IMO this part of the standard is horribly worded, and I would love to
> get it improved, because this topic comes up again and again.

agreed

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

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

[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? What on earth is the point of the
text I quoted about promoted types if your interpretation of the text
that follows is correct?

Rich

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

[Jens Gustedt]

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

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



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

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

[Rich Felker]

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

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

[Jens Gustedt]

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

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

I also only have the corrected version in front, but I vaguely
remember that the change was from types [u]intXX_t to [u]int_leastXX_t
because the macros are supposed to exist, even if the corresponding
[u]intXX_t doesn't.

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

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.

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

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

[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

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

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

[Jens Gustedt]

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

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

[Rich Felker]

On Wed, Dec 03, 2014 at 11:20:04AM +0100, Jens Gustedt wrote:
> 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
> > 
> > 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.
> 
> I also only have the corrected version in front, but I vaguely
> remember that the change was from types [u]intXX_t to [u]int_leastXX_t
> because the macros are supposed to exist, even if the corresponding
> [u]intXX_t doesn't.
> 
> > 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.
> 
> 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.

If you have access to discussions that aren't public, could you try to
get the GCC folks in on them? GCC's stdint.h agrees with my
interpretation and I don't think it's useful to flip back and forth
between interpretations or make more incompatible ones. We should be
aiming to get a real understanding of what the intended requirement
is, whether there's consensus on implementing that, and what needs to
be done to get things right. Obviously my preference is to keep things
the way GCC and musl is doing, but if WG14 would spell out explicitly
that this is wrong (and hopefully get GCC and others to listen), I'm
fine with changing it.

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

No, consider things like UINT64_C(42). Simply using 42 or 42U would
have the wrong type, which matters for passing arguments to variadic
functions that expect uint64_t, use with sizeof, etc.

Of course you could just cast, as in (uint64_t)42, but that loses the
"promotions" aspect of the macros. I don't see why the macros would
even exist if this were the intent, since casts work just as well if
not better. The added value of the macros is that they give you the
right promoted type when it matters, but of course you could also get
this via something like +(uint8_t)42, so IMO the macros are utterly
useless and there's no reason for any code to be using them or
depending on which behavior they have.

Rich

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

[Rich Felker]

On Wed, Dec 03, 2014 at 03:17:18PM +0100, Jens Gustedt wrote:
> 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 :)

5.2.4.2.1 says "Moreover, except for CHAR_BIT and MB_LEN_MAX, the
following shall be replaced by expressions that have the same type as
would an expression that is an object of the corresponding type
converted according to the integer promotions"

I would assume their signedness at the preprocessor level is supposed
to match the signesness of the types they're required to have, which
would be int, and thus signed, for any unsigned type whose values are
representable in int.

Rich