Austin Group Issue Tracker - Issues

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

Sun, 26 Apr 2026 07:45:12 +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 &

0001976: specify array variables and syntax

Sat, 25 Apr 2026 06:04:11 +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

0001971: Changing lex prefixes

Thu, 23 Apr 2026 17:39:35 +0000

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

0001975: at_quick_exit Description in Search Results has Stray Characters

Thu, 23 Apr 2026 17:08:49 +0000

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

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

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

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

Thu, 23 Apr 2026 15:58:51 +0000

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

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

Tab stop value:

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

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

I believe that indicated sentence:

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

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

For additional context, this came up in following:

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

I've tried to summarize in following comment:

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

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

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

Thu, 16 Apr 2026 05:38:16 +0000

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

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

0001966: Current/previous job definition scattered and ambiguous

Thu, 16 Apr 2026 05:29:39 +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.

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

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

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

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

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

Then later the ERRORS section contradicts that:

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

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

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

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

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

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

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

The iconv utility specification has:

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

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

But the exit status section has:

> >0
> An error occurred.

Which seems to be in contradiction.

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

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

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

I've not tested other implementations.

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

0001977: posix_spawn_file_actions_addopen and posix_spawn_file_actions_adddup2 contridiction with respect to OPEN_MAX.

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

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

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

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

0001973: awk "numeric string " origins

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

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

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

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

It can be interpreted as meaning that

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

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

Same applies for ARGV, FILENAME...

Typo in rationale section btw:

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

is -> it

0001972: Determinism in POSIX Utilities

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

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

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

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

For example, invoking:

c17 foo.c

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

c17 foo.c bar.c

and

c17 bar.c foo.c

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

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

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

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

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

However, the standard currently says:

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

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

---

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

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

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

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

Current spec says:

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

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

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

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

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

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

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

0001963: sccs create should use get

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

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

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

0001961: assert.h lacks static_assert macro

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

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

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

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

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

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

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

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

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

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

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

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

Hey.

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

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

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

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

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

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

0001958: typo in if_indextoname(3)

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

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

0001954: please allow shells to unignore signals

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

The specification of the trap utility has:

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

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

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

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

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

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

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

0001953: getdelim() behavior is ambiguous on empty file

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

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

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

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

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

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

0001952: (n)gettext and NLSPATH

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

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

0001951: getopts example oversight

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

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