ben-craig / freestanding_proposal

20 stars 0 forks source link

Why did you make errno.h, system_error and charconv freestanding? #6

Open trcrsired opened 10 months ago

trcrsired commented 10 months ago

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)

ben-craig commented 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.

frederick-vs-ja commented 10 months ago

Note that the macro errno is not made freestanding, and <charconv> (including the freestanding-deleted portion) doesn't need to rely on it.

frederick-vs-ja commented 10 months ago

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

ben-craig commented 10 months ago

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.

ben-craig commented 10 months ago

https://cplusplus.github.io/LWG/issue4049