All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: libc-alpha@sourceware.org
Cc: gcc@gcc.gnu.org, linux-man@vger.kernel.org
Subject: _ISOCxx_SOURCE
Date: Sat, 13 Jun 2026 14:02:18 +0200	[thread overview]
Message-ID: <ai1DVieT3gTr4J5S@devuan> (raw)

[-- Attachment #1: Type: text/plain, Size: 1523 bytes --]

Hi!

I was reviewing the feature_test_macros(7) page, and found the
documentation of the _ISOC{99,11,23,...}_SOURCE macros to be incorrect.
And thinking about fixing that led me to think that the design of those
macros is less than ideal.

Here's for example some of the problematic text:

        Defining _ISOC23_SOURCE also enables C11, C99, and C95 features.

The above is not true.  See for example some contradicting (and also
incorrect/incomplete) text in the HISTORY section of gets(3):

	glibc header files don’t expose the function declaration if the
	_ISOC11_SOURCE feature test macro is defined.

gets(3) is a C89 and C99 feature, which is disabled with C11 and later
standard versions.  The text saying that _ISOC23_SOURCE enables older
features is only true as much as those features remain in the C23
standard.  And in gets(3), we should say that the function is not
exposed on C11 or later (not just C11).

A better design of this macro would be to have a single identifier, and
use a value to specify the version.  This is how POSIX does it.  We
could call it _ISO_C_SOURCE, and have a value such as 202311L for
requesting C23.  That would make it easier to describe: features are
available within a range of versions; often a half-bounded interval,
starting at a version, and not ending; but other times a bounded
interval, starting at a version, and ending at another version.

What do you think?


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

                 reply	other threads:[~2026-06-13 12:02 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ai1DVieT3gTr4J5S@devuan \
    --to=alx@kernel.org \
    --cc=gcc@gcc.gnu.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.