Open trcrsired opened 10 months ago
First, it's fine for an implementation to implement the integer charconv code in headers if they so choose. The floating point charconv code is the crazy expensive stuff.
Second, "freestanding" doesn't imply header only. It is totally fine for there to still be runtime support in a freestanding implementation. So if an implementation wants charconv to stay in their runtime support, then they can do that.
Finally, freestanding C++ has always required more facilities from C than the strict minimum of freestanding C (notably, abort
and friends). The fact that P2338 requires more than a minimal freestanding C implementation is mentioned in the paper, and was discussed in LEWG.
Note that the macro errno
is not made freestanding, and <charconv>
(including the freestanding-deleted portion) doesn't need to rely on it.
@ben-craig The title claimed that errno.h
is made freestanding, but it seem that the current wording doesn't specify any meow.h
header to be freestanding in C++ even if meow.h
is freestanding in C or the corresponding cmeow
is freestanding. Is this intended?
I agree with your reading @frederick-vs-ja . It is not intended to exclude the C <meow.h>
headers. I'll file an LWG issue on it.
charconv is not possible to implement in freestanding without creating a static lib and -ffreestanding might change the definitions of errno (since errno.h does not exist in the toolchain)