Austin Group Issue Tracker - Issues

0002000: XSH 3/strfmon misses info and needs attention

Thu, 17 Sep 2026 19:28:07 +0000

In the sequel, I shall refer solely to strfmon(), but everything applies equally to strfmon_l().
The mechanism by which the locale data is made available is not material to anything in this defect report.

The following defects are ordered in decreasing order of importance, as I see them, except with some related issues grouped adjacent to one another.
All defects (except probably the last) should be corrected however.

When issue 0001199 was fixed (the changes made as the result of that I generally agree with) one part of the original issue report seems to have been forgotten.
It (0001199) said:

However, without a distinction between positive and negative values, and without a visible decimal separator, this behaviour is useless, or even dangerous

The issue with positive/negative was (mostly) handled, the issue when there is no visible decimal separator was not, and needs to be.
See issue 0001199 for an example illustrating the problem.
Following on from the previous, it is also unclear, even with the text as amended by issue 0001199, what should be done when a locale defines non-empty strings to be used as the signs, but specifies the same string for both cases.
This is effectively the same problem as issue 0001199 dealt with, being unable to determine whether a value is positive, or negative, just in a different way.

Relevant to this, and what makes it different from the empty string case, is that the result might differ when the position of the sign string is different for positive and negative values.
That is, it is not necessarily simply invalid to use the same non-empty string for both the positive and negative signs.
It is not always clear in the specification when character means character and when it means byte or perhaps "character from a restricted character set", or something different entirely.

That the specification generally means character is clear from line 69523:

The format is a character string, beginning and ending in its initial state, if any, ...

which would make no sense if character was being used as a synonym for the C programming language char data type, or simply a byte, or even a character from the Portable Character Set from the standard (XBD 6.1).
Those kinds of characters have no state, hence no initial state to require.

This issue crops up in many places, the most obvious is in (line 69540):

An '=' followed by a single character f which is used as the numeric fill character.

The text (lines 69541-69542) attempts to add some meaning to this:

In order to work with precision or width counts, the fill character shall be a single byte character; if not, the behavior is undefined.

But that makes no sense at all.
To work with the precision and width counts, the fill character needs to occupy one column position in the output.
That distinction has nothing at all to do with how many bytes are in the representation of the character.
A single byte character, in some locales, might be zero-width or occupy multiple columns in the output, even in a constant width font.
Obvious examples are the character, and ASCII control characters.
A or would have different, but related, issues.
It is also unclear why the behaviour should be undefined should the application not give a suitable character as the fill character value.
That is a truly machiovellian punishment.
Would it not be better to simply make it clear than in such cases the intended alignment might not be able to be achieved?
That is, the implementation should just use whatever character is specified as f when needed as the fill character, and if that character is not suitable for the purpose, the output will look odd, instead of nice.
No calling abort(), or removing all of the user's files, which "undefined behaviour" would permit.

A similar problem can be found at line 69577:

A decimal digit string w specifying a minimum field width in bytes

which also makes little sense, if one assumes as the specification seems to imply, at a minimum, that the objective is to be able to align output from multiple calls to strfmon().
What matters is the appearance of the final output, not how many bytes of encoded characters are needed to achieve that result.
The number of bytes is, or should, only be relevant when determining whether the result fits within the maxsize number of bytes available in the output buffer.
Everything else should be using characters, possibly constrained in some cases to be printing or graphic characters, and perhaps sometimes constrained by the widths of the characters concerned.
This needs to be clear in the specification, with no mention of bytes in any of the relevant places.

The same problem arises with everything else inserted into the resulting output string, including the mon_decimal_point and the strings.
Lines 69592-69594 do explain the idea:

To ensure alignment, any characters appearing before or after the number in the formatted output such as currency or sign symbols are padded as necessary with characters to make their positive and negative formats an equal length.

though that text does give rise to the immediately following defect.

It should also be made clear what other constraints, if any, must be met for the output to be able to be nicely aligned.
The use of a monospace (constant width) font to display the result is an obvious one, without that achieving alignment requires much more complex mechanisms that simply counting characters, which is all that is available here.
But is it expected that all the values intended to be able to be aligned have neen formatted using the same locale, or is it intended that output from different locales be able to be intermixed, and remain aligned?
The answer to that question constrains what constraints should be placed upon what is permitted in locales for the mon_decimal_point (I have a fake locale, for testing purposes, which uses $'\u3002' as that character, and the font I use for my terminal sessions renders that character in 2 columns).
Is strfmon() expected to work with such a value?
It does, even to aligning (approximately) as intended, as the alighnment is primarily for the value to the left of the radix, which is unaffected by this.
But something similar might be used as the mon_thousands_sep.
Further, different locales might have different mon_grouping settings.
My fake locale uses "2;3;2;3;2" which is going to result in a different number of separators being inserted in some values than the more common "3".
As one call to strfmon has no way to communicate decisions to another, nor to predict what locale might be in use when the next call is made, it might seem necessary to constrain the alignment goal to apply only as long as the same locale is used for all relevant strfmon calls.
But that might also be too strict, perhaps as long as the locales used all use the same mon_grouping, and use as their mon_decimal_point and mon_thousands_sep strings which occupy the same number of columns as the equivalent setting in all other locales used in a sequence intended to align correctlty, that would be enough?

Did no-one ever consider any of these questions?
The text at lines 69592-69594:

To ensure alignment, any characters appearing before or after the number in the
formatted output such as currency or sign symbols are padded as necessary with
characters to make their positive and negative formats an equal length.

concentrate entirely upon making the positive and negative output forms of equal length, but the text at lines 69582-69584:

This option can be used to keep the formatted output from multiple calls to the strfmon( ) function aligned in the same columns.

makes it clear that the aim that is implied by lines 69592-69594 is not sufficient to meet the expectations of the strfmon specification, and that more precision is required to meet the overall objective.

That is, if for positive numbers, the sign follows the value, and for negative nnumbers the sign precedes the value, then, to keep the numeric parts of a positive and a negative value aligned, both of them must allocate space in the resulting
string for the possible negative sign before the value, and the possible positive sign following the value (when positive signs are being included), so that either of them might be used to occupy the sign value.
What's more, that is what implementations I have seen actually do.
Simply having the positive and negative formats being of equal length is not suffficient.

It is also not stated anywhere, but clearly is intended (I hope), that the expected alignment is only achieved if the same format string is used for all the applicable calls to strfmon().
A corollary to the previous two points, is that it should be made explicit that aligned values can only be expected to remain aligned when displayed or printed, if they are rendered in a constant width font, or at least one in which all characters are represented in a non-negative integer multiple of a fixed column width.
The description of "grouping characters" (a term for which incidentally I can find no definition in the standard, though it is obvious that in this context it means the mon_thousands_sep characters inserted to perform the grouping function of monetary output values, which is a defined operation) and how they apply to the Left Precision given in lines 69589-69590 is one of the least useful specifications I think I have ever seen.
It states (lines 69589-69590):

If grouping has not been suppressed with the '^' flag, and it is defined for the current locale, grouping separators are inserted before the fill characters (if any) are added.

The pre-conditions are simple enough, but I would interpret the action as meaning that each "grouping separator" (another undefined term) inserted replaces one (or perhaps more) of the fill characters, which then fill in any remaining unused positions as specified in the previous paragraph (lines 69581-69588).
The subsequent sentence (line 69591), which ends the paragraph, about the inapplicability of grouping to fill characters, even if they are digits, is clear enough as it stands.

But as illustrated by the examples (see lines 69640-69642 (or 69643-69645 or 69646-69648) in comparison with lines 69649-69651 which, apart from the use of a non-space fill character in the alternatives of the former, which is immaterial, show the same example, except the former has grouping enabled, and the latter with it suppressed), and from observing what is done by actual implementations, that is not what is intended at all.
Rather, the value given by the Left Precision "n" value, is to be increased by the maximum number of "grouping separators" which would be needed if a value to be formatted generates n (as specified) digits before the radix character (decimal-point) if any.
Then the value is formatted, and the number of "grouping separators" required for the actual value are inserted, and finally the increased value of n is used to fill any remaining unused positions with fill characters.
That is, the use of grouping can increase the number of fill characters to be used for a particular value, and the actual left precision width from what is in the conversion specification, but never decrease it, compared to when grouping is not used.

How, an implementer, or an application writer, is intended to determine the intended behaviour from the written specification bamboozles me.
It needs rewriting.

Note also, that though the linux manual page for this function attempts to make this clear, it is not a lot better:

Next, there may be a left precision of the form "#" followed by a decimal digit string.
If the number of digits left of the radix character is smaller than this, the representation is padded on the left with the numeric fill character.
Grouping characters are not counted in this field width.

That would make it seem as if the number of grouping characters inserted, or which might be inserted, has no effect on the padding inserted by the left precision, which is not correct either.
The ERRORS section at lines 69628-69630 states the functions shall fail if:
- [EINVAL]
  
  The '+' flag was included in a conversion specification and the locale's positive_sign and negative_sign values would both be returned by localeconv( ) as empty strings.
The APPLICATION USAGE section, at lines 69672-69676:

The '+' flag should be used with care, because if the locale's positive_sign and negative_sign values are both empty strings, there is no way to distinguish negative from positive values with signs and therefore strfmon( ) fails. If the application has a preference for signs but parentheses are acceptable, it should try strfmon( ) with the '+' flag first, and if it fails with [EINVAL] then repeat the call without the '+' flag.

and the RATIONALE at lines 69678-69680:

The [EINVAL] error condition applies only when the '+' flag is used because this flag indicates that the application requires the use of signs, and if there are no signs in the locale data then this requirement cannot be satisfied.

together expand upon this intended unique use.

While implementations are generally permitted to add error numbers, and to add meanings to errors the standard specifies, as specified by XSH 2.3 at lines 17831-17833:

Implementations may support additional errors not included in this list, may generate errors included in this list under circumstances other than those described here, or may contain extensions or limitations that prevent some errors from occurring.

that same section goes on to place a restriction upon this implementation freedom, at lines 17839-17841 (and following for more restrictions not relevant here):

Implementations may generate error numbers listed here under circumstances other than those described, if and only if all those error conditions can always be treated identically to the error conditions as described in this volume of POSIX.1-2024.

Taken together all of this implies, to me anyway, that the implementation may not generate EINVAL for any error other than the one listed, as an application would then be unable to ascertain that the problem was the '+' in the format string, and offer a different format for the locale in question in that case.

The problem all this causes for the implementation, is just how it should deal with applications which fail to meet their shall obligations, for example the one at line 69529:

The application shall ensure that a conversion specification consists of the following sequence:

I appreciate that when an application fails to comply with its obligations, implementation behaviour is unspecified, or perhaps even undefined, and is certainly beyond the scope of the standard.
This however does not help the implementer, who must do something in such cases.
Further as it seems above, the implementer is prohibited from using the obvious EINVAL error code in such a situation.
Further, it does not help the application writer either, if some implementations simply ignore such issues and continue formatting as best they can, others return -1 and a seemingly random error code, and yet others simply call XSH 3 section 3/abort (pages 577-558).

At the very least, the specification should offer some guidance in this situation, and probably rewrite the application usage and rationale, so as to no longer constrain EINVAL such that it cannot be used by the implementation for other issues.
The standard offers no guidance on what should be done, should some of the data expected to be provided by the locale, is not defined there.
The POSIX locale is one which does not supply any.
Particularly after the resolution of issue 0001199, some of this has
been dealt with, but not all.
This includes the lack of a (non-empty) mon_decimal_point.
There is also no discussion on what should be done if any of the specified strings are non-empty, but do not contain anything which produces a visible representation in the output.

There should be.
Returning to APPLICATION USAGE section, at lines 69672-69676:

The '+' flag should be used with care, because if the locale's positive_sign and negative_sign values are both empty strings, there is no way to distinguish negative from positive values with signs and therefore strfmon( ) fails. If the application has a preference for signs but parentheses are acceptable, it should try strfmon( ) with the '+' flag first, and if it fails with [EINVAL] then repeat the call without the '+' flag.

That suggests that simply omitting the '+' flag, will cause stfrmon() to use parentheses as the indicator for negative values.
That is not what the post-issue 0001199 standard causes to happen.
Instead, as stated on lines 69567-69571 when considering the case that
neither of the '+' nor '(' flags are included in the format:

If the style cannot be determined from these locale values because a value that needs to be used would be returned by localeconv() as {CHAR_MAX}, the style used shall be that specified for the '+' flag; if this would cause strfmon( ) to fail because the locale's positive_sign and negative_sign values would both be returned by localeconv( ) as empty strings, strfmon( ) shall behave as if the negative_sign value was the string "-".

In other words, unless the format specifies the '(' flag (in which case this section is never reached, and its positive_sign and negative_sign and sign placement values are all ignored), if the '+' flag is not given, and the locale's default is not to use parentheses to indicate negative values, then the resulting output would use the empty positive_sign if the value is non-negative, and use "-" instead of an empty negative_sign if the value is negative.

This APPLICATION USAGE text needs to be rewritten to take that into account.
At times the standard is too specific in what it specifies.
For example, at lines 69557-69558:

If a sign's placement cannot be determined from these locale values because a value that needs to be used would be returned by localeconv() as 0 or {CHAR_MAX}, ...

Why is it important what the issue is with the value?

The range of values for the sign position are 0 to 4, with 0 not being useful for the situation being discussed in those lines, or {CHAR_MAX} to mean no value is supplied.
But what if the locale data specifies a value of 7?
That has no (currently) defined meaning, and hence is not useful for determining the placement of the sign, but it is not "returned by localeconv() as 0 or {CHAR_MAX}", so what is the implementation to do?

This kind of over specification should be removed, it is not important why the sign placement cannot be determined from the locale values, just that it cannot.
Note that this is not just a fanciful, perhaps even imagined, impossible case.
A later version of the standard may add extra possible values to any of the fields for which a set of numeric designated choices are provided, and an older implenentation (an instance of stfrmon compiled into an existing applicaion for example) may encounter a previously invalid value, and needs to know how to handle that case.
This is not an instance where "behaviour is unspecified" (or even "undefined") is an acceptable outcome.
The standard must be permitted to evolve without invalidating existing applications.
The EXAMPLES section, page 2132 (lines 69632-69670) assumes the existence of "a locale for the US" and, to make sense of the example output, what that locale must contain.
I can find no justification in the standard to assume that such a locale exists anywhere.
I certainly believe that most readers would understand USD as the international currency symbol for the United States of America, and $ as its national currency symbol, and probably that its frac_digits and int_frac_digits would usually both be two.
I am not sure however that using a "-" to indicate negative values, and nothing for positive ones, rather than enclosing negative values in parentheses, or use of CR for positive and DB for negative, is how such a locale would be defined.
Nor would I necessarily expect the sign, if used, to precede the currency symbol, rather than follow it.

If some fictional locale is to be used for examples, regardless of whether that locale might be an actual locale on some system used by one or more of the actual writers of the text, then at least as much of it as is needed to understand the examples should be presented in the specification.

Further, there should certainly be examples given where the POSIX (aka C) locale, the only one the standard actually specifies, is used.
Had there been, some of the problems this specification had before issue 0001199 rectified them, and some of the problems it still has, might have been recognised and corrected much sooner than this.
The DESCRIPTION at lines 69524-69526 contains:

..., and conversion specifications, each of which shall result in the fetching of zero or more arguments which are converted and formatted.

"Zero or more" ?

The zero case is obviously for the %% format conversion specification (which I personally would not treat as a conversion specification at all, but as an escaping mechanism, but that isn't the point here).

But "or more" ??

One is certainly more than zero, and one (exactly) is what every other format conversion requires.
Why not just say "zero or one", and not leave the reader wondering when more than one might be required?
Of course, if there is some hidden intent to allow indirect specification of the field width, the left precision, or the right precision, or some or all of those, in the way that the printf family of functions permit, which would perhaps be a useful addition, though not supported by any implementation of which I am aware, then the "or more" would be justified.
In the same paragraph as the previous defect (lines 69524-69526) the text elided at the beginning of the text quoted previously is:

The format is a character string, beginning and ending in its initial state, if any, that contains two types of objects: plain characters, which are simply copied to the output stream, ...

but there is no definition anywhere of what is a plain character.
The intent is obvious, but standards should not rely upon readers being able to deduce from what appears to be obvious, they should be explicit.
The locale specification (XBD 7) and the specification of strfmon seem to lack the ability to format currency amounts in the (old style to be sure) formats previously used in the UK, and other countries including AU and NZ.
That is, the Lsd format, as in £10/- or £9-19-11 and similar constructions.
There may be other formats in use, or previously in use, which are similarly neglected.

There is also no way to specify that other characters, rather than '(' and ')' be used to surround values, further it should be possible to have different characters surrounding positive and negative values - the positive_sign and negative_sign settings cannot be used for this, as only one of them is ever used for any particular value, and whichever that is is only ever used once.

These issues should be fixed, but this is not the place to do it.
Thus I will not offer potential solutions - the issue is here just so it is clear that the problems are known, and cannot at some future time be dismissed with "We didn't ever consider those possibilities."

0001992: Add getexepath() to retrieve the absolute pathname of the current process executable image.

Tue, 15 Sep 2026 04:03:15 +0000

There is currently no standardized, portable mechanism in POSIX to retrieve the absolute pathname of the executable file currently executing the calling process. Runtimes, language interpreters, and asset loaders must resort to highly unportable, platform-specific mechanisms.

- Linux relies on parsing the "/proc/self/exe" symlink or using `getauxval(AT_EXECFN)`.
- FreeBSD and NetBSD use a sysctl interface via KERN_PROC_PATHNAME.
- SunOS implements getexecname().
- macOS implements a non-POSIX _NSGetExecutablePath() function.

Others like OpenBSD force us to rely on argv[0] and (if the process didn't start with an absolute path) scanning the PATH environment variable, which is fundamentally unsafe and unreliable (someone else in the PATH with the same name appearing early is picked up). Furthermore, the parent process can easily manipulate or empty argv and envp during an execve() call, leaving the child completely unable to safely determine its own physical location.

Adding a native, safe API to POSIX eliminates immense cross-platform boilerplate across programming frameworks and toolchains that require explicit binary path auditing.

0001616: Standardize mktemp utility

Mon, 14 Sep 2026 16:55:58 +0000

The current standard has no reliable and convenient utility to create temporary file or directory, despite that low-level interfaces, mkstemp/mkdtemp, are available for this use case. The mktemp(1) utility is a perfect candidate to fill this gap. Its interface is fairly simple and mostly consistent across various implementations, however not without some differences. I evaluated GNU, LSB, NetBSD, FreeBSD, OpenBSD, Illumos, Solaris, sbase, toybox, busybox implementations and here is what I found:

- FreeBSD, NetBSD accept multiple templates. Others do not.
- FreeBSD does not specify -p option. Others do.
- LSB does not specify -d and -p options. Others do.
- FreeBSD, NetBSD accept parameter for -t option. Others do not.
- FreeBSD, NetBSD use -t option to specify prefix. Others use it to explicitly tell mktemp to create temporary file in temporary directory rather than in current directory.
- All have different default value for template.
- All have different requirements regarding how many Xs template should contain, but it seems they all accept six Xs.
- sbase, Illumos, Solaris override -p parameter with TMPDIR value if it is set. Others do not.
- GNU overrides -p parameter with TMPDIR value or /tmp if parameter is empty string. Others do not.
- OpenBSD, Illumos, Solaris(not sure), toybox do not allow '/' in template if -p option is passed. Others do.

Given that, I think mktemp interface is not completely lost and below is my attempt to make it portable.

0001997: cp,mv,pax should not need to diagnose timestamp downresing

Mon, 14 Sep 2026 16:06:46 +0000

When the command ‘mv /a/SOURCE DEST’ crosses file system boundaries, the resulting file DEST can have a timestamp with less low-order information as described by futimens (POSIX.1-2024 page 1075 lines 36821–36822). For example, the source file’s timestamp might be 1786900895.478636836 but the destinations might be on a FAT32 filesystem so its timestamp might be only 1786900895.47, as FAT32 has only 10 ms resolution.

This topic recently came up in a bug report for GNU mv <https://bugs.gnu.org/13601#40>. One commenter there said that this loss of information triggers the clause for mv (page 3199 lines 108114–108115) saying “If the duplication of the file characteristics fails for any reason, mv shall write a diagnostic message to standard error” which means a diagnostic is required.

GNU mv, and I expect all other mv implementations, does not do that. Instead, it uses futimens or utimensat to set DEST’s timestamps, and if that succeeds it does not issue a diagnostic. Checking whether DEST’s timestamp lost low-order info would require another system call, and I don’t know of any mv implementation that does so.

A clarification is needed here for the phrase “duplication of the file characteristic fails for any reason”. Does the phrase mean that (a) a system call like futimens failed, or does it mean that (b) the destination’s characteristics disagree, even slightly, from the source’s? Although implementations have chosen (a) POSIX could be read as requiring (b).

If an implementation wanted to implement (b), for efficiency it would be helpful if utimensat acquired an additional flag to cause the system call to fail if the timestamp is downresed. However, that would be a separate topic from this bug report, and I know of no platform that has such a flag so at this point it would be pure invention on the POSIX committee’s part.

In the DESIRED ACTION I have attempted to word things so that an implementation can do either (a) or (b). (b) is allowed because an implementation can always issue a diagnostic whenever it likes, so long as it does not change the exit status.

0001998: Where should MANTIS issues be submitted?

Mon, 14 Sep 2026 15:17:10 +0000

I just spent an hour or two filling in an issue report (a long one)
only for when I submitted it to be told there was an invalid security
token, either I had submitted twice (no) or the session had timed
out (possible, given it had taken a LONG time to get all the details
page numbers, line numbers, ... inserted properly. And to decide
what exactly I needed to report.

It told me to press the back button on my browser. I did. All the
text I had entered was gone (in previous interfaces that didn't happen,
I could create a new report, and cut and paste everything from the old
to the new, which would take much less time, and no timeout would
occur - it has been ages since my last interaction with this, I had forgotten
this issue.

0001996: Add SIGEV_SIGNAL_THREAD to allow more efficient handling of sigevent-using functions.

Sun, 13 Sep 2026 22:12:31 +0000

Currently, there are only two notification mechanisms for use with sigevent: SIGEV_SIGNAL and SIGEV_THREAD. Both of these methods have issue preventing their use, and so a new notification should be added.

SIGEV_THREAD typically spawns a new thread on each event, which degrades performance to the point that it defeats the purpose of using such a notification; performing the corresponding blocking opperation in a new thread would typically be both faster and more convenient. SIGEV_SIGNAL requires use of a signal handler; as signal handlers are shared between all threads in a process, this makes it unsuitable for use in a library.

To resolve this, several platforms have added mechanisms to direct the signal to a specific thread. However, this mechanism is not standardised, which imhibits its use. This proposal serves to standardise it.

0001994: exp() assumes default rounding

Fri, 11 Sep 2026 23:39:49 +0000

If the correct value would cause overflow, a range error shall occur
and exp(), expf(), and expl() shall return the value of the macro
HUGE_VAL, HUGE_VALF, and HUGE_VALL, respectively.

0001999: Session timeouts too short

Wed, 02 Sep 2026 15:51:29 +0000

0001976: specify array variables and syntax

Wed, 12 Aug 2026 15:36:30 +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

0001995: Add SHM_ANON to shm_open()

Mon, 10 Aug 2026 22:10:11 +0000

SHM_ANON can be used to create an unnamed shared memory object, which will be automatically destroyed when last reference to it is removed. It is mainly useful for avoiding potential conflicts with already existing shared memory objects, hiding the object from other processes and making the use of shm_unlink unnecessary since the object has no name.

This extension is known to be implemented at least by QNX and FreeBSD. Linux provides similar memfd_create() interface, which can be used to mimic SHM_ANON.

See also: https://github.com/lassik/shm_open_anon

0001949: Restore the traditional realloc(3) specification

Mon, 10 Aug 2026 08:55:56 +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.

0001984: Ambiguous requirements for command -v on printing absolute pathnames

Wed, 29 Jul 2026 07:19:22 +0000

The requirements for command -v read:

- Executable utilities, regular built-in utilities, command_names including a character, and any implementation-provided functions that are found using the PATH variable (as described in 2.9.1.4 Command Search and Execution), shall be written as absolute pathnames.

This is ambiguous as to whether "that are found using the PATH variable" applies to "Executable utilities, regular built-in utilities, command_names including a character, and any implementation-provided functions", or only to "any implementation-provided functions".

Given that "command_names including a character" are never looked up using the PATH variable (as pointed out by Herbert Xu on the dash mailing list), the intent must be that "that are found using the PATH variable" applies only to "any implementation-provided functions", but at least one shell (bash) does not currently write command_names including a character as absolute pathnames, even in POSIX mode, and in my opinion, the current text of the standard does not say it should.

0001993: pthread_create() should allow failure with ENOMEM, not just EAGAIN

Tue, 28 Jul 2026 08:55:40 +0000

pthread_create() is currently defined to allow EAGAIN or EPERM. while _some_ resource issues fit EAGAIN, others do not warrant a retry loop. glibc and bionic both want to return ENOMEM in particular as an unretriable failure.

0001973: awk "numeric string " origins

Mon, 20 Jul 2026 16:11:56 +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

0001987: The option value type for TCP_NODELAY is not specified.

Mon, 20 Jul 2026 15:36:02 +0000

The option value type for TCP_NODELAY is not specified. This seem to be the case since at least Issue 6.

Many other options have types of rank `int`, and their Windows counterparts often have DWORD or similar, as such I believe the type for this option value is most likely also `int`, rather than `_Bool` which may have issue with ABI compatibility.

0001991: touch -d 2026-06-29T00:00:60 should not be required to succeed

Mon, 13 Jul 2026 09:13:35 +0000

The POSIX spec for 'touch' (POSIX.1-2024 page 3451 line 117731) specifies an option -d whose argument uses ISO 8601 notation to specify the time. However, if read literally there is a disagreement with ISO 8601 that I believe is unintentional, and which causes GNU coreutils 'touch' to fail to conform.

The apparent disagreement was introduced in POSIX.1-2017, when -d was added with ISO 8601 syntax, but with semantics that seem to defer to the longstanding -t option in the treatment of the seconds (SS) field, namely, if SS is 60 that should mean the first second of the next minute. This meaning for SS contradicts ISO 8601, which says an SS value of 60 can only mean a leap second.

I expect this disagreement with ISO 8601 was unintentional. Furthermore, the disagreement disagrees with GNU 'touch', which reserves SS=60 for true leap seconds which exist on (non-POSIX) platforms that support leap seconds.

GNU 'touch' takes the not unreasonable position that it is helpful to catch typos, such as hours, minutes or seconds that are out of ISO 8601 range. POSIX surely did not intend to require implementations to implement timestamps in a way that disagrees with ISO 8601. Although some implementations, such as FreeBSD 'touch', treat ":60" as meaning the first second of the next minute, this behavior should not be required.

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

Mon, 13 Jul 2026 09:02:53 +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 <...>

0001989: Confusing reference to "Symbol" for $0

Thu, 09 Jul 2026 15:25:35 +0000

> The symbol $0 shall refer to the entire record

It's not a "symbol", it's the $ operator applied to number 0 that yields the "full record variable", $ 0, $(12/4-3) refer to the same variable.

0001988: Incorrect reference to "whole input record" for $0

Thu, 09 Jul 2026 15:19:49 +0000

In

> The print statement shall write the value of each expression
> argument onto the indicated output stream separated by the
> current output field separator (see variable OFS above), and
> terminated by the output record separator (see variable ORS
> above). All expression arguments shall be taken as strings,
> being converted if necessary; this conversion shall be as
> described in Expressions in awk, with the exception that the
> printf format in OFMT shall be used instead of the value in
> CONVFMT. An empty expression list shall stand for the whole
> input record ($0).

That late sentence is erroneous and misleading as $0's value is only the input record after that record has been read in and before it has been modified.

0001985: Add a dark theme to the HTML rendition

Thu, 02 Jul 2026 15:31:44 +0000

Right now, there's only a light theme of the HTML rendition, which has a bright background.

This may cause eye sore for some readers, who switches back and forth between their IDE and the standard text.

0001548: Addition of a POSIX.utf-8 locale (likely as 7.3 "POSIX.utf-8 locale")

Thu, 02 Jul 2026 12:38:11 +0000

Today's modern POSIX systems use Unicode aware locales, almost all realized via the UTF-8 8-bit character set.
Even though the standard(s) do not offer proper interfaces to deal with this, external libraries (GNU libunicode, ICU) fill this gap in practice.
(These libraries can also be used with UTF-16 and UTF-32 character sets, the latter i think prefers the 16-bit encoding that is in use in a widely distributed commercial non-POSIX operating system.)

As it stands users are using language/territory specific UTF-8 locales in real-life, like en_US.utf8 or de_DE.utf8.
Right now there is no UTF-8 aka Unicode-spectrum POSIX locale available.

Some operating systems (OpenBSD) and some libraries (musl LibC) however, and already, "always work with UTF-8 8-bit" Unicode, giving it the name "C.UTF-8" (musl; and as can be seen, the usual naming scheme mess continues).

0001990: This is a configuration test issue. Please ignore if you see this.

Thu, 25 Jun 2026 19:55:24 +0000

Please ignore.

0001986: This is a configuration test issue. Please ignore if you see this.

Thu, 25 Jun 2026 18:33:07 +0000

Test a new email notification configuration on the new hosting setup.

0001983: typo in sendmsg() EXAMPLES

Thu, 04 Jun 2026 15:16:40 +0000

I'm forwarding a report I received by email from someone else.

On 2026-06-02T15:02:40+0800, Zhai Can wrote:
> https://man7.org/linux/man-pages/man3/sendmsg.3p.html
>
> In the EXAMPLES section it states a "Done." which is weird here. I suppose it
> should be a "None."? A quick grep shows the whole 3p manuals (2017) only have
> the one occurrence.
>
> ~/man-pages-posix-2017/man3p ❯ rg Done.
> sendmsg.3p
> 281:Done.
>
> It's an upstream issue. Also in:
>
> https://pubs.opengroup.org/onlinepubs/9799919799/

Reported-by: Zhai Can <bczhc0@126.com>

0001981: Request to define ssize_t as the signed version of size_t

Thu, 04 Jun 2026 15:12:53 +0000

Currently ssize_t is defined as:
ssize_t shall be signed integer types.
The type ssize_t shall be capable of storing values at least in the range [-1, {SSIZE_MAX}].

But the sizeof ssize_t is not explicitly defined.

And for glibc,musl,cygwin newlib, they all defined that sizeof(ssize_t)=== sizeof(size_t)

And maybe because the sizeof ssize_t is not defined clearly. clang did not defined the sizeof of ssize_t well:

https://github.com/llvm/llvm-project/issues/198975

The glibc defined the sizeof ssize_t to be equal to size_t by the following codes:
#if __WORDSIZE == 32
# define __SWORD_TYPE int
#else
# define __SWORD_TYPE long int
#endif

at
https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/bits/types.h;h=33b582a8eabf09aadc093658db82353c288590d2;hb=HEAD#l118

#define __SSIZE_T_TYPE __SWORD_TYPE
at
https://sourceware.org/git/?p=glibc.git;a=blob;f=bits/typesizes.h;h=466dd36681a7364952e49b73067d66174543cffd;hb=HEAD#l60

__STD_TYPE __SSIZE_T_TYPE __ssize_t; /* Type of a byte count, or error. */
at
https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/bits/types.h;h=33b582a8eabf09aadc093658db82353c288590d2;hb=HEAD#l194

#ifndef __ssize_t_defined
typedef __ssize_t ssize_t;
# define __ssize_t_defined
#endif
at
https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/sys/types.h;h=2b524761748fc2e0576e3b86fd5558e8a9ebcb18;hb=HEAD#l108

And the document of __WORDSIZE is:
/* Size in bits of the 'long int' and pointer types. */
#define __WORDSIZE
at
https://sourceware.org/git/?p=glibc.git;a=blob;f=bits/wordsize.h;h=53013a9275c7c81eccb0356ab956eb2688bcf512;hb=HEAD#l7

So basically glibc is already ensure ssize_t is the same size as size_t. Even thoug the command "/* Size in bits of the 'long int' and pointer types. */" is a bit mis-leading.
As sizeof pointer will not always have the same size as size_t.