Prefixes for the Standard Library

Published Proposal,

Previous Revisions:
https://thephd.dev/_vendor/future_cxx/papers/C - Prefixes for the Standard Library.html
Paper Source:
Issue Tracking:
Proposal Category:
Policy and Feature Request
C23, C2Y/C3X and Beyond
ISO/IEC JTC1/SC22/WG14 9899: Programming Language — C


An informal paper detailing the experience of existing practice.

1. Changelog

2. Revision 0 - April 12th, 2022

3. Introduction & Motivation

After a series of papers by Aaron Ballman and Jens Gustedt to provide what are now known as * potentially reserved names* in the C Standard, we enabled strictly-conforming and pedantic implementations of the C Standard to avoid warning on names that were not officially taken by the implementation or standard. This removed a bunch of warnings on potentially non-conforming code that included certain headers and had aggregates with members such as:

struct streptobacillus;
/* previously reserved and UB, now potentially-reserved
   and not UB unless implementation or standard
   takes the name. */

This solves one problem, but leaves another: the actual introduction of names.

3.1. Handling New Names

As of right now, if the C standard or an implementation decides to take the name streptobacillus, the name would get retroactively taken from the user. This is not a real material improvement despite the names being potentially reserved in the C Standard. For over 40 years now, developers and users alike have used a different technique to prevent this kind of name collision from happening: library prefixes. The standard already uses a set of built-in prefixes to add new values to C: names with __ anywhere in the name and starting with _ followed by an uppercase latin letter are reserved for the standard and implementations. Given our past track record, the C Standard chooses names starting with _ followed by an uppercase basic latin letter for its language keywords that are fairly new to the space. This has been the case for:

However, we still do not have a similar consistent practice for the C Standard Library’s functions. Much of these are sourced from C implementations, which means we generally have to follow the behavior and practice of existing C libraries to-the-letter. This can be problematic when we want to make changes to such interfaces, such as Annex K’s bsearch_s or qsort_s, where the callback parameter had its userdata pointer and key element pointers swapped from the original Microsoft Secure Library Extensions proposal. This rendered Microsoft’s implementation of Annex K forever non-conforming for all functions taking a callback without an API and ABI break.

One way to avoid these problems is by providing for a prefix for use with the standard library. This has been proposed before in Nick Stoughton’s [N1345], but Mr. Stoughton’s proposal contained a fatal flaw: it was also for the use of new keywords of the language as well. Therefore, it would not be _Static_assert, but stdc_static_assert. It would not be typeof, but stdc_typeof. This was brought up during the meeting the proposal was discussed - in fact, it was the only relevant detail brought up asides from the paper’s contents itself - and, according to the minutes, immediately after that the poll was taken. The proposal was defeated swiftly and the next topic was discussed.

Some discussion on the reflector 13 years later, more functions were being added to the standard and new areas of interest that already had widely existing practice were being tackled. There were too many builtins and user-named functions which had taken popular library names, like popcnt, popcount, countones, count_ones, and similar for bit intrinsics. Thusly, it was proposed these functions take the prefix stdc_. It was recommended that this was split off into a separate "policy proposal", rather than just incorporating the change into individual proposals.

4. Design

The choice of name will have to be up to Committee Consensus, if it is deemed that a prefix for the standard library would be desirable to aid in prevention of name collisions with the existing ecosystem. Some popular selections for prefixes for the C standard library include the below choices. Note the C Standard now requires up to 32 characters of significant names for external identifiers, so there is some breathing room as opposed to the old limit of 8 characters.

Whatever the Committee chooses for a name, it will be substituted into the wording below for the token STANDARD-C-PREFIX, if any prefix finds consensus in the first place. If nothing happens, then the status quo remains.

5. Specification

The following specification is related to the latest C Standard Draft at the time of publication (N2731).

5.1. Add a new bullet point at the top for globally-reserved macro and library names to §7.1.3 "Reserved Identifiers, paragraph ¶1.

— All identifiers starting with STANDARD-C-PREFIX are reserved for future use.

5.2. Add a new item to the C Charter

Additionally, on top of this wording, the specification changes should also include a change to the C Charter Document to recommend:

New library functionality (not Core Language functionality) should use the prefix STANDARD-C-PREFIX where it is desirable to avoid collision with existing code or widely-established practice that may have divergent APIs and ABIs for the purposes of unification. It is important to leave old code without undue modification.


Informative References

Nick Stoughton. N1345: Namespace Reservations for the C Standard. September 10th, 2008. URL: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1345.htm