Austin Group Issue Tracker - Issues

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

Tue, 11 Aug 2026 11:38:46 +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.

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.

0001994: exp() assumes default rounding

Wed, 29 Jul 2026 08:40:41 +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.

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.

0001966: Current/previous job definition scattered and ambiguous

Mon, 01 Jun 2026 10:14:49 +0000

POSIX defines the "current job" as:

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

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

With the fg utility specification stating:

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

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

Previous job is defined as:

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

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

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

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

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

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

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

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

The Rationale there also has:

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

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

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

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

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

0000298: Need a way to refer to the note being added in an update

Thu, 28 May 2026 16:19:11 +0000

When adding a note to a bug when marking it as "accepted as marked" and when
adding an interpretation response, we end up having to update the bug twice.
First to add a note and fix most of the status fields and then again to fill in the
"Final Accepted Text" field with the newly added bugnote reference. This causes
extra work for those updating bugs and generates unneeded email messages.

0000228: Mantis sends quoted characters instead of real ones in Password Reset mail

Thu, 28 May 2026 16:18:54 +0000

I have received the following message when trying to reset my password:

----v----
From: Austin Group Bug Tracker <noreply@msnkbrown.net>
Subject: [Austin Group Defect Tracker] Password Reset
Message-ID: <457512dd3d0b96d23290ef1bcbe178e5@austingroupbugs.net>

Someone (presumably you) requested a password change through e-mail
verification. If this was not you, ignore this message and nothing will
happen.\n\nIf you requested this verification, visit the following URL to change
your password:

----^----

0000204: Fix Message-ID headers in next version of Mantis (Tracker notifications have incorrect mail headers)

Thu, 28 May 2026 16:18:33 +0000

The Austin Group Bug Tracker sends messages with 2 Message-ID headers:

[...]
Subject: [1003.1(2008)/Issue 7 0000129]: exception to syntax guidelines for -I
Date: Wed, 5 Aug 2009 15:12:18 +0000
From: Austin Group Bug Tracker <noreply@msnkbrown.net>
Message-ID: <3e797608891e599f1193f27f81c4c242@austingroupbugs.net>
X-Priority: 3
X-Mailer: PHPMailer [version 1.73]
keywords: [1003.1(2008)/Issue 7] Shell and Utilities
Message-ID:
[...]

Also note that the second Message-Id is incorrect (missing domain
part).

A second mail was sent, with a note added to the issue. This one
contains only one (correct) Message-Id, but the In-Reply-To header
references the wrong Message-Id:

[...]
Subject: [1003.1(2008)/Issue 7 0000129]: exception to syntax guidelines for -I
Date: Wed, 5 Aug 2009 20:00:48 +0000
From: Austin Group Bug Tracker <noreply@msnkbrown.net>
Message-ID: <80ab3cdfdc0269c6797c80cd065aa4b0@austingroupbugs.net>
X-Priority: 3
X-Mailer: PHPMailer [version 1.73]
keywords: [1003.1(2008)/Issue 7] Shell and Utilities
In-Reply-To:
[...]

0000116: Ability to search on Line Number 0

Thu, 28 May 2026 16:16:11 +0000

I note that I can't set a filter for "Page Number" with value "0" or
"Line Number" with value "0" to look for bugs that may need to have
page and line numbers filled in. Setting Page Number or Line Number
to 0 and hitting Apply Filter turns the field value into "any". Is
there a way around this?

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

Thu, 28 May 2026 16:15:44 +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>

0001980: misleading reference to $(jobs -p) in jobs application usage

Thu, 21 May 2026 16:09:36 +0000

In the "APPLICATION USAGE" section, the jobs utility
specification currently has:

> Usage such as $(jobs -p) provides a way of referring to the
> process group of the job in an implementation-independent way.

However, $(...) instroduces a subshell environment and the
"DESCRIPTION" section has:

> If the current shell execution environment (see 2.13 Shell
> Execution Environment) is not a subshell environment, the jobs
> utility shall display the status of background jobs that were
> created in the current shell execution environment; it may
> also do so if the current shell execution environment is a
> subshell environment.

Meaning the expansion of $(jobs -p) is unspecified.

What "so" means above in "it may also do so" should be clarified
as it's unclear whether it may report jobs of the shell outside
subshell environments, or jobs of the subshell environment or of
the parent subshell environment or combinations thereof.

In practice, there's a lot of variation between shells and in
some shells, not all subshells are equal, with the ones created
by command substitution treated differently from some other ones
in some for instance.

With bash:

$ bash -c 'sleep 1 & (sleep 2 & (sleep 3 & jobs))'
[1]+  Running                    sleep 3 &
$ bash -c 'sleep 1 & (sleep 2 & printf "%s\n" "$(sleep 3 & jobs)")'
[1]-  Running                    sleep 2 &
[2]+  Running                    sleep 3 &

Similarly for subshells incurred by pipelines:

$ bash -c 'sleep 1 & (jobs)'
$ bash -c 'sleep 1 & jobs | cat'
[1]+  Running                    sleep 1 &