consider whether [cinttypes.syn] is in the right place

[zygoloid]

<cinttypes> is a weird header. It contains abs and div for intmax_t, plus some primitive string \<-> integer conversion functions. And some printf / scanf format string macros. And we put it in the iostreams portion of the standard.

Is this really best?

We once kept all the formatting and parsing stuff within [input.output], but now we have [charconv], and somewhere near there seems like a much better fit for the primitive formatting and parsing functions in .

The integer div / abs functionality seems to belong in [numerics].

The format string macros seem to belong near [cstdio.syn], which is where the header currently is.

And maybe we could "compromise" and put the header in [cstdint].

So: I'm not sure what's best, but we should talk about it some more, especially given that the advent of [charconv] significantly weakens the argument for the current home.

[tkoeppe]

We can try an approach similar to <cstddef>: the synopsis lives in some place, but its parts are documented in (I believe) three different parts of the Standard.

[BoPersson]

The current placement might actually be a mistake.

In early drafts like http://wg21.link/N2009 the header is mentioned in clause 18.2 [lib.support.limits]

"The headers <limits>, <climits>, <cfloat>, and <cinttypes> supply characteristics of implementation-dependent fundamental types (3.9.1)."

But the header synopsis surprisingly appeared at the very end of clause 27 (input/output).

When I mentioned this inconsistency on the comp.std.c++ news group, it was fixed by striking all references to the header from clause 18. I had perhaps expected the synopsis to be moved. :-)

[tkoeppe]

I mean, I can see how one might have come to that conclusion. cintypes isn't about characteristics of types, but rather about how you use printf. To that end, cinttypes includes cstdint, which is part of [support.general]. (The abs and div bit are weird, though.)

[zygoloid]

I think I would like the idea of treating this like <cstddef> and distributing the detailed description... except that we don't have much in the way of detailed description for this header, just the synopsis, a pointer to the C standard, and bad overloads of std::abs and std::div (that should be made available by <cstdlib>, matching what we do for all the other primitive-type overloads of std::abs).

Hmm. We should point out to LWG that LWG 2294 / 2192 missed a spot...

[jensmaurer]

Editorial meeting consensus: This is the least worst location for the header. Remaining issue: This has abs/div declarations that need to become part of the complete overload set for these functions.