Austin Group Issue Tracker - Issues

0001979: conflicting specification for open("existing-directory", O_RDONLY | O_CREAT, 0644)

Sun, 05 Apr 2026 05:13:40 +0000

The description of open() explains O_CREAT with a paragraph that starts:

O_CREAT If the file exists, this flag has no effect except as noted under O_EXCL below. <...>

'file' is of course the XBD 'file' which includes directories, devices, etc. So, open(O_RDONLY|O_CREAT) naming a directory that exists should behave the same as open(O_RDONLY) of that same path.

Then later the ERRORS section contradicts that:

[EISDIR] The named file is a directory and oflag includes O_WRONLY or O_RDWR, or
includes O_CREAT without O_DIRECTORY, or <...>

0001966: Current/previous job definition scattered and ambiguous

Thu, 02 Apr 2026 15:10:37 +0000

POSIX defines the "current job" as:

> In the context of job control, the job that will be used as
> the default for the fg or bg utilities.

(https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/basedefs/V1_chap03.html#tag_03_93).

With the fg utility specification stating:

> no job_id operand is given, the job_id for the job that was
> most recently suspended, placed in the background, or run as a
> background job shall be used.

(https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/utilities/fg.html)

Previous job is defined as:

> In the context of job control, the job that will be used as
> the default for the fg or bg utilities if the current job
> exits.

(https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/V1_chap03.html#tag_03_286)

We however need to refer to the "jobs" utility specification to
make some sense out of that:

> The character '+' identifies the job that would be used as a
> default for the fg or bg utilities; this job can also be
> specified using the job_id %+ or "%%". The character '-'
> identifies the job that would become the default if the
> current default job were to exit; this job can also be
> specified using the job_id %-. For other jobs, this field is a
> . At most one job can be identified with '+' and at
> most one job can be identified with '-'. If there is any
> suspended job, then the current job shall be a suspended job.
> If there are at least two suspended jobs, then the previous
> job also shall be a suspended job.

(https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/utilities/jobs.html)

That suggests "the job_id for the job that was most recently
suspended, placed in the background, or run as a background job
shall be used" from the "current job" definition is to be
interpreted as:
1. the most recently suspend job if there are suspended jobs
2. if not, the job most recently "placed in the background"
(whatever that means) if there are some.
3. if not the job most recently started in background.

As far I know, the only ways to "place" a job in the background
are to suspend them whilst they are in foreground or start them
in background in the first place, so there are several ways to
interpret that "2" above:

a) 3 is redundant but it's to emphasis that it's the time of
last suspend (whilst in foreground, or not, to be clarified)
that's important for those jobs that have been suspended.
b) it's to say that jobs that have ever been suspended (have
ever been in foreground before) take precedence over jobs that
were started in background in the first place and were never
suspended.
c) maybe "resumed in background" (by way of bg or any other way
SIGCONT is delivered) was intended instead of "placed in
background".

The Rationale there also has:

> The job control features provided by bg, fg, and jobs are
> based on the KornShell. The standard developers examined the
> characteristics of the C shell versions of these utilities and
> found that differences exist. Despite widespread use of the C
> shell, the KornShell versions were selected for this volume of
> POSIX.1-2024 to maintain a degree of uniformity with the rest
> of the KornShell features selected (such as the very popular
> command line editing features).

However, testing ksh88 from Solaris 11.4's /usr/xpg4/bin/sh and
ksh93u+m/1.0.8 2024-01-01, those are clearly not compliant, as

$ sleep 1001
^Z[1] + Stopped sleep 1001
$ sleep 1002 &
[2] 20308
$ jobs
[2] + Running sleep 1002 &
[1] - Stopped sleep 1001

The suspended job is not made the current job, whilst that's the
part that is clearly unambiguous in the spec in the description
of the jobs utility.

In practice, I see a lot of variation between implementations,
and I don't think I've come across one that fully implements any
of the interpretations listed above.

0001978: Standardize .shrc as the default interactive sh start-up file when ENV is unset

Wed, 01 Apr 2026 00:29:09 +0000

Many shells support rc files as a way for the user to provide an initialization script for their interactive shell (for example, Bash's .bashrc and the Korn family's .kshrc). However, there is no standard location that the user can rely on for a portable POSIX sh initialization script across compliant systems. The only standard user initialization mechanism in POSIX sh is the ENV environment variable, but that mechanism is only useful if ENV has first been set, typically by a login profile or by implementation-specific start-up processing, and in existing practice it is also used either directly as the interactive initialization file or to name a shell-specific rc file.

The following is a proposal to introduce the .shrc file to be used by interactive sh when the ENV variable is not set. This preserves the precedence of the existing standard mechanism, which already commonly takes precedence over per-shell rc-file initialization, and provides a standard fallback location for portable POSIX sh use. This mechanism is essentially the analogue in POSIX sh of the POSIX ex/vi .exrc file (where EXINIT takes precedence over .exrc), and some of the wording has been borrowed from its definition.

0001970: exit status unclear for iconv -c on invalid input

Tue, 31 Mar 2026 11:11:40 +0000

The iconv utility specification has:

> The presence or absence of -c shall not affect the exit status of iconv.

Which suggests that iconv should return the same exit status with -c that it should without.

But the exit status section has:

> >0
> An error occurred.

Which seems to be in contradiction.

AFAICT, both the iconv that comes with GNU libc and GNU libiconv exit with status 1 and no error message in:

printf '\303\n' | iconv -c -f UTF-8

For instance and the one from FreeBSD gives no error and exit with 0.

I've not tested other implementations.

BTW, all three implementations exit with 1 and report an error message when the decoding error is found at the end (like in printf '\303' | iconv -c -f UTF-8), which seems to be in breach of the POSIX specification. Not sure whether that's intentional or not.

0001971: Changing lex prefixes

Thu, 26 Mar 2026 16:24:10 +0000

The yacc utility has a -p option that allows the use of a prefix other than the default "yy" - which is useful when linking multiple parsers in the same program/library. Alas, lex does not have a similar option even though they are supposed to be used together. This is an interface mismatch.

0001977: posix_spawn_file_actions_addopen and posix_spawn_file_actions_adddup2 contridiction with respect to OPEN_MAX.

Thu, 26 Mar 2026 05:23:12 +0000

The ERRORS section for posix_spawn_file_actions_addopen states that it should fail with errno set to EBADF if "The value specified by fildes is negative or greater than or equal to {OPEN_MAX}." It then goes on to state that "It shall not be considered an error for the fildes argument passed to these functions to specify a file descriptor for which the specified operation could not be performed at the time of the call. Any such error shall be detected when the associated file actions object is later used during a posix_spawn() or posix_spawnp() operation." The same text is used for posix_spawn_file_actions_adddup2.

On systems where the open file descriptor limit can be changed and OPEN_MAX returns the limit given by RLIMIT_NOFILE, this text is contradictory. The first quoted text suggests that increasing RLIMIT_NOFILE after posix_spawn_file_actions_addopen, but before posix_spawn, is not allowed. The second quoted text suggests that it is allowed.

The description of https://austingroupbugs.net/view.php?id=418 only mentions the second quoted text for posix_spawn_file_actions_addclose. However, at some point it seems to have changed to "these functions". Therefore, I think it was probably the intention to make this change.

0001974: tabs: wrong description of semantics of arbitrary tab stops

Sun, 22 Mar 2026 00:13:58 +0000

To get tab stops with a standard interval of 8:
$ tabs -8

Analogous to that when arbitrary tab stops are used:
$ tabs 1,9,17,25

Tab stop value:

* is > 0
* represents a column (left-most being 1) where cursor moves and output occurs after preceding \t character
* as a special case, the 1st tab stop value is always 1 (whether explicitly specified or not) to demonstrate that without preceding \t character output occurs in the left-most column

The above is true for most common implementation of tabs from ncurses.

I believe that indicated sentence:

> The phrase "tab-stop position N" shall be taken to mean that, from the start
of a line of output, tabbing to position N shall cause the next character output
to be in the (N+1)th column position on that line.

is wrong with regards to what actual semantics of operand(s) is.

For additional context, this came up in following:

* https://github.com/gwsw/less/issues/737

I've tried to summarize in following comment:

* https://github.com/gwsw/less/issues/737#issuecomment-4033517061

Further of note are comments by @avih who were instrumental in tracking down
historical sources of tabs and its documentation.

0001976: specify array variables and syntax

Fri, 13 Mar 2026 21:10:07 +0000

POSIX sh specifies one array per function, the argument array

many sh implementations support having array variables past the argument array

due to posix shell specifying a syntax for the argument array, sh implementations
with array extensions naturally landed on similar and compatible syntax

mksh, ksh93, bash, zsh, osh, yash, all support the following syntax:
foo=(a b "c d" e)
foo+=(f g)
"${foo[@]}" # a b "c d" e f g
"${foo[*]}" # "a b c d e f g"
"${foo[expr]}" # indexed by expr, where expr is evaluated like $(( expr ))
"${#foo[@]}" # 6, the lenght of foo

additionally, mksh, ksh, and zsh, support declaring arrays as such:
set -A name -- values

notably ksh does not implement the name=(values) syntax, but has no other syntax
that would conflict with it either

ash and dash do not currently implement any sort of arrays, but also have
no syntax that conflicts with the existing extensions

0001975: at_quick_exit Description in Search Results has Stray Characters

Thu, 12 Mar 2026 15:31:40 +0000

When searching for _exit at https://pubs.opengroup.org/onlinepubs/9799919799/, the search results pane shows these results:

_Exit, _exit — terminate a process
at_quick_exit — register a function to to be called from \f2quick_exit()
pthread_exit — thread termination
quick_exit — terminate a process
thrd_exit — thread termination

Notice the "\f2" before quick_exit() on line 2. This error does not appear on the linked to page for quick_exit().

0001973: awk "numeric string " origins

Sat, 07 Mar 2026 11:48:05 +0000

The awk specification (https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/utilities/awk.html#tag_20_06_13_02) has:

<<<
A string value shall be considered a numeric string if it comes from one of the following:

1. Field variables
2. Input from the getline() function
3. FILENAME
4. ARGV array elements
5. ENVIRON array elements
6. Array elements created by the split() function
7. A command line variable assignment
8. Variable assignment from another numeric string variable
>>>

It can be interpreted as meaning that

awk 'BEGIN{$1 = "10"; print ($1 > 2)}'

should return 1 for instance. But no implementation that I know does so. By assigning a string to $1, it loses that special property whereby when containing a string that looks like a number it shall be considered as a number.

Same applies for ARGV, FILENAME...

Typo in rationale section btw:

> also shall have the numeric value of the numeric string" was removed
>from several sections of the ISO POSIX-2:1993 standard because *is*
> specifies an unnecessary implementation detail

is -> it

0001972: Determinism in POSIX Utilities

Thu, 05 Mar 2026 16:55:48 +0000

This ticket concerns determinism in POSIX utilities: the property that, for a given implementation, invoking a utility with the same declared inputs (options, operands, input files, and specified environment) yields the same observable results.

This property is increasingly important in modern software development and distribution practices, including artifact signing, verification, auditing, and what is commonly referred to as reproducible builds. Many widely used systems and projects rely on deterministic tool behavior as an implicit assumption when building software and producing distributable artifacts, including: Arch Linux, Debian, Fedora, openSUSE, FreeBSD, NetBSD, GNU Guix, Tor, etc.

The intent of this proposal is not to address interoperability between different systems or implementations. Rather, it concerns intra-implementation behavior. In particular, running the same utility with the same options, operands, input files, and relevant environment on the same system should not produce different results due to undeclared or arbitrary factors such as the current time or date, process identifiers, randomness, or unrelated filesystem state, except where such behavior is explicitly permitted by the specification.

For example, invoking:

c17 foo.c

is not expected to produce identical output across different systems or implementations. However, invoking the same command multiple times on the same system with the same inputs should not result in observably different output solely due to nondeterministic implementation choices. On the flip side,

c17 foo.c bar.c

and

c17 bar.c foo.c

should be allowed to produce different results if the implementation so chooses.

This proposal is concerned with utilities whose output formats or behaviors are partially or fully unspecified by POSIX, yet for which deterministic behavior is reasonably expected. Examples include, but are not limited to, ar, c17, delta, lex, pax, and yacc.

0001969: strptime() %y with a 1 digit field

Thu, 05 Mar 2026 16:23:09 +0000

The strptime() %y description says it is the "last 2 digits of the year" but this is misleading, as later text makes it clear the field can have 1 digit.

Specifically, the description of %y says "leading zeros shall be permitted but shall not be required". Since leading zeros are not required, a single digit input field is explicitly permitted, e.g. "1" is allowed; it doesn't have to be "01". Likewise, the statement "A leading '+' or '-' character shall be permitted" means that there is no requirement for there to be two digits because the only way for a 2-character field to have a leading '+' or '-' is if the second character is the only digit.

0001968: All "pure" functions (including unspecified ones) must be safe with regard to async signals, or no signal handler is.

Thu, 26 Feb 2026 16:31:54 +0000

It is common practice in compilers, to generate code using inline functions provided by the runtime that're internal to the implementation, most notably, libgcc_s emit 64-bit arithmetic codes for 32-bit targets. Setting aside the relevance of 32-bit system aside first, the capability of CPUs vary from one architecture to another, so there necessitates these kind of inline stubs on some architecture while not on others.

However, the standard currently says:

> All other functions (including generic functions) and function-like macros may be unsafe with respect to signals

making essentially any code that does anything other than calling async-signal safe functions unsafe.

---

I propose that, we define "pure" functions and declare this class of functions safe in signal handlers - typical characteristic of these functions include:
1. their behavior is deterministic with regard to their inputs (and their state should we decide to allow them to keep state),
2. they do not modify the memory of its callers unless a non-const-qualified pointer is explicitly given,
3. any state they keep (should we decide to allow it) are have access semantic that're safe with regard to signals.

C23 has introduced 'attributes', some of which are geared towards permitting compiler optimizing calls to "pure" functions, so we can consult their text during word smithing.

0001967: still references old IEEE-754 standard issued in 1985.

Thu, 26 Feb 2026 16:13:57 +0000

Current spec says:

HUGE_VAL: A positive double constant expression, not necessarily representable as a float. Used as an error value returned
by the mathematics library. HUGE_VAL evaluates to +infinity on systems supporting IEEE Std 754-1985.
HUGE_VALF: A positive float constant expression. Used as an error value returned by the mathematics library. HUGE_VALF evaluates to
+infinity on systems supporting IEEE Std 754-1985.
HUGE_VALL: A positive long double constant expression. Used as an error value returned by the mathematics library. HUGE_VALL
evaluates to +infinity on systems supporting IEEE Std 754-1985.
INFINITY: A constant expression of type float representing positive or unsigned infinity, if available; else a positive constant
of type float that overflows at translation time.
NAN: A constant expression of type float representing a quiet NaN. This macro is only defined if the implementation supports
quiet NaNs for the float type.

which made reference to the older floating point standard published in 1985, when a revised IEEE-754-2019 is available.

0001965: Why isn't pthread_equal async-signal safe?

Tue, 17 Feb 2026 10:58:46 +0000

Currently there are 4 pthread_* functions that're async-signal-safe, including pthread_self.

IMHO, there's no reason to not make pthread_equal safe, unless during some thread control operation, some function would modify the internal data structure if pthread_t is not a scalar.

Additionally, unless some implementation _does_ alter pthread_t handle, I think it's perfectly fine to require that the arguments be const-qualified, or that pthread_t be a pointer to a const-qualified data structure.

0001963: sccs create should use get

Tue, 17 Feb 2026 10:58:08 +0000

The sccs frontend to the SCCS utilities performs a get operation after a successful create operation. The way POSIX currently defines create is actually how many implementations implement the enter operation, not defined by POSIX. While this behavior is not made explicit by man pages in several of the below flavors, they are all confirmed by either the source code or by non-man vendor documentation:

1. Sun SCCS (https://docs.oracle.com/cd/E19504-01/802-5880/6i9k05dhr/index.html)
2. IBM AIX SCCS (https://www.ibm.com/docs/en/rational-synergy/7.2.1?topic=terms-using-creating-adding-deleting-removing-objects)
3. Heirloom SCCS (sccs.c: line 108)
4. schilytools SCCS (sccs.c: line 126)
5. GNU CSSC (sccs.c: line 206)

0001961: assert.h lacks static_assert macro

Tue, 17 Feb 2026 10:57:37 +0000

C11 introduced the static_assert() macro, which C17 kept (and C23 transformed into a keyword).

0001959: dd conv=lcase and conv=ucase should only translate single byte locales

Fri, 23 Jan 2026 12:09:00 +0000

The `conv=lcase` and `conv=ucase` to `dd` require that conversion be done as specified by `LC_CTYPE`. Here is the description of `conv=lcase`, for reference:

> Map uppercase characters specified by the LC_CTYPE keyword tolower to the corresponding lowercase character. Characters for which no mapping is specified shall not be modified by this conversion.

This requirement means that if `LC_CTYPE` is a multibyte locale, one may have to read across block boundaries to have a full character for case conversion. For example using 512-byte blocks, a UTF-8 character like д, encoded as 0xd0 0xb4, might have 0xd0 at byte 512 of the first block and byte 0xb4 at byte 1 of the second block. This is not a problem if `dd` behaves on single bytes instead of characters.

However, introducing case conversion means we we must read entire multibyte characters, even if they extend across a block. Also complicating factor is that case conversion may change the length of the character in Unicode. Take the following example:

$ python3 -c 'print(len("ß"))'
1
$ python3 -c 'print(len("ß".upper()))'
2

If we have an input block containing all ASCII characters and `ß` as the last character, using `conv=ucase,sync bs=512` would result in a 512-byte output block followed a second block contains the second byte of uppercase `ß` and 511 NUL bytes. This is probably not what someone expects when using `dd`.

0001913: clarify/define the meaning of n<&n and m>&m redirections

Tue, 13 Jan 2026 17:09:10 +0000

Hey.

This originated from a thread that started at
https://collaboration.opengroup.org/operational/mailarch.php?soph=N&action=show&archive=austin-group-l&num=38114&limit=100&offset=100&sid=

In short:
The motivation was whether it's possible to portably differentiate whether a non-zero exit status originated from a utility or failed redirection on that.
The idea was that, with the clarifications from #1879 and assuming that there is at least on exit status which a utility is known not to use, a construct like the following:
( command exec || exit 125; utility )
where the subshell is merely to clean up any redirections, can be used to differentiate between a redirection error (which above would be indicated by 125) or a non-zero exit status from the utility.

For file descriptors less than or equal to 2, this should already be guaranteed to work portably, as POSIX demands those to be passed on to the utility.
For FDs greater than two, this is no longer guaranteed, though.

An idea was brought up by Harald van Dijk, that n<&n and m>&m could be used e.g.:
( command exec || exit 125; utility n<&n... m>&m... )
in order to "manually" pass on on any such FDs.

Questions remained:
a) Does that behaviour even follow from POSIX (in an obvious way where it's really clear that shells should behave like this, not just some wobbly way)
b) Does it even solve the original problem, or could e.g. such a n<&n respectively m>&m fail itself (not e.g. because a file doesn't exist, but because of something like resource exhaustion, etc.)

When the original thread was continued a bit later at:
https://collaboration.opengroup.org/operational/mailarch.php?soph=N&action=show&archive=austin-group-l&num=38279&limit=100&offset=0&sid=
it apparently turned out that n<&n and m>&m redirections are not defined because POSIX uses the wordings:
"The redirection operator: [n]<&word shall duplicate one input file descriptor from another"
respectively
"The redirection operator: [n]>&word shall duplicate one output file descriptor from another"
i.e. one from another, implying the two must not be the same, as Geoff Clare pointed out.

0001958: typo in if_indextoname(3)

Tue, 13 Jan 2026 17:03:21 +0000

In the CHANGE HISTORY section {IF_NAMESIZE} is misspelled as {IF_NAMESIZ}.

0001954: please allow shells to unignore signals

Tue, 13 Jan 2026 17:02:40 +0000

The specification of the trap utility has:

<<<
Signals that were ignored on entry to a non-interactive shell cannot be trapped or reset, although no error need be reported when attempting to do so. An interactive shell may reset or catch signals ignored on entry.
>>>

In this day and age, that requirement is unhelpful and annoying. That means one has to resort to things like perl or shells that ignore that requirement to work around it. For example, to make sure SIGPIPE is not ignored:

#! /bin/sh -
if [ -n "$RESTORED_SIGPIPE" ]; then
  unset -v RESTORED_SIGPIPE
else
  RESTORED_SIGPIPE=1 exec perl -e '$SIG{PIPE} = "DEFAULT"; exec @ARGV' -- "$0" "$@"
fi

I guess POSIX introduced that requirement because that's what the Bourne shell or ksh88 did back then, and they likely did it because they were written before BSD job control was invented in the 80s, so handling of "background" jobs was done by ignoring SIGINT/SIGQUIT, and restoring their disposition in those jobs would defeat that.

Nowadays, we should no longer need that. In any case, even back then that requirement would not make sense in an interactive shell which likely explains why POSIX doesn't mandate it there.

So unless there's another good reason that still holds today (but I doubt so, zsh has been ignoring that for 35 years and I don't think anyone ever complained), I'd suggest dropping it.

That comes back regularly in usenet or stackexchange discussions, with one of the work arounds being to switch shell to zsh.

0001953: getdelim() behavior is ambiguous on empty file

Tue, 13 Jan 2026 17:01:21 +0000

When Issue 7 added getdelim() and getline() in 2008, the intent was that we would be standardizing the interface already implemented by glibc at the time.

However, a recent glibc bug report complained that the wording in POSIX disagrees with the behavior of glibc when calling getdelim() on an empty file: https://sourceware.org/bugzilla/show_bug.cgi?id=28038. According to the bug report, if the file is empty, then getdelim() immediately encounters end-of-file and must return -1, but even though it is returning -1, it is NOT returning an error (errno is not set and the stream error indicator is clear), so the argument was that POSIX requires *lineptr to be an empty string (truncating any contents already in lineptr from an earlier invocation). But the glibc behavior at the time POSIX added the interface was to leave the contents of *lineptr unchanged unless returning a non-negative value for success (although lineptr itself might be modified, as it could have been allocated prior to detecting end-of-file).

So glibc recently patched its behavior to guarantee that on encountering EOF that a NUL terminator is added, but this has the observable side effect that where you could previously use a loop of getline() until returning -1 to grab the last line of a file (think, for example, of the summary line of a du invocation), now such a loop leaves lineptr on an empty string rather than the last line of the file.

While POSIX is clear that encountering EOF on success must use a null terminator, it is less obvious whether returning -1 falls under the same rules, or whether POSIX should have allowed the traditional glibc behavior. On the one hand, guaranteeing that a non-NULL lineptr always has a null terminator even when getdelim() fails makes it harder for a programmer mistake to escalate into a SEGFAULT for reading beyond the bounds of the array. On the other hand, forcefully terminating lineptr to an empty string after the last non-empty line with a proper terminator takes away a convenient access to the contents of the last line of a file, although it is not quite obvious whether that was ever portable.

The desired action lists two approaches: one to relax things to explicitly permit the older glibc behavior and warn the user that the contents of *lineptr are not necessarily usable on a return of -1 (although this still does not guarantee stable access to the last line of the file); the other to tighten the specification to mandate that any time *lineptr is returned non-NULL, it must be null terminated even if the overall function fails for any other reason. I'm not sure which of the two options the group will prefer.

0001952: (n)gettext and NLSPATH

Tue, 13 Jan 2026 16:59:52 +0000

On XSI systems, gettext and ngettext require NLSPATH to take precedence over TEXTDOMAINDIR. This is undesirable because it means every one-off script using translations has to install its translation files in the system's global locale directory. Should such scripts instead choose to change NLSPATH to, say, a local subdirectory then all other utilities used by the script (including gettext/ngettext) would lose access to their own translations. Imagine a situation where in order to use an install script you have to first install its messages/catalogs.

0001951: getopts example oversight

Tue, 13 Jan 2026 16:58:04 +0000

The example snippet handles ? instead of \?. It still works but only by accident (the ? wildcard still matches the literal question mark returned by getopts) because no other options are handled after it.

0001949: Restore the traditional realloc(3) specification

Fri, 09 Jan 2026 17:58:28 +0000

Name
alx-p0001r0 - Restore the traditional realloc(3) specification

Category
Remove UB.

[ADMINISTRATOR EDIT: removed personal email addresses from Description]

History
<https://www.alejandro-colomar.es/src/alx/alx/std/posix/alx-p0001.git/>

alx-0029r0 (2025-06-17):
- Initial draft.

alx-0029r1 (2025-06-20):
- Full rewrite after the recent glibc discussion.

alx-0029r2 (2025-06-21):
- Remove CC. Add CC.
- wfix.
- Drop quote.
- Add a few more principles
- Clarify why ENOMEM is used in this proposal, and make it
optional.
- Mention exceptional leak in code checking (size != 0).
- Clarify that part of the description of realloc can be
editorially removed after this change.

alx-0029r3 (2025-06-23):
- Fix diff missing line.
- Remove ENOMEM from the proposal.
- Clarify that ENOMEM should be retained by platforms already
using it.
- Add mention that LLVM's address sanitizer will catch the leak
mentioned in r2.
- Add links to real bugs (including an RCE bug).

alx-0029r4 (2025-06-24):
- Use a better link for the Whatsapp RCE.
- s/Description/Rationale/
- wfix
- Mention that glibc <2.1.1 had the BSD behavior.
- Add footnote that realloc(3) may fail while shrinking.

alx-0029r5 (2025-06-26):
- It was glibc 2.1.1 that broke it, not glibc 2.2.
- wfix
- Mention in the footnote that the pointer may change.
- Document why not go the other way around. It was explained
several times during discussion, but people keep suggesting
it.

alx-0029r6 (2025-06-27; n3621):
- Clarify that the paragraph about what happens when the size
is zero refers to when the total size is zero (for calloc(3)
that is nmemb*size).
- s/Unix V7/V7 Unix/
- tfix.
- wfix.

Brno meeting (2025-08-27):
- 9/13/6
- Along the lines: 21/1/5
- People recognized in the dinner after the meeting, and in the
reflector, and in corridor discussions, that they hadn't
understood the paper, and that it was more well thought than
they initially thought. They would change their vote to be
in favour with this proposal.

alx-0029r7 (2025-09-21):
- Add link.

alx-p0001r0 (2025-09-21):
- Fork POSIX proposal from ISO C proposal.

See also
<https://www.alejandro-colomar.es/src/alx/alx/wg14/alx-0069.git/>
<https://nabijaczleweli.xyz/content/blogn_t/017-malloc0.html>
<https://sourceware.org/pipermail/libc-alpha/1999-April/000956.html>
<https://inbox.sourceware.org/libc-alpha/nbyurzcgzgd5rdybbi4no2kw5grrc32k63svf7oq73nfcbus5r@77gry66kpqfr/>
<https://inbox.sourceware.org/libc-alpha/20241019014002.3684656-1-siddhesh@sourceware.org/T/#u>
<https://inbox.sourceware.org/libc-alpha/qukfe5yxycbl5v7ooskvqdnm3au3orohbx4babfltegi47iyly@or6dgf7akeqv/T/#u>
<https://github.com/bminor/glibc/commit/7c2b945e1fd64e0a5a4dbd6ae6592a7314dcd4b5>
<https://github.com/llvm/llvm-project/issues/113065>
<https://www.austingroupbugs.net/view.php?id=400>
<https://www.austingroupbugs.net/view.php?id=526>
<https://www.austingroupbugs.net/view.php?id=688>
<https://sourceware.org/bugzilla/show_bug.cgi?id=12547>
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_400.htm>
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n868.htm>
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2438.htm>
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf>
<https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/realloc.html>
<https://pubs.opengroup.org/onlinepubs/9699919799.2013edition/functions/realloc.html>
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120744>
<https://lore.kernel.org/lkml/20220213182443.4037039-1-keescook@chromium.org/>
<https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/>
<https://gbhackers.com/whatsapp-double-free-vulnerability/>

Rationale
The specification of realloc(3) has been problematic since the
very first standards, even before ISO C. The wording has
changed significantly, trying to forcedly permit implementations
to return a null pointer when the requested size is zero. This
originated from the intent of banning zero-sized objects from
the language in C89, but that never worked well in
retrospective, as we can see from the fallout.

None of the specifications have been good, and C23 finally gave
up and made it undefined behavior.

The problem is not only theoretical. Programmers don't know how
to use realloc(3) correctly, and have written weird code in
their attempts. This has resulted in a lot of non-sensical code
in configure scripts[1], and even bugs in actual programs[2].

[1] <https://codesearch.debian.net/search?q=%5Cbrealloc%5B+%5Ct%5D*%5B%28%5D%5B%5E%2C%5D*%2C%5B+%5Ct%5D0%5B%29%5D&literal=0>
[2] <https://lore.kernel.org/lkml/20220213182443.4037039-1-keescook@chromium.org/>

In some cases, this non-sensical code has resulted in RCEs[3].

[3] <https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/>

However, this doesn't need to be like that. The traditional
implementation of realloc(3), present in V7 Unix, inherited by
the BSDs, and currently available in a range of systems,
including musl libc, doesn't have any issues regarding zero-size
allocations. glibc --which uses an independent implementation
rather than a Unix derivative-- also had this behavior
originally; it changed to the current behavior in 1999
(glibc 2.1.1), only for compatibility with C89, even though
ironically C99 was released soon after and removed the text that
glibc was trying to comply with, and introduced some new text
that was very confusing, and one of its interpretations would
make the new glibc behavior non-conforming.

Code written for platforms returning a null pointer can be
migrated to platforms returning non-null, without significant
issues.

There are two kinds of code that call realloc(p,0). One
hard-codes the 0, and is used as a replacement of free(p). This
code ignores the return value, since it's unimportant. This
code currently produces a leak of 0 bytes plus associated
metadata on platforms such as musl libc, where it returns a
non-null pointer. However, assuming that there are programs
written with the knowledge that they won't ever be run on such
platforms, we should take care of that, and make sure they don't
leak. A way of accomplishing this would be to recommend
implementations to issue a diagnostic when realloc(3) is called
with a hardcoded zero. This is only an informal recommendation
made by this proposal, as this is a matter of QoI, and the
standard shouldn't say anything about it. This would prevent
this class of minor leaks.

Moreover, in glibc, realloc(p,0) may return non-null, in the
case where p is NULL, so code must already take that into
account, and thus code that simply takes realloc(p,0) as a
synonym of free(p) is already leaky, as free(NULL) is a no-op,
but realloc(NULL,0) allocates 0 bytes.

The other kind of code is in algorithms that realloc(3) an
arbitrary size, which might eventually be zero. This gets more
complex.

Here's the code that should be written for AIX or glibc:

errno = 0;
new = realloc(old, size);
if (new == NULL) {
if (errno == ENOMEM)
free(old);
goto fail;
}
...
free(new);

Failing to check for ENOMEM in these platforms before freeing
the old pointer would result in a double-free. If the program
decides to continue using the old pointer instead of freeing it,
it would result in a use-after-free.

In the platforms where realloc(p,0) returns non-null, such as
the BSDs or musl libc, it is simpler to handle it:

new = realloc(old, size);
if (new == NULL) { // errno is ENOMEM
free(old);
goto fail;
}
...
free(new);

Whenever the result is a null pointer, these platforms are
reporting an ENOMEM error, and thus it is superfluous to check
errno there.

Most code is written in this way, even if run on platforms
returning a null pointer. This is because most programmers are
just unaware of this problem. Part of the reason is also that
returning a non-null pointer with zero bytes is the natural
extension of the behavior, which is what programmers intuitively
expect from libc; that is, if realloc(p,3) allocates 3 bytes,
r(p,2) allocates two bytes, and r(p,1) allocates one byte, it is
natural by induction to expect that r(p,0) will allocate zero
bytes. Most algorithms naturally extend to 0 just fine, and
special casing 0 is artificial.

If the realloc(3) specification were changed to require that
realloc(p,0) returns non-null on success, and that realloc(p,0)
only fails when out-of-memory (and assuming the implementations
will continue setting errno to ENOMEM), then code written for
AIX or glibc would continue working just fine, since the errno
check would be redundant with the null check. Simply, the
conditional (errno == ENOMEM) would always be true when
(new == NULL).

Then, there are non-POSIX platforms that don't set ENOMEM. In
those platforms, code might do this:

new = realloc(old, size);
if (new == NULL) {
if (size != 0)
free(old);
goto fail;
}
...
free(new);

That code would continue working with this proposal, except for
a very rare corner case, in which it would leak. In the normal
case, (size != 0) would never be true under (new == NULL),
because a reallocation of 0 bytes would almost always succeed,
and thus not return a null pointer under this proposal.
However, in some cases, the system might not find space even for
the small metadata needed for a 0-byte allocation. In such
case, the (size != 0) conditional would prevent deallocating
'old', and thus cause a memory leak. This case is exceptional
enough that it shouldn't stop us from fixing realloc(3).
Anyway, on an out-of-memory case, the program is likely to
terminate rather soon, so the issue is even less likely to have
an impact on any existing programs. Also, LLVM's address
sanitizer will soon able to catch such a leak:
<https://github.com/llvm/llvm-project/issues/113065>

This proposal makes handling of realloc(3) as straightforward as
one would expect, with only two states: success or error. There
are no in-between states.

The resulting wording in the standard is also much simpler, as
it doesn't need to define so many special cases.

For consistency, all the other allocation functions are updated
to both return a null pointer on error, and use consistent
wording.

Why not go the other way around?
Some people keep asking why not go the other way around: why not
force the BSDs and musl to return a null pointer if size is 0.
This would result in double-free and use-after-free bugs, which
can result in RCE vulnerabilities (remote code execution), which
is clearly unacceptable.

Consider this code, which is the usual code for calling
realloc(3) in such systems:

new = realloc(old, size);
if (new == NULL) {
free(old);
goto fail;
}
...
free(new);

If realloc(p,0) would return a null pointer and free the old
block, then the third line would be a double-free bug.

Prior art
gnulib
gnulib provides the realloc-posix module, which aims to wrap the
system realloc(3) and reallocarray(3) functions so that they
behave in a POSIX-complying manner.

It previously behaved like glibc. After I reported that it was
non-conforming to POSIX, we discussed the best way forward,
which we agreed was the same direction that this paper is
proposing now for C2y. The implementation was changed in

gnulib.git d884e6fc4a60 (2024-11-04; "realloc-posix: realloc (..., 0) now returns nonnull")

There have been no regression reports since then, as we
expected.

V7 Unix, BSD
The proposed behavior is the one endorsed by Doug McIlroy, the
author of the original implementation of realloc(3) in V7 Unix,
and also present in the BSDs.

glibc <= 2.1
glibc was implemented originally to return non-null. It was
only in 1999, and purely to comply with the standards --with no
requests by users to do so--, that the glibc maintainers decided
to switch to the current behavior.

Design decisions
This change needs two changes, which can be applied all at once,
or in separate steps.

The first step would make realloc(p,s) be consistent with
free(p) and malloc(s), including when p is a null pointer, when
s is zero, and also when both corner cases happen at the same
time. This change would already turn the implementations where
malloc(0) returns non-null into the end goal we have. This
would require changes to (at least) the following
implementations: glibc, Bionic, Windows.

The second step would be to require that malloc(0) returns a
non-null pointer. This would require changes to (at least) the
following implementations: AIX.

This proposal has merged all steps into a single proposal.

Caveats
n?n:1
Code written in the near future should be careful, in case it
can run on older systems that are not fixed to comply with this
stricter specification. Thus, code written in the near future
should call realloc(3) similar to this:

realloc(p, n?n:1);

When all existing implementations are fixed to comply with this
stricter specification, that workaround can be removed.

ENOMEM
Existing implementations that set errno to ENOMEM must continue
doing so when the input pointer is not freed. If they didn't,
code that is currently portable to all POSIX systems

errno = 0;
new = realloc(old, size);
if (new == NULL) {
if (errno == ENOMEM)
free(old);
goto fail;
}
...
free(new);

would leak on error.

Since it is currently impossible to write code today that is
portable to arbitrary C17 systems, this is not an issue in
ISO C.

- New code written for C2y will only need to check for
NULL to detect errors.

- Code written for specific C17 and older platforms
that don't set errno will continue to work for those
specific platforms.

- Code written for POSIX.1-2024 and older platforms
will continue working on POSIX C2y platforms,
assuming that POSIX will continue mandating ENOMEM.

- Code written for POSIX.1-2024 and older will not be
able to be run on non-POSIX C2y platforms, but that
could be expected.

The only important thing is that platforms that did set ENOMEM
should continue setting it, to avoid introducing leaks.