Repository navigation
[cstdint.syn.2] is not in line with intention #3521
Description
I find
The header defines all types and macros the same as the C standard library header <stdint.h>.
to not fully reflect the intention as the
defines... same as the C standard library header
would mean, that cstdint also needs to define non std:: version of aliases. This is also against:
[library.5]
the contents of each header cname is the same as that of the corresponding header name.h as specified in the C standard library. In the C++ standard library, however, the declarations (except for names which are defined as macros in C) are within namespace scope of the namespace std. It is unspecified whether these names (including any overloads added in [language.support] through [thread] and [depr]) are first declared within the global namespace scope and are then injected into namespace std by explicit using-declarations.
I propose to reword the [cstdint.syn.2] or remove it (since library.5 already handles this case).
In case of rewording it could sound like:
The header defines all types and macros the same as the C standard library header <stdint.h>, except for the types, which are defined in the namespace std.
Activity
tkoeppe commentedon Dec 4, 2019
I think this is the subject of long-standing library issue http://wg21.link/lwg2820, which is just never quite important enough to be handled. But we should definitely make some changes here. I venture to say that those aren't editorial, though, and should be handled by LWG.
jwakely commentedon Dec 4, 2019
@tkoeppe I don't think it's the same as (pun intended) that, and I do think it's editorial.
The topic of this issue is not the macros, which can't be in or out of namespace std anyway, because they're macros. The issue is that "the same as" suggests "declares the same types, in the same namespace" i.e.
<cstdint>is required to put the types in the global namespace. That is not the intent of those words, and so clarifying it seems editorial to me.jwakely commentedon Dec 4, 2019
What the words mean is that after including both
<cstdint>and<stdint.h>,std::same_as<std::int_least32_t, ::int_least32_t>is true. i.e. the implementation is not allowed to definestd::int_least32_taslongif::int_least32_tisint. It is only saying the typedefs must refer to the same underlying types, not that "all the same declarations are provided, in the same namespaces".dawidpilarski commentedon Dec 4, 2019
In such case, the wording would be more like:
then it makes distinction of the two types.
namespace std{ struct S{}; }struct S{};are different definitions
jwakely commentedon Dec 4, 2019
Or "every typedef declared in this header denotes the same type as the corresponding typedef in the C standard library header
<stdint.h>". Maybe we just want that as a blanket statement for all the<cxxx>headers. We never want to allow e.g.std::max_align_tto be different to::max_align_t.tkoeppe commentedon Dec 4, 2019
@jwakely: yes, good point, thanks. I always took "same as" to mean that "the type defined by the alias is the same type (not type name!) as that defined by C; I didn't interpret "same as" to appertain to the declarations. The clarification seems useful (though I also don't think it's terribly misleading at the moment).
dawidpilarski commentedon Dec 4, 2019
Should I create PR with @jwakely wording for that?
jensmaurer commentedon Dec 6, 2019
Sure, go ahead (with the "blanked wording for all
<cxxx>headers" approach).dawidpilarski commentedon Dec 6, 2019
pull request created:
#3528
frederick-vs-ja commentedon Aug 2, 2023
Is there really an issue?
[extern.types]/1 (has been existing since C++98) reads: