Date: Sun, 7 Nov 2021 22:26:50 +0000
Attached is a revised draft of "P2338: Freestanding Library: Character primitives and the C library", that we discussed on Friday, 2021-11-05.
This adds strtok, makes wchar.h optional for freestanding (with a feature test macro), and changes the editorial strategy to keep all the information in 4. Conformance, instead of spread through 7. Library.
The feature test macro is named __STDC_WCHAR_H_FREESTANDING_LIBRARY__, and it is either defined to 0 (if you don't support wchar.h) or defined to a year constant (if you do support wchar.h). This is different from most feature test macros, but it aids users in that they can distinguish between old and new implementations, based on whether the macro is defined at all.
I will also share an implementation strategy in this email. There were some concerns that adding wchar.h support would increase customer code size, even when the wchar.h facilities weren't used. This is because some linkers don't remove unused functionality at a per-function granularity. I will claim that there are workarounds in this situation. In the Linux world, the C library is not contained entirely in one library. Users need to do things like pull in the m (i.e. math) library, the rt library, and the pthread library in order to support all the facilities of a hosted C implementation. A similar strategy could be employed on other implementations to separate out infrequently used pieces from frequently used pieces. A wchar library could be in a separate physical library, and users would only choose to link against it if they specifically needed those facilities. This could even be broken down into a more fine-grained approach, with a wchar_wcslen library, a wchar_wcscmp library, etc. Users that don't care about wchar facilities wouldn't need to change anything in their build process to avoid wchar overhead. This is somewhat moot though, as my paper has been revised to make wchar.h facilities entirely optional in C.
Please let me know about any concerns or questions about this revision. I plan on making it a "P" paper in the next week and getting it into the next C++ mailing.
This adds strtok, makes wchar.h optional for freestanding (with a feature test macro), and changes the editorial strategy to keep all the information in 4. Conformance, instead of spread through 7. Library.
The feature test macro is named __STDC_WCHAR_H_FREESTANDING_LIBRARY__, and it is either defined to 0 (if you don't support wchar.h) or defined to a year constant (if you do support wchar.h). This is different from most feature test macros, but it aids users in that they can distinguish between old and new implementations, based on whether the macro is defined at all.
I will also share an implementation strategy in this email. There were some concerns that adding wchar.h support would increase customer code size, even when the wchar.h facilities weren't used. This is because some linkers don't remove unused functionality at a per-function granularity. I will claim that there are workarounds in this situation. In the Linux world, the C library is not contained entirely in one library. Users need to do things like pull in the m (i.e. math) library, the rt library, and the pthread library in order to support all the facilities of a hosted C implementation. A similar strategy could be employed on other implementations to separate out infrequently used pieces from frequently used pieces. A wchar library could be in a separate physical library, and users would only choose to link against it if they specifically needed those facilities. This could even be broken down into a more fine-grained approach, with a wchar_wcslen library, a wchar_wcscmp library, etc. Users that don't care about wchar facilities wouldn't need to change anything in their build process to avoid wchar overhead. This is somewhat moot though, as my paper has been revised to make wchar.h facilities entirely optional in C.
Please let me know about any concerns or questions about this revision. I plan on making it a "P" paper in the next week and getting it into the next C++ mailing.
Received on 2021-11-07 16:26:56