Austin Group Issue Tracker - Issues

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

Wed, 07 Oct 2026 10:58:16 +0000

The requirements for command -v read:

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

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

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

0001633: Add memrchr

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

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

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

(And probably many others).

0001622: Standardize getpeereid function

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

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

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

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

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

Fri, 02 Oct 2026 10:18:41 +0000

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

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

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

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

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

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

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

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

0001832: Add preadv() and pwritev()

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

Many implementations offer preadv() and pwritev() interfaces, which are like
the existing readv() and writev() APIs, except that they use specified
positions instead of the current file offsets, just like the existing
pread() and pwrite() versions of read() and write().

FreeBSD:
- https://man.freebsd.org/cgi/man.cgi?query=preadv
- https://man.freebsd.org/cgi/man.cgi?query=pwritev
illumos:
- https://illumos.org/man/2/preadv
- https://illumos.org/man/2/pwritev
Linux (GNU libc):
- https://man7.org/linux/man-pages/man2/preadv.2.html
NetBSD:
- https://man.netbsd.org/preadv.2
- https://man.netbsd.org/pwritev.2
OpenBSD:
- https://man.openbsd.org/preadv.2
- https://man.openbsd.org/pwritev.2
Solaris:
- (man pages not online yet, just added in 11.4.69 in May 2024)

Known consumers include PostgreSQL and libuv, as discussed in the thread at
https://twitter.com/MengTangmu/status/1729704220368990235 .

0001824: cp: directories and symlinks

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

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

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

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

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

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

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

To summarize:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

stm = *tm;

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

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

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

t = mktime(&stm);

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

if (t == -1)
return tz_leap;

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

*tai_offset = tz_tai_offset;

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

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

stm = *tm;

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

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

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

t = mktime(&stm);

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

if (t == -1)
return tz_leap;

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

*tai_offset = tz_tai_offset;

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

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

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

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

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

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

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

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

issue 1007 resolves this to

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

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

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

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

However, as Martin Sebor stated in the issue description,

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

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

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

0001818: Add strcasestr() & strcasestr_l()

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

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

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

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

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

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

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

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

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

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

0000864: Insufficient specification of storage requirements for synchronization objects

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

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

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

Here are some specific questions I have:

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

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

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

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

0001291: Add method to obtain pthread attributes

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

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

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

glibc: pthread_getattr_np
freebsd: pthread_attr_get_np
netbsd: pthread_attr_get_np and pthread_getattr_np

RTEMS follows glibc/linux with pthread_getattr_np.

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

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

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

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

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

0000132: Obsolete tags listed as "existing tags"

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

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

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

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

0001999: Session timeouts too short

Thu, 01 Oct 2026 19:22:51 +0000

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

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

0000039: tag filter ignores first tag

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

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

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

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

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

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

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

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

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

Wed, 30 Sep 2026 08:47:22 +0000

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

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

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

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

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

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

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

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

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

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

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

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

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

0001893: Many links are followed by extra spaces

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

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

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

0000694: missing PDF bookmark for mbsnrtowcs()

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

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

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

0001985: Add a dark theme to the HTML rendition

Mon, 28 Sep 2026 15:25:18 +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.