Austin Group Issue Tracker - Issues

0001999: Session timeouts too short

Thu, 15 Oct 2026 21:14:22 +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.

0002000: XSH 3/strfmon misses info and needs attention

Mon, 12 Oct 2026 16:17:05 +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."

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

Wed, 07 Oct 2026 10:58:16 +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.

0001633: Add memrchr

Mon, 05 Oct 2026 14:42:55 +0000

memrchr is a simple and useful function that is similar to memchr, except it finds the last occurrence of a byte. It is provided by the following implementations already:

* glibc (https://www.man7.org/linux/man-pages/man3/memrchr.3.html)
* musl
* openbsd (https://man.openbsd.org/memrchr.3)
* freebsd (https://man.freebsd.org/cgi/man.cgi?query=memrchr&manpath=FreeBSD+13.1-RELEASE+and+Ports)

(And probably many others).

0001622: Standardize getpeereid function

Mon, 05 Oct 2026 14:40:56 +0000

This function provides a mechanism to get credentials of a peer that
created/initialized unix socket. Such mechanism is useful for AF_UNIX servers
and clients that need a reliable way to know each other's credentials to
implement e.g. accounting or authorization. See also: https://cr.yp.to/docs/secureipc.html

It is quite portable and already implemented at least in QNX, AIX, FreeBSD,
NetBSD, OpenBSD, Cygwin. Linux and Illumos/Solaris provide similar interfaces,
though they don't look suitable for inclusion. Linux SO_PEERCRED is incompatible
with OpenBSD due to a different structure name, whereas Illumos/Solaris
getpeerucred() is just terrible; it allocates memory and requires a dedicated
function to free it.

I also evaluated LOCAL_PEERCRED from FreeBSD and LOCAL_PEEREID from NetBSD that
are used there to power getpeereid(). LOCAL_PEERCRED uses structure which has
platform-specific type in it, so I immidiately rejected it. As of LOCAL_PEEREID,
it looks fine, but I afraid if we going to standardize it, it'll cause friction
in systems that already provide similar(and potentially incompatible)interface in
getsockopt(). Therefore let's just add getpeereid.

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

Fri, 02 Oct 2026 10:18:41 +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).

0001930: Add flock(1) utility to manage locks from shell scripts

Thu, 01 Oct 2026 19:56:10 +0000

I myself make extensive use of this utility in my system management etc shell scripts.

It must be said it is not widely available -- as flock(1).
Linux has it, NetBSD has it; semantics are somewhat shared
FreeBSD and DragonFly have lockf(1), which is quite similar, but use lockf(3) (i think).
Busybox (Linux toolbox) has it, with some minimized interface, currently without -w (wait for lock).

If POSIX could standardize this it would be great, and if it would include F_OFD_SETL locks when doing so, that would be even better!

0001832: Add preadv() and pwritev()

Thu, 01 Oct 2026 19:54:16 +0000

0001824: cp: directories and symlinks

Thu, 01 Oct 2026 19:53:37 +0000

I would like to request a clarification on the matter of cp's handling
of symbolic links in the destination.

To begin with, I find the wording of the final paragraph of the
rationale (90876-90880) confusing. It mentions “file types not
specified by the System Interfaces” and implies that symbolic links
fall into that category, but I can no indication anywhere else that
this is the case. On the contrary, the definition of “file” in §3.139
on page 51 explicitly includes “symbolic link” in its enumeration of
file types (1592-1593), before stating that “[o]ther types of files
may be supported by the implementation” (1593-1594).

If we jump back to the description section, the behavior of cp if a
source file is a directory and the corresponding destination file
exists and is a symbolic link is not entirely clear to me. If you
believe the final paragraph of the rationale, it is covered by item 2c
(90638-90639) which says it's implementation-defined. If you don't,
it depends on a couple of additional factors. First, do you consider
the type of the link or the type of its target? (I will come back to
this later.) If you consider the type of the link, or if you consider
the type of its target and its target is not a directory, we turn to
item 2d (90640-90642) which says to emit an error, not descend, and go
on with the next source file. If you consider the type of its target
and its target is a directory, we turn to item 2f (90649-90650) which
says to copy the contents of the source into the destination.

I cannot find any discussion anywhere in the specification for cp of
what to do if the target of a symbolic link does not exist, unless the
second paragraph of item 4c (90697-90698) is intended to cover this
case (but 4c discusses the case where the source is a symbolic link,
so it doesn't tell us what to do if the destination exists, is a
symbolic link, and references a non-existent file).

Now for the matter of whether, if the destination file is a symbolic
link, we should consider instead the type of its target. The
descriptions of the -L and -P options repeatedly use the phrase
“symbolic links encountered during traversal of a file hierarchy”
(cf. 90625, 90627, 90712, 90715). Given that the surrounding text
mostly refers to the source, it is not clear to me whether this phrase
only applies to the source, or to both the source and the destination.
Turning to historical precedent, BSD cp has traditionally followed
symbolic links in the destination hierarchy while GNU cp appears not
to. FreeBSD recently changed its implementation to take the -R, -L,
and -P options into consideration when checking the destination as
well, while the GNU cp documentation appears to state quite clearly
(and, in my opinion, correctly) that these options only apply to the
source. I believe that this change was a mistake, and I intend to
revert it. However, I cannot make up my mind as to whether the
historical behavior of BSD cp (always follow symbolic links in the
destination) is correct. I can easily conceive of situations where
you would want cp to do that, but it has been pointed out to me that
doing so, at least by default, can be considered a security risk.

Note that in the case where the source file is a file and the
destination exists (item 3a lines 90657-90671), the file type of the
destination is not taken into account at all. I am not as concerned
with this case as I am with the directory case, but it should probably
be addressed as well.

To summarize:

- The rationale implies that symbolic links are an extension, which I
believe to be incorrect.

- It is unclear whether symbolic links in the destination should be
followed, and whether the -L and -P options apply, when inspecting
destination paths.

- There is historical precedent for answering these questions with
“yes” and “no”, respectively. Recent history suggests the wording
is vague enough that implementers are confused on the second point.

- The description section does not adequately discuss how cp should
behave if the source is a directory and the destination exists and
is a symbolic link.

- The description section does not consider the type of the
destination at all in the case where the source is a file and the
destination exists.

0001794: Please add tzalloc/tzfree and localtime_rz, mktime_z interfaces

Thu, 01 Oct 2026 19:52:45 +0000

[I copy a mail from austin-group-l@]

As stated in [1] the localtime() and mktime() series of functions
have the inherent problem of not being thread-safe regarding
possible changes to the time zone: in a pure POSIX environment
changes to TZ always affect global data.

If my memory serves correctly, about a decade ago the NetBSD
project contacted the IANA TZ maintainer in order to upstream
a new, truly thread-safe interface that addresses this issue.
Since some time in 2014 (see [1]) the IANA TZ database, which
includes the Public Domain aka open source code as is used by many
projects to implement the time related programming interface,
includes a new series of functions:

timezone_t tzalloc(char const *TZ);
void tzfree(timezone_t tz);

struct tm *localtime_rz(timezone_t restrict zone,
time_t const *restrict clock,
struct tm *restrict result);
struct tm *restrict tm);
time_t mktime_z(timezone_t restrict zone,
struct tm *restrict tm);

[1] https://austingroupbugs.net/view.php?id=1788

If POSIX would offer this interface, the open source (public
domain) code and manual of which are available via the IANA TZ,
truly "thread-safe" time programming becomes possible in POSIX.

This is especially important if no CLOCK_TAI is available.
For an example, here is what the widely used NTP server chrony
performs in order to achieve its task:

tm = gmtime(&when);
if (!tm)
return tz_leap;

stm = *tm;

/* Temporarily switch to the timezone containing leap seconds */
tz_env = getenv("TZ");
if (tz_env) {
if (strlen(tz_env) >= sizeof (tz_orig))
return tz_leap;
strcpy(tz_orig, tz_env);
}
setenv("TZ", leap_tzname, 1);
tzset();

/* Get the TAI-UTC offset, which started at the epoch at 10 seconds */
t = mktime(&stm);
if (t != -1)
tz_tai_offset = t - when + 10;

/* Set the time to 23:59:60 and see how it overflows in mktime() */
stm.tm_sec = 60;
stm.tm_min = 59;
stm.tm_hour = 23;

t = mktime(&stm);

if (tz_env)
setenv("TZ", tz_orig, 1);
else
unsetenv("TZ");
tzset();

if (t == -1)
return tz_leap;

if (stm.tm_sec == 60)
tz_leap = LEAP_InsertSecond;
else if (stm.tm_sec == 1)
tz_leap = LEAP_DeleteSecond;

*tai_offset = tz_tai_offset;

This is especially important if no CLOCK_TAI is available.
For an example, here is what the widely used NTP server chrony
performs in order to achieve its task:

tm = gmtime(&when);
if (!tm)
return tz_leap;

stm = *tm;

/* Temporarily switch to the timezone containing leap seconds */
tz_env = getenv("TZ");
if (tz_env) {
if (strlen(tz_env) >= sizeof (tz_orig))
return tz_leap;
strcpy(tz_orig, tz_env);
}
setenv("TZ", leap_tzname, 1);
tzset();

/* Get the TAI-UTC offset, which started at the epoch at 10 seconds */
t = mktime(&stm);
if (t != -1)
tz_tai_offset = t - when + 10;

/* Set the time to 23:59:60 and see how it overflows in mktime() */
stm.tm_sec = 60;
stm.tm_min = 59;
stm.tm_hour = 23;

t = mktime(&stm);

if (tz_env)
setenv("TZ", tz_orig, 1);
else
unsetenv("TZ");
tzset();

if (t == -1)
return tz_leap;

if (stm.tm_sec == 60)
tz_leap = LEAP_InsertSecond;
else if (stm.tm_sec == 1)
tz_leap = LEAP_DeleteSecond;

*tai_offset = tz_tai_offset;

I want to point out that setting an environment variable can be
a costly operation, but moreover changing the timezone as such
may involve several file system operations, being a potentially
very expensive operation. (By the way the draft 4 uses "file
system" as well as "filesystem".)

With the new interface two timezone objects can be preallocated,
and the operations are totally detached from global data and
multithread-safe.

0001774: Support ' as a format specifier flag character in utilities

Thu, 01 Oct 2026 19:48:49 +0000

[Page numbers against draft 3 for Issue 8; this will need to be updated once Issue 8 is finalized]

During the 31 Aug 2023 teleconference, it was noted that many, but not all, shells have already implemented support for printf "%'i" 1000 outputting thousands separators (for example, producing "1,000" in the en_US.UTF-8 locale), matching what is already specified for the printf( ) function under shading. However, we also discussed that standardizing this would be a feature addition, and therefore too late for Issue 8, and thus not fit for inclusion in 0001771

0001635: iconv: please be more explicit in input-not-convertible case

Thu, 01 Oct 2026 19:47:24 +0000

issue 1007 resolves this to

If iconv() encounters a character in the input buffer that is valid, but for which an identical character does not exist in the output codeset:

If either the //IGNORE or the //NON_IDENTICAL_DISCARD indicator suffix was specified when the conversion descriptor cd was opened, the character shall be discarded but shall still be counted in the return value of the iconv() call.

If the //TRANSLIT indicator suffix was specified when the conversion descriptor cd was opened, an implementation-defined transliteration shall be performed, if possible, to convert the character into one or more characters of the output codeset that best resemble the input character. The character shall be counted as one character in the return value of the iconv() call, regardless of the number of output characters.

If no indicator suffix was specified when the conversion descriptor cd was opened, or the //TRANSLIT indicator suffix was specified but no transliteration of the character is possible, iconv() shall perform an implementation-defined conversion on the character and it shall be counted in the return value of the iconv() call.

However, as Martin Sebor stated in the issue description,

The specification for the iconv() function assumes that every input sequence that is valid in the source codeset is convertible to some sequence in the destination codeset. In particular, the specification doesn't allow the function to fail when a valid sequence in the source codeset cannot be represented in the destination codeset. As an example where this assumption doesn't hold, consider a conversion from UTF-8 to ISO-8859 where a large number of source characters don't have equivalents in the destination codeset.

A survey of a subset of existing implementations shows that they fail with EILSEQ in such cases, despite the specification defining the error condition as "Input conversion stopped due to an input byte that does not belong to the input codeset."

And this is true, GNU C library and GNU libiconv seem to fail output conversion immediately with the same EILSEQ error that denotes invalid input data.
(A much more drastic error, .. is it!?!)

0001818: Add strcasestr() & strcasestr_l()

Thu, 01 Oct 2026 19:44:30 +0000

strcasestr(), a case insensitive version of strstr(), is a popular extension
implemented on many platforms already. Many of them also offer the strcasestr_l() variant to specify the locale to be used for determining
matching characters.

FreeBSD: https://man.freebsd.org/cgi/man.cgi?query=strcasestr&sektion=3
illumos: https://illumos.org/man/3C/strcasestr
Linux (GNU libc): https://man7.org/linux/man-pages/man3/strcasestr.3.html
MacOS: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/strcasestr.3.html
NetBSD: https://man.netbsd.org/strcasestr.3
OpenBSD: https://man.openbsd.org/strcasestr.3
Solaris: https://docs.oracle.com/cd/E88353_01/html/E37843/strcasestr-3c.html

0001831: how do you get the timestamp resolution of a symlink?

Thu, 01 Oct 2026 19:43:38 +0000

The description of pathconf() doesn't contain any specific wording about how it should handle a path which names a symlink. Contrast rename()'s description which says
If either the old or new argument names a symbolic link, rename() shall
operate on the symbolic link itself, and shall not resolve the last
component of the argument.

and unlink()'s description which says
If path names a symbolic link, unlink() shall remove the symbolic link
named by path and shall not affect any file or directory named by the
contents of the symbolic link.

It thus appears that pathconf() is expected to completely follow symlinks and report the values appropriate for the final result of the pathname resolution.

However, it would be useful to be able to get the timestamp resolution (_PC_TIMESTAMP_RESOLUTION) for a symlink, even if it's dangling or points to a path on a filesystem with a different timestamp resolution.

(This was encountered when trying to fix a pax implementation's handling of timestamp comparison for -u when the target filesystem had courser resolution that the source filesystem by using pathconf(_PC_TIMESTAMP_RESOLUTION) on the target path to handle the loss of high-precision time info...but the symlink pointed to a location with high-precision timestamps so it couldn't know to round the times when doing the comparison...)

0000864: Insufficient specification of storage requirements for synchronization objects

Thu, 01 Oct 2026 19:42:57 +0000

This report actually covers multiple questions, mostly related to process-shared synchronization objects, but they all stem from a lack of specification of the storage requirements for synchronization objects, which is the core issue I'm reporting.

The rationale for pthread_mutexattr_init and pthread_mutexattr_destroy provide the only documentation I can find regarding the intended supported usage cases for process-shared mutexes and their storage in shared memory, but this text is not normative.

Here are some specific questions I have:

1. Is it permitted to perform operations on a non-process-shared synchronization objects if they are stored in shared memory by the process that created them, but only used by this process? If so, if this shared memory is mapped more than once at different addresses, is it permitted to access the non-process-shared object mapped at an address different from the address where it was originally initialized?

2. If storage for a synchronization object is deallocated without first destroying the object, is the behavior undefined? The answer to this question has implications for shared memory objects which have already been unlinked and for which there are no file descriptors, which cease to exist when the last process with a mapping unmaps them -- in this case the deallocation of storage is not explicit.

3. Under what conditions can the storage for a synchronization object in MAP_SHARED storage be unmapped without destroying it? As an example of a difficult case, if two threads in a process both access a mutex via a common shared memory mapping, is thread A permitted to unmap the memory after successfully locking and unlocking the mutex if (1) thread B was the previous owner of the mutex, (2) thread B will not attempt to access the mutex again, but (3) due to scheduling, thread B has not actually finished returning from the pthread_mutex_unlock function (this is related to issue 811, but for unmapping rather than destruction).

4. Is it permitted for a thread to lock a mutex in shared memory, unmap it, then later map it again (possibly at a different address) to unlock it?

0001291: Add method to obtain pthread attributes

Thu, 01 Oct 2026 19:39:32 +0000

This is a commonly added pthread capability but there is little agreement on the API name.

https://musl.openwall.narkive.com/dD88I7eH/pthread-getattr-np provides this list of API names for this capability in the context of discussing how to get the current stack information:

glibc: pthread_getattr_np
freebsd: pthread_attr_get_np
netbsd: pthread_attr_get_np and pthread_getattr_np

RTEMS follows glibc/linux with pthread_getattr_np.

If this capability is provided, then the current stack information can also be obtained.

The naming pattern pthread_[sg]attr_* is used to modify the pthread_attr_t structure used in a pthread_create() call. The Linux name of pthread_attr_get() seems like a choice which is an easy name and wouldn't be confused.

0000031: Want to know what mail header information is put in bug mails

Thu, 01 Oct 2026 19:27:18 +0000

is there a difference in the email headers between types of mail notifications?
bugzilla does this. enables mail sorting.

0000132: Obsolete tags listed as "existing tags"

Thu, 01 Oct 2026 19:26:33 +0000

There are some tags that were used during development of Aardvark Mk
III that are no longer needed, and have been removed from all bugs
that were tagged with them. They are:

in aardvark, Real bug, real bug in aardvark, real bug not in aardvark

These tags are still included in the drop-down list of "existing tags"
that is presented when adding a tag to a bug, or when choosing tags in
the View Issues filter. Since they are not intended for future use,
it would be good if they could be removed from the list of existing tags.

0000039: tag filter ignores first tag

Thu, 01 Oct 2026 19:20:49 +0000

I think there is an off-by-one error in the way the "View Issues" filter processes the selected tags. It ignores the first tag in the list.

For example, with the default filters there are currently 15 issues listed. Selecting "real bug in aardvark" from the tag list and clicking "Apply Filter" produces the same list. However, selecting the same tag again (so that the filter is now looking for "real bug in aardvark, real bug in aardvark") and re-applying produces the correct list of the 5 issues with that tag.

0001982: probably-unintended wording difference with ISO C in mbrtowc(3) and mbrtowcs(3)

Wed, 30 Sep 2026 08:59:32 +0000

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

On 2026-05-21T23:08:20+0800, Kang-Che Sung wrote:
> There's a discrepancy in the wording of the mbrtowc(3) function (and
> similarly, mbsrtowcs(3) function) between in POSIX and ISO C. It could be
> reported as an issue to POSIX (the Austin Group), and I am not sure if you
> can do that.
>
> In ISO C (I checked in both C99 and C23, in particular the N3220 draft),
> there's a statement that if mbrtowc() returns a (size_t)(-1) as an encoding
> error occurs, "the conversion state is unspecified".
>
> POSIX (see <
> https://pubs.opengroup.org/onlinepubs/9799919799/functions/mbrtowc.html>),
> for the same part it says "the conversion state is undefined".
>
> This wording difference matters when the "unspecified behavior" and
> "undefined behavior" are technically different. An example is how the
> mbstate_t object can be reused after an invalid sequence is encountered.
> When the state is said to be "undefined" it's implied to be not usable
> again (unless it is reset, e.g., by an `mbrtowc(NULL, "", 1, ps)` call).
> When it's "unspecified" then implementations can allow the state to be
> reused for certain encodings (possible for UTF-8, for example).
>
> This is something I discovered accidentally when researching the multibyte
> functions in the C standard library and how they work with an encoding like
> UTF-8.

Reported-by: Kang-Che Sung <explorer09@gmail.com>

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

Wed, 30 Sep 2026 08:47:22 +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.

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

Wed, 30 Sep 2026 08:43:59 +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.

0000921: please add support for the tt (typewriter text) tag

Mon, 28 Sep 2026 17:24:37 +0000

If a comment contains lessthan-tt-greaterthan then Mantis escapes the angle brackets rather than formatting the text in a monospace font.

0001893: Many links are followed by extra spaces

Mon, 28 Sep 2026 15:32:43 +0000

Many links in the HTML edition are followed by undesirable spaces that are not present in the PDF edition. I believe most if not all of the affected links are cross-references, but I don't know whether all cross-references are affected. These extra spaces should be removed, if possible.

(This problem is also widespread in the 2008 edition of Issue 7 but is significantly rarer in the 2013, 2016, and 2018 editions.)

0000694: missing PDF bookmark for mbsnrtowcs()

Mon, 28 Sep 2026 15:29:11 +0000

The PDF for Issue7+TC1 contains hierarchical bookmarks (PDF metadata) to help the reader easily jump between sections. These bookmarks are missing an entry for mbsnrtowcs() (to jump to page 1289) under XSH Chapter 3.

(The HTML version is OK -- the link to mbsnrtowcs() is not missing.)