Austin Group Defect Tracker - ISSUES

0000712: typographic error: .I in short description

the short description in gets.html reads

gets - get a string from a .I stdin stream

the .I seems to be from a failed *roff to html conversion

the issue occures at least in

functions/gets.html
functions/getline.html
functions/getdelim.html
functions/getchar.html
functions/getwchar.html
idx/ig.html

0000714: yn(n,0) is incorrect for odd n<0

the return value description for y0, y1 and yn says:

"If x is 0.0, -HUGE_VAL shall be returned and a pole error may occur."

"If the correct result would cause overflow, -HUGE_VAL or 0.0 shall
be returned and a range error may occur."

this is fine for y0 and y1 but it is inconsistent with the
mathematical definition of yn when n is negative and odd

the sign is flipped according to yn(-n,x) = (-1)^n yn(n,x)
or

lim yn(n,x) = +Inf, for all n<0 and n%2==1
x->+0

it seems historical implementations got this wrong at x==0
eg. the original v7 implementation of yn starts with

if (x <= 0) {
errno = EDOM;
return(-HUGE);
}

but if x>0 and x is close to 0 then yn(-odd,x) overflows
and the mathematically reasonable +Inf is returned which
is inconsistent with the description in posix
(i assume most historical implementations work this way)

0000713: in remquo quo should be unspecified when the result is NaN

the description of quo in remquo(x,y,quo) is

"In the object pointed to by quo, they store a value whose sign
is the sign of x/y and whose magnitude is congruent modulo 2^n
to the magnitude of the integral quotient of x/y, where n is an
implementation-defined integer greater than or equal to 3. If y
is zero, the value stored in the object pointed to by quo is
unspecified."

quo does not seem to be correctly specified when x/y
is +-Inf or NaN, only the y==0 special case is handled

this may affect ISO C as well

0000515: Typos on make's page

I found a couple of typos on make's page (section: Extended Description, subsection: Include Lines) but I don't really know whether they only apply to the online version or not.

0000711: Are the stdarg.h macros async-signal-safe?

XSH 2.4.3 lists functions which are async-signal-safe and does not include va_* in its list; however, va_* are specified to be macros and functions are not required to exist. Thus, it seems unclear to me whether variadic functions may access their arguments from an async-signal context.

0000703: Add errno values for clock

The clock() function has failure cases specified (unavailable or unrepresentable processor time usage) but does not have error codes defined. As the resolution of #686 imposes a common real-world failure case on implementations using 32-bit clock_t, it seems desirable to have the cause of failure reported in errno.

0000705: Add hash, type and ulimit to regular built-in utilities

Like cd, getopts, read, umask and wait, the utilities hash, type and ulimit are most simply implemented within the shell. hash reports on or modifies a list within the shell environment. type may report on aliases and functions only known within the shell environment. ulimit may modify a process property which would not affect the shell if it were to be done in a child process.

Note that the current standard requires that hash, type and ulimit be exec'able (the latter two only for XSI implementations).

0000706: require subshell environment to have its own copy of ulimit

Users/scripts may expect that a ulimit command in a subshell environment does not affect any parent shell environment, like a cd or umask command. In fact, this is the case even in ksh93 which explicitly forks when a non-fork subshell environment tries to change ulimit. If the subshell environment is implemented via fork() or if the parent environment cannot execute any more commands, changes to ulimit do not affect the parent either.

Some historical non-compliant implementations execute command substitutions invoking a single built-in utility in the current shell environment. Apart from the fact that this is non-compliant for other reasons, a lone ulimit command with a new value in a command substitution is also unlikely to occur in practice because there is normally no code to run with the new limit and such a command generates no output.

0000707: unclear symbolic constants in tar.h

The General definitions table contains the following entries:

TVERSION "00" 00 without a null byte.
TVERSLEN 2 Length of the above.

This is unclear, or at least hard to implement. String constants do include the null byte.

It seems sizeof(TVERSION) != TVERSLEN on most systems, contrary to above text.

0000708: Make mblen, mbtowc, and wctomb thread-safe for alignment with C11

Per C11 7.1.4 paragraph 5,

"Unless explicitly stated otherwise in the detailed descriptions that follow, library functions shall prevent data races as follows: A library function shall not directly or indirectly access objects accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function's arguments. A library function shall not directly or indirectly modify objects accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function's non-const arguments. Implementations may share their own internal objects between threads if the objects are not visible to users and are protected against data races."

7.22.7 (Multibyte/wide character conversion functions) does not specify that these functions are not required to avoid data races with other calls. The only time they would even potentially be subject to data races is for state-dependent encodings, which are all but obsolete; for single-byte or modern multi-byte (i.e. UTF-8) encodings, these functions are pure.

Note that 7.29.6.3 (Restartable multibyte/wide character conversion functions) does make exceptions that the "r" versions of these functions are not required to avoid data races when the state argument is NULL.

0000709: specification of when a string is converted to integer doesn't match existing practice

The extended description of expr says:
A string argument is an argument that cannot be identified
as an integer argument or as one of the expression operator
symbols shown in the OPERANDS section.

According to that, the "010" in each of the following commands:
expr 010
expr $ 010 $
expr 010 : '$.*$'
expr 0 '|' 010

is _not_ a string argument because they _can_ be identified as an
integer argument, which means that the output of each of those
should be "10", but that isn't done in Solaris, Linux, FreeBSD, or
OpenBSD. They all consistently output "010" for those.

I believe that existing implementations all only convert a string
to an integer only when it is used as an operand of a binary operator
other than ':'.

Side note: the HTML formatting of the table is misleading/wrong, as
the rows separators are identical within and between precedence.

0000710: read() and write() pages use "file pointer"

The read() and write() pages sometimes use the term "file offset" and
sometimes (in connection with pread() and pwrite()) use "file pointer".
The correct term is "file offset".

This was corrected in Issue 7 for pwrite() in the DESCRIPTION section
(but oddly not for pread()), but has crept in again in the EINVAL error.

0000704: Clarify interoperability of wordfree(3)

It seems the wording of wordexp(3) / wordfree(3) permits the interpretation that wordfree(3) is only valid after a _successful_ wordexp(3) call.

(Apple Mac OS X Snow Leopard behaves that way if one globbers the wordexp_t backing memory before calling wordexp(3), whereas the checked sources of FreeBSD [since first commit 2002] and NetBSD [ditto, 2004] zero the backing memory unless WRDE_APPEND is set, as i'd expected.)

0000693: Clarification on export status of make variables

Whereas the standard defines exactly the significance of the sources of macros / variables (command line, MAKEFLAGS environment variable, environment content, in the Makefile), it does not talk about the resulting export status of the macro / variable that will be passed down the call chain.
This shell snippet can be used for a quick test:

#!/bin/sh -
[ -z "${MAKE}" ] && MAKE=make
SHELLVAR=shell
export SHELLVAR MAKE
cat > t1.make << \!
SHELLVAR = t1
all:
@$(MAKE) -f t2.make all
!
cat > t2.make << \!
all:
@echo "Should echo t1, but echoes $(SHELLVAR)"
!
${MAKE} -f t1.make all
rm -f t1.make t2.make

GNU make (3.82, Slackware 14; 3.81, Mac OS X) echoes "t1", FreeBSD 10.0 make(1), NetBSD 6.99.19 make(1), OpenBSD 5.3 make(1) as well as smake(1) 1.2 echo "shell".

0000696: either NAME_MAX shouldn't be optional, or readdir_r() needs clarification

The description says this about the Pathname Variable Values, which include NAME_MAX:
A definition of one of the symbolic constants in the following
list shall be omitted from the header on specific
implementations where the corresponding value is equal to or
greater than the stated minimum, but where the value can vary
depending on the file to which it is applied. The actual value
supported for a specific pathname shall be provided by the
pathconf() function.

So implementations can leave NAME_MAX undefined if the limit varies. Meanwhile, the readdir_r() description says:
The storage pointed to by entry shall be large enough for a
dirent with an array of char d_name members containing at least
{NAME_MAX}+1 elements.

If NAME_MAX really is optional, then the above text should be replaced with a discussion of NAME_MAX vs pathconf(dir, _PC_NAME_MAX). And what should you do if pathconf() returns -1, which it does for 32bit Linux binaries accessing filesystems where statvfs() fails with EOVERFLOW?

0000697: Adding of a getdirentries() function

POSIX systems don't follow the Unix paradigm "everything is a file" for directories in that it is impossible to simply open(2) a directory and read(2) the descriptor to get access to the list of direntries therein.

In the current POSIX standard there is no way to gain access to directory entries but by using the completely intransparent (in respect to internal resource usage; though today there is now fdopendir(3), but still) and unpredictable ("directory status snapshot") opendir(3) / readdir(3) / closedir(3) family of functions.

On the other hand all (to the best of my knowledge) POSIX systems support some kind of getdents(2), getdirentries(2) or getdirent(2) system call (with, despite their names, almost identical semantics).
This functionality can be used to fully control reading of directory entries, at least in respect to resource usage, and including the possibility to perform bulk reads. A publically accessible example would be [1].

[1] http://code.google.com/p/plan9port/source/browse/src/lib9/dirread.c?r=6daaa8f20a12cc5eda13b0e13f293a4cd4174729 [^]

0000615: pthread_setcancelstate should be async-signal-safe

In order to write a signal handler for an asynchronous signal which can run safely in a cancellable thread, pthread_setcancelstate must be used to disable cancellation for the duration of the signal handler. This is because acting on cancellation at a cancellation point that occurs during a signal handler is, from the perspective of the asynchronously interrupted code, asynchronous cancellation.

Consider for example the case where the main flow of execution of the thread is in malloc at the time a signal arrives, and the signal handler calls an async-signal-safe function which is also a cancellation point (such as open/close).

0000592: consistent use of struct timespec

Most headers that use struct timespec require that it be defined as in ( line 7210, line 9846, line 10543, line 10756, line 10967, line 12650, line 13044).

However, while permits the inclusion of (line 10892), it does not require it and does not mandate that a forward reference to struct timespec be in place before the declaration of sem_timedwait(), which means that the declaration could be inadvertently declaring a pointer to a unique type if the headers are included in the wrong order. Worse, directly uses struct timespec (line 14264), but does not require either the type to exist nor the use of . Both of these go against the goal of Issue 7 in making more headers self-contained.

Finally, a number of functions list the inclusion of in their SYNOPSIS section, supposedly to guarantee the correct struct timespec, although this is redundant as demonstrated by the requirements listed above.

0000700: Clarify strtoul's behaviour on strings representing negative numbers

In which cases does strtoul (and other strtou* functions) fail with ERANGE? How is the range check performed?

This ticket follows the discussion about strtoul on austin-group-l in May 2013.

The RETURN VALUE section in
http://pubs.opengroup.org/onlinepubs/009696799/functions/strtoul.html [^]
says:
If the correct value is outside the range of representable values, {ULONG_MAX} or {ULLONG_MAX} shall be returned and errno set to [ERANGE].

Some people understand this as "if the value I read (the correct value) is outside the [0, ULONG_MAX] range, then strtoul fails with ERANGE".

However, it seems that many implementations do the following:
1. Read independently the optional sign and the subject [0-9]+ sequence
2. If the subject sequence fits in the unsigned long type, then store it in an unsigned long variable. Otherwise (outside the [0, ULONG_MAX] range), fail with ERANGE.
3. If there was a minus sign, then apply negation on the unsigned long variable as if it were a signed long.

According to the discussion on the austin-group-l mailing list, it looks like this is what the POSIX standard (and the C standard) intend to specify. But it looks like it is not clear enough in the specification.

0000699: setr?e[gu]id should be async-signal-safe

The standard already requires that setgid() and setuid() be async-signal safe; however, these two functions are inadequate to completely set all aspects of a process' identity when compared with the more powerful sete*id and setre*id variants. Yet, when writing a multi-threaded application, the only time at which it is possible to safely set the identity of a child process is either by the use of posix_spawn() (which is limited in what it can do), or between the fork() and exec*() of the child process (where it is only safe to use async-signal-safe functions). It makes no sense for the simpler function to be safe while the more complex function is unsafe, especially if the simpler one can be implemented in terms of the more complex one.

As a side note: The standard intentionally doesn't document initgroups() or setgroups(), but presumably initgroups() may have the same non-safety issues as getpwuid_r, while setgroups() would be async-signal-safe. Thus, a privileged application that can spawn child processes on behalf of another user would learn the uid, gid, and supplemental gids to use prior to forking, then change the identity of the child after forking.

0000686: Application usage for clock() conflicts with normative text

"If the processor time used is not available or its value cannot be represented, the function shall return the value (clock_t)-1."

vs

"The value returned by clock() may wrap around on some implementations. For example, on a machine with 32-bit values for clock_t, it wraps after 2147 seconds or 36 minutes."

The former (aligned with ISO C) requires unrepresentable time values to result in (clock_t)-1; the latter seems to permit implementations to instead truncate the value.

What's worse, if the value is truncated and clock_t is a signed type, the recommended application usage (subtracting clock_t values to measure intervals) causes the application to invoke undefined behavior via integer overflow. In particular, if the initial call to clock() returned A>0 (by virtue of some processor time having been consumed before the start of main() or the point of first measurement), and a subsequent call returned B=INT_MIN just after overflow, then the recommended practice of computing B-A invokes undefined behavior.

Note that the issue is exacerbated by the XSI requirement that CLOCKS_PER_SEC be 1000000, which makes overflow on 32-bit systems the norm rather than the exception.

0000690: clarify behavior when calling waitpid with SA_NOCLDWAIT

From the description for waitpid:
If the calling process has SA_NOCLDWAIT set or has SIGCHLD set to SIG_IGN, and the process has no unwaited-for children that were transformed into zombie processes, the calling thread shall block until all of the children of the process containing the calling thread terminate, and wait() and waitpid() shall fail and set errno to [ECHILD].

Similar text also appears in 2.4.3 Signal Actions of the base definitions.
The description for waitid (no p) doesn't indicate what its behavior is at all.

Please clarify the interaction when waitpid is called with a pid parameter that matches no children. As specified, I believe a strict interpretation requires the calling thread to block even when calling waitpid with an invalid pid. A more desirable interpretation might allow waitpid to return immediately if the pid doesn't exist or is not a child.

See attached source file.

0000672: Necessary step(s) to synchronize filename operations on disk

POSIX documents a way of ensuring data is actually sync'ed on permanent storage through fsync(), fdatasync() and aio_fsync().

This way, previously written data, and/or modified meta-data, are guaranteed to be actually protected against a reasonably unexpected situation (system crash, power outage ...)

However, when dealing with file entry handling, such as:
* file creation (open(O_CREAT))
* file renaming (rename())
* symlinking (symlink())
* hard-linking (link())
* etc.
there is no documented way to actually give the same guarantee.

Some implementations (such as the Linux glibc) have a somewhat (badly) documented way:
* open the container directory in read-only (O_RDONLY)
* apply fsync() or fdatasync() on it

Please refer to the "fsync()'ing a directory file descriptor" thread on the austin-group-l mailing list for insightful comments on this issue.

Several points were discussed, and these (possibly not fully correct) observations were made:
* directory entries are not attributes of the files they point to, and can not expect to be synchronized [when fsync'ing the file]
* tracking relationship between directory entries and file descriptors would be cumbersome (a file may be hard-linked in another directory, then have its initial entry being deleted, for example, or renamed to another location)
* it is not clear whether a directory can be opened at all using open() (readdir() may be the only allowed interface), and what would be the open flags
* it is not clear what fsync() on a directory file descriptor would do

0000687: Not all filesystems support posix_fallocate

As described in 0000684, not every filesystem can (or can easily) support posix_fallocate().

Applications need to know whether a filesystem supports posix_fallocate(). In addition to an error return from posix_fallocate() itself, it would be useful if an application could determine in advance whether or not a filesystem will support a call to posix_fallocate().

0000701: unget[w]c() and file position after discarding push back

The ungetc() description, as updated by TC1, includes the following:

The value of the file-position indicator for the stream after all
pushed-back bytes have been read, or discarded by calling fseek(),
fseeko(), fsetpos(), or rewind() (but not fflush()), shall be the
same as it was before the bytes were pushed back.

Similarly for ungetwc() (with "characters" instead of "bytes").

The "discarded" part of this requirement does not make any sense.
All of the listed functions which discard the push back also _set_ the
file position. The file position will end up as whatever the function
sets it to, not "the same as it was before the bytes [or characters]
were pushed back".

Since these requirements derive from the C Standard, we should raise
this issue with the C committee.