Austin Group Issue Tracker - Issues

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>

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

Thu, 28 May 2026 16:01:32 +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.

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 &

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

Thu, 21 May 2026 15:34:08 +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

Fri, 15 May 2026 00:44:17 +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.

0001977: posix_spawn_file_actions_addopen and posix_spawn_file_actions_adddup2 contridiction with respect to OPEN_MAX.

Thu, 14 May 2026 15:40:08 +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.

0000418: posix_spawn_file_actions_addclose() should not check against OPEN_MAX

Thu, 14 May 2026 15:12:02 +0000

On some systems there can be file descriptors open that are greater
than or equal to {OPEN_MAX} (if {OPEN_MAX} is reduced after they were
opened). These need to be able to be closed on spawn, therefore
posix_spawn_file_actions_addclose() should not be required to check
against {OPEN_MAX}.

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

Sat, 09 May 2026 07:32:38 +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.

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.

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).