N2968
Prefixes for the Standard Library

1. Changelog

2. Revision 0 - April 12^th, 2022

• 🎉 Initial (and hopefully, only) release!

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:

• _Thread_local

• _Static_assert

• _Atomic

• _Bool (recently fixed)

• _BitInt(…)

• and more…

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.

• stdc_: this name is frequently brought up, even in casual conversation and random social media posts. It was the original choice for this proposal. It is 5 characters, so a bit long. It matches the macro-version that we have been using in the C Standard for some time as well (__STDC_…__). It is a "logical" name to take. It may look silly when nested in C++'s own std namespace (std::stdc_), but that is C++'s problem and if this proposal goes through perhaps they should look into properly truncating name declarations.

• std_: This is another name that is brought up. It is as good as stdc_, and it is shorter. It is also a "logical" name to take, and would not surprise users. It may look silly when nested in C++'s own std namespace (std::std_), but that is C++'s problem.

• iso_: this is a semi-popular suggestion, and is already a reserved name. It follows as logical from the reservations and who is doing the reservations (this is "ISO Standard C", after all). A good alternative to std_.

• isoc_: this is a semi-popular suggestion, and is already a reserved name. It follows as logical from the reservations and who is doing the reservations (this is "ISO Standard C", after all) A good alternative to stdc_.

• c_: this is often mentioned for its shortness and simplicity. It also "looks good" when nested in the C++ std namespace (std::c_foo(…)) but suffers problems of already being used in some places.

• sc_: this prefix is similar to c_ in that it is short and sweet. However, it is also a name prefix that has been used before (e.g. for the semi-popular SystemC specification for C, C++, and similar language space related to hardware).

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.

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: