Austin Group Defect Tracker - ISSUES

0000540: Add API for adding entries to user accounting database by passing a pseudo-terminal master file descriptor

There are libraries out there, such as `libutempter' that can be used to update utmp(x) entries without any root-like privileges, by passing the file descriptor to a pseudo-terminal master device. These libraries typically spawn a setuid binary to perform the update to the database.

It would be nice if POSIX were to integrate such a feature. Currently there is quite some inconsistency in current implementations whether or not they work without any additional privileges. In (almost) all cases, these unprivileged applications are only interested in managing entries for pseudo-terminals.

0000529: fildes unspecified on close()'s [EINTR]

The standard currently reads

If close() is interrupted by a signal that is to be caught, it shall return -1 with errno set to [EINTR] and the state of fildes is unspecified.

If a signal occurs and we reissue close(), we might get an [EBADF]. Worse, if a different thread opens a file at the wrong time and gets our file descriptor, we might end up closing the wrong file.

0000538: Missing part of basename changes from bug 192

When applying the TC1 changes to the SUSv4 source, the editors noticed
that part of the changes from bug 0000192 (the change to the RATIONALE
section) were overlooked when it was split into separate changes.

A correction will be made in the next draft of TC1, but since this is
not a simple editorial change this bug is being submitted to record the
change. A simple editorial correction to the section name on line 9892
is also being made at the same time.

At this late stage in the development of TC1 the correction needs to be
made without altering any of the later change numbers. Fortunately
there is a neat way to distribute the full set of changes between the
existing three change numbers (65, 66, 67).

0000528: Support extended regular expressions (EREs) in sed

I propose standardizing a flag so sed users can use Extended Regular Expression (EREs) and not just basic regular expressions (BREs), making sed consistent with grep and awk. I recommend using “-E”, though “-r” is plausible (both are widely implemented).

Here is my rationale:

1. This would make sed consistent with the related POSIX utilities grep (which supports EREs using -E) and awk (which *only* supports EREs). It is an odd inconsistency that POSIX sed cannot use EREs at all, when related utilities *allow* or *require* EREs.

2. Many matches and substitutions are simpler to express as an ERE than as a BRE, and these are typical uses of sed. BRE doesn’t include functionality like ERE’s special character | (“or”) at all. Common BRE expressions like $, $, \{, and \} are, in ERE, the simpler (, ), {, and }. BRE doesn’t include the ERE special character + to mean “one or more”; you can simulate it with "\{1,\}”, and GNU sed includes the extension \+, but EREs include this as a special character because it is such a common need. This increased functionality and simplification matters.

3. Supporting EREs also makes sed more consistent with the many programming languages that support regular expressions, including Perl and Python. Most languages with built-in regular expression support either EREs or Perl-like REs (which are a superset of EREs), not BREs. As a result, far more people are familiar with the ERE syntax than the BRE syntax.

4. Many people consider BREs “obsolete” and that EREs are more “modern”. For example, the FreeBSD sed documentation says that its “-E” flag uses “extended (modern) regular expressions rather than basic regular expressions (BRE's)”, and its documentation for regex(7) describes the REG_EXTENDED flag as “Compile modern (‘extended’) REs, rather than the obsolete (‘basic’) REs”. The book “Mac OS X UNIX: 101 byte-sized projects” by Adrian Mayo, page 450, says: “Unix supports three types of regular expressions... modern (also termed extended), obsolete (also termed basic), and Perl regular expressions...”. You don’t need to agree that BREs are obsolete, but since many people do believe this, it would be valuable to have a standard way to use their preferred regex format.

5. This capability is widely implemented using the “-E” flag, the “-r” flag, or both:
* GNU sed supports EREs using either “-r” or “-E”, though it only documents “-r”. To confirm that it supports “-E”, see its source code at http://git.savannah.gnu.org/cgit/sed.git/tree/sed/sed.c [^] and look for the line containing the comment “Undocumented, for compatibility with BSD sed... case ‘E’: ”).
* OpenBSD sed supports EREs using “-E” (and recommends this flag) and “-r” (the “-r” flag is documented as being for portability with GNU sed). See: http://www.openbsd.org/cgi-bin/man.cgi?query=sed&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html. [^]
* FreeBSD sed has the same situation as OpenBSD; it supports “-E” (and recommends this flag), and it supports “-r” for compatibility with GNU sed. http://www.freebsd.org/cgi/man.cgi?query=sed&apropos=0&sektion=0&manpath=FreeBSD+8.2-RELEASE&arch=default&format=html [^]
* NetBSD sed is the same as OpenBSD; it supports “-E” and “-r”. See: http://netbsd.gw.com/cgi-bin/man-cgi?sed++NetBSD-current [^]
* MacOS sed supports only -E for this, and not “-r”: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/sed.1.html [^]

6. ERE support is trivial to add to existing sed implementations if they don’t already have it. A sed implementation that doesn’t already implement EREs could simply recognize a flag, and later call regex() using REG_EXTENDED if that flag was present. Since regex() is already in the standard, this should be trivial to do for any sed implementation that cares about the POSIX standard at all.

7. People really do depend on sed supporting EREs. For example, in this email: http://ghostscript.com/pipermail/gs-bugs/2010-June/014175.html [^] the developers were using sed with EREs, and decided that they would use different flags for different systems instead of trying to use BREs. They noted that this their approach would fail if sed didn’t support EREs, but that seemed to be of no concern to them. Which suggests there’s a need to standardize using EREs in sed!

The question is, what flag should be used? Both “-E” (BSD-style) and “-r” (GNU-style) are in common use. I recommend that the “-E” (BSD-style) flag be standardized at least, because:
1. It’s consistent with grep (which already uses the “-E” flag).
2. The flag letter is more obviously related to “Extended Regular Expressions (EREs)”.
3. It’s widely supported. In particular, GNU sed already supports -E, while MacOS (as far as I can tell) doesn’t support “-r”.

A counter-argument is that some people might be confused by upper and lower case flags (‘E’ vs. ‘e’) with such different meanings. I disagree. POSIX flags are already case-sensitive; widely-used utilities like “ls” already have lots of flags that differ only by case. Indeed, the related POSIX utility awk has flags that differ by case (“-F” vs. “-f”). The symbols “e” and “E” have very different appearance in most fonts, so it’s unlikely that they would be visually confused.

One minor problem is that many non-portable sed scripts already use “-r”, since that is what GNU sed actually documents and originally implemented. Alternatives include:
1. Supporting both “-r” and “-E” (as synonyms). This would have the advantage of making many existing scripts comply with the new specification, without any changes. It’s also very easy to implement; most implementations could just add a case statement if it’s not there already.
2. Supporting just “-r” instead of “-E”. I think “-E” is better, as described above, but this would be fine as well.
3. Recommending, but not requiring, that implementations support “-r” as a synonym.
I don’t *really* care what the flag name(s) are, as long as there’s a standard way to access EREs.
If people want those instead, the proposal could be easily tweaked to accommodate this.

0000539: tighten du regarding files encountered through multiple command line arguments

0000527 gave a resolution that for TC2 of Issue 7, du would be documented
as having unspecified behavior if a file is encountered multiple times
through multiple command line arguments, but also added a future directions
stating that this may be tightened in the future. Issue 8 is the perfect
time to make these additional restrictions binding on implementations.

The desired action is written assuming that 0000527 has already been
applied, but uses line numbers from Issue 7.

0000527: du and files found via multiple command line arguments

The standard currently states about du:

[line 84170] Files with multiple links shall be counted and written for
only one entry. The directory entry that is selected in the report is
unspecified.

A strict interpretation of the standard applies this restriction to
all ways in which the same file can be found, even if the file is
found twice only by virtue of multiple command line arguments.
However, this strict reading renders existing du implementations
non-compliant, since they reset their hash of duplicate files when
proceeding on to additional arguments; meanwhile, GNU du implemented
this strict reading of the standard, and is in the middle of a debate
about whether this change from traditional behavior is desirable:
http://debbugs.gnu.org/10281 [^]

This shell sequence demonstrates traditional behavior (as implemented
on Solaris 10) vs. GNU behavior (the fact that the overall numbers
differ appears to stem from allocation patterns on the file system,
and what appears to be a slight algorithm differences between Solaris
and GNU about whether to favor st_blocks or st_size, and how rounding
affects matters; but that's unrelated to the point at hand about
eliding duplicate entries).

$ mkdir tmp && cd tmp
$ mkdir a b
$ printf %04098d 1 > a/a
$ ln a/a b/b
$ # both implementations detect that a/a and b/b are links, and elide b/b
$ /usr/xpg4/bin/du -ak .
5 ./a/a
6 ./a
1 ./b
9 .
$ ~/gnu/du -ak .
5 ./a/a
7 ./a
2 ./b
10 .
$ # now, compare when a and b are listed as separate arguments
$ /usr/xpg4/bin/du -ak a b
5 a/a
6 a
5 b/b
6 b
$ ~/gnu/du -ak a b
5 a/a
7 a
2 b

Meanwhile, the existing wording can be deemed self-conflicting, in that
both the -a and -s options mention listing all arguments given on the
command line, in contrast to the earlier statement about eliding
duplicates:

[line 84117] Regardless of the presence of the −a option, non-directories
given as file operands shall always be listed.
[line 84185] Instead of the default output, report only the total sum for
each of the specified files.

In all likelihood, the intent of the standard was to codify traditional
behavior where the hash for duplicate files is reset each time du
starts processing the next command line argument, and GNU du was
wrong for trying to take the standard too literally. However, it was
pointed out that the GNU behavior of remembering duplicates across
multiple command line arguments does have a use not possible in the
traditional implementation: if a user has multiple directories, all
of which share some hard links, then only the GNU semantics make it
possible to see how much disk space will be reclaimed by removing
the one directory, by invoking 'du -s' with the directory to be
removed as the last argument. Therefore, I'm presenting two options
for solving the conflict in the standard, although my preference
would be for option 1 (the GNU implementation is willing to change
its behavior to comply with option 1 by adding an extension option
to provide its current behavior of remembering links across
multiple command line arguments, and all other implementations
already comply with option 1).

0000537: for set -e, compound commands and functions case should be clarified

URL:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_25 [^]

Although it is clear what to do in the case of a simple command, in the case of a compound command or a function behavior is unclear. This results in a weird change of execution flow when a function is called from within `if' statement and so on.
If we take this passage literally, the entire shell should exit in case of an error status of a command called within a function or compound *command* called from `if' compound *list*?

That is, here `reach' would be printed:
set -e
if false; then echo unreach; fi
echo reach

That is, here `reach' would not be printed?
set -e
if { false; }; then echo unreach; fi
echo reach

Fortunately currently existing shell interpreters do not exit shell here, unfortunately they do a bad job instead, they mask -e entirely within compound commands and functions. This results, in the worst case, to alteration of command flow withing a shell function depending on the place where the function was called which is against the expectations of any sane programmer who normally expects that the function must immediately exit after the first error since he is using `set -e'.

Examples:
This command
{ set -e; false; echo ok; } && echo true
and this
( set -e; false; echo ok; ) && echo true
and this
f() { set -e; false; echo ok; }; f && echo true
print 'ok' and 'true' at least in bash, sh and zsh.
Note that calling f without `&& echo true' makes the shell exit without printing 'ok'.

If my proposal is accepted, the above commands would print nothing. It should not affect existing shell scripts in negative manner.

0000052: description of set -e does not match existing practice

The description of set -e does not match existing practice in
several respects, as discussed at length on the austin-group-l
mailing list in threads beginning 2009-02-10 ("error handling in
shell pipelines") and 2009-02-17 ("set -e description").

The new description of set -e proposed below is taken from the
minutes of the March 12th teleconference, with a few minor changes:

* shallification
* changed "!" to "the ! reserved word"
* changed "2.8.1" to "[xref to 2.8.1]"
* changed "AND or OR list" to "AND-OR list"

and the two major changes, related to pipelines and functions,
discussed in replies to the minutes.

I have also added the fix to 2.9.2 identified during the original
discussion, and some application usage and rationale.

0000535: require support for path separator in function and alias names

Alias names and function names are may contain path separator characters as an extension.

Using path separators in alias and/or function names is a way to change the execution environment (e.g. the compilation environment) without requiring privileges. For example, a developer may define a function named /usr/bin/cc to hook into executions of the compiler without affecting other users and without requiring administrator privileges.

0000510: sort -k should allow more than one modifier in [type]

A strict reading of sort -k 'keydef' says that each optional 'type'
is a single modifier. But there are cases where it is desirable to
have more than one modifier in a -k listing. Consider a file containing:

1b1 b
2a2 b
3a3 a

In the POSIX locale, this file is correctly sorted under the
specification of a primary key being the second non-blank character of
field 1 in reverse order, and a secondary key of the second field
including blanks in normal order. But the only way to express this as
a sort command line is to use multiple types on either the start or the
end field of key 1; use of a global -b or -r would break the sorting
desired of the secondary key. That is, there is no alternative to this
command line:

printf ' 1b1 b\n2a2 b\n3a3 a\n' | LC_ALL=C sort -k1.2b,1.2rb -k2,2

which would result in the same output, but without using a [type] of rb
in at least one of the two positions of the first -k option.

My testing shows that GNU, Solaris, BSD, AIX, HP-UX, and IRIX sort all
support the above use of multiple letters for type, so this proposal
should not be very controversial.

0000532: clarify atomicity of semctl()

It would be helpful to clarify the atomicity of semctl() commands, especially
SETALL; e.g., in the unlikely case of concurrent SETALL operations, or in the
more likely case when a process is blocked in a semop(), and the values of the
semaphores in the set are altered by a call to semctl() in another process.

For example, if a semaphore set comprises two semaphores with values {0, 0},
and a process is blocked in a call to semop() with sem_ops {-1, 0}, it would
ideally not be possible for this semop() to complete during a call to
semctl(...,SETALL,...) in another process with arg.array values of {1, 1}.

Regarding existing practice, the Linux semctl() manual page contains the
following wording, which seems to imply issuing a SETALL or SETVAL command
when there are pending semop() operations is safe on Linux:

"...If the changes to semaphore values would permit blocked semop(2) calls in
other processes to proceed, then those processes are woken up."

0000533: backslash newline in sed s replacement string

The description of the s command in the sed EXTENDED DESCRIPTION
includes the following:

The meaning of a immediately followed by any character
other than '&' , , a digit, or the delimiter character
used for this command, is unspecified.

but the paragraph after that describes how backslash can be used
to escape a newline.

This appears to be a simple editorial omission in the list in the
quote above. The propose change adds newline to the list, but
also moves the sentence to after all of the uses of backslash
have been described, and inserts "unescaped".

0000536: missing statement from C99 about no need to generate signals

C99 contains this statement in 7.14 after the list of signals:

An implementation need not generate any of these signals, except
as a result of explicit calls to the raise function.

For POSIX the same thing can be deduced (explicitly for SIGFPE, SIGILL
and SIGSEGV, and by implication for the others) from this statement
after the table of si_code values on the page:

Implementations [...] may contain extensions or limitations that
prevent some values from being generated.

However, it would be better if POSIX contained a direct equivalent
of the C99 statement.

The proposed change also removes CX shading from something that
is a statement of fact about the C Standard, and therefore not an
extension to it.

0000534: unclear phrasing in "mv" regarding same source and destination file

I. Suppose I want to replace a hard link with a symlink without disturbing other processes that might want to use it:

>file
ln file link
ln -s file link.tmp
mv -f link.tmp link

Is this required to succeed? What guarantees, if any, are there concerning the state of "link" when all is said and done?

II. Similarly, suppose I do:

>file
ln -s file file.tmp
mv -f file.tmp file

Is this required to succeed, and must "file" end up a symlink to itself?

III. How about this?

>file
ln file file2
ln -s file link
ln -s file2 link.tmp
mv -f link.tmp link

Is this required to succeed, and must "link" end up as a symlink to file2 if it does?

Reading the mv specification, it seems to come down to what it means for two operands to name the same file in step (2).

If naming the same file means referring to the same inode after following symlinks (e.g., checked using stat()), that would mean that in example (III) above an implementation can succeed by removing link.tmp and leaving link as a symlink to "file" (step 2c).

I suspect the intent was rather for "name the same file" to mean referring to the same inode after path resolution (e.g., checked using lstat()). This would match the corresponding case in rename():

| If the old argument and the new argument resolve to either the same
| existing directory entry or different directory entries for the same
| existing file, rename() shall return successfully and perform no other
| action.

There might be some alternative non-buggy condition to use. See http://debbugs.gnu.org/6960 [^] for some thoughts on that subject.

0000531: Inclusion of may make visible symbols defined in

Struct timespec is allowed (since IEEE Std 1003.1-2001/Cor 2-2004, item XBD/TC2/D6/25) to be defined in , however the text then was not accompagnied by the usual boilerplate "Inclusion of the header may make visible symbols defined in " (where is the native place where struct timespec is to be fully defined.)

With IEEE Std 1003.1-2008, the definition of struct timespec is no longer optional.

This is at odds with the way struct timespec is handled in the (various) other headers which are referencing it.
Also several mainstream operating systems took for granted they could import their (or ) namespaces when including ; it is certainly not an excuse though.

Another solution could be to "move" the reference to struct timespec toward , effectively making it a "POSIX base type." It would lower the name pollution, but the fact it is a struct, not a typedef, could be problematic. Also it won't reduce the already existing pollution (sys/select.h, aio.h are examples.)

0000073: wmemcmp C conflict?

This issue is for tracking purposes.

The following question is being discussed in the C committee at present, and highlights a difference between C-1990 with AMD-1 and C99. POSIX has followed the C89+AMD1 words, and so is possibly at odds with C99.

===> from Joseph Myers

When are wide string library functions required to handle values of type
wchar_t that do not represent any value in the execution character set,
and when does using such values with a library function result in
undefined behavior?

Consider the following testcase as an example:

#include
#include

wchar_t w0 = WCHAR_MIN;
wchar_t w1 = WCHAR_MAX;

int
main (void)
{
if (wmemcmp (&w0, &w1, 1) < 0)
return 0;
else
abort ();
}

Suppose that WCHAR_MIN and WCHAR_MAX do not both represent values in the
execution character set. If the arguments to wmemcmp are valid, wmemcmp
must return a value less than 0 because 7.24.4.4 says the comparison is
done the same way as comparing integers of type wchar_t, so the program
must execute successfully. With the GNU C Library, however, it aborts;
wchar_t is UTF-32 but has a signed type so WCHAR_MIN is negative and does
not represent a member of the execution character set.

C90 AMD1 had an explicit statement (7.16.4.6) that made clear that these
inputs were valid (and so wmemcmp had to return a value less than 0 for
the above example in C90 AMD1):

These functions operate on arrays of type wchar_t whose size is
specified by a separate count argument. These functions are not
affected by locale and all wchar_t values are treated identically. The
null wide character and wchar_t values not corresponding to valid
multibyte characters are not treated specially.

I cannot however find any equivalent statement in C99. Was this a
deliberate change from AMD1, or a side-effect of how the functions were
rearranged when added to C99?

POSIX repeats the above requirement from C90 AMD1, but I believe this is
an accident of taking the specification from there originally and is not
intended to impose any requirements beyond those of C99.

Much the same issue applies to wcscmp and wcsncmp, where the comparison
semantics are specified but AMD1 has no mention of wide characters not
corresponding to members of the execution character set, and in principle
to other wcs* and wmem* functions that have no reason to need to consider
the semantics of the characters they process (but are less likely than the
comparison functions to have problems with the full set of wchar_t values
in practice).

0000514: Enhance internal macros in make

The set of make's internal macros is expanded in some make implementations, or have various restrictions removed.

The "$<" value has special-case restrictions; remove them. Also, add $^ (list all prerequisites without dups) and $+ (list all prerequisites with dups - e.g., for linking).

0000506: additional grantpt errors are possible

In several implementations, grantpt() is implemented by forking and execing
a setuid helper application to make the requested changes on the slave side
of the just-opened pseudo-terminal. Therefore, we probably ought to document
additional possible errno values.

0000530: Support in-place editing in sed (-iEXTENSION)

I propose standardizing option(s) so sed users can perform in-place editing of files in an easier, more efficient, and less error-prone way. This capability is already supported in several widely-used sed implementations using (at least) the “-i” option; I know it’s in at least GNU sed, FreeBSD sed, and MacOS sed. Here are the details on why I think this is worth standardizing.

It is extremely common for sed to be used on already-existing files to make changes. Currently, the obvious way to do this portably is to combine sed with mv or cp. That works, but this is overly complicated for such a common simple task, especially when there are multiple files (e.g., find … -exec … {}.bak isn’t portable, and using while loops portably and correctly requires read -r, IFS setting, quoting everywhere, and assuming filenames won’t include newline). It is also inefficient; this starts at least two processes for each file, and sed must be re-initialized separately for each file (again, this matters when there are many files).

Search-and-replace becomes really easy to do efficiently with in-place editing. E.g.:
find . -name "*.c" -exec sed -i.bak -e 's/foo/bar/g' {} +
or if it’s just the current directory:
sed -i.bak -e 's/foo/bar/g' *.c

A variety of sed implementations support in-place editing:
* GNU sed: http://www.gnu.org/software/sed/manual/html_node/Invoking-sed.html#Invoking-sed [^] (note that extensions containing “*” are treated specially)
* FreeBSD sed: http://www.freebsd.org/cgi/man.cgi?query=sed&apropos=0&sektion=0&manpath=FreeBSD+8.2-RELEASE&arch=default&format=html [^] (it has a -I as well as -i)
* MacOS sed: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/sed.1.html [^] (their documentation recommends using an extension to keep a backup, but it does document a no-backup-extension capability).

The Wikipedia article on sed (as of this moment in time) highlights this extension to sed as important, saying: “GNU sed added several new features. The best-known is in-place editing of files (i.e., replace the original file with the result of applying the sed program), which was later included in BSD sed too. This feature is nowadays often used instead of ed scripts....”.

Let me try to quickly counter some objections:
1. Won’t this imply adding a similar option to every filter? No. The “sed” utility is usually used for relatively simple text manipulation cases, so making it especially easy to use for its common case makes sense.
2. Why should it manipulate files when it deals with streams? The sed utility already reads data from files, after all, that’s where the data often is. This option just makes it easier to put the data back where it belongs once stream processing is done.

The good news is that there is widespread support for in-place editing, and the syntax even has wide agreement *if* the original file contents are backed up with an extension. The syntax, supported by GNU sed, FreeBSD sed, and MacOS sed (at least), is “-iEXTENSION”. With this, each original “file” is kept as “fileEXTENSION” and the new contents are stored in “file”. (Perl even copied that syntax; I’m not proposing to standardize perl, just noting that this capability is so common that other tools are copying it.) These implementations differ subtly in semantics if “*” is part of the extension, because in GNU sed, every instance of “*” is replaced with the filename. I don’t think this GNU sed capability is used often and thus doesn’t need to be standardized; it’d be easy to just declare that the semantics are undefined if “*” is part of EXTENSION, so that GNU sed can keep doing that but no one else has to copy it. In all cases, line numbering restarts at 1 for each new file, and “$” matches the end of each file.

Sadly, GNU sed and FreeBSD/MacOS differ on the syntax if no extension is cuddled right after the “-i”. In GNU sed, the extension is optional; if it’s not immediately cuddled after the “-i” then there is no extension, and no backup is kept (perl uses this syntax too). In FreeBSD and MacOS, the extension is required; if no extension is cuddled after the “-i” then the NEXT ARGUMENT is used as the extension, and if that next argument is the 0-length "", no backup is kept. So everyone supports backups if you just cuddle the extension right after “-i”. In addition, everyone supports omitting the backup, but they have slightly different incompatible syntaxes for doing so, which leads to an interesting question in that case.

I see these options for standardizing in-place editing without backups:
1. Don’t support it in the standard; require that backups be kept when using -i, and require users to do the mv by hand if they don’t want backups. I think that’s a bad idea. Not needing backups is common (particularly when it’s part of a script or makefile command), so people will probably keep using nonstandard constructs for common cases. If someone uses -i on “all files” and forgets to erase the backups after each time, they can end up with file.bak, file.bak.bak, file.bak.bak.bak, and so on. It’s also a problem when you have many big files; the option flag system shouldn’t force people to keep backups if they are processing 10,000 files that are a gigabyte each! The standard can do better.
2. Require everyone to support -i "" (a separate null-length argument) as a special case meaning “don’t keep a backup”. FreeBSD and MacOS do this already. This would require a patch to GNU sed, but it’s hard to imagine that this weird extension would interfere with any scripts; a null-length string is not a valid option, and it’s not a valid filename. GNU sed could, when it confronts “-i” with no extension, look at the next parameter to see if it’s zero-length and consume it if it is. It is odd, however.
3. Create a new option flag to mean “-i, but do not keep backup files”. I don’t care so much which flag is used, but in the spirit of putting forth a concrete proposal, I would propose “-N” (for iN-place). This would be a standards committee invention, but the invention is not the ability (many sed implementations have this). The invention is the name of a common option flag, created because there are incompatible interfaces in current practice and the point of a standard is to create some common way to invoke functionality.

I’m currently proposing #3, but option #2 would work too.

If we wish to stay compatible with current practice this a minor violation of XBD 12.1 point 2a. Basically, users MUST cuddle the extension right after “-i” (as this is the agreed-on intersection between GNU and FreeBSD/Apple). But lots of commands already violate XBD 12.1 in various small ways. This particular kind of minor violation occurs in several other places in the standard. In addition, it doesn’t create a new violation, it just documents a minor violation already in existing practice.

0000521: Behaviour of !(command) should not be specified

Currently section 2.9.2, in combination with the tokenisation rules
and grammar, requires that !(command) is treated as a pipeline
beginning with the reserved word ! and containing a subshell command.

However, in ksh88 this was treated as a negated pathname expansion
!(pattern), not a negated subshell command. Since the POSIX shell
description was based on ksh88, specifying negated pipelines in a way
that made ksh88 non-conforming was clearly not intended.

0000522: Says shmat() returns -1 on error; should be (void*)-1

The declaration for shmat() is:

void *shmat(int shmid, const void *shmaddr, int shmflg);

The description of the returned value say, in part:

Otherwise, the shared memory segment shall not be attached, shmat() shall return -1, and errno shall be set to indicate the error.

-1 is of type int, not of type void*

0000523: Add support for special target .PHONY in make

It is often useful to define "make" targets that are not simply the name of a file generated when running make, but are instead the name of a "recipe" to do some task by that name. In these cases, it is useful to be able to declare that these targets are "PHONY" using the .PHONY special target. Such targets are considered to not exist for the purposes of make's execution.

One use case is names for items that will never create a file. "make all", "make test", and "make clean" are some common cases. It's common to see:
.PHONY: all
all: prog1 prog2
So that "make all" will always make "prog1" and "prog2". Otherwise, if a file "all" was ever created in the directory, "make all" probably fail to work as intended. Instead, make will check to see that all came after prog1 and prog2, and if it is, is will not rebuild prog1 and prog2 as needed. There are also performance advantages; on systems with rule chaining, implicit rule searching can be short-circuited (since the system knows the file will not exist, for make's purposes).

Another use case is when you want to name subdirectories, so that "make DIR" will execute the default makefile for some subdirectory DIR. In this case, the subdirectory DIR will already exist, making it more convoluted to execute the make. By declaring DIR as .PHONY, make will ignore the fact that the directory already exists, and act as if it did not.

Many implementations of "make" include support for the special target .PHONY, including:
* GNU make
* NetBSD make (implemented as "bmake" on Fedora Linux)
* FreeBSD’s make http://www.freebsd.org/cgi/man.cgi?query=make&sektion=1 [^]
* OpenBSD’s make http://www.openbsd.org/cgi-bin/man.cgi?query=make&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html [^]
* fastmake http://www.fastmake.org/doc.html [^]

For example, here is FreeBSD's documentation on .PHONY:
.PHONY Apply the .PHONY attribute to any specified sources. Targets with this attribute are always considered to be out of date."

This is so useful that even some very basic introductions to "make" include it, e.g.:
http://linuxdevcenter.com/pub/a/linux/2002/01/31/make_intro.html?page=2 [^]

Phony targets can have prerequisites, but I don't think that needs to be specified here; the existing make specification handles that quite well without any additional material.

I didn't find much documentation on what should happen with a blank target list for phony, that is:
.PHONY:
but both GNU make and NetBSD make ignore such statements, which seems reasonable enough. Erasing the list, as with .SUFFIXES, seems like a bad idea.

I did add to the definition some material that's only implied in typical documentation. Once you "build" a phony target, it's not rebuilt again during that execution of 'make'. For example, "make all" will print "Hello there" only once, not twice, given this makefile:
all: def ghi
def: abc
ghi: abc
abc:
@echo "Hello there"
.PHONY: abc

You can sort-of get the effect of .PHONY in the first case by selecting a file you're "sure" won't happen, e.g., "FORCE":
clean: FORCE
rm $(objects)
FORCE:
However, using .PHONY is more specific and efficient (especially if a make implements rule chaining or complex VPATHs). And if someone creates a file named FORCE, very weird things happen in this case. (If the filesystem folds case, which happens on some systems, even creating files like "force" can cause real problems.) And this approach completely fails to handle the case where you'd like to allow "make DIR", where DIR is the name of a subdirectory to be built. As a result, many "make" implementations include .PHONY.

0000525: portable makefile example

The standard is redundant: this text appears in both APPLICATION
USAGE (lines 96098-96102) and RATIONALE (lines 96267-96271):

"The best way to provide portable makefiles is to include all of the
rules needed in the makefile itself. The rules provided use only
features provided by other parts of this volume of POSIX.1-2008. The
default rules include rules for optional commands in this volume of
POSIX.1-2008. Only rules pertaining to commands that are provided are
needed in an implementation’s default set."

Furthermore, the standard requires that a portable makefile start with
the special target .POSIX, then proceeds to give an example makefile
that does not use that target. The remaining examples only claim to
be a portion of a makefile, rather than an entire makefile.

0000330: In make, add support for assignments "::=", "+=", and "?=".

The widely-supported additional assignment operators ":=", "+=", and "?=" should be added to the standard's specification for make, as they greatly speed up and simplify larger systems that use make. Below are the arguments for each.

Traditional make macros (defined with "=") cause exponential growth in execution time, inhibiting scalability as systems get bigger and more complex. That's because instead of being expanded when they are defined, they are expanded on use. A widely-used alternative is ":=", which creates an 'immediate-expansion' macro (which are expanded immediately) instead of a traditional 'delayed-expansion' macro.
The article "Recursive Make Considered Harmful" by Peter Miller
(http://miller.emu.id.au/pmiller/books/rmch/ [^] and
http://aegis.sourceforge.net/auug97.pdf) [^] notes this as a key problem when creating makefiles,
and strongly recommends using := instead.
Similarly, the guidelines "How-to write a makefile" specifically
recommend using := and not = because of efficiency issues, even for portable makefiles
(http://sites.google.com/site/michaelsafyan/coding/resources/how-to-guides/how-to-write-a-makefile). [^]

Immediately-expanded macros are not only more efficient, they also tend to be easier for developers to use. Traditional macros are very different from "normal" variables in other languages, and thus traditional macros are also a trap for the unwary. Since := style macros work like traditional variables, using them eliminates a subtle source of errors.

The "+=" (append) and "?=" (set if not already set) simplify setting macro variables. These make it simple to perform relatively common operations. These are especially helpful in larger systems with multiple makefiles that are combined together into a single large run of 'make'.

The ":=", "+=", and "?=" operators already have wide support:
* GNU make: http://www.gnu.org/software/autoconf/manual/make/index.html [^]
* FreeBSD make: http://www.freebsd.org/cgi/man.cgi?query=make&sektion=1 [^]
* OpenBSD make: http://www.openbsd.org/cgi-bin/man.cgi?query=make [^]
* Solaris make: http://developers.sun.com/solaris/articles/make_utility.html [^]
* MKS make supports := and += (though not ?=) http://www.mkssoftware.com/docs/man1/make.1.asp [^]
There are probably others, but that should be enough to make the point. There's some common code heritage, of course, but my point is that it's widely available, and thus should be in the standard.

These additions are relatively simple to implement, for the rare implementations that don't already have them.

0000526: Adopt C99 wording for zero size calloc(), malloc() et al.

While correcting the application of 0000400 in the TC1 draft it was
noticed that the wording related to the zero size case for calloc(),
malloc() and realloc() is different in C99, which says:

If the size of the space requested is zero, the behavior is
implementation-defined: either a null pointer is returned, or the
behavior is as if the size were some nonzero value, except that
the returned pointer shall not be used to access an object.

The C99 wording is better because it avoids explicit mention of
passing the returned pointer to free(), thus ensuring there can be no
doubt about whether the pointer can also be deallocated by realloc().

In fact, 0000400 already changes the realloc() DESCRIPTION wording
to match C99 but does not remove the now-redundant mention of free()
in the RETURN VALUE section.

The proposed changes also make the errno handling for calloc() and
malloc() more consistent with the realloc() change in 0000400,
although using "may" because they don't have the same need for
errno to indicate that the space was not freed.

In addition they tidy up an editorial problem with duplicate
statements in the 0000400 text about the returned pointer being
used to access an object. (The statement is made once as "shall not
be used" as in C99, and once as "the application shall ensure ...";
the changes turn the first one into a statement about undefined
behaviour, since the second is the appropriate POSIX wording.)

For consistency, similar changes should be made for posix_memalign().