[cstdint.syn.2] is not in line with intention

[dawidpilarski]

I find

The header defines all types and macros the same as the C standard library header .

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 , except for the types, which are defined in the namespace std.

[tkoeppe]

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]

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

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 define std::int_least32_t as long if ::int_least32_t is int. 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]

In such case, the wording would be more like:

All definitions of types in this header are the same as corresponding types from the C standard library header .

then it makes distinction of the two types.

namespace std{ struct S{}; }

struct S{};

are different definitions

[jwakely]

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_t to be different to ::max_align_t.

[tkoeppe]

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

Should I create PR with @jwakely wording for that?

[jensmaurer]

Sure, go ahead (with the "blanked wording for all <cxxx> headers" approach).

[dawidpilarski]

pull request created: https://github.com/cplusplus/draft/pull/3528

[frederick-vs-ja]

Is there really an issue?

[extern.types]/1 (has been existing since C++98) reads:

For each type T from the C standard library, the types​ ::​T and std​::​T are reserved to the implementation and, when defined, ​::​T shall be identical to std​::​T.