Viewing Issue Advanced Details
1470 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Error 2021-05-07 13:22 2021-05-07 13:22
dennisw
 
normal  
New  
Open  
   
Dennis Wölfing
tdelete
2138-2139
68532-68556
---
tdelete example is incorrect
The example says that a comparison function that always returns 0 can be used with tdelete to delete the root node of a binary search tree. However the standard does not actually guarantee this. It only says that some node will be deleted in this case but nothing says that this will be the root node.

Perhaps a balancing search tree algorithm might need to look at multiple nodes to ensure balancing and might then end up with deleting a non-root node since all nodes are considered to be equal.
On page 2138 line 68532 change
tdelete((void *)elementptr, &root, delete_root);
to
tdelete((void *)elementptr, &root, node_compare);


On pages 2138-2139 lines 68547-68556 delete
/*
 * This comparison routine can be used with tdelete()
 * when explicitly deleting a root node, as no comparison
 * is necessary.
 */
int
delete_root(const void *node1, const void *node2)
{
    return 0;
}
There are no notes attached to this issue.




Viewing Issue Advanced Details
1469 [Issue 8 drafts] Base Definitions and Headers Editorial Error 2021-05-04 16:03 2021-05-06 15:07
dennisw
 
normal  
Resolved  
Accepted  
   
Dennis Wölfing
<search.h>
316
11052-11055
Inconsistent return type for tfind and tsearch
0001011 added the posix_tnode type and changed the return types of tfind and tsearch to posix_tnode*. However in the current draft the return type is only changed in XSH but not in XBD <search.h>.
On page 316 line 11052-11055 change
void *tfind(const void *, posix_tnode *const *,
    int(*)(const void *, const void *));
void *tsearch(const void *, posix_tnode **,
    int(*)(const void *, const void *));
to
posix_tnode *tfind(const void *, posix_tnode *const *,
    int(*)(const void *, const void *));
posix_tnode *tsearch(const void *, posix_tnode **,
    int(*)(const void *, const void *));
Notes
(0005350)
geoffclare   
2021-05-06 09:30   
Thanks for spotting this. Clearly an oversight on my part when I applied bug 1011. I changed the function parameters in <search.h> but not the return types.




Viewing Issue Advanced Details
1468 [1003.1(2008)/Issue 7] Shell and Utilities Editorial Enhancement Request 2021-04-24 15:20 2021-04-24 21:10
mortoneccc
ajosey  
normal  
Under Review  
Open  
   
Ed Morton
awk
2493
80182-80184
---
awk FS definition not quite correct
(sorry, I don't see any page or line numbers in the online spec, hence the 1 and 1 used above).

In the definition of FS in the awk spec (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html) [^] it says:

-----
The following describes FS behavior:

   If FS is a null string, the behavior is unspecified.

   If FS is a single character:

       If FS is <space>, skip leading and trailing <blank> and <newline> characters; fields shall be delimited by sets of one or more <blank> or <newline> characters.

       Otherwise, if FS is any other character c, fields shall be delimited by each single occurrence of c.

       Otherwise, the string value of FS shall be considered to be an extended regular expression. Each occurrence of a sequence matching the extended regular expression shall delimit fields.
-----

but that final case isn't exactly correct because an ERE can match a null string while a FS can't. Try for example splitting a record on all non-commas:

$ echo 'x,y,z' | awk -F'[^,]*' '{for (i=1;i<=NF;i++) print i, "<"$i">"}'
1 <>
2 <,>
3 <,>
4 <>

which makes sense since there's a null string before the first non-comma (x), 2 commas around the 2nd non-comma (y) and a null string after the last non-comma (z). Now remove the "y" from the middle to get:

$ echo 'x,,z' | awk -F'[^,]*' '{for (i=1;i<=NF;i++) print i, "<"$i">"}'
1 <>
2 <,,>
3 <>

and note that the null string between the 2 commas which would match the regexp `[^,]*` isn't actually matched by the FS `[^,]*`.
Change the final paragraph of the FS definition mentioned above to say something like "Otherwise, the string value of FS shall be considered to be an extended regular expression such that each occurrence of a sequence **of one or more characters** matching the extended regular expression shall delimit fields."
There are no notes attached to this issue.




Viewing Issue Advanced Details
1467 [Issue 8 drafts] Shell and Utilities Editorial Enhancement Request 2021-04-16 22:37 2021-05-06 15:08
kre
 
normal  
Resolved  
Accepted  
   
Robert Elz
XCU 2.14 Special Built-In Utilities, "colon"
2316
75174-5
Poor language in CHANGE HISTORY entry for Issue 8 for ':' command (defect 1272) changes.
The CHANGE HISTORY added to the colon special built-in shell command
includes the words:

   the null utility does not expand its arguments,

This was added because the earlier description of the command said:

   This utility shall only expand command arguments.

which was incorrect, the shell does the arg expanding, the utility
does nothing at all with its arguments.

However the choice of words "does not expand" could be misinterpreted to
indicate that the shell should also not expand the arguments to this utility.
That is not what is intended.

Please note that (by request) this bug is being submitted against
Issue 8, draft 1.1 (and the page and line numbers reflect that) but
bug 1272 (which caused this section to be inserted) is tagged for Issue7-tc3
so if there ever is a tc3 for issue 7 (I know, not currently planned, but...)
this bug should be handled when the CHANGE HISTORY for this issue is
modified from Issue 8 to whatever it will be in that case.
Change the clause (which spans lines 75174 and 75175) from

    the null utility does not expand its arguments,

to

    the null utility does not process its arguments,

which reinforces the args being ignored, which they are, while not
suggesting that the args would not be expanded before the utility is invoked.

Other wording which avoids the suggestion that the args do not get
expanded would be fine.
Notes
(0005320)
kre   
2021-04-16 22:48   
Ugh: When I added that "Please Note" paragraph in the Description
(the last thing I did before submitting) I though I was added it right
at the end of the description ... the paragraph that follows should
come before that one!

Apologies for not checking more thoroughly.
(0005321)
Don Cragun   
2021-04-17 00:33   
Description modified as suggested in Note: 0005320.
(0005322)
geoffclare   
2021-04-19 08:13   
Regarding getting this change into TC3 (if there is one), this bug should be tagged tc3-2008 when it is accepted, so that it will be applied in the Issue7TC3 branch in gitlab.
(0005324)
kre   
2021-04-19 17:09   
Re Note: 0005321 Thanks.




Viewing Issue Advanced Details
1466 [Issue 8 drafts] Base Definitions and Headers Editorial Enhancement Request 2021-04-16 15:22 2021-04-19 20:44
jauricchio
 
normal  
New  
Open  
   
Joe Auricchio
Apple Inc.
3.277 Pseudo-Terminal and others
68-2126
2129-68880
Pseudo-terminal devices should be renamed
At Apple, we’re working to remove and replace non-inclusive language across our developer ecosystem, including within Xcode, platform APIs, documentation, and open source projects [1]. In this effort, we are allied with individuals and organizations across the software industry. For example, in July 2020, the Linux kernel style guide was updated to recommend avoiding non-inclusive language [2], and in December 2020, IEEE committed to write standards to avoid non-inclusive and insensitive terminology [3]. As part of this effort, we would like the Austin Group’s help in updating the language used in the POSIX standard.

The two device ends of a pseudo-terminal are named the “master” and “slave” devices in previous and current versions of the standard. These should be renamed.

We invite the Austin Group community to propose new names, debate, and reach consensus. Since this has become an issue of public discourse, many suggestions have been made on forums across the internet, so there is no shortage of ideas out there.

[1] https://developer.apple.com/news/?id=1o9zxsxl [^]
[2] https://standards.ieee.org/about/sasb/resolutions.html [^] (December 2020)
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst#n338 [^]
The words “master” or “slave” within the context of pseudo-terminal devices appear in the following places in Issue 8 Draft 1.1 (202x_d1.1.pdf). Please update all of these when new names are chosen.

Page 68, lines 2129-2133. 3.277 Pseudo-Terminal
Page 181, line 6422. 11.1.1 Opening a Terminal Device File
Page 659, lines 22861-22863. close() - Description
Page 663, line 23061. close() - Change History
Page 1086, lines 37188-37191. grantpt() - Description
Page 1086, line 37200-37202. grantpt() - Errors
Page 1375, line 46052. open() - Description
Page 1375, line 46070-46072. open() - Description
Page 1377, line 46146. open() - Errors
Page 1421, line 47580. posix_openpt() - Description
Page 1421-1422, lines 47604-47619. posix_openpt() - Examples
Page 1422, line 47622-47624. posix_openpt() - Application Usage
Page 1422, lines 47627-47632. posix_openpt() - Rationale
Page 1667, lines 54812-54817. ptsname() - Description.
Page 1667, line 54823-54824. ptsname() - Return Value
Page 1667, line 54841. ptsname() - Errors
Page 1668, line 54849. ptsname() - Rationale
Page 2061, lines 66908-66910. tcsetwinsize() - Application Usage
Page 2126, line 68870-68872. unlockpt() - Name
Page 2126, line 68865. unlockpt() - Description
Page 2126, line 68880. unlockpt() - Errors
Notes
(0005325)
enh   
2021-04-19 20:44   
since POSIX is all about "standardizing existing practice"... fwiw, in Android we already went with "pty"/"tty" for master/slave in APIs like openpty(). from a checkin comment (https://android-review.googlesource.com/c/platform/bionic/+/1374048): [^]

```
This was initially just to try on "pty" and "tty" for size, while
discussing with other projects to try to align on vocabulary, but -- in
the implemention and tests at least -- but these work out so well that
I'm tempted to go with them anyway if we can't come to a concensus. We
can always come back and change them again later.

What I really like is that you pass the pty to functions like ptsname()
and grantpt() with a 'p' in the name, and the tty to functions like
ttyname() and tcsetattr() with just 't's.

The use of "parent" and "child" in forkpty() seems helpful too.
```


the Linux man-pages project went with
```
    slave ==> "terminal device"
           (or "terminal end of the pseudoterminal device pair")
    
    master ==> "pseudoterminal device"
           (or "pseudoterminal end of the pseudoterminal device pair")
    
    pseudoterminal (device) ==> "pseudoterminal device pair"
```
see https://www.spinics.net/lists/linux-man/msg16641.html [^] for more (including a long discussion of alternatives, but also background links for some of the precedent we went with).


(as an aside, if there's someone from Apple who'd be interested in joining the libc-coord@lists.openwall.com list, that's a good place for libc owners to coordinate changes, and i think Apple's the biggest libc that's not yet represented there.)




Viewing Issue Advanced Details
1465 [Online Pubs] Shell and Utilities Editorial Error 2021-04-11 06:18 2021-04-12 08:39
mihai_moldovan
 
normal  
New  
Open  
   
Mihai Moldovan
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#trap [^]
trap
trap synopsis missing newline
The trap utility has two different forms, which are described in the text later on.

However, the synopsis currently lists just one weird form, since both are concatenated there.
Add newline between the two different forms of the trap utility.
Notes
(0005310)
Don Cragun   
2021-04-11 08:16   
It displays correctly in the PDF of the 2017 version of the standard (2008 + TC1 + TC2) on P2420 L77484-77485.
(0005311)
geoffclare   
2021-04-12 08:38   
This was previously reported in bug 0001285 and the root cause was identified as a problem in the troff source; a fix has been applied there. However, it would make sense to do a separate fix in the current HTML version.




Viewing Issue Advanced Details
1464 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Enhancement Request 2021-04-05 13:20 2021-04-08 19:15
mohd_akram
 
normal  
New  
Open  
   
Mohamed Akram
grep
2842-2843
93588,93590,93592,93642
---
grep(1): add -o option
The -o option makes grep print only the matching parts of a line. It's widely available across systems.
On page 2842, line 93588, change

  grep [−E|−F] [−c|−l|−q] [−insvx] −e pattern_list

into

  grep [−E|−F] [−c|−l|-o|−q] [−insvx] −e pattern_list

On page 2842, line 93590, change

  grep [−E|−F] [−c|−l|−q] [−insvx] [−e pattern_list]...

into

  grep [−E|−F] [−c|−l|-o|−q] [−insvx] [−e pattern_list]...

On page 2842, line 93592, change

  grep [−E|−F] [−c|−l|−q] [−insvx] pattern_list [file...]

into

  grep [−E|−F] [−c|−l|-o|−q] [−insvx] pattern_list [file...]

On page 2843, insert after line 93641

  -o Print only the matching parts of selected lines.
Notes
(0005301)
kre   
2021-04-05 15:14   
I have no problem in principle with adding the option, but even though
the typical man page for it says exactly what has been suggested here,
that's not nearly adequate to describe how the option works, or should work.

In particular, if I do:

     echo 'abc
     xxx yzpq
     abc def abc
     abcabcabc def abc' | grep abc

then I get the 3 lines that contain abc. If I add -o, on the implementation
I use anyway (no idea if this is as intended, or a bug) I get 7 lines of
output, one for each instance of 'abc' in the input stream. The 7 lines
each contain exactly 'abc'.

If I combine -c with -o, the answer is 3, just as if the -o was not there.

If the answer had been 7 things would have been more consistent, and the
-o would have been useful as a way to count how many times the pattern
appears in the file (but would probably need specification of what happens
with patterns that overlap ... it probably needs that anyway).

If I combine -n with -o ... well this one has to be seen to be believed.

     echo 'abc
     xxx yzpq
     abc def abc
     abcabcabc def abc' | grep -no abc
     1:abc
     3:abc
     abc
     4:abc
     abc
     abc
     abc

Is that what is supposed to happen? I have no idea, but what I do know
is that "-o Print only the matching parts of selected lines." is not nearly
a good enough description of what is happening. But nor is it good enough to
describe what should happen, if this was not it.

I didn't bother testing it, but I'm not sure that I could even guess what
combining -v and -o might do ... what does it mean to print only the
matching parts of lines that do not match?

Presumably -o would be a no-op when used with -q.

Personally, I'd send this option back to the drawing board, and let whoever
initially invented it do a better job of specifying it, at the very least.
As it is now (at least the implementation I use) it looks very much like
a hack invented to solve some particular problem (which would probably have
been better handled by sed) with essentially no thought given to how it
interacts with the rest of what grep does.
(0005302)
stephane   
2021-04-05 17:08   
Also note that with the GNU implementations (where the option comes from), only the non-empty matches are output (one per line). So you can be in a situation where nothing is output, but grep returns success as some lines matched.

With the ast-open implementation (which is the grep builtin of ksh93 when built as part of ast-open), empty matches are output, but then you enter an infinite loop as the same match is found again and again.

Try:

echo foo | grep -o '^'


for instance. In that implementation,

$ echo foo | grep -o '^.'
f
o
o


As after the first match, "^." is matched against what follows on the line, so "oo"

Some sed implementations have the same kind of issue with s/^./x/g or s/\<./x/g
(0005303)
stephane   
2021-04-05 17:15   
pcregrep has -o1, -o2 and --om-separator which is useful with things like:

grep -Eo1 -o2 '^(....).*( error: .*)'


for instance.

Though that's the thing you'd use "sed" for portably:

sed -nE 's/^(...).*( error: )/\1\2/p'


(except that few sed implementations support perl-like regexps; you can do the same with "perl -n" but that's outside the scope of POSIX).

IMO, grep -o is useful especially when combined with -P on the command line as a quick way to extract information, but is otherwise mostly redundant with sed/perl.
(0005304)
geoffclare   
2021-04-06 14:23   
Another difference between BSD and GNU:

BSD (macOS)
$ echo abc | grep -o -e ab -e bc
ab
$ echo abc | grep -o -e bc -e ab
bc

GNU
$ echo abc | grep -o -e ab -e bc
ab
$ echo abc | grep -o -e bc -e ab
ab
(0005305)
stephane   
2021-04-06 16:29   
Re: Note: 0005304

well spotted. However note that one can't just say BSD to refer to the behaviour on any system in the BSD family when it comes to grep at least.

For a long time, grep on most BSDs was GNU grep, and AFAIK it still is on FreeBSD and NetBSD (though based on a very old version). IIRC macos relatively recently switched to a different implementation (which is why you can't get access to the source code any longer).

I don't have access to a macos machine, but the behaviour you're describing matches that of FreeBSD and NetBSD based on GNU grep 2.5.1, so it's likely the behaviour one could find in older versions of GNU grep.

On OpenBSD, which has a different implementation (but likely also tried to preserve some backward compatibility to the GNU grep API), I get:
$ grep --version
grep version 0.9
$ echo abc | grep -o -e ab -e bc
ab
bc
(0005306)
stephane   
2021-04-06 16:55   
Re: Note: 0005301

Out of curiosity, I tried
echo x | grep -vno y


I find that:

- in the ancient GNU grep 2.5.1 as found on FreeBSD or NetBSD (also verified with a build of that old version on GNU/Linux), it outputs 1: without trailing newline

- in recent GNU grep and in OpenBSD grep it outputs nothing and returns success (which sounds like the most reasonable behaviour to me)

- in ast-open grep, it outputs 1:x

- in busybox grep, it segfaults
(0005307)
enh   
2021-04-06 17:04   
fwiw, toybox (and thus Android) agrees with ast-open for that one:

/tmp/toybox$ echo x | ./toybox grep -vno y
1:x

it matches GNU for the '^'/'^.' and ab/bc examples.

why do you think that "output nothing and return success" makes sense? i wasn't responsible for the toybox behavior, but it's actually doing what i'd have guessed -vno would mean here. (and i don't understand the GNU behavior at all, especially with input like yxya where toybox's 1:x 1:a is again what i'd expect, but GNU outputs nothing at all!)
(0005308)
kre   
2021-04-06 22:39   
(edited on: 2021-04-06 22:54)
The default NetBSD grep is indeed GNU grep 2.5.1a (with a local change, I
did not check what that is).

But we can also build a different grep, it is a choice when building the
system, It claims to bs 2.5.1 (that's suspicious) from FreeBSD.
(It is much smaller than the normal one, which is ~100KB text,
whereas this one is just ~25K text).

The small one includes
    * Copyright (c) 1999 James Howard and Dag-Erling Co\xc3\xafdan Sm\xc3\xb8rgrav
    * Copyright (C) 2008-2009 Gabor Kovesdan <gabor@FreeBSD.org>
It has a standard BSD licence (no GPL).

That one is much the same as shown for BSD grep above, except the
     echo x | grep -vno y
test prints 1:x (with the newline!)

and
     echo foo | grep -o '^.'

prints just one line 'f' (with the newline). No additional 'o' lines
(the default NetBSD grep - the one shipped with binary distributions, does
print the 'o' lines).

The case without the '.'
     echo foo | grep -o '^'
prints a single empty line (the default NetBSD grep prints nothing,
and yes, with an exit status of 0). With -n added, both versions
include 1: before what they otherwise (do or don't) print. That is
the small one prints "1:\n" and the big (GNU) one "1:".

For the grep -vno case, as I said in my original note, I can't guess what
might be correct, I can understand the 1:x output (that's taking the lines
that did not match (-v) and outputting what did not match from that line
(ie: -v inverts the sense of -o, which makes some sense). The case of
printing nothing also makes sense, that is taking the lines which did not
match, and printing what did match on those lines (ie: nothing). Apart from
the missing newline, the version that just prints 1: also makes some sense,
just the same as the one that prints nothing, except this one is obeying
the -n flag, even in that case. None of those is obviously right, or
obviously wrong.

The specification however is wholly inadequate. This request should be
withdrawn, until we get some common (documented) view of what -o should do,
and the implementations have a chyance to converge on that.

(0005309)
mohd_akram   
2021-04-08 19:15   
Toybox's behavior with regards to -vo is definitely the most useful, although it requires a change to how -v is described. GNU is probably the most accurate with respect to the current wording. I'm not sure how useful -vo is practically in the first place, but IMO the choice should be between toybox or "unspecified", since the other implementations either print nothing (useless) or have the same output as -v (also useless).

With regards to -n, GNU is both the most accurate with respect to the current wording ("precede each output line by its relative line number"), and the most useful, since the output can be more easily processed.

For '^.', it should only print the first character - I think this one is the least controversial. GNU is also correct in printing an empty line for empty matches.

In summary, I would say both Toybox and GNU's behavior satisfy the spec as it currently stands. At minimum, the other implementations need to fix their behavior with '^' (should only match line start), empty matches (should print a newline), and with -n (should prefix every output line with the line number).




Viewing Issue Advanced Details
1463 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Error 2021-04-02 22:44 2021-04-06 11:19
quinq
 
normal  
New  
Open  
   
Quentin Rameau
gencat
2820
92835
---
Small discrepency between the description and the explanation
The description of the quote option is stated as:

$quote n

and in the explanation, the character is illustrated as c instead of n:

This line specifies an optional quote character c
Replace the character 'n' in

$quote n

with 'c', as

$quote c
There are no notes attached to this issue.




Viewing Issue Advanced Details
1462 [1003.1(2016/18)/Issue7+TC2] System Interfaces Comment Enhancement Request 2021-03-26 15:34 2021-03-26 15:34
geoffclare
 
normal  
New  
Open  
   
Geoff Clare
The Open Group
time()
2149
68870
---
Require (at least) 64-bit time_t
The time() FUTURE DIRECTIONS section says:
In a future version of this volume of POSIX.1-2017, time_t is likely to be required to be capable of representing times far in the future. Whether this will be mandated as a 64-bit type or a requirement that a specific date in the future be representable (for example, 10000 AD) is not yet determined.
The time to do something about this is now, as the next major revision is likely to be at least ten years after this one, which will be uncomfortably close to 2038.

Note that if time_t is required to be 64-bit, implementations can still support legacy programming environments where time_t is 32-bit. In order to conform, there just needs to be at least one environment where time_t is 64-bit. (The suggested changes include additions advising about this.)
On page 2050 line 65758 section strftime() RATIONALE, change:
With tm_year being a signed 32 or more-bit int and with many current implementations supporting 64-bit time_t types in one or more programming environments, these assumptions are clearly wrong.
to:
Since tm_year is a signed int with a width of at least 32 bits and time_t is required to have a width of at least 64 bits (in conforming programming environments), these assumptions no longer hold.

On page 2149 line 68857 section time() RATIONALE, change:
Implementations in which time_t is a 32-bit signed integer (many historical implementations) fail in the year 2038. POSIX.1-2017 does not address this problem. However, the use of the time_t type is mandated in order to ease the eventual fix.
to:
Earlier versions of this standard allowed the width of time_t to be less than 64 bits. A 32-bit signed integer (as used in many historical implementations) fails in the year 2038, and although a 32-bit unsigned integer does not fail until 2106 the preferred solution is to make time_t wider rather than to make it unsigned.

On page 2149 line 68870 section time(), change FUTURE DIRECTIONS to:
None.

Cross-volume changes to XBD ...

On page 404 line 13726 section <sys/types.h>, change:
  • clock_t shall be an integer or real-floating type. [CX]time_t shall be an integer type.[/CX]
to:
  • clock_t shall be an integer or real-floating type.

  • [CX]time_t shall be an integer type with a width (see [xref to <stdint.h>]) of at least 64 bits.[/CX]

On page 450 line 15504 section <unistd.h> APPLICATION USAGE, add a new paragraph:
Implementations may support multiple programming environments with some of them conforming to this standard and some not conforming. The _POSIX_Vn_ILP* and _POSIX_Vn_LP* constants, and corresponding sysconf() and getconf calls, only indicate whether each programming environment is supported; they do not indicate anything about conformance of the environments that are supported. For example, an implementation may support the ILP32_OFF32 environment for legacy reasons with a 32-bit time_t, whereas in a conforming environment time_tis required to have a width of at least 64 bits. Application writers should consult an implementation's POSIX Conformance Document for information about the conformance of each supported programming environment.

Cross-volume changes to XCU ...

On page 2546 line 82421 section c99 EXTENDED DESCRIPTION, change:
Applications can use sysconf() or getconf to determine which programming environments are supported.
to:
Applications can use the _POSIX_Vn_ILP* and _POSIX_Vn_LP* constants in <unistd.h>, and corresponding sysconf() and getconf calls, to determine which programming environments are supported.

On page 2549 line 82527 section c99 APPLICATION USAGE, add a new paragraph:
Implementations may support multiple programming environments with some of them conforming to this standard and some not conforming. The _POSIX_Vn_ILP* and _POSIX_Vn_LP* constants in <unistd.h>, and corresponding sysconf() and getconf calls, only indicate whether each programming environment is supported; they do not indicate anything about conformance of the environments that are supported. For example, an implementation may support the ILP32_OFF32 environment for legacy reasons with a 32-bit time_t, whereas in a conforming environment time_tis required to have a width of at least 64 bits. Application writers should consult an implementation's POSIX Conformance Document for information about the conformance of each supported programming environment.

Cross-volume change to XRAT ...

On page 3519 line 119141 section A.4.16 Seconds Since the Epoch, change:
Implementations that implement time_t as a signed 32-bit integer will overflow in 2038. This standard requires that time_t be an integer type with implementation-defined size, but does not mandate a particular size.
to:
The number of seconds since the epoch overflows a signed 32-bit integer in 2038. This standard requires that time_t is an integer type with a width of at least 64 bits (in conforming programming environments).

There are no notes attached to this issue.




Viewing Issue Advanced Details
1461 [1003.1(2016/18)/Issue7+TC2] System Interfaces Comment Clarification Requested 2021-03-22 10:40 2021-03-22 10:40
geoffclare
 
normal  
New  
Open  
   
Geoff Clare
The Open Group
tgamma()
2145
68720
---
tgamma() with negative integer argument
The tgamma() FUTURE DIRECTIONS section says:
It is possible that the error response for a negative integer argument may be changed to a pole error and a return value of ±Inf.

C17 allows a domain error or a pole error (with implementation-defined return value). However, when IEC 60559 Floating-Point is supported, an "invalid" floating-point exception (i.e. a domain error) and NaN return are required. This has not changed in the Dec 2020 C2x draft. So changing POSIX to require a pole error would introduce a conflict with the C standard.

I would suggest that we just change POSIX to match the C standard, i.e. allow either a domain error or a pole error, when IEC 60559 Floating-Point is not supported.
On page 2145 line 68720 section tgamma(), change:
If x is a negative integer, a [CX]domain[/CX] error may occur and either a NaN (if supported) or an implementation-defined value shall be returned.
to:
If x is a negative integer, either a domain error or a pole error may occur and either a NaN (if supported) or +/-Inf (if supported), respectively, or an implementation-defined value shall be returned.

On page 2146 line 68762 section tgamma(), change:
Pole Error The value of x is zero.
to:
Pole Error The value of x is zero or a negative integer.

On page 2146 line 68781 section tgamma(), change:
It is possible that the error response for a negative integer argument may be changed to a pole error and a return value of ±Inf.
to:
None.

There are no notes attached to this issue.




Viewing Issue Advanced Details
1460 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Clarification Requested 2021-03-16 16:53 2021-03-22 09:40
geoffclare
 
normal  
New  
Open  
   
Geoff Clare
The Open Group
hash
2847
93806
---
hash implementations differ when a utility is not found
The behaviour of the hash builtin differs between shells as to whether they report an error when a utility specified as an operand is not found. For example, bash reports an error but ksh (88 and 93) does not.
After:
The name of a utility to be searched for and added to the list of remembered locations.
add a new sentence:
If the search does not find utility, it is unspecified whether or not this is treated as an error.

Notes
(0005277)
joerg   
2021-03-16 18:22   
Do you have other shells than ksh and mksh in mind?

There is a problem anyway since hash on these shells is a builtin alias instead of a builtin command.
(0005278)
shware_systems   
2021-03-16 19:01   
What type of error report is it, an exit code unequal to zero or just text to stdout/err? If the latter, and they still add remaining found operands, I'd think that's more an App Usage note, that some are silent, some not.
(0005279)
kre   
2021-03-17 03:05   
All shells I have tested do the "text to stderr" (not stdout) thing on
"hash garbage", all add "ls" in addition to that on "hash garbage ls".
The difference is the exit code, the various ksh versions and the NetBSD sh
exit 0 (always), bash, zsh, bosh, the FreeBSD sh, dash, yash all exit 1
when something failed to be added.
(0005280)
geoffclare   
2021-03-18 09:38   
Which version of ksh93 did you test? With 93u+ I get no message on stderr:

$ ksh -c 'echo ${.sh.version}; hash garbage; echo status $?'
Version AJM 93u+ 2012-08-01
status 0

Tested on Solaris 11.4 and Debian Buster. This matches how ksh88 (/usr/xpg4/bin/sh) behaves on 11.4

(I checked with "type garbage" that neither system has a "garbage" utility to find.)

If a later ksh93 has started writing a message to stderr without changing the exit status, that's a new non-conformance (violating 1.4 Utility Description Defaults under STDERR).
(0005284)
kre   
2021-03-18 18:29   
(edited on: 2021-03-18 18:32)
You're right, I didn't look closely enough at that, I got no message
from it (or the other ksh variants I tested), and just didn't notice...

Apologies.

(0005285)
kre   
2021-03-18 18:52   
(edited on: 2021-03-18 19:00)
I also just noticed, that in the Application Usage section of hash, it says
(Lines 92140-2 of Issue 8 draft 1.1 - it is also in older versions)

     The effects of hash -r can also be achieved portably by resetting
     the value of PATH; in the simplest form, this can be:

     PATH="$PATH"

That isn't true, at least of the NetBSD sh - for a very long time it has
optimised PATH setting wrt the hash table ... rather than invalidate the
whole thing, it looks to find the first changed element of the new PATH
compared to the old, and only invalidates hash table entries from that
point down, so if we had

    PATH=/a:/b:/c
and then changed it to
    PATH=/a:/x:/b

then anything found in /a that was in the hash table remains and
remains used, things from /c are removed (obviously) and sp are those
from /b. as we don't know that they aren't overridden by what's in /x

In particular that means that PATH=${PATH} is a no-op when it comes to
what happens to the hash table.

If one were to insist on manipulating PATH for this purpose, the way
to do it would be
      x=$PATH; PATH=; PATH=$x; unset x
(where 'x' is any variable name that isn't used anywhere else).

I see no point in this note in this section, hash -r is the way to
remove everything from the hash table, it is less costly than assigning
to PATH (even in the simple case given in the current text).

Can we just delete it?

(0005287)
geoffclare   
2021-03-19 10:57   
Re Note: 0005285, that statement about PATH is pointing out a normative requirement from XCU 2.9.1. In Issue 8 draft 1.1 it's on page 2292 line 74177:
Once a utility has been searched for and found (either as a result of this specific search or as part of an unspecified shell start-up activity), an implementation may remember its location and need not search for the utility again unless the PATH variable has been the subject of an assignment.

If you think this needs to change please submit a separate bug.

(0005292)
kre   
2021-03-19 16:03   
Re Note: 0005287: No I don't think 2.9.1 about this needs to change, but why
is not a topic for here, so I will discuss that on the mailing list.

However I still believe the relevant text in the hash command application usage
section, even if you were right and it follows directly from 2.9.1 (with which
I disagree) is inappropriate and should be deleted.

One would add an application usage hint like that if there were some
defect in the command being described, but an alternative, known working,
method was available. Eg: if it were unspecified whether "hash -r"
worked or not for clearing the hash table, but assigning to PATH always
did, then it would be reasonable to have a note like that. It would
also be reasonable if the alternative method were cumbersone, or could
have other side effects

But "hash -r" is not unspecified, is simple, it does work to clear the hash
table. But what is a new reader to believe when reading this Application Usage
section and seeing an alternative *portable* method to clear the hash table?
Perhaps "hash -r" is not portable? Better not use that then. The note,
even if it were correct, sends entirely the wrong message. It isn't needed.
Doing PATH=$PATH is the wrong way even if it worked (in addition to clearing
the hash table it also needs to expand $PATH and then do a variable assignment, which also means (as PATH is usually exported) perhaps rebuilding the
exported environment for no good reason. Just delete it.

On procedural issues, if you'd prefer a new bug, rather than a tack on to
this one, for this specific issue, I can do that, but in that case, please
indicate whether you would prefer it filed against 7 TC2 or 8 D1.1 (or
something else).
(0005296)
geoffclare   
2021-03-22 09:40   
Re Note: 0005292, since you emphasised *portable*, I think I now see how we arrived at the current situation. In Issue 6, hash was part of the XSI option. That text in APPLICATION USAGE was put there to advise users of shells that do not have a hash built-in how to achieve the same thing as hash -r without it. In Issue 7, hash was made mandatory and this advice became out-of-date and should have been modified at the time (as should 2.9.1 and/or the description of PATH to mention the hash table).

Since this issue is not related to the issue raised in this bug, it should be dealt with in a separate bug (against Issue7+TC2), alongside any related change to 2.9.1 and/or PATH that comes out of the mailing list discussion.




Viewing Issue Advanced Details
1459 [Online Pubs] System Interfaces Editorial Clarification Requested 2021-03-13 11:01 2021-03-15 09:26
andras_farkas
 
normal  
New  
Open  
   
Andras Farkas
https://pubs.opengroup.org/onlinepubs/9699919799/functions/signgam.html [^]
signgam
signgam.html differs from lgamma.html
The webpage for signgam
https://pubs.opengroup.org/onlinepubs/9699919799/functions/signgam.html [^]
differs from the webpage for lgamma
https://pubs.opengroup.org/onlinepubs/9699919799/functions/lgamma.html [^]
The lgamma.html, lgammaf.html, and lgammal.html pages are identical: this makes me assume that signgam.html should also be the same.
I'm not mathematically proficient enough to be a good judge of which one's better, but I have an instinctive feeling that lgamma.html is probably the "correct" version and signgam.html should be changed to match.

Also, neither formula image has alt text. (I don't know if it'd be easy to do for a math formula, though)

I wonder if there's an easier way to do things than to have multiple copies of these pages.
Change signgam.html so it's identical with lgamma.html
Notes
(0005270)
geoffclare   
2021-03-15 09:26   
In the PDF the signgam page is a pointer page to lgamma(). The HTML translator handles pointer pages by copying the referenced page, and in the original 2008 edition it appears that signgam.html was indeed a copy of lgamma.html:

https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/lgamma.html [^]

https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/signgam.html [^]

However, there have been subsequent changes made to lgamma.html that have not been duplicated in signgam.html.




Viewing Issue Advanced Details
1458 [Online Pubs] System Interfaces Editorial Omission 2021-03-13 10:08 2021-03-15 09:16
andras_farkas
 
normal  
New  
Open  
   
Andras Farkas
https://pubs.opengroup.org/onlinepubs/9699919799/functions/semctl.html [^]
semctl
semctl missing first link to sys/sem.h
On
https://pubs.opengroup.org/onlinepubs/9699919799/functions/semctl.html [^]
The first link that would normally be included isn't there.
In the text
#include <sys/sem.h>
the text
sys/sem.h
should be a link to
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_sem.h.html [^]

The semget and semop pages are currently correct, only semctl has this omission of a link.

This omission also affects the previous standard's equivalent page, too:
https://pubs.opengroup.org/onlinepubs/009695399/functions/semctl.html [^]
Make the text "sys/sem.h" in "#include <sys/sem.h>" a link to
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_sem.h.html [^]
Notes
(0005269)
geoffclare   
2021-03-15 09:16   
Looks like the root cause of this is that the troff source has:
#include\ <sys/sem.h>

The HTML translator is presumably looking for something like "#include[[:blank:]]*<" and so the backslash throws it off.

I will remove the backslash so that when the translator is run for Issue 8 the problem is not repeated, but the problem should in the meantime be corrected by hand in the current online edition.




Viewing Issue Advanced Details
1457 [1003.1(2008)/Issue 7] Shell and Utilities Editorial Enhancement Request 2021-03-09 21:21 2021-03-09 21:21
steffen
ajosey  
normal  
Under Review  
Open  
   
Steffen Nurpmeso
Vol. 3: Shell and Utilities.
(page or range of pages)
(Line or range of lines)
---
Add readlink(1) utility
Some POSIX utilities (like find) offer operators to work with symbolic links.
It is not possible to read content of symbolic links by itself as far as i know, as is offered by readlink(1) which seems to be widely available, for a long time.
The current standard does not mention this utility as having been obsoleted in the past either, so i am asking for inclusion.
Add the readlink utility.
The most minimal form seems to be from OpenBSD, it states:


NAME

readlink — display target of symbolic link on standard output
SYNOPSIS
readlink [-fn] file
DESCRIPTION

The readlink utility when invoked with the pathname of a symbolic link as its argument dereferences the symbolic link and prints the name of target on standard output. If the -f option is not specified and readlink is invoked with an argument other than the pathname of a symbolic link, it exits with a nonzero exit code without printing anything.

The options are as follows:

-f
    Canonicalize by following every symlink in every component of the given path recursively. readlink will resolve both absolute and relative paths and return the absolute pathname corresponding to file. The argument does not need to be a symbolic link.
-n
    Do not print a trailing newline character.

EXIT STATUS

The readlink utility exits 0 on success, and >0 if an error occurs.
There are no notes attached to this issue.




Viewing Issue Advanced Details
1456 [1003.1(2013)/Issue7+TC1] System Interfaces Objection Omission 2021-03-09 20:09 2021-03-09 20:09
eblake
 
normal  
New  
Open  
   
Eric Blake
Red Hat
XSH 2.2.2
477
16418
---
Permit implementations to add additional confstr()/pathconf()/sysconf() constants
XSH 2.2.2 states that implementations can generally add more constants that fit within approved namespace restrictions, and further states that any identifier beginning with underscore then upper-case is reserved for the implementation (line 16438), so an implementation can indeed add more confstr() (_CS_*), pathconf() (_PC_*) and sysconf() (_SC_*) symbols without violating the requirements. However, without explicit direction, it is not obvious that an application can test for the existence of which extensions an implementation supports, nor that an implementation should not blindly define macros in this namespace if they are not compatible with confstr/pathconf/sysconf semantics.
Before page 477 line 16418 (XSH 2.2.2), add a new paragraph:
Additional symbolic constants with the prefix _CS_, _PC_, and _SC_ may be defined by the inclusion of <unistd.h>, but as these are already reserved for the implementation, they are not included in the table above. Extensions with these prefixes should be compatible with use by confstr(), pathconf(), and sysconf(), respectively.


After page 443 line 15205 (XBD <unistd.h>), add a paragraph:
The implementation may define additional symbolic constants beginning with _CS_* for use by confstr().


After page 444 line 15235, add a paragraph:
The implementation may define additional symbolic constants beginning with _PC_* for use by pathconf().


After page 447 line 15362, add a paragraph:
The implementation may define additional symbolic constants beginning with _SC_* for use by sysconf().


Optionally, the Austin Group should decide whether to add an additional requirement that extensions of these forms must be suitable for use in #if preprocessor directives.
There are no notes attached to this issue.




Viewing Issue Advanced Details
1455 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Clarification Requested 2021-03-02 14:16 2021-03-02 14:16
geoffclare
 
normal  
New  
Open  
   
Geoff Clare
The Open Group
2.4.3
494
17135,17137
---
readv() and writev() are missing from the table of async-signal-safe functions
It appears that readv() and writev() were accidentally omitted from the table of async-signal-safe functions in 2.4.3 when SUSv2 and POSIX.1-1996 were merged in 2001.

The description of readv() begins with "The readv() function shall be equivalent to read(), except as described below", and nothing "below" says that one of the exceptions is that the async-signal-safe requirement for read() does not apply to readv().

Likewise for writev().
Add readv() and writev() to the table.
There are no notes attached to this issue.




Viewing Issue Advanced Details
1454 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Comment Error 2021-02-16 16:29 2021-02-25 09:41
geoffclare
 
normal  
New  
Open  
   
Geoff Clare
The Open Group
2.9.4.3
2372
75780
---
Conflict between "case" description and grammar
A discussion in comp.unix.shell identified that the format summary in the description of "case" conflicts with the syntax defined in the formal shell grammar, as it doesn't allow a case statement with no patterns:

case foo in
esac

whereas the grammar has a line whose sole purpose is to allow it:

Case WORD linebreak in linebreak Esac

The grammar has precedence, so the description should be updated to match it.

All shells I tried accepted a case statement with no patterns, although ksh93 reports a syntax error if the newline is omitted (case foo in esac). However, this appears to be a bug introduced into ksh93, as ksh88 accepts it. It is clear from the grammar that having a newline there should make no difference, since "linebreak" is zero or more newlines.
On page 2372 line 74408 section 2.9.4.3, change:
the first one of several patterns
to:
the first one of zero or more patterns

On page 2372 line 75780 section 2.9.4.3, delete the line:
[(] pattern1 ) compound-list ;;

Note to the editor: in Issue 8 draft 1.1 the line to delete has "terminator" instead of ";;" because of the change to allow ";&".
Notes
(0005241)
kre   
2021-02-16 20:44   
I agree that shells (and my testing also says all but ksh93) work this
way, and have always done so, and consequently as the grammar appears to
allow, should continue working this way .. but I suspect the ksh93 variation
might just be deliberate, rather than simply a bug, in that they might be
attempting to follow the POSIX standard's rules (words), rather than the
actual standard (what everyone (else) implements).

The issue is that I see nothing in the standard currently which allows that
"esac" to be parsed as the Esac (reserved word) token, or not when it is
not following a \n or ; (etc), or a pattern. That is, reserved words
generally (with the specific exceptions called out by references to the
XCU 2.10.2 rules in the grammar) are generally recognised only when in
the command word position (if the thing parsed were to be a simple command).

In "case foo in x) stuff ..." "stuff" is in the command word position, so
a reserved word lookup happens.

On the other hand, in "case foo in stuff..." "stuff" is not in the command
word position (it will be taken as the pattern, and should be followed by
')' or '|') and so is not subject to reserved word lookup. This is what
makes "case word in for) command;; esac" legal, "for" there is not the
reserved word, just a string. All shells accept that (ksh93 included).

But if "for" there is not a reserved word, how could it be if spelled "esac"
instead? Shells do reject "case word in esac) command;; esac", that is,
except for ksh93, which permits it.

So, I while I believe that we should ask ksh93 to follow the real standard,
rather than what is currently in the POSIX text, I also believe that we need
to add some more magic to the grammar, and tokeniser rules, in order to
make this all legitimate.

It isn't as simple as just updating the description in 2.9.4.3.
(0005242)
kre   
2021-02-16 20:55   
(edited on: 2021-02-16 21:02)
Ignore most of that (Note: 0005241) - I missed rule 4.

However, rule 4 only applies when looking at a pattern. That is
in a case_list (or case_list_ns) as a case_item (or case_item_ns).

The grammar rule in question:
      Case WORD linebreak in linebreak Esac
contains no case_list, hence no patterns, hence rule 4 would seem
not to apply.

The other rules always require a case_list[_ns] which always requires
at least one case_item[_ns] and those things always require a ')'
(every single possibility).

So, I still believe that the grammar needs work, even if slightly different
work than I expected in Note: 0005241 . It may be as simple as adding
/* Apply rule 4 */ to the grammar rule line quoted earlier in this note,
but I haven't considered all the ramifications of that yet.

(0005243)
geoffclare   
2021-02-17 10:07   
I agree that we should add /* Apply rule 4 */ to that line in the grammar.
Or something technically equivalent - there would be an editorial problem with simply adding it (and removing redundant spaces) because:

Case WORD linebreak in linebreak Esac /* Apply rule 4 */

is two characters too long to fit on the line.

Perhaps we could change all occurrences of "Apply rule X" to just "Rule X"?
The comments only need to make clear which rule it is that applies; it is the wording in 2.10.1 about those comments that specifies how the indicated rules are applied. (The comment that says "Do not apply rule 4" would stay as-is.)
(0005244)
kre   
2021-02-17 13:18   
Unfortunately, upon reflection, it is not quite that simple (ignoring
temporarily the editorial issue, for which just using "Rule N" instead
of "Apply..." would be fine) as rule 4 says that if the word is "esac"
then the Esac token is returned. If that applies to the grammar production
in question, then
     case esac in esac
isn't going to parse correctly, as the first "esac" which should be WORD
would instead become Esac and so not match.

Perhaps instead, change all occurrences of :"Esac": (in all the productions)
to "case_end", and add a new production:

     case_end: Esac ; /* Apply Rule 4 */

(formatted however is appropriate) which also conveniently side-steps the
editorial issue.

But please consider this carefully, it is a spur of the moment suggestion,
I'm not sure if it might cause other issues.
(0005245)
geoffclare   
2021-02-17 14:26   
Re Note: 0005244 I wondered about "case esac in ..." as well when I was writing my previous note, but decided it's not a problem because of this text in 2.10.1:
Some of the productions in the grammar below are annotated with a rule number from the following list. When a TOKEN is seen where one of those annotated productions could be used to reduce the symbol, the applicable rule shall be applied to convert the token identifier type of the TOKEN to a token identifier acceptable at that point in the grammar.

So rule 4 only causes "esac" to be recognised as the token Esac when it appears in the position of an Esac in the grammar, and it therefore doesn't apply to "case esac in ..." because the "esac" there is in the position of WORD in the grammar, not Esac.
(0005246)
kre   
2021-02-18 10:32   
Re Note: 0005245

That raises an additional problem, as (not concerning the case productions
here) that isn't the way things actually work.

   "convert the token identifier type of the TOKEN to a token identifier
    acceptable at that point in the grammar."

isn't what (normally) happens. If it were the command

    do my work

would run the "do" command, as "do" (the reserved word) is not acceptable
at that point in tne grammar, so the TOKEN "do" should have been (according
to that text) turned into a WORD rather tha nthe keywoprd "do".

There isn't a shell around that behaves like that, it is in the command line
position, "do" matches the spelling of the reserved word, Rule 1 applies, the
reserved word is generated, despite not being "acceptable at that point in
the grammar":.

Once we have an explanation for why this analysis isn't right, or a fix for
that text in 2.10.1 we can revisit how to handle the recognition of "ecac"
in that peculiar case statement with no patterns.
(0005252)
geoffclare   
2021-02-25 09:41   
New proposed changes based on comments made here and on the mailing list ...

On page 2372 line 74408 section 2.9.4.3, change:
the first one of several patterns
to:
the first one of zero or more patterns

On page 2372 line 75780 section 2.9.4.3, delete the line:
[(] pattern1 ) compound-list ;;

Note to the editor: in Issue 8 draft 1.1 the line to delete has "terminator" instead of ";;" because of the change to allow ";&".

On page 2375 line 75888 section 2.10.1, change:
... convert the token identifier type of the TOKEN to a token identifier acceptable at that point in the grammar.
to:
... convert the token identifier type of the TOKEN to:
  • The token identifier of the recognized reserved word, for rule 1.

  • A token identifier acceptable at that point in the grammar, for all other rules.

On page 2379,2380 line 76041,76043,76084-76134 section 2.10.2, change:
/* Apply rule ...
to:
/* Rule ...

On page 2379 line 76058 section 2.10.2, change:
case_item_ns      :     pattern ')' linebreak
                  |     pattern ')' compound_list
                  | '(' pattern ')' linebreak
                  | '(' pattern ')' compound_list
                  ;
case_item         :     pattern ')' linebreak     DSEMI linebreak
                  |     pattern ')' compound_list DSEMI linebreak
                  | '(' pattern ')' linebreak     DSEMI linebreak
                  | '(' pattern ')' compound_list DSEMI linebreak
                  ;
pattern           :             WORD      /* Apply rule 4 */
                  | pattern '|' WORD      /* Do not apply rule 4 */
to:
case_item_ns      : pattern_list ')' linebreak
                  | pattern_list ')' compound_list
                  ;
case_item         : pattern_list ')' linebreak     DSEMI linebreak
                  | pattern_list ')' compound_list DSEMI linebreak
                  ;
pattern_list      :                  WORD /* Rule 4 */
                  |              '(' WORD /* Do not apply rule 4 */
                  | pattern_list '|' WORD /* Do not apply rule 4 */
                  ;




Viewing Issue Advanced Details
1453 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Error 2021-02-16 10:10 2021-02-16 10:10
geoffclare
 
normal  
New  
Open  
   
Geoff Clare
The Open Group
lex
2885
95160, 95165
---
lex LC_COLLATE/LC_CTYPE incorrect wording about unspecified behaviour
The descriptions of LC_COLLATE and LC_CTYPE in the lex ENVIRONMENT VARIABLES section say:
If this variable is not set to the POSIX locale, the results are unspecified.

Taken at face value, this means that applications have to set those variables exactly as stated in order to avoid unspecified behaviour, e.g.:
LC_COLLATE=POSIX LC_CTYPE=POSIX lex ...
This is obviously not what was intended, which is that if the combination of the LANG, LC_COLLATE, LC_CTYPE, and LC_ALL variables results in the locale in effect for the LC_CTYPE or LC_COLLATE category not being the POSIX locale, the behaviour is unspecified.
On page 2885 line 95160,95165 section lex, delete:
If this variable is not set to the POSIX locale, the results are unspecified.

On page 2885 line 95170 section lex, add a paragraph after the list:
If the values (if any) of the LANG, LC_COLLATE, LC_CTYPE, and LC_ALL variables result in the locale in effect for the LC_CTYPE or LC_COLLATE category not being the POSIX locale, the behavior is unspecified.
and move the following text from LANG on page 2884 line 95154 to become a second sentence in the added paragraph:
(See [xref to XBD 8.2] for the precedence of internationalization variables used to determine the values of locale categories.)

There are no notes attached to this issue.




Viewing Issue Advanced Details
1452 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Error 2021-02-11 15:07 2021-02-11 15:07
geoffclare
 
normal  
New  
Open  
   
Geoff Clare
The Open Group
prs
3120
104398
---
prs :KV: is mandated but most implementations do not support it
The prs page includes :KV: in the table of "SCCS File Data Keywords" that can be used with the -d option. However, the AIX, Solaris and CSSC prs utilities do not recognise it (Solaris and CSSC output :KV: unaltered; non-support on AIX is based on the online AIX man page). HP-UX is the only implementation I could find that supports it, and it appears that all it does is substitute :KV: with "none", so I suspect the only reason it recognises the value is because it is listed in SUS.

The VSC test for this keyword says that it has not been implemented pending interpretation VWG/065/011994. So it seems that this is a known problem that was first raised in 1994 but has persisted until now. Unfortunately that date (Jan 19, 1994) predates the start of the ogtgbase email archive, and consequently I have been unable to find how that interpretation was resolved. Being 27 years old it probably doesn't affect how this should be handled now anyway.
1. Issue a "defect case" interpretation.

2. Delete the :KV: row of the table:
| :KV: | Keyword validation string | " | text | S |

There are no notes attached to this issue.




Viewing Issue Advanced Details
1451 [Issue 8 drafts] Shell and Utilities Comment Clarification Requested 2021-02-11 11:07 2021-05-06 15:21
geoffclare
 
normal  
Resolved  
Accepted As Marked  
   
Geoff Clare
The Open Group
awk
2395
78089
Note: 0005351
awk ARGV description addition about -v is problematic
Bug 0000974 added notes to the descriptions of ARGC and ARGV saying it is unspecified whether alterations to ARGC and to elements of ARGV can be made using the -v option.

The one for ARGC is fine, but the one for ARGV is problematic. This is because the standard places a requirement on applications to ensure that the -v option-argument has a variable name to the left of the '='. Thus it cannot be used to assign values to array elements.

Note that since bug 974 was tagged tc3-2008, this bug should also be tagged tc3-2008 despite being reported against Issue 8 draft 1.1.
Change:
It is unspecified whether this alteration to ARGV can be made using the -v option.
to:
Note that this alteration cannot be made using either the assignment operand or the -v option, because an operand with a '[' before '=' is treated as a file operand, not an assignment operand, and applications are required to ensure that the -v option-argument has the same form as an assignment operand. (See the OPTIONS and OPERANDS sections.)

Notes
(0005231)
geoffclare   
2021-02-11 11:08   
Credit to Arnold Robbins for catching this.
(0005351)
rhansen   
2021-05-06 15:18   
Change:
It is unspecified whether this alteration to ARGV can be made using the -v option.
to:
Note that alterations to ARGV cannot be made using either the assignment operand or the -v option, because an operand with a '[' before '=' is treated as a file operand, not an assignment operand, and applications are required to ensure that the -v option-argument has the same form as an assignment operand. (See the OPTIONS and OPERANDS sections.)
(0005352)
nick   
2021-05-06 15:21   
Note tagged as issue 8 since 0000974 is an approved interpretation




Viewing Issue Advanced Details
1449 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Editorial Enhancement Request 2021-02-04 17:25 2021-02-04 17:27
rhansen
 
normal  
New  
Open  
   
Richard Hansen
3 Definitions
---
"Decimal-point character" vs. "radix character"
The standard sometimes uses "decimal-point character" or "decimal point character" where "radix character" would be more appropriate (because POSIX does not have a definition of "decimal-point character").

Note: The C standard uses "decimal-point character" for the same concept as POSIX's "radix character" (section 7.1.1).
On page 53 after line 1637 insert a new definition:
Decimal-Point Character
See Radix Character.

Change page 83 line 2369 from:
Radix Character
to:
Radix Character (or Decimal-Point Character)
There are no notes attached to this issue.




Viewing Issue Advanced Details
1448 [Issue 8 drafts] System Interfaces Objection Error 2021-02-02 22:12 2021-02-02 22:12
kre
 
normal  
New  
Open  
   
Robert Elz
XSH 3/poll()
1399-1400
46800-1. 46807-46813, 46820, 46824, 46867
Misleading text in description of poll()
This report is about wording, I do not believe I am reporting any
technical issues with the text, simply incorrect ways of saying what
it is attempting to say. If this should have been filed as "Editorial"
rather than "Objection" then please change - but note that the issues are
not (quite) simple typos, punctuation errors, or similar.

I am also filing this against issue 8 draft 1.1 as the text in poll() has
been updated from issue 7 (+TC2) but the updates do not affect the issues I see
(I believe) so it could just as easily been files against that one.

At lines 46800-1:
   The poll( ) function shall identify those file descriptors on which an
   application can read or write data, or [...]

That would imply that (given a POLLIN response in revents) that it is
possible to successfully read data, which is not true. Later the text
(correctly) says (line 46846)
    Regular files shall always poll TRUE for reading and writing.
and that's true even if the seek pointer (current offset into the file)
is at EOF, in which case there is no more data to read.

Line 46807 (and lines 46808, 46809, and 46810 which are similar)
say it better:
    POLLIN Data other than high-priority data may be read without blocking.

what's important about poll() (and select()) is that after being told
that an operation may be attempted, the application will not block when
performing the relevant operation, not that anything in particular will
be returned from the attempt.

Much the same applies to the write is OK bits in revents - but there
there's another problem, the bit set indicates that some data can be
written without blocking, but it does not promise how much. The
APPLICATION USAGE section should probably be changed from None (line 46867)
and say that applications wanting to avoid blocking when writing need
to do all of: use poll() (or select()), set non-blocking mode on the
file descriptor, and write relatively small chunks of data (where how
small will depend upon the kind of file the descriptor references) - as
no matter what poll() says, since non-blocking mode does not apply in any
useful way to regular file i/o, if an application attempts to write a
gigabyte to a file in one operation, it is going to block.

And while this (at line 46819) about POLLHUP might be true
    This event and POLLOUT are mutually-exclusive;
however the rationale given (line 46820) makes no sense:
    a stream can never be writable if a hangup has occurred.
as what poll() is indicating is that the application will not
block if it attempts to (in this case) write using the file descriptor,
which is true if a hanhup has occurred, the write simply returns immediately
with an error indication.

In line 46824
    POLLNVAL The specified fd value is invalid.

Is there a definition somewhere of what it means for a file descriptor
to be "invalid". Normally one might assume that this would (inter alia)
include negative values, as file descriptors are all >= 0, but lines 46828-9
say what happens in the case of a fd < 0, and setting POLLNVAL is not it.

So does this just mean a fd greater than the maximum permitted by the
implementation? Or does an "invalid" fd simply mean one that is not
open? (that is where a read/write (etc) would return EBADF, except in
the < 0 case). Or something different than that?

[Aside; XBD 3.136 *File Descriptor" does not define "invalid" ones, there
is no definition of "invalid" (alone) in XBD 3 that I can see, but that I
failed to find it doesn't mean that it doesn't exist somewhere.


It might also be worth bringing back the EXAMPLES section that has been
deleted for Issue 8 (which was all about STREAMS I/O, all obsolete,
and so quite rightly deleted) with an example (or two) using sockets, the
application field (along with terminal I/O) where poll() is most used.
But supplying text for that in this bug report is too much for now...
If that does happen, please do not attempt to copy the old EXAMPLES text
at all, all that nonsense about "permission to write" was simply bigus
(poll has nothing whatever to do with permissions, or any other kind of
authorisation).
In the settence beginning on line 46801, change the words
    on which an application can read or write data
to
    on which an application can make an attempt to read or write data
    without blocking

In line 46808 change
    POLLRDNORM Normal data may be read without blocking.
to
    POLLRDNORM An attempt to read normal data will not block.

and similar changes on lines 46807, 46809, and 46810).

On line 46811 change
    POLLOUT Normal data may be written without blocking.
to
    POLLOUT An attempt to write one byte of data will not block.
                 How much data may be written without blocking depends
                 upon the object underlying the file descriptor, and its
                 current state.

and a similar change on line 46813 (because of the way it is worded, lime
46812 needs no change). Note that line 46813 (alone of all of these lines)
does not mention "without blocking", it should.

On line 46820 delete the words (and punctuation)
    ; a stream can never be writable if a hangup has occurred

On line 46824 either add an xref to the definition of "invalid" as it
applies to file descriptors, or change the words
     is invalid
to
     {something, I have no idea what this is actually trying to say}
but just maybe to:
     does not represent an open file descriptor in the process [thread ??].
     
On line 46867 change
     None
to (something like):
     When poll() indicates a read may be attempted, a resulting read()
     call may return data, indicate EOF, or indicate an error, but shall
     not block. When poll() indicates that a write may be attempted,
     the application may write one or more bytes, however, when more than
     one byte is written, there is no guarantee that no block will occur.
     Applications which desire to write more than a single byte each time
     poll() indicates that a write may occur, and which want to avoid
     blocking need to take other measures to determine how much may be
     successfully written.

     Applications should note that repeating a poll() call which indicated
     that I/O was possible on one or more of the file descriptors given,
     without causing some change to the state, either by altering the fds[]
     array, or causing appropriate input or output to occur on at least one
     file descriptor indicated as ready will simply result in ppll() busy
     waiting - a subsequent call will always return immediately indicating
     the same (or perhaps more) revents as the previous one.

It would also be useful to have more information included on how the
various flags apply to terminals and sockets (rather than the undue overload
applied to FIFOs). What constitutes an error (POLLERR) or hangup (POLLHUP)
or a terminal fd? A hangup, a revoked fd, a parity error ??? And similarly
for sockets, a closed connection? Receipt of an ICMP message (on INET[46[
sockets), a TCP RST? a TCP FIN? Lack of response (broken network) (after
how long?)

Lines 46826-7 do say:
    The significance and semantics of normal, priority, and high-priority
    data are file and device-specific.
but there is nothing similar about HUP or ERR.
There are no notes attached to this issue.




Viewing Issue Advanced Details
1447 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Omission 2021-01-31 22:51 2021-01-31 22:51
kre
 
normal  
New  
Open  
   
Robert Elz
XSH 3 / fread; XSH 3 / fwrite; (maybe more)
931, 1001
None specifically, this is an omission...
---
fread()/fwrite() (maybe more similar) specify no requirements on args
This may be something that ought to be sent to the C standard committee, I will
leave that for others to determine.

As specified, neither fread() nor frwite() say anything at all about what
is required of their arguments - except perhaps for the stream arg, via the
list of errors from fgetc()/fputc() which are incorporated by reference.

In particular, while it is stated that the results for fread() or data
written for frwite() come from an unsigned char array that overlays the
data struct (*ptr), and it is implied that array is nitems * size bytes large
(never actually stated, but one can conclude that from the description)
there's no statement that the user's provided buffer actually needs to be
that big.

That is, if that is even possible to achieve, each of size and nitems is a
size_t, hence each (alone) is large enough to represent the largest possible
object that can exist - multiply them together and (unless at least one of
them is 0 or 1) it is possible to overflow the biggest possible object size,
and even if it is possible to write that much data, it cannot be done in an
overlayed char array (which being a single object must have a size that can
be represented in a size_t).
Add words to specify requirements on the args.

That is, ptr must point at a buffer which is at least nitems * size bytes
large, and nitems * size must not overflow a size_t.

The first is not possible for the functions to check, so that one must
simply be a requirement on the application, but the functions can validate
that nitems * size does not overflow, and I believe some implementations
check that, and return EINVAL if it happens.

Add EINVAL to the list of possible errors. EFAULT is probably also needed
- though some implementations probably SEGV instead of returning EFAULT,
it depends whether the implementation actually does a large sequence of
fgets/fputc calls, or whether it simply calls read() (or write()) and then
manipulates the stream data struct to handle that. These are errors that
don't occur from fgets()/fputc().
There are no notes attached to this issue.




Viewing Issue Advanced Details
1446 [1003.1(2016/18)/Issue7+TC2] System Interfaces Editorial Clarification Requested 2021-01-25 18:17 2021-01-26 18:49
dalias
 
normal  
New  
Open  
   
Rich Felker
musl libc
posix_spawn_file_actions_addopen et al
unknown
unknown
---
Does a shall-fail in terms of an undefined limits.h macro impose any requirement?
posix_spawn_file_actions_addopen has a "shall fail" error condition for "The value specified by fildes is negative or greater than or equal to {OPEN_MAX}" and similar conditions appear elsewhere. If the implementation does not define OPEN_MAX, does this impose any requirement on the implementation to fail when the value exceeds a dynamic sysconf(_SC_OPEN_MAX), or is the condition vacuously false?
Clarity whether {OPEN_MAX} refers to the actual macro value or some abstract limit by the name whose value may only be available at runtime, or just explicitly limit the condition to the case where it is defined, as in:

EBADF
    The value specified by fildes is negative or the implementation defines OPEN_MAX in limits.h and the value specified by filedes is greater than or equal to OPEN_MAX.
Notes
(0005209)
geoffclare   
2021-01-26 09:39   
The <limits.h> page contains these paragraphs before the list of limits that includes {OPEN_MAX}:
A definition of one of the symbolic constants in the following list shall be omitted from <limits.h> on specific implementations where the corresponding value is equal to or greater than the stated minimum, but is unspecified.

This indetermination might depend on the amount of available memory space on a specific instance of a specific implementation. The actual value supported by a specific instance shall be provided by the sysconf() function.

I would hope that from this it is sufficiently clear that any error condition worded in terms of {OPEN_MAX} is required to be checked against the runtime value obtained from sysconf() if there is no OPEN_MAX definition in <limits.h>. Likewise for the other limits in the same list.
(0005211)
dalias   
2021-01-26 17:27   
I don't see any way that this is "sufficiently clear". Either reading is plausible and defensible, and moreover semantically the check only makes sense if the limit is static, since otherwise it's an inherent TOCTOU error (limit at time of creating the file actions object may be different than limit at the time of posix_spawn).

If a particular reading is intended it should be documented explicitly. That could be general text in the limits.h specification, to the effect that when {x} appears in the description of an interface it should be read as the dynamic limit obtainable by sysconf if the static limit is not defined. However I wonder if there might be other places where such a requirement is unintended and/or harmful, and I'd like to have a thorough review of everything potentially affected.
(0005212)
shware_systems   
2021-01-26 18:05   
I believe the expectation is these values will be static, at least for the life of the process, so applications and implementation internals can rely on sysconf(). They certainly would be if the header provided them as #define's, after all. The only reason I see for returning a different value on a subsequent call would be to mirror calls by an application to other interfaces requesting a higher or lower value be applied. Maybe this needs to be stated better in <limts.h>, maybe not, that it is on implementations not to modify these arbitrarily without such requests, as a conformance requirement.
(0005213)
dalias   
2021-01-26 18:15   
In the case of sysconf(_SC_OPEN_MAX), historically it varies dynamically within the process lifetime with setrlimit (RLIMIT_NOFILE), and moreover it's very reasonable to want to change the limit for a child process (in fact various implementors have proposed extending posix_spawn to include setrlimit-like action). Maybe it's inappropriate for sysconf(_SC_OPEN_MAX) to represent the rlimit anyway and it should just be returning -1. But this is something of a mess at present, I think.
(0005214)
shware_systems   
2021-01-26 18:49   
That is the application explicitly requesting changes, though, via setrlimit(). It's on the developer to guard against TOCTOU for that circumstance, not the standard.

Where interfaces indicate a value that isn't necessarily constant is to be referenced the behavior should be as if sysconf() is called, in the description of the curly brace notation by default more than per interface, whether the header includes an entry for the constant or not.




Viewing Issue Advanced Details
1445 [Issue 8 drafts] Shell and Utilities Editorial Error 2021-01-21 18:11 2021-02-12 16:50
rhansen
 
normal  
Applied  
Accepted  
   
Richard Hansen
2.14
2311
74980-74981
Update "special built-in" to match changes from bug #854
Bug #854 updated many sections regarding PATH search for different types of utilities but missed a spot in XCU 2.14 (as mentioned in Note: 0003228).
On page 2311 lines 74980-74981 (XCU 2.14 2nd paragraph) change:
The term "built-in" implies that the shell can execute the utility directly and does not need to search for it.
to:
The term "built-in" implies that there is no need to execute a separate executable file because the utility is implemented in the shell itself.
There are no notes attached to this issue.




Viewing Issue Advanced Details
1444 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Editorial Error 2021-01-19 10:42 2021-01-19 10:42
geoffclare
 
normal  
New  
Open  
   
Geoff Clare
The Open Group
<wordexp.h>
466
16113
---
Broken cross-references to wordexp()
The SEE ALSO section on the <wordexp.h> page is supposed to have a cross-reference to the wordexp() function in XSH, but it instead points to XCU 2.6. The XSH pages for fnmatch() and glob() have the same problem.

This is happening because the troff source uses the same tag "wordexp" for both of these cross-reference targets.
Fix the broken wordexp() cross-references in SEE ALSO on the <wordexp.h>, fnmatch(), and glob() pages.

Note to the editor: there are many more correct xrefs to XCU 2.6 than there are broken xrefs to wordexp(), so the least disruptive way to fix this is to change the xref tag for wordexp() to "wordexp_xsh".
There are no notes attached to this issue.




Viewing Issue Advanced Details
1443 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Objection Omission 2021-01-19 10:40 2021-01-19 10:40
geoffclare
 
normal  
New  
Open  
   
Geoff Clare
The Open Group
3.274 Pattern
77
2224
---
Definition of "pattern" omits some uses
The definition of "pattern" talks about pathname expansion, but not pathname matching or other uses of shell patterns, such as case statements or the four varieties of parameter expansion that provide for substring processing.

It should talk about shell pattern matching notation the same way it does about regular expression notation, including referring in the small-font note to the section that defines the notation (instead of the current reference to the section about pathname expansion).

The problem extends to the text "as a means of selecting various character strings or pathnames", which only covers a subset of the uses of patterns. It would be best just to omit this part, as the references in the small-font note can be followed to find out more about what each type of pattern is used for. (Although an addition to XCU 2.13 along the lines suggested below would help in this regard.)
On page 77 line 2224 section 3.274 Pattern, change:
A sequence of characters used either with regular expression notation or for pathname expansion, as a means of selecting various character strings or pathnames, respectively.
to:
A sequence of characters used either with regular expression notation or with shell pattern matching notation.

On page 77 line 2227 section 3.274 Pattern, change:
See also [xref to XCU 2.6.6 Pathname Expansion].
to:
Shell pattern matching notation is defined in detail in [xref to XCU 2.13 Pattern Matching Notation].

On page 2308 line 74866 section 2.13 Pattern Matching Notation, after:
The pattern matching notation described in this section is used to specify patterns for matching strings in the shell.
add a sentence:
This notation is also used by some other utilities (find, pax, and optionally make) and by some system interfaces (fnmatch(), glob(), and wordexp()).

There are no notes attached to this issue.




Viewing Issue Advanced Details
1442 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Comment Enhancement Request 2021-01-10 13:10 2021-01-10 22:42
andras_farkas
 
normal  
New  
Open  
   
Andras Farkas
getopts
2840
93538 and 93541
---
Improvement to getopts example, remove double negation
On getopts's page
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/getopts.html [^]
The example uses interesting double negation in the two tests:
if [ ! -z "$aflag" ]; then
if [ ! -z "$bflag" ]; then
! -z could be shortened to -n
Replace
if [ ! -z "$aflag" ]; then
with
if [ -n "$aflag" ]; then
and
if [ ! -z "$bflag" ]; then
with
if [ -n "$bflag" ]; then
There are no notes attached to this issue.




Viewing Issue Advanced Details
1441 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Enhancement Request 2021-01-07 16:56 2021-01-07 16:56
rhansen
 
normal  
New  
Open  
   
Richard Hansen
2.5.3 Shell Variables, PS4
2352
74965
---
PS4 should be printed for non-interactive shells as well
The specification of PS4 only applies to interactive shells. It should also apply to non-interactive shells.
On page 2352 line 74965 (XCU 2.5.3 PS4), change:
When an execution trace (set −x) is being performed in an interactive shell,
to:
When an execution trace (set −x) is being performed,

There are no notes attached to this issue.




Viewing Issue Advanced Details
1440 [1003.1(2016/18)/Issue7+TC2] System Interfaces Comment Omission 2021-01-04 15:49 2021-01-13 10:50
ciprian_craciun
 
normal  
New  
Open  
   
Ciprian Dorin Craciun
system(3)
N/A
N/A
---
Calling `system("-some-tool")` fails (although it is a valid `sh` command)
This report is in relation to the following `glibc` and Linux man-pages issues:
* https://sourceware.org/bugzilla/show_bug.cgi?id=27143 [^]
* https://bugzilla.kernel.org/show_bug.cgi?id=211029 [^]

However it seems that the root cause is the interaction mandated by the POSIX standard between `system(3)` and `sh(1)`.


In simple terms, calling `system("-some-tool")` has an unexpected behaviour when delegating that to `sh`, as in `sh -c -some-tool`. (For how to replicate this just see the first link.)


In more details:

* the `system(3)` specification requires that:
~~~~
# from: https://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html [^]

The system() function shall behave as if a child process were created using fork(), and the child process invoked the sh utility using execl() as follows:

execl(<shell path>, "sh", "-c", command, (char *)0);
~~~~

* however the `sh(1)` specification requires that:
~~~~
# from https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html [^]

sh -c [-abCefhimnuvx] [-o option]... [+abCefhimnuvx] [+o option]...
       command_string [command_name [argument...]]
~~~~

I.e. `sh(1)` allows extra flags between `-c` and the `command_string`; however the `system(3)` doesn't account for a command that might start with a hyphen.

Thus, depending on what the command might be, the outcome is either a missing command (if the given command resembles an option accepted by `sh`), or an unknown option (if the given command doesn't resemble an option accepted by `sh`).
The "optimal" solution would be to require `system(3)` to call `sh(1)` with an extra `--` between `-c` and the `command`, as in:
~~~~
execl(<shell path>, "sh", "-c", "--", command, (char *)0);
                                ^^^^
~~~~

Given that `sh(1)` already mandates a compliant shell to correctly handle `--`, this shouldn't have many unintended consequences.

Alternatively add a warning in the specification stating that a command starting with `-` has an undefined behaviour and should be worked-around by preperding a space to any such command.
Notes
(0005191)
Vincent Lefevre   
2021-01-06 13:20   
Since with -c, there must be at least a non-option argument, how about doing a correction/improvement in sh as follows? If -c is given and there is a single argument after -c, then this argument should be regarded as a command string.

(This could be done in addition to adding "--" on the system() side.)
(0005192)
ciprian_craciun   
2021-01-06 15:41   
> Since with -c, there must be at least a non-option argument, how about doing a correction/improvement in sh as follows? If -c is given and there is a single argument after -c, then this argument should be regarded as a command string.


I think adding such a requirement is not advisable for multiple reasons:

* first, none of the existing `sh` implementations (as reported in one of the tickets none of `bash`, `dash` or `zsh`) exhibit such a behaviour, therefore this change will all of a sudden break their POSIX compliance;

* second, although it solves the `system` corner-case, it opens other potential issues; imagine for example a script that calls `sh -c -x "${@}"`; now if the user doesn't provide an argument, then all of a sudden `sh` executes `-x` as a command, as opposed to until now when it didn't execute anything;


Personally I don't know what is the best course of action here, besides updating `system` to use the `--` separator which is backward compatible and shouldn't break virtually anything.

However, given how much "legacy" there is based on `sh`, I wouldn't change its behaviour, except perhaps giving a warning in the man page about the situation.
(0005193)
joerg   
2021-01-06 16:12   
Please note that this problem has been introduced by POSIX. It does not
exist in pre-POSIX shells.

In the classical Bourne Shell, -c wasn't even seen as a real option but
as some kind of prefix to the command argument.

Since the problem has been introduced by shells while implementing POSIX
requirements, I am fully open to set up a new POSIX requirement for shell
option parsing that would fix the parsing to make it compatible to the
historic Bourne Shell again.

This would however require to find a simple and still always working
algorithm. Just counting the arguments after -c does not work.

Note that with the classical Bourne Shell

    sh -x -c 'echo foo'

does not work, but requiring it to work by POSIX seems to be a useful
enhancement compared to the classical Bourne Shell and the fact that
POSIX requires

    sh -c -x 'echo foo'

to work also seems to be a useful extension.

As a result, it may be hard to fix this problem in the shell...
(0005194)
kre   
2021-01-06 16:13   
(edited on: 2021-01-06 16:22)
Re Note: 0005191 and Note: 0005192

Not only is the suggestion in Note: 0005191 not the right thing to do,
as showin in Note: 0005192 (it would also cause sh to not satisfy the
utility guidelines in XBD 12.1)

But beyond that, it would also be insufficient to solve the problem
in general, as there can be more than one arg after -c, and the first
of those might begin with a "-" - which means the shell would either
fail just the same way (just not perhaps when called from system()) or
would run the wrong thing as a command.

This needs to be fixed in system(), or in the application, not in sh.

That could be done in system() adding a -- in the arg list, perhaps only if
the command string starts with a '-', or by prefixing a space to the arg
(though that would mean copying it, so probably would not be the method of
choice), or however else the system() function wants to do it.

Or we could simply note the potential issue in the APPLICATION USAGE of
system() and tell application authors not to attempt system() (or popen())
with a string starting with a '-' - there are a zillion ways (including
prependiong a space, or quoting the command name, or ...) the application
can avoid that ever happening.

Personally, I would put the onus on the application - the way system()
works has neevr really changed, the way sh works has never changed, it
has always been necessary for the application to deal with the combination
that results from that if they're doing something unusual (like starting
a command with a '-').

(0005199)
Vincent Lefevre   
2021-01-13 10:50   
And what about the invocation of $EDITOR and $VISUAL?

A proposed manpages patch for Debian at https://bugs.debian.org/866060 [^] has:

 .BR EDITOR / VISUAL
 The user's preferred utility to edit text files.
+Any string acceptable as a command_string operand to the
+.I sh -c
+command shall be valid.

Executing the command with "sh -c" will fail if it starts with "-". But I wonder how this is handled in practice in various implementations and whether something is missing in the spec, which is not very explicit.




Viewing Issue Advanced Details
1439 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Editorial Clarification Requested 2020-12-24 03:47 2021-01-16 11:27
dannyniu
 
normal  
New  
Open  
   
DannyNiu/NJF
<dlfcn.h>, <sys/mman.h>
many
many
---
The POSIX standard did not distinguish object and function pointers as did the C standard.
The C standard distinguishes function pointers from object pointers. The POSIX standard treat them as the same in <dlfcn.h> and in <sys/mman.h> where the return type of `dlsym` and `mmap` is `void *`.

However, the specification of ILP32 and LP64 memory models can be seen as implying the standard is treating function and object pointers as the same.
Explicitly state that function and object pointers are the same, and share the same process address space.
Notes
(0005189)
geoffclare   
2021-01-04 10:49   
(edited on: 2021-01-04 10:50)
This is effectively requesting that we revert to the situation before bug 0000074 was applied in Issue7 TC1. Prior to that, XSH7 included this section:
2.12.3 Pointer Types

All function pointer types shall have the same representation as the type pointer to void. Conversion of a function pointer to void * shall not alter the representation. A void * value resulting from such a conversion can be converted back to the original function pointer type, using an explicit cast, without loss of information.

Note: The ISO C standard does not require this, but it is required for POSIX conformance.

This had been added in the original Issue 7 because of dlsym(), but the decision made for bug 74 was that we should instead have a much narrower requirement specific to the conversions needed for dlsym() rather than this very general requirement.

This new bug also mentions mmap(), which I don't recall coming up before in this context. If there is existing application code that casts the mmap() return value to a function pointer, then we should consider adding an mmap() requirement similar to the current dlsym() one.

(0005195)
dannyniu   
2021-01-10 11:03   
(edited on: 2021-01-10 11:05)
If the decision of bug-0074 was made based on security, then I find it not very meaningful, as modern computers are capable of enforcing code/data access control in hardware, and many operating systems are also capable of emulating such access control in software should hardware support is lacking.

The other point which says:

> it need not necessarily be supported to try to examine
> the instructions that make a function by ...

While I can't fully understand it (probably due to my knowledge of English being limited), I think such examination is more of a feature.

Lastly, the "tiny code generator" (TCG) accelerator in QEMU is known to use mmap. I'm not sure if it actually acquires executable memory pages and calls function residing in it, but being a "code generator", I think it almost certainly does that. Although this last point isn't very compelling as QEMU is all about things that are hardware-specific (and thus implementation-specific).

My reason for reverting the decision of bug-0074 would only be for desiring an intuitive, simple, and straightforward memory model and type system.

(0005196)
joerg   
2021-01-10 14:53   
(edited on: 2021-01-10 16:31)
I don't believe that there is a need to change the mmap() requirements,
since the related tricks that may be needed could be hidden behind dlopen().

The mentioned change was needed to permit dlsym() to work both for
functions and data objects. The reason however was not security or
address space division but some older IBM mainframes had a different
bit-ness for code and data. The change requires the provider of a
POSIX platform to define the type void * to be useful for both,
function pointers and data pointers, while the C standard only requires
void * to work for data pointers.

I don't believe there is a need to change the current POSIX text
unless you like to explicitly permit mmap() to be useful for
self-managed mapped code segments. Even with that background, I cannot
see a problem, since mmap() already returns void * and there is PROT_EXEC.

(0005197)
shware_systems   
2021-01-10 16:29   
It is because of those hardware access controls that the need arises to distinguish between code and object pointers. With some processors, for each executable, a code pointer and an object pointer may have different bit widths. This is notably evident with the Intel 80286 processors using various memory models. A code pointer can be 32 bits, object pointers may only be 16 bits wide. For another file code pointers may be 16 bits, and object pointers may be 32. To support dlsym() this requires the storage for a void * to be 32 bits to be able to hold either possibility.

The other salient aspect to these is only object pointers are writable. Any data objects pointed to by code pointers is const qualified, enforced by the hardware on store dereferences if code attempts it. Because they can not be modified, there is no reason they need to be readable either. A compiler can as easily produce a reference to an area reserved for objects as into a function body and put the data there, after all. It is up to the compiler to manage function entry points and branch labels as rvalues only.

From the standard's perspective the only interfaces that should be modifying code pointers are the exec family and dlopen(), as trusted code doing load time relocation calculations. Any other code has to be presumed to have malicious intent in even trying to read a function body, as the security consideration.

While there are classes of applications where this isn't the intent, such as in-situ debuggers, the specification of these is considered out of scope for the standard. This is because they are so dependent on hardware knowledge and unspecified implementation support for them.
(0005202)
dannyniu   
2021-01-16 11:27   
<signal.h> describes siginfo_t and claims it has the following member:

void *si_addr // Address of faulting instruction




Viewing Issue Advanced Details
1438 [1003.1(2016/18)/Issue7+TC2] System Interfaces Editorial Clarification Requested 2020-12-17 19:19 2020-12-17 19:19
steffen
 
normal  
New  
Open  
   
steffen
iconv
1123
38001
---
iconv: clarify which "codeset" is meant
Nitpick that seems to sometimes cause issues in practice, as shown in thread on ML.
On page 1123 lines 38001 ff. change

If a sequence of input bytes does not form a valid character in the specified codeset, conversion shall stop after the previous successfully converted character.

to

If a sequence of input bytes does not form a valid character in the specified input codeset, conversion shall stop after the previous successfully converted character.
There are no notes attached to this issue.




Viewing Issue Advanced Details
1437 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Enhancement Request 2020-12-15 21:02 2020-12-17 21:16
steffen
 
normal  
New  
Open  
   
steffen
Vol. 3: Shell and Utilities, Issue 7, make
(2975) 2989
(98708, 98742) 99308
---
make: (document .NOTPARALLEL and .WAIT special targets) in RATIONAL
Parallel, even massively parallel processing has become the widely supported and
used default, yet the standard make(1) does not document it.

If the -j command line option as requested in issue #1436 is standardized,
the standard should also mention ways to synchronize rule processing, in order
to support more complicated build relationships seen in real-life projects.

The suggestion given here can be used with the most widely used make(1)
implementations (GNU make, BSD make) on any tested platform (Linux, *BSD, SunOS
/ Solaris).

The make family rooted on the Sun side of likfe has has at least .WAIT: reserved
for decades, and in practice

  .NOTPARALLEL:
  .WAIT: # Luckily BSD make supports specifying this as target, too

  tangerine: config .WAIT build .WAIT test .WAIT install
  citron: config .WAIT build .WAIT install
  all: config .WAIT build

produces the desired outcome.
(
On page 2975, insert before line 98708

  .NOTPARALLEL
    When specified all rules specified in the given makefile are processed
    sequentially, as if -j has not been given.

On page 2975, insert before line 98472

  .WAIT
    When .WAIT appears in a dependency line, prerequisites that appear after it
    are built no sooner until all preceeding prerequisites have been built
    successfully.

On page 2975, change on line 98472 ff.

  The special targets .IGNORE, .POSIX, .PRECIOUS, .SILENT, and .SUFFIXES shall
  be specified without commands.

to

  The special targets .IGNORE, .NOTPARALLEL, .POSIX, .PRECIOUS, .SILENT,
  .SUFFIXES and .WAIT shall be specified without commands.
)

On page 2989, insert before line 99308

  The special targets .NOTPARALLEL and .WAIT represent different, rather
  incompatible synchronisation concepts of parallel build environments as
  used by the diverse implementations. By using an indirection both approaches
  can be supported: for implementations which use .NOTPARALLEL in a makefile to
  ensure sequential rule processing in the given file the full power of parallel
  processing will be available in recursive make instances invoked on makefiles
  without the directive, implementations which synchronize on the .WAIT special
  target will synchronize on it, for example:

    .NOTPARALLEL: # Process all rules sequentially
    .WAIT: # Define to satisfy "the other implementation"

    install: config .WAIT all
      echo Installing..
      ..
    all: config .WAIT build
    build:
      make -f makefile.build
    config:
      ./configure
Notes
(0005184)
psmith   
2020-12-17 17:10   
Just to note, GNU make does not support the .WAIT special target.
(0005185)
steffen   
2020-12-17 19:23   
Ach! I wish it would, i think the .WAIT approach "is better" (as in explicit, and does not need an indirection).
But you said on the ML that you do not plan to support it either.

This is why the first part above is in parenthesis, and this issue actually requests some words in RATIONALE instead.

The presented solution has the desired effect also in GNU make ("build" target uses parallel processing).
(0005186)
psmith   
2020-12-17 21:16   
I don't believe I said I didn't want GNU make to support it; I agree that it seems like a useful feature. I just said that given the way make's parallel support works I suspect implementation is not so easy and I didn't plan to work on it as I have other things on my (relatively small) plate.

But, if someone else were to get motivated to try to get this working that would be fine with me :). I wonder if creating some kind of internal/implicit prerequisite relationship that wasn't visible to users would be a simpler way to implement this... or not. Well, something for someone to consider.




Viewing Issue Advanced Details
1436 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Enhancement Request 2020-12-15 21:00 2021-04-29 20:19
steffen
 
normal  
Resolved  
Accepted As Marked  
   
steffen
Vol. 3: Shell and Utilities, Issue 7, make
2969
98473
---
Note: 0005327
make: add "-j max_jobs" option to support simultaneous rule processing
Parallel, even massively parallel processing has become the widely supported and
used default, yet the standard make(1) does not document it.

P.S.:
Even though on SunOS/Solaris the first approach taken (long ago) involved
distribution of make jobs to different computers via a special "dmake" program,
it seems even there a default make(1) could follow an adjusted standard by doing
the equivalence of "exec dmake ARGUMENTS".
On page 2969, insert before line 2969

  -j max_jobs
    Specifies the maximum number of rule-processing jobs to run simultaneously.
Notes
(0005299)
psmith   
2021-03-22 21:27   
Defining -j in a single instance of make is not too hard to understand and most likely all versions of make, that currently support -j, do it essentially the same way.

The question is, what happens when a parent make with -j invokes a command which is a sub-make. This is where it gets hard, and where there's probably not too much agreement on what the behavior should be between existing implementations.
(0005327)
rhansen   
2021-04-22 15:34   
At (TC2) page 2969 line 98438, make SYNOPSIS, add:
[-j maxjobs]
(SD shaded as the rest)


After page 2969 line 98472, make OPTIONS, add:
-j maxjobs Set the maximum number of targets that can be updated concurrently. If this option is specified multiple times, the last value of maxjobs specified shall take precedence. If this option is not specified, or if maxjobs is 1, only one target shall be updated at a time (no parallelization). If the value of maxjobs is non-positive, the behavior is unspecified. When this option is specified with maxjobs greater than 1 and a rule invokes make (perhaps via <tt>$(MAKE)</tt>), the parent make shall attempt to establish communication with the child make in an unspecified manner, possibly via an implementation-specific flag in MAKEFLAGS. If the -j option is passed to the child make via the MAKEFLAGS environment variable with the same maxjobs value as the parent and is not overridden by a maxjobs value from another source (even if it has the same value), the child make shall establish communication with the parent make before it attempts to update any targets. In all other cases it is unspecified whether the child make establishes communication with the parent make. The parent make and any children it is communicating with, recursively, shall between them update no more than maxjobs targets in parallel. Implementations are permitted to silently limit maxjobs to an unspecified positive value; if this limit is 1, make need not attempt to establish communication with a child make.


At page 2972 line 98587, make EXTENDED DESCRIPTION, change:
The make utility shall treat all prerequisites as targets themselves and recursively ensure that they are up-to-date, processing them in the order in which they appear in the rule. The make utility shall use the modification times of files to determine whether the corresponding targets are out-of-date.
to:
The make utility shall treat all prerequisites as targets themselves and recursively ensure that they are up-to-date, using the modification times of files to determine whether the corresponding targets are out-of-date. If the -j option is not specified, a rule's prerequisites shall be processed in the order in which they appear in the rule. If targets are being updated in parallel (see -j in OPTIONS), the order of processing of prerequisites is unspecified except the make utility shall ensure that all of a prerequisite's own prerequisites are up-to-date before the prerequisite itself is made up-to-date.


At page 2986 line 99174, make RATIONALE, delete the bullet item:
Syntax supporting parallel execution (such as from various multi-processor vendors, GNU, and others)


After page 2987 line 99244, make RATIONALE, add a new paragraph:
Some implementations of make allow omission of the option-argument for the -j option, although not in the manner described in item 2.b in [xref to XBD 12.1] (where the option-argument, if present, needs to be directly adjacent to the option in the same argument string). To allow the option-argument to follow -j as a separate argument, these implementations check whether the next argument begins with a digit. If it does, it is treated as an option-argument for -j; if it does not, the -j is processed as not having an option-argument and the next argument is processed as if it followed a -j option-argument. This behavior is not suitable for inclusion in this standard as it does not meet the syntax guidelines. However, it is an allowed extension since following -j with an argument that does not begin with a digit would otherwise be a syntax error. At least one implementation of make uses <tt>-j 0</tt> to mean "use a sensible value for the maximum number of targets that can be updated in parallel". If an implementation wants to add this feature, the standard developers suggest following this convention.


At page 2988 line 99280, make RATIONALE, change:
The make utilities in most historical implementations process the prerequisites of a target in left-to-right order, and the makefile format requires this. It supports the standard idiom used in many makefiles that produce yacc programs; for example:
foo: y.tab.o lex.o main.o
    $(CC) $(CFLAGS) −o $@ t.tab.o lex.o main.o
In this example, if make chose any arbitrary order, the lex.o might not be made with the correct y.tab.h. Although there may be better ways to express this relationship, it is widely used historically. Implementations that desire to updatem prerequisites in parallel should require an explicit extension to make or the makefile format to accomplish it, as described previously.
to:
When targets are not being updated in parallel (see -j in OPTIONS), make processes the prerequisites of a target in left-to-right order. This supports a common idiom used in many makefiles that produce yacc programs; for example:
foo: y.tab.o lex.o main.o
    $(CC) $(CFLAGS) −o $@ y.tab.o lex.o main.o
In this example, if make chose any arbitrary order, the lex.o might not be made with the correct y.tab.h. Although there may be better ways to express this relationship (that would be needed if -j is specified), it is widely used historically.
(0005328)
psmith   
2021-04-22 18:36   
Thanks for all the work on this! I will make an effort to review this from a GNU make perspective and provide comments, if any, before Monday.
(0005329)
psmith   
2021-04-23 17:40   
> When this option is specified with maxjobs greater than 1 and a rule invokes make (perhaps via <tt>$(MAKE)</tt>),

I think that this isn't sufficient. It's not clear what make is intended to do here: how can make determine if a "rule invokes make"? Make doesn't have a shell parser so it cannot determine whether or not a command will actually invoke make or not.

In GNU make, we require the recipe to contain a reference to the MAKE variable; the command string must contain either $(MAKE) or ${MAKE} somewhere. Or, it must be prefixed with "+". If either of those are true then make assumes that the child may or will invoke make, and it prepares to allow that process to participate in the parallel domain. If neither of those are true then make assumes that the child will not invoke make and it won't configure that child to be available in the parallel domain.
(0005330)
psmith   
2021-04-23 17:47   
(edited on: 2021-04-23 18:09)
> shall between them update no more than maxjobs targets in parallel

It's not clear from the text whether this set of targets includes make itself. In a recursive make scenario, you will be running sub-makes to create targets. In GNU make we do not count make itself as one of the targets to be updated and I recommend this behavior here as well.

If you don't have this, then you can have a situation where you run with -jN and you invoke N instances of sub-makes, and now no sub-make can start a new target because all available jobs are used.

Not counting make is sensible because while all jobs are running, make itself is not actually running: it's waiting for one of the jobs to complete.

In GNU make, we basically say that each invocation of make is given one "free" jobserver token that it can use for starting one job at a time: if it ever wants to start more than one job it needs to get another jobserver token as expected. This way every instance of make can always make progress.

(0005331)
psmith   
2021-04-23 18:28   
I think the rest of the content here will work for GNU make. Thanks!
(0005345)
rhansen   
2021-04-29 16:59   
(edited on: 2021-04-29 17:00)
Re: Note: 0005330:
It's not clear from the text whether this set of targets includes make itself. In a recursive make scenario, you will be running sub-makes to create targets. In GNU make we do not count make itself as one of the targets to be updated and I recommend this behavior here as well.
Out of curiosity, how is this implemented in GNU make? Does the act of establishing a connection to the parent make conceptually return a worker to the pool of available workers? Make doesn't parse shell code, so make can't know whether a rule spawns a submake even if the rule expands the MAKE macro (<tt>echo $(MAKE)</tt> expands the MAKE macro but it doesn't spawn a submake).

(0005346)
rhansen   
2021-04-29 17:03   
(edited on: 2021-04-29 17:18)
> Out of curiosity, how is this implemented in GNU make?

Nevermind, you already answered this in Note: 0005330:
In GNU make, we basically say that each invocation of make is given one "free" jobserver token that it can use for starting one job at a time: if it ever wants to start more than one job it needs to get another jobserver token as expected.
Apologies for not reading closely.

(0005347)
rhansen   
2021-04-29 17:30   
(edited on: 2021-04-29 17:34)
Re: Note: 0005330:
> In GNU make, we basically say that each invocation of make is given one "free" jobserver token that it can use for starting one job at a time: if it ever wants to start more than one job it needs to get another jobserver token as expected.

If I understand GNU make's behavior correctly, a user could exceed N parallel jobs if they write a rule that starts multiple submakes in parallel. For example:
all:
    i=0; subs=''; while [ $$i -lt 10 ]; do $(MAKE) -C subdir$$i & subs="$$subs $$!"; i
=$$((i+1)); done; for sub in $$subs; do wait $$sub || exit 1; done

The above could have up to 11 jobs running in parallel if <tt>-j2</tt> is passed to make. Correct? We'll want to make sure the standard permits that behavior, probably by saying that the behavior is unspecified if a rule invokes multiple submakes in parallel.

(0005348)
psmith   
2021-04-29 20:19   
Yes, that's correct: it is possible to circumvent this limit. It's unfortunate but alternative implementations which are completely reliable are proportionately more difficult, and I just figured if people want to write their makefiles that way and break the jobserver behavior, then, they get to keep both pieces :).




Viewing Issue Advanced Details
1435 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Error 2020-12-15 14:50 2021-03-22 15:44
zackw
 
normal  
Resolved  
Accepted As Marked  
   
Zack Weinberg
GNU
exec
(unknown)
(unknown)
---
Note: 0005298
execlp and execvp should not execute a command interpreter when other members of the exec family would fail with ENOEXEC
When execve would fail for a particular process image file and set errno to [ENOEXEC], execlp and execvp are specified to retry execution of that file as-if it were a shell script (see the text quoted as to-be-deleted, under "Desired Action").

This behavior exists only for historical reasons -- it predates the `#!` mechanism implemented by all current-generation Unixes -- and *may* constitute a security hole. On the computer where I'm typing this, the first eight bytes of a machine-code executable are consistently 7f 45 46 02 01 01 00. The behavior of `sh` when fed a file beginning with these bytes is not specified, as far as I can tell; I have observed at least one implementation which, when given an input file containing those eight bytes, attempts to execute a program whose name is "\177ELF\002\001\001" (C string notation). Suppose an unprivileged process that can create a program with that name in a location on a higher-privileged process's PATH. The higher-privileged process is believed only to run programs with known names, but one of the programs with a known name is corrupt and will be rejected by `execve` with ENOEXEC, causing `execvp` to attempt to run it as a shell script, and in turn to execution of the injected program named "\177ELF\002\001\001".

Yes, this exploit chain involves a questionable implementation of `sh` *and* two different system misconfigurations, but I think we all know that vendors will try to argue that each of those three things is harmless and does not need fixing.
From <https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html>, [^] delete all of the following text from the DESCRIPTION section:

---
There are two distinct ways in which the contents of the process image file may cause the execution to fail, distinguished by the setting of errno to either [ENOEXEC] or [EINVAL] (see the ERRORS section). In the cases where the other members of the exec family of functions would fail and set errno to [ENOEXEC], the execlp() and execvp() functions shall execute a command interpreter and the environment of the executed command shall be as if the process invoked the sh utility using execl() as follows:

execl(<shell path>, arg0, file, arg1, ..., (char *)0);

where <shell path> is an unspecified pathname for the sh utility, file is the process image file, and for execvp(), where arg0, arg1, and so on correspond to the values passed to execvp() in argv[0], argv[1], and so on.
---

Also, in the ERRORS section, move the entry for [ENOEXEC] to the first group of errors ("The exec functions shall fail if: ...")
Notes
(0005173)
geoffclare   
2020-12-15 15:22   
There is no point changing execlp() and execvp() as there are many other ways that a shell can be invoked to try to execute such a file (e.g. system(), popen(), or just interactive use of a shell). The right place to deal with the issue is in the shell, and this was done in bug 0001226.

However, looking again at 1226 I see that there are two occurrences of the text that it fixes, and it only fixes one of them. Since that bug has already been applied, we should use this new bug as an opportunity to fix the other one.

On page 2368 line 75615 section 2.9.1.1, change:
If the executable file is not a text file, the shell may bypass this command execution. In this case, it shall write an error message, and shall return an exit status of 126.
to:
The shell may apply a heuristic check to determine if the file to be executed could be a script and may bypass this command execution if it determines that the file cannot be a script. In this case, it shall write an error message, and shall return an exit status of 126.
<small>Note: A common heuristic for rejecting files that cannot be a script is locating a NUL byte prior to a <newline> byte within a fixed-length prefix of the file. Since sh is required to accept input files with unlimited line lengths, the heuristic check cannot be based on line length.</small>
(0005174)
zackw   
2020-12-15 15:31   
The other C-level APIs you mention, system and popen, are expected to invoke a shell. The exec family, on the other hand, is expected *not* to invoke a shell. I think it is worth changing execlp and execvp just to eliminate this corner case where a shell might be invoked, contrary to expectations.
(0005175)
geoffclare   
2020-12-15 15:45   
Re Note: 0005174

No, only execl, execle, execv, and execve are expected not to invoke a shell. The execlp and execvp functions have always invoked a shell if the file cannot be executed directly and are very much expected to do so. Changing this would break a huge number of applications which rely on them executing a shell in cases where the shell script does not start with #! or the system does not support #!, including every strictly conforming application that includes a shell script to be executed using execlp or execvp (since strictly conforming applications cannot use #!)
(0005176)
zackw   
2020-12-15 15:53   
If you would prefer a more practical rationale for the proposed change, consider a program (a test suite driver, for instance) that wants to execute binaries that may have been cross-compiled and therefore may not be executable on the system where it's running, and distinguish ENOEXEC-type failure from other forms of failure. It runs on a wide variety of systems and therefore cannot rely on any binary-rejection heuristic being implemented by the shell. The only alternative is to avoid using execlp and execvp, but this means reimplementing PATH search by hand, and depending on the implementation language, it may not even be possible. (For instance, the Perl interpreter *only* exposes execvp and system to Perl programs.)
(0005177)
zackw   
2020-12-15 15:54   
On a closely related note, why on earth hasn't #! been standardized? I have *never* encountered a system that claims POSIX conformance but doesn't implement it, not even 25 years ago.
(0005178)
zackw   
2020-12-15 15:56   
> Changing this would break a huge number of applications

Please give one example of such an application.
(0005179)
shware_systems   
2020-12-15 16:11   
Those interfaces support the idea a utility may be implemented as a binary or a script, with binaries having attempt priority. The #! concept is an adjunct to this, not a replacement. It is for hardware and configuration dependant reasons like in the description why #! is precluded by the standard, however. There was a request to add it, a few years ago, and the issues discussed for rejecting it include factors out of scope for the standard.

It is also on the shell to provide a heuristic that recognizes sequences like in the description as being non-text, as the specified behavior, and reject processing it, per bug 1226. This is the same as the binary loader is expected to reject binaries for an incompatible processor. If it doesn't do this adequately it is a bug in that shell or loader, that I see, not a standard defect.
(0005180)
dannyniu   
2020-12-16 02:08   
(edited on: 2020-12-16 02:18)
As a read-only member on the mailing list who currently supervises the security logic of the web app deployed on our Linux server, I totally agree this is a serious potential security exploit.

I suggest a moderate modification. That is:

Change:

> execlp() and execvp() functions shall execute a command interpreter ...

To

> execlp() and execvp() functions may execute the "sh" command interpreter ...

This would allow implementations with additional access control deny certain scripts with say "security flags" attached to them when they're fetched from network or scanned by anti-virus software.

(0005294)
kre   
2021-03-19 17:51   
We certainly cannot make the change as requested, which looks to me to be
an attempt to force implementation change via the standards process, which
is not the way that things should work.

If implementations find that security is being compromised because of the
way execlp() and execvp() work, then they will change the way those things
work, or the applications that use them and become vulnerable. If the
former were to happen, updating the standard might become reasonable.

I actually doubt there is any real problem however, privileged applications
shouldn't (while privileged) be running anything using execlp() or execvp(),
there are way too many ways to compromise that ... doing so using the
method described here would be way down the list of things to try - and one
of earlier attempts would probably succeed. Avoiding using those functions
in privileged applications is the correct solution (and doing manual PATH
searches as a replacement is almost as bad, so they shouldn't do that either).

Just reject this bug.
(0005295)
kre   
2021-03-19 17:55   
Re Note: 0005294

Just in case I caused confusion, I have no problem using this bug as
a mechanism to fix the issue noted in Note: 0005173

Just not to do what is requested in the Desired Action.
(0005298)
geoffclare   
2021-03-22 15:43   
At page 784, line 26542 exec DESCRIPTION, change:
The argument path points to a pathname that identifies the new process image file.
to:
For the execl(), execle(), execv(), and execve() functions, the argument path points to a pathname that identifies the new process image file.

At page 784, line 26543 exec DESCRIPTION, change:
The argument file is used to construct a pathname ...
to:
For the execlp() and execvp() functions, the argument file is used to construct a pathname ...

On page 2368 line 75615 section 2.9.1.1, change:
If the executable file is not a text file, the shell may bypass this command execution. In this case, it shall write an error message, and shall return an exit status of 126.
to:
The shell may apply a heuristic check to determine if the file to be executed could be a script and may bypass this command execution if it determines that the file cannot be a script. In this case, it shall write an error message, and shall return an exit status of 126.
<small>Note: A common heuristic for rejecting files that cannot be a script is locating a NUL byte prior to a <newline> byte within a fixed-length prefix of the file. Since sh is required to accept input files with unlimited line lengths, the heuristic check cannot be based on line length.</small>




Viewing Issue Advanced Details
1434 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Comment Enhancement Request 2020-12-15 01:08 2021-04-01 09:40
andras_farkas
 
normal  
Applied  
Accepted As Marked  
   
Andras Farkas
pr
3107
103845-103847
---
Note: 0005283
Moving the -p option in the pr utility synopsis
In
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pr.html [^]
-f and -p are put together as [-fp] in the synopsis. As far as I can tell, if I understand it right, this is a historical artifact from them being added to POSIX from the old SUS standard at the same time. -f is XSI while -p is normal (required, unshaded) so I feel -p can be moved into [-adFmrt] for [-adFmprt] since those are all the other regular flags that don't take arguments.

I originally noted this as a minor nit here:
https://austingroupbugs.net/view.php?id=1432 [^]

An additional thing that could be done might be to move -f too, in the sense of taking it from the very end of the synopsis, and putting it closer to the front, like so:
[-adFmprt] [-f]
Move -p into [-adFmrt] to make that section [-adFmprt]
Notes
(0005171)
andras_farkas   
2020-12-15 01:10   
Or, even, since a single flag can be XSI shaded in a group of flags, maybe even...
[-adfFmprt] or [-adFfmprt] (with XSI shading around the f)
(0005172)
andras_farkas   
2020-12-15 01:10   
Though if that should be a separate issue, I can make that. Or we can rename this issue to "moving multiple options in the pr synopsis" or something like that.
(0005283)
geoffclare   
2021-03-18 15:52   
Change:
[−adFmrt]
to:
[−adfFmprt]
with XSI shading on just the "f" character.

Delete "[ −fp]"
(0005293)
andras_farkas   
2021-03-19 16:03   
That's even better! Thanks, geoffclare.




Viewing Issue Advanced Details
1433 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Clarification Requested 2020-12-12 00:16 2021-04-27 09:13
andras_farkas
 
normal  
Applied  
Accepted As Marked  
   
Andras Farkas
pr
Approved
Note: 0005282
The use of carriage-return in pr
On
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pr.html [^]
I see that -p waits for <carriage-return>.

Is this intentional?

I see that OpenSolaris (System V), Unix 10th edition, FreeBSD, and NetBSD pr wait for <newline> ('\n') and not <carriage-return>. I did not find an implementation which waits for <carriage-return>. Also, in grepping the entire POSIX standard for carriage-return and \r I find very few uses of it, while uses of <newline> for user input are universal.
Figure out whether pr should truly wait for <carriage-return> or not.
Notes
(0005282)
Don Cragun   
2021-03-18 15:41   
Interpretation response
------------------------
The standard states thar pr waits for <carriage-return>, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor.

Rationale:
-------------
This is not the way any implementation works and conflicts with similar requirements for other utilities.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------

On page 3108 line 103918 section pr, change:
<carriage-return>
to:
<newline>
(0005288)
agadmin   
2021-03-19 11:35   
Interpretation proposed: 19 March 2021
(0005326)
agadmin   
2021-04-22 08:42   
Interpretation Approved: 22 April 2021




Viewing Issue Advanced Details
1431 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Error 2020-12-10 16:00 2021-04-01 09:38
dirk_f
 
normal  
Applied  
Accepted  
   
Dirk Fieldhouse
XCU/4 Utilities/command
2596
84261ff
---
Incorrect xref for shell function lookup in specification of the 'command' utility
> The command utility shall cause the shell to treat the arguments as a simple command,
> suppressing the shell function lookup that is described in Section 2.9.1.1 (on page 2367), item 1b.

Should be "item 1c".

From Geoff Clare:
"It seems that the fault lies with bug 935 which added a new item 1b (and was applied via TC2)."

Change the text quoted in the Description above, as below:

"
The command utility shall cause the shell to treat the arguments as a simple command, suppressing the shell function lookup that is described in Section 2.9.1.1 (on page 2367), item 1c.
"

The issue continues in the latest Issue 8 draft, although the Section reference itself has been updated to 2.9.1.4. Is there an automatic process for forwarding this, or does it need a separate report?
Notes
(0005163)
geoffclare   
2020-12-10 17:40   
Re "Is there an automatic process for forwarding this, or does it need a separate report?"

It's automatic. Assuming this bug is resolved with a tc3-2008 tag, the fix will be applied in the Issue7TC3 branch in gitlab and then will automatically get merged into the Issue8 branch the next time I do a "git pull origin Issue7TC3" in that branch.




Viewing Issue Advanced Details
1430 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Error 2020-12-09 12:02 2021-04-01 09:36
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
write()
2311, 2314
73485, 73634
---
Text about interleaving data should say thread not process
Where the description of write() talks about data written to a pipe (or FIFO) being interleaved it refers to "other processes" but should say "other threads".

Also, the text on line 73481 before the bullet list says "pipe or FIFO" but the bullet list items only say "pipe".
On page 2311 line 73485 section write(), change:
Write requests of {PIPE_BUF} bytes or less shall not be interleaved with data from other processes doing writes on the same pipe. Writes of greater than {PIPE_BUF} bytes may have data interleaved, on arbitrary boundaries, with writes by other processes, whether or not the O_NONBLOCK flag of the file status flags is set.
to:
Write requests of {PIPE_BUF} bytes or less shall not be interleaved with data from other threads performing write operations on the same pipe. Writes of greater than {PIPE_BUF} bytes may have data interleaved, on arbitrary boundaries, with write operations by other threads, whether or not the O_NONBLOCK flag of the file status flags is set.

On page 2311 lines 73483-73500 section write(), change all occurrences of "pipe" to "pipe or FIFO".

On page 2314 line 73634 section write(), change:
interleaved with data from any other process
to:
interleaved with data from any other thread

There are no notes attached to this issue.




Viewing Issue Advanced Details
1429 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Omission 2020-12-02 16:57 2021-04-01 09:34
Konrad_Schwarz
 
normal  
Applied  
Accepted As Marked  
   
Konrad Schwarz
Siemens AG
recvfrom timeout
recvfrom
1
1
---
Note: 0005281
recvfrom does not specify the errno on timeout when the SO_RCVTIMEO option has been set
POSIX specifies the SO_RCVTIMEO socket option, that causes a receiving call on a socket to timeout when an error occurs. However, the recvfrom() (and presumably the related calls recv(), read() etc.) do not specify what errno is set to in this case.
According to the Linux socket(7) man page, EAGAIN/EWOULDBLOCK is returned in this case. (ETIMEDOUT would also kind of make sense and is what I assumed originally).

Add to the description of EGAIN in ERRORS the possibility of a timeout due to SO_RCVTIMEO.
Notes
(0005148)
geoffclare   
2020-12-03 10:39   
The required behaviour is specified in XSH 2.10.16 Use of Options:

P530 L18640 (SO_RCVTIMEO):
If a receive operation has blocked for this much time without receiving additional data, it shall return with a partial count or errno shall be set to [EAGAIN] or [EWOULDBLOCK] if no data were received.

P531 L18665 (SO_SNDTIMEO):
If a send operation has blocked for this much time, it shall return with a partial count or errno set to [EAGAIN] or [EWOULDBLOCK] if no data were sent.


We could either repeat this detail on each affected function page or just add a reference to 2.10.16.
(0005149)
Konrad_Schwarz   
2020-12-03 10:48   
My apologies; I think I was a bit tired yesterday.

I think the suggested reference would be fine.
(0005150)
shware_systems   
2020-12-03 11:25   
I'm more partial to requiring EAGAIN, not either, reserving EWOULDBLOCK for discovered conditions unrelated to timing such as hardware power failure on other end, if these are 2 different values. If they are the same value this would be a case for requiring them to be different.
(0005151)
kre   
2020-12-03 13:59   
Re Note: 0005150

XBD 14 <errno.h> says:

    [EAGAIN] Resource unavailable, try again (may be the same value as
          [EWOULDBLOCK]).

    [EWOULDBLOCK] Operation would block (may be the same value as [EAGAIN]).

In an I/O operation they mean the same thing, the two are very often the
same errno number (which is why the standard says they may be).

Apart from that (which I suppose could be undone, at the expense of breaking
many systems, as changing these values totally destroys binary compat for
the system) "reserving EWOULDBLOCK for discovered conditions unrelated to
timing such as hardware power failure on other end" is definitely not
EWOULDBLOCK - that's EIO.

The only argument against EAGAIN/EWOULDBLOCK here (and it is a weak one) is
that those generally occur immediately, rather than after a timeout period.
ETIMEDOUT (if it had its description changed from "connection timed out" to
"operation timed out" would probably fit a little better for an operation which
tries for a while, then eventually gives up.

But what really matters is not what anyone believes makes sense, but what
the actual implementations return.
(0005159)
shware_systems   
2020-12-04 18:02   
I would expect EIO to be about the system calling the interface, not about conditions on the other end of a connection. This is because there are codes like EAGAIN that are explicitly about the other end of a connection. Maybe some implementations don't differentiate and just use EIO as a blanket report code, given the terseness of "I/O error" as its definition in <errno.h>; maybe some have EAGAIN and EWOULDBLOCK as the same value, and use that where some other implementation might use EIO, but other systems may have 3 values. It is a definite portability issue on these systems if some return EAGAIN, and others EWOULDBLOCK; it forces application code to test for both constants, bloating both code and exec time, and does not give an application sufficient info about whether to retry or abort the attempt.

There's not a single one for indicating a timeout occurred but should complete eventually (nothing broke, latency is just higher than was expected), and a different one that says something happened where it can't tell if the operation might complete (something did break, but it wasn't corrected on other end before the timeout expired), and even a third for something broke on our end and any retry can't succeed until that's fixed.
(0005281)
geoffclare   
2021-03-18 15:23   
(edited on: 2021-03-18 15:24)
On page 1793, libes 58071-58074 section recv(), change:
    
If no messages are available at the socket and O_NONBLOCK is not set on the socket’s file descriptor, recv( ) shall block until a message arrives.

to:
    
If no messages are available at the socket and O_NONBLOCK is not set on the socket’s file descriptor, recv( ) shall block until a message arrives or a timeout occurs (see SO_RCVTIMEO in [xref to section 2.10.16]).


On page 1794 line 58081 section recv() ERRORS, append:
See also SO_RCVTIMEO in [xref to section 2.10.16].


On page 1794 at line 58111 add setsockopt() to the "SEE ALSO" list.

On page 1797 lines 58170-58173 section recvfrom(), change:
If no messages are available at the socket and O_NONBLOCK is not set on the socket’s file descriptor, recvfrom( ) shall block until a message arrives.

to:
If no messages are available at the socket and O_NONBLOCK is not set on the socket’s file descriptor, recvfrom( ) shall block until a message arrives or a timeout occurs (see SO_RCVTIMEO in [xref to section 2.10.16]).


On page 1797 line 58185 section recvfrom() ERRORS, append:
See also SO_RCVTIMEO in [xref to section 2.10.16].


On page 1798 at line 58208 add setsockopt() to the "SEE ALSO" list.

On page 1799 lines 58251-58252 section recvmsg(), change:
If no messages are available at the socket and O_NONBLOCK is not set on the socket’s file descriptor, recvmsg( ) shall block until a message arrives.

to:
If no messages are available at the socket and O_NONBLOCK is not set on the socket’s file descriptor, recvmsg( ) shall block until a message arrives or a timeout occurs (see SO_RCVTIMEO in [xref to section 2.10.16]).


On page 1800 line 58284 section recvmsg() ERRORS, append:
See also SO_RCVTIMEO in [xref to section 2.10.16].


On page 1801 at line 58310 add setsockopt() to the "SEE ALSO" list.

On page 1877 line 60823-60825 section send(), change:
If space is not available at the sending socket to hold the message to be transmitted, and the socket file descriptor does not have O_NONBLOCK set, send( ) shall block until space is available.

to:
If space is not available at the sending socket to hold the message to be transmitted, and the socket file descriptor does not have O_NONBLOCK set, send( ) shall block until space is available or a timeout occurs (see SO_SNDTIMEO in [xref to section 2.10.16]).


On page 1877 line 60837 section send() ERRORS, append:
See also SO_SNDTIMEO in [xref to section 2.10.16].



On page 1881 lines 60918-60920 section sendmsg(), change:
If space is not available at the sending socket to hold the message to be transmitted, and the socket file descriptor does not have O_NONBLOCK set, sendmsg( ) shall block until space is available.

to:
If space is not available at the sending socket to hold the message to be transmitted, and the socket file descriptor does not have O_NONBLOCK set, sendmsg( ) shall block until space is available or a timeout occurs (see SO_SNDTIMEO in [xref to section 2.10.16]).


On page 1881 line 60934 section sendmsg() ERRORS, append:
See also SO_SNDTIMEO in [xref to section 2.10.16].


On page 1884 line 61051-61054 section sendto(), change:
If space is not available at the sending socket to hold the message to be transmitted and the socket file descriptor does not have O_NONBLOCK set, sendto( ) shall block until space is available.

to:
If space is not available at the sending socket to hold the message to be transmitted, and the socket file descriptor does not have O_NONBLOCK set, sendto( ) shall block until space is available or a timeout occurs (see SO_SNDTIMEO in [xref to section 2.10.16]).


On page 1885 line 61066 section sendto() ERRORS, append:
See also SO_SNDTIMEO in [xref to section 2.10.16].






Viewing Issue Advanced Details
1428 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Objection Omission 2020-11-27 14:56 2021-04-01 09:30
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
3
71,79
2069,2270
---
Add definitions of "negative" and "positive"
A discussion on the mailing list that arose from Note: 0005108 identified the need to add definitions of the terms "negative" and "positive".
On page 71 line 2069 section 3, insert:

3.239 Negative
When describing a value (not a sign), less than zero. Note that in the phrase ``negative zero'' it describes a sign, and therefore negative zero (also represented as -0.0) is not a negative value.
and renumber the later subsections.

On page 79 line 2270 section 3, insert:

3.285 Positive
When describing a value (not a sign), greater than zero. Note that in the common phrase ``positive zero'' (which is not used in this standard, although the representation +0.0 is) it describes a sign, and therefore positive zero (+0.0) is not a positive value.
and renumber the later subsections.
There are no notes attached to this issue.




Viewing Issue Advanced Details
1427 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Error 2020-11-26 15:21 2021-04-27 09:11
geoffclare
 
normal  
Applied  
Accepted As Marked  
   
Geoff Clare
The Open Group
2.8.1 Consequences of Shell Errors
2364
75421
Approved
See Note: 0005271
2.8.1 does not take into account "command"
The table in XCU 2.8.1 does not take account of the fact that when the command utility is used, it prevents the shell from aborting when an error occurs in a special built-in utility, as per this statement in the description of command:
If the command_name is the same as the name of one of the special built-in utilities, the special properties in the enumerated list at the beginning of Section 2.14 (on page 2384) shall not occur.

In the "Special built-in utility error" row of the table in 2.8.1 add a 1 superscript after "shall exit" in the "Non-Interactive Shell" column. Renumber the other superscripts. After the table insert a new note 1:
The shell shall exit only if the special built-in utility is executed directly. If it is executed via the command utility, the shell shall not exit.

Notes
(0005124)
kre   
2020-11-30 19:36   
(edited on: 2020-11-30 19:37)
It might be worth answering the question "what does happen when a shell
does not exit after an error which would normally be 'shall exit'?" in the
various situations where this can occur.

My impression (without a lot of testing for now) is that when the reason
the shell does not exit is because it is interactive, the normal behaviour
is to abort whatever processing was happening (the entire command/list/program
that has been input) and return to the top level, issue PS1, and wait for
more from the command input stream.

At least that's the case for the top level shell, my impression is that even
for interactive shells, when encountering a "shall exit" in a sub-shell
environment, that sub-shell exits (I'm not sure if this is specified somewhere,
it might be.)

On the other hand, when not exiting because "command" has turned a special
builtin error into a "not exit" condition, my (so far limited) testing
indicates that shells simply continue with whatever follows the "command"
command in the normal sequence. That's not at all the same as what happens
with an interactive shell where the same special builtin (but without the
"command" command being used) fails for whatever reason it is failing.

An easy test setup for this is to use the special builtin "eval" as that
one is trivially easy to make fail.

The two scenarios are, in an interactive shell

        eval 'nonsense ><; foobar'; printf 'continued\n'

and in any shell

        command eval 'nonsense ><; foobar'; printf 'continued\n'

and see wehen there are differences.

(0005125)
geoffclare   
2020-12-01 16:28   
Re Note: 0005124

Looks like you've identified a related problem with this text at the end of 2.8.1:
In all of the cases shown in the table where an interactive shell is required not to exit, the shell shall not perform any further processing of the command in which the error occurred.

I think this should change to:
In all of the cases shown in the table where an interactive shell is required not to exit and a non-interactive shell is required to exit, an interactive shell shall not perform any further processing of the command in which the error occurred.


(The subshell-of-an-interactive-shell behaviour is already the subject of bug 0001384.)
(0005129)
kre   
2020-12-01 18:40   
(edited on: 2020-12-01 19:13)
Re bugnote: 5125

First, for subshells, yes, 0001384 will take care of that.

For the rest, the proposed change leaves unspecified (I believe) just
what "the command" in "the command in which the error occurred" actually
is. Clearly the actual simple command (usually) which fails should not
be executed any further, but if that command is a part of a pipeline, or
a list, or is embedded in a function, or ... (there are many possibilities)
then is only that one simple command not executed, and everything else
should continue (an interesting concept with something like:

     grep foo /some/file | command eval 'nonsense ><;' | wc -l

and I'm not sure how I'd do that), or is something more than just "the
command" to not be executed, and if so, how much, and how do we specify
that.

I did a little more testing after sending Note: 0005124, and found that
with the command line

   eval 'nonsense ><; foobar'; printf 'continued\n'

given to an interactive shell, yash, bash, ksh93, and zsh print "continued"
whereas the ash derived shells (dash, FreeBSD (my version is getting old now)
and NetBSD), and bosh and mksh do not.

bosh and mksh also do not print "continued" when the command line
is changed to be:

   command eval 'nonsense ><; foobar'; printf 'continued\n'

whereas the ash derived shells do. The others (naturally) continue to
print it.

When not interactive, executing

    $SHELL -c "eval 'nonsense ><; foobar'; printf 'continued\n'"

ksh93 and zsh still print "continued" (as does bash when not in posix mode).
The other shells tested (including bash in posix mode) do not.

With the "command" prefix, that is:

    $SHELL -c "command eval 'nonsense ><; foobar'; printf 'continued\n'"

we cannot test zsh, as its "command" command ignores builtins (special or
not) and only runs filesystem commands, and my system (NetBSD) has no
filesystem command for "eval" (as a special builtin, one isn't required,
but the same happens with "eval cd ..." with zsh as we don't have a cd
filesystem command either). It does however still print "continued".

Of the others all except yash bosh and mksh print "continued" (yash
actually reports 2 syntax errors, one for each of the < and > redirect
operators which are both missing operands). It does that with or without
the "command" command being used.

My summary is that bosh and mksh simply return to the PS1 prompt level on
any "must exit" error, regardless of the use of "command" and then if
non-interactive just exit. That seems broken. Perhaps.

bash in non-posix mode basically ignores the "special" in special builtin
I think, which explains its behaviour then. Explaining what ksh93 and
yash do is harder.

For interactive shells there's a clear difference between the ash derived
shells and the others (the ones not already discounted as broken) over
just how much "command" should be aborted on an otherwise "must exit"
error.

Note that in the above tests, none of the shells attempted to run "foobar"
(ie: that never elicited a command not found error message ... there is no
"foobar" command (or function, or anything similar) on my system).


For the pipeline case above, I actually just tested:

    grep NetBSD /etc/motd | eval 'nonsense ><;' | wc -l
and
    grep NetBSD /etc/motd | command eval 'nonsense ><;' | wc -l

Much to my surprise all shells (really all) went ahead and ran the
pipeline (both cases) and printed "0" as the line count (The word
NetBSD does in appear in /etc/motd). The grep is also run, as when
I used (cut and paste from above) "/some/file" I got an error from
grep (all shells) about that file not existing. This might be explained
by the commands in a pipeline being run in a sub-shell environment, but
only really if each command in the pipeline is run in its own environment.

For the case of functions, given a function definition

    badfunc() {
        $1 eval 'nonsense ><;'
        printf 'continued\n'
    }

interactive shells printed "continued" exactly in the same cases as
above (when the function was called as "badfunc" and "badfunc command".

When that was run in a non-interactive shell

    $SHELL -c "badfunc() {
        $1 eval 'nonsense ><;'
        printf 'continued\n'
    }
    badfunc command
    badfunc
    printf 'done\n'"

again the results were more or less as above (including the difference
for bash in or not in posix mode) - except that the ash derived shells
seem to ignore the "command" use (passed as an arg to badfunc) never print
"continued" at all, and only issue one syntax error. bash in posix mode
generates a syntax error for each call of badfunc, but never prints "continued",
it does not print "done". mksh is similar to bash in posix mode here, but
does print "done". bash (in non-posix mode) ksh93, and zsh, are the only
shells that print "continued" (twice) along with 2 error messages (they also
all print done). yash probably is closest to being "correct" (whatever that
is) - it prints 2 syntax error messages, and nothing else.

All this looks like a giant mess to me. For what it is worth, this is
an area I have no problems with making changes to the way the NetBSD
shell works, if we can ever arrive at a sensible definition of what should
be done in all of these cases.

(0005271)
Don Cragun   
2021-03-15 15:27   
Interpretation response
------------------------
The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.

Rationale:
-------------
The standard is unclear about whether the shell shall exit when there is a special built-in utility error if the special built-in was executed via the command utility. The "Consequences of Shell Errors" says that the shell shall exit, but the description of the command utility says that the command utility suppresses the exit.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
On page 2364 in the "Special built-in utility error" row of the table in 2.8.1 add a 1 superscript after "shall exit" in the "Non-Interactive Shell" column. Renumber the other superscripts and notes. After the table insert a new note 1:
The shell shall exit only if the special built-in utility is executed directly. If it is executed via the command utility, the shell shall not exit.



On page 2364 lines 75449-75450, change:
In all of the cases shown in the table where an interactive shell is required not to exit, the shell shall not perform any further processing of the command in which the error occurred.
to:
In all of the cases shown in the table where an interactive shell is required not to exit and a non-interactive shell is required to exit, an interactive shell shall not perform any further processing of the command in which the error occurred.
(0005272)
agadmin   
2021-03-15 19:42   
Interpretation Proposed: 15 March 2021
(0005323)
agadmin   
2021-04-19 13:48   
Approved: 19 April 2021




Viewing Issue Advanced Details
1426 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Objection Clarification Requested 2020-11-26 10:45 2021-03-25 14:29
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
4.12 Memory Synchronization
111
3066-3075
---
Clarifications regarding functions that synchronize memory
XBD 4.12 needs some clarifications regarding the conditions under which the functions in the table synchronize memory.

In Issue 6 it appears that the intent was that functions in the table always synchronize memory (on successful calls). A separate statement about pthread_once() was made after the table because it was only the first call in each thread (for a given pthread_once_t object) that needed to synchronize memory.

However, later changes have muddied the waters, in particular the addition of a paragraph about recursive mutexes, which now means that there are mutex functions in the table which do not always synchronize memory (on successful calls).

The statement "Unless explicitly stated otherwise, if one of the above functions returns an error, it is unspecified whether the invocation causes memory to be synchronized" has also become a problem following the addition of robust mutexes, since calls that return EOWNERDEAD lock the mutex and therefore should be required to synchronize memory.

Finally, the pthread_mutex_setprioceiling() function is missing from the table.
On page 111 line 3065 section 4.12, change:
The following functions synchronize memory with respect to other threads
to:
The following functions shall synchronize memory with respect to other threads on all successful calls

On page 111 line 3066-3075 section 4.12, remove all pthread_mutex_*() functions, pthread_cond_wait(), and pthread_cond_timedwait() from the table.
 
On page 111 line 3076-3079 section 4.12, change:
The pthread_once() function shall synchronize memory for the first call in each thread for a given pthread_once_t object. If the init_routine called by pthread_once() is a cancellation point and is canceled, a call to pthread_once() for the same pthread_once_t object made from a cancellation cleanup handler shall also synchronize memory.
to:
The pthread_once() function shall synchronize memory for the first successful call in each thread for a given pthread_once_t object. If the init_routine called by pthread_once() is a cancellation point and is canceled, a successful call to pthread_once() for the same pthread_once_t object made from a cancellation cleanup handler shall also synchronize memory.

On page 111 line 3080-3083 section 4.12, change:
The pthread_mutex_lock() function need not synchronize memory if the mutex type if PTHREAD_MUTEX_RECURSIVE and the calling thread already owns the mutex. The pthread_mutex_unlock() function need not synchronize memory if the mutex type is PTHREAD_MUTEX_RECURSIVE and the mutex has a lock count greater than one.
to:
The pthread_mutex_lock(), [RPP|TPP]pthread_mutex_setprioceiling(),[/RPP|TPP] pthread_mutex_timedlock(), and pthread_mutex_trylock() functions shall synchronize memory on all calls that acquire the mutex, including those that return [EOWNERDEAD]. The pthread_mutex_unlock() function shall synchronize memory on all calls that release the mutex.
<small>Note: If the mutex type is PTHREAD_MUTEX_RECURSIVE, calls to the locking functions do not acquire the mutex if the calling thread already owns it, and calls to pthread_mutex_unlock() do not release the mutex if it has a lock count greater than one.</small>
The pthread_cond_wait() and pthread_cond_timedwait() functions shall synchronize memory on all calls that release and re-acquire the specified mutex, including calls that return [EOWNERDEAD], both when the mutex is released and when it is re-acquired.
<small>Note: If the mutex type is PTHREAD_MUTEX_RECURSIVE, calls to pthread_cond_wait() and pthread_cond_timedwait() do not release and re-acquire the mutex if it has a lock count greater than one.</small>

On page 111 line 3084-3085 section 4.12, change:
Unless explicitly stated otherwise, if one of the above functions returns an error, it is unspecified whether the invocation causes memory to be synchronized.
to:
Unless explicitly stated otherwise, if one of the functions named in this section returns an error, it is unspecified whether the invocation causes memory to be synchronized.

There are no notes attached to this issue.




Viewing Issue Advanced Details
1425 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Error 2020-11-23 23:10 2021-03-25 14:27
kre
 
normal  
Applied  
Accepted As Marked  
   
Robert Elz
XCU 2.14 / exit
2399
76764-5
---
Note: 0005266
exit in an EXIT trap is not clearly specified
the page for the special builtin command "exit" says

    A trap on EXIT shall be executed before the shell terminates,
    except when the exit utility is invoked in that trap itself,
    in which case the shell shall exit immediately.

The issue is what "that trap itself" means.

Consider

   $SHELL -c 'trap "trap \"echo bar\" EXIT; echo foo; exit" EXIT'

When the exit command in the outer exit trap is executed, the EXIT
trap has been changed to be something different, that is, the
shell is not executing the (current) EXIT trap when that exit command
is executed, so by a literal reading of the standard, the inner trap
should fire, and the shell should print

    foo
    bar

before exiting.

That is what the FreeBSD and NetBSD shells, and bosh, mksh, and zsh do.
bash yash ksh93 and dash print only "foo", that is they seem to ignore
the "that" in "that exit trap" and treat the text as if it said

    except when the exit utility is invoked in an exit trap

The page in XCU 2.14 for trap says nothing pertinent to this issue
(I am not suggesting that it should, just noting it).
Since the "reference" shells seem to do this the broken way, it is
unlikely that the standard will have words (or an example) added to
reinforce the current wording (I am guessing).

But since the other shells are doing exactly what the standard requires
of them, it would be incorrect, and unfair to specify this so as to
require the currently non-standard behaviour that the reference shells
implement.

Given that, the best that can be done, I believe, is to add a new
sentence, immediately after the one quoted above (which is unchanged
in 202x drafts) something like

    It is unspecified whether an EXIT trap defined while executing
    a previous EXIT trap will be executed before the shell terminates
    after completing execution (via an exit command, or reaching the
    end) of the earlier EXIT trao.

Notes
(0005266)
rhansen   
2021-03-11 17:07   
In c181 on page 2399 append another sentence to the paragraph at lines 76764-76765:
It is unspecified whether setting a new trap action on EXIT during execution of a trap action on EXIT will cause the new trap action to be executed before the shell terminates.




Viewing Issue Advanced Details
1424 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Clarification Requested 2020-11-22 10:19 2021-03-25 14:26
rillig
 
normal  
Applied  
Accepted As Marked  
   
Roland Illig
make
(page or range of pages)
(Line or range of lines)
---
Note: 0005120
Inconsistent spelling of single suffix vs. single-suffix
* it is a single-suffix inference rule
* the single suffix inference rules
* The single-suffix inference rules
* one of the single suffixes appended
* SINGLE SUFFIX RULES

The words single-suffix should be spelled consistently.
Replace "single suffix" with "single-suffix" everywhere since it is meant to be an adjective.
Notes
(0005120)
geoffclare   
2020-11-23 09:35   
I have moved this bug to the Issue7+TC2 project, as this problem exists in C181.pdf.

The 2nd and 5th bullet points in the description are the cases that need a hyphen added. The 4th ("one of the single suffixes appended") does not need a hyphen, as "single suffixes" is not being used as an adjective there.




Viewing Issue Advanced Details
1422 [Issue 8 drafts] Shell and Utilities Objection Error 2020-11-18 13:49 2021-03-25 14:24
joerg
 
normal  
Applied  
Accepted As Marked  
   
Jörg Schilling
2894-2895
97277-97282
Note: 0005265
The current definition for the += assingment is in conflict with existing behavior of make and unpredictable/error-prone
The += operator has been introduced in January 1986 by SunPro Make.
It is defined to behave the same way as the = operator (to use delayed
expansion) regardless of how the assigned macro has been used before.

The current text in the standard does not seem to be compatible to long
existing behavior and it would be higly error-prone in complex makefiles
in special if these makefiles make use of the include directive.

Complex makefiles that make use of the include directive usually have
previous macro assignments in files from global make-include directories.
The author of a specific makefile thus cannot easily know whether there
was a previous = or ::= assinment for a specific macro since this would
require to manually scan many include files. Even worse: Which makefiles
are included is not easy to predic in object oriented makefile systems
that include different makefiles depending on the content of make
macros. As a result, the current standard text would cause
unpredictable results of the whole.

It seems to be better and more flexible to introduce a new operator +:= or
:+= for immediate expansion of the string to append, or to document this
work-around using the helper macro VAR2:

VAR2 := $(VAR3)
VAR = some text
VAR += $(VAR2)

instead of

VAR = some text
VAR += $(VAR3)

to enforce quasi-immediate expansion of the appended text.

In order to avoid an incompatible change for gmake users, we could
permit gmake to continue to support its deviating bahavior for the
non-standad := operator and require the POSIX ::= operator to behave
in a predictable way as proposed in Desired Action below.

P.S.:

Immediate expansion cannot be seen as completely new behavior because
SunPro Make in January 1986 already introduced immediate assignment in
contrast to delayed assignment for this:

VAR :sh= command

which is an immediate command substitution that calls the shell once
at parse time and this construct has been in use since then (using
the echo command) to emulate the behavior that recently has been
standardized for ::=

This problem was discovered while implementing ::= for SunPro Make
Change the text in line 97277-97282 to:

  If the macro named by string1 exists, then a <space> character followed
  by the unevaluated string2 shall be appended to the value currently
  assigned to the value of the macro named by string.



To make the standard compatible to the existing behavior.

Discuss the proposal for +:= or :+= and for the standard and write
a related proposal, or document the workaround mentioned above.
Notes
(0005257)
geoffclare   
2021-03-05 16:11   
This request makes no sense and seems to be the result of misunderstanding how immediate-expansion macros work.

If the wording is changed so that += always appends an unexpanded value, as requested, then it would be impossible to use any macros on the right hand side of += when the left hand side is an immediate-expansion macro, because they will never be expanded. See lines 97290-97297 (emphasis added):
Macro expansions in string2 of macro definition lines shall be performed according to the form used to define the macro. Immediate-expansion forms (including appending to an existing immediate-expansion macro) shall be expanded in the macro definition line, and shall not be re-expanded when used in a rule or command. Delayed-expansion forms (including appending to an existing delayed-expansion macro, and conditional assignment to a macro not previously existing) shall be expanded when the macro identified by string1 is expanded in a rule or command, and the result of the expansion shall be scanned for further macros.


Regarding the point made in the bug description, "The author of a specific makefile thus cannot easily know whether there was a previous = or ::= assignment for a specific macro since this would require to manually scan many include files", makefile authors can easily avoid this situation by adopting a naming convention for macros that distinguishes the two types of macro. For example, use uppercase and underscore for delayed-expansion macros and something involving at least one lowercase character for immediate-expansion macros. It may be worth adding something to APPLICATION USAGE recommending the use of a naming convention to distinguish the macro types.
(0005258)
psmith   
2021-03-05 17:07   
(edited on: 2021-03-05 17:17)
GNU make's implementation of += has always been that the RHS is treated in the same way (immediate or deferred expansion) as the type of the variable being appended to. This can't be changed as that would be a disastrous backward-compatibility break.

I am not excited about the idea of having ::= work differently from := in this specific way, plus as Geoff mentions I don't see how this can actually work.

Put another way, I think that ::= is much closer to GNU make's := than it is to SunPro make's :sh= and that its behavior should follow GNU make's implementation.

(0005259)
joerg   
2021-03-05 18:30   
Re: Note: 0005257

This seems to be a missunderstanding.

1) += always was a delayed (textual) append, the same way = is a delayed (textual) assignment. This always was independent from whether the macro does not exist before using +=, whether it has been assigned via = delayed assingment or via the immediate assignment "macro :sh=command" before.The current POSIX text breaks that rule that exists since Janary 1986.

2) using $(macro) in a make command or a right hand side of a dependency list always expands the content of that macro. If you use the "immediate epand" feature "macro :sh= command", this just immediately assigns the output of "command" into the content of the make macro "macro". If that output contains further make macro references, these references are expanded when $(macro) is finally referenced.

If I understand your text correctly and you expect a macro that has been assigned with := before should not undergo the usual final macro expansion step when used in a make command or LHS of a dependency, this is in conflict with existing make behavior and it would introduce a desastrous inconsistency.
(0005260)
psmith   
2021-03-05 19:18   
(edited on: 2021-03-05 19:38)
The behavior of += with respect to = (delayed) assignment is as you describe it: it appends the new text to the end of the existing text without any expansion and expansion happens when the variable is used.

Regarding "macro :sh=command", that is not part of the POSIX standard so you can decide how it works with respect to += as you like, I suppose.

Regarding the ::= assignment: this is intended to work (as I understand it) the same way that ":=" works in GNU make. That is, when the variable assignment is made the RHS is expanded immediately, and after that the value is treated as a static string and is no longer expanded when the variable is used. If a "+=" is made to a variable that was created with "::=", the RHS is expanded first, then the result of that expansion is appended to the variable.

I think it's misleading to consider "::=" to be related to Sun's ":sh="; they are different and unrelated to each other. The goal of introducing a new operator like "::=" is exactly because the behavior we want there is not like existing make behavior; so it is not an inconsistency that they are different.

Allowing the value of a "::=" assignment to be re-expanded again when the variable is used would be quite confusing. For example:

    foo ::= $$hello

    all: ; @echo '$(foo)'

would print 'ello', instead of the desired '$hello'.

(0005262)
joerg   
2021-03-08 15:32   
(edited on: 2021-03-08 15:42)
The following make implementations support +=

SunPro Make This was the first make implementation (1986) to support +=
            All macro references left to : and in commands are always expanded.

gmake in an incompatible way since 1989

AIX make supports += and explicitly mentions that all macro references
            left to : and in commands are always expanded in it's man page

smake supports += since 1996 compatible to SunPro Make
            All macro references left to : and in commands are always expanded.

The problem is that gmake is incompatible to SunPro Make, AIX make and smake and POSIX should standardize commonly supported features. This does not apply to what gmake implements with :=.

As mentioned before: the main problem with the gmake := implementation is that it leads to unpredictable behavior in huge makefile systems that make use of "include". For this reason, a method should be supported that is compatible to what people expect (the SunPro behavior) and that results in predictable behavior.

A possible way to support predictable behavior could be to define a :::= that expands the right hand side but does not lead to a macro that behaves incompatible to previous make behaviot.

Another useful predictable method could be a +:= operator that immediately expands the right side of the += opration.

(0005263)
psmith   
2021-03-08 18:56   
(edited on: 2021-03-08 18:58)
Can you explain what is incompatible about GNU make's use of +=? As far as I understand it, GNU make's use of += is the same as all other versions of make _when applied to standard make variables_ (created with "="). Put another way, if we posit a makefile that adheres completely to traditional POSIX make plus the extra "+=" operator only (and not "::=") then there is no incompatibility across implementations. If you disagree please explain.

The question being raised here is what the behavior should be for += when applied to the new operator, "::=". Since this is a new operator that doesn't exist in other versions of make, it cannot be the case that its behavior is incompatible with other versions of make.

I just want to make clear that comparing "::=" to either SunPro ":=" or SunPro ":sh=" is not right; those are very different operators and have no relationship to "::="; using the way they work as examples for "::=" isn't appropriate IMO. No version of the POSIX standard makes any statement about how the ":=" operator should work.

It seems there are two issues being discussed WRT "::=".

The first is whether the value of such macros should be re-expanded when they are used, as the ":=" operator is defined in BSD make for example, or whether they should not be, as for the GNU make version of ":=" for example.

This difference was already raised in issue #330 comment ~577. The resolution of that issue chose the GNU make method, where the expansion happens only once. So for example given this makefile:

  one = $$one
  two ::= $$two
  all: ; @echo '$(one) $(two)'

you would get "$one $two" (as with GNU make ":=") not "$one wo" (as with BSD make ":="). Of course I'm biased but to me this behavior is more reasonable and what users would expect. It is confusing and unexpected to have values assigned with "=" to be evaluated one time and values assigned with "::=" to be evaluated twice.

The other issue is what the behavior should be for "+=" when applied to a variable set with "::=".

If we use the current behavior of "::=" as defined by issue #330 then it's clear that the RHS of the "+=" must be expanded immediately on assignment and the result appended to the value. In fact it is wrong to do anything else, otherwise, as Geoff points out above, the added text will never be expanded. This is the current definition of the behavior as accepted in issue #330.

If the behavior of "::=" were to be changed to allow for the BSD make version in addition to the GNU make version, then either form of "+=" (one where the expansion happens immediately and one where expansion is delayed) could work.

I personally am not a fan of that change since I think allowing both methods adds confusion and makes it harder to write portable makefiles.

(0005264)
joerg   
2021-03-11 15:50   
(edited on: 2021-03-11 15:51)
The BSD version of make I have at home (from 4/2020) implements the
same behavior for := and += as smake. += does not expand the right side
and macro content is always expanded at use time.

Make on AIX supports += and explicitly documents that macros are always
expanded at use time. I currently have no access and thus cannot say
whether there is also support fpr :=.

So we have two make implementations that implement the full featureset
but behave identical in this area and different from GNU make.

It has however been reported that a ubuntu binary for bmake seems to have
been changed.

Yesterday, I worked on smake (I started with smake because I know smake
since 36 years and with SunPro Make only since 4 years) and tried to
implement the :::= and +:= proposal. The code is ready now and will be
published next week. So this is no longer invention.

I also checked whether it would be possible to disable macro expansion at
use time on request. This is at least hard to implement since macro name
expansion still needs to be done.

(0005265)
geoffclare   
2021-03-11 16:26   
On page 2903 line 97634,97638,97638 section make (APPLICATION USAGE) change "IMMED" to "Immed".

On page 2903 line 97641 section make (APPLICATION USAGE), add a new paragraph:
Because the behavior of the <tt>+=</tt> assignment differs depending on whether the macro being appended to is a delayed-expansion macro or an immediate-expansion macro, it is recommended that when both macro types are used in a set of multiple makefiles and include files, a naming convention is adopted to distinguish the two macro types. This avoids any confusion about whether <tt>+=</tt> will append the expanded or unexpanded value. A suitable convention might be to name delayed-expansion macros using uppercase and underscore characters and immediate-expansion macros using a name that contains at least one lowercase character.
(0005267)
dmitry_goncharov   
2021-03-11 22:07   
> Make on AIX supports += and explicitly documents that macros are always
expanded at use time.

The man page for aix make says
"Variable substitution occurs at two distinct times, depending on where the variable is being used. Variables in dependency lines are expanded as the line is read. Variables in shell commands are expanded when the shell command is executed."

$ cat makefile
what = hello
msg += $(what)
all:
        @echo msg=$(msg)


what=bye
$ /usr/bin/make
msg=bye
$
$ cat makefile2
what = hello
msg += $(what)
all: $(msg)
        @echo msg=$(msg)


what=bye
$ /usr/bin/make -f makefile2
make: 1254-002 Cannot find a rule to create target hello from dependencies.
Stop.
$

> I currently have no access and thus cannot say
whether there is also support fpr :=.

No support for :=.
(0005268)
psmith   
2021-03-12 19:18   
Regarding implementation details for POSIX "::=", the straightforward way to implement it is to have a bit associated with the variable stating whether it was assigned via "::=" or not; when the variable value is to be expanded you check that bit and if it's set then instead of expanding the content of the variable you copy the content into the result verbatim. To implement "+=" you check if the bit is set and if so, you expand the RHS and append it to the current value.
(0005291)
joerg   
2021-03-19 14:34   
Re: Note: 0005260 A make compliant way to avoid the problem you mentioned in that bugnote is to use:

foo ::= $$$$hello
all: ; @echo '$(foo)'


Re: Note: 0005263 A make compliant way to avoid the problem you mentioned in that bugnote is to use:

one = $$one
two ::= $$$$two
all: ; @echo '$(one) $(two)'


Re: Note: 0005268 Whom do you like to help with that note? The remark misses the most important problem:

A full blown make implementation needs to be able to update targets (e.g. arguments from include directives) while parsing Makefiles. This makes it hard to switch off expansion in a way similar to gnu make. The only way I see in e.g. smake without throwing all 40 year old code structures away is to introduce a global variable to enforce expansion when in a parser related part of the code. This enforces ugly code :-(

This is the background why I propose to add :::= for an expanding assignment without creating a different macro type and a +:= append operator that always expands the right side.
(0005297)
psmith   
2021-03-22 14:48   
Certainly there are workarounds. The argument raised against the behavior of "::=" as described in the standard is that it is inconsistent with other variables during expansion, but the only way to make it consistent on the expansion side is to make it inconsistent during assignment, as you show with these workarounds. My belief is that this would be a worse situation. YMMV.

I don't understand the comments about "updating targets (e.g. arguments from include directives)". To implement the "::=" operator as defined in the POSIX standard, there's no special handling of targets, included files, or anything else. Any implementation of make must have a mapping between variable names and variable values. To implement "::=" what's needed is to add a boolean flag to each value saying whether it was assigned with "::=" or not. Then during expansion (any expansion, at any time) if that flag is not set the value is expanded normally. If the flag is set then the value is copied as-is without expansion. During "+=" the variable being assigned is checked and if the flag is set then the RHS is expanded first, then appended to the existing value. Otherwise the unexpanded RHS is added to the value. That's all that needs to happen; I'm not familiar with the internal structure of smake but I don't see how this could require throwing out existing data structures; the only change to data structures is the one additional flag per variable.

A quick look in the smake code suggests that all that's needed is a new flag value, such as F_NOEXPAND or something, that can be added to flags in struct obj. No changes to data structures required.

I have no comment about a putative ":::=" since I don't understand exactly what it does or what it is for, except to say that I don't see a need for yet another assignment operator in make; certainly no GNU make users have suggested to me that there's a problem that needs to be solved.




Viewing Issue Advanced Details
1421 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Comment Clarification Requested 2020-11-10 12:13 2021-03-19 09:54
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
make
2983
99076
---
make APPLICATION USAGE about default rules
The make APPLICATION USAGE section includes this statement:
The best way to provide portable makefiles is to include all of the rules needed in the makefile itself.
It seems that its purpose is to advise writers of portable applications not to rely on the default rules. (It is followed by other text relating to the default rules.) However, following the addition of include lines to the standard, it can be misinterpreted as advising against the use of include lines.

The problem could be fixed by changing "in the makefile itself" to "in the makefile(s), and any include files, themselves", but since the advice seems dubious I would prefer just to remove it (and make some adjustments to the text that follows it).
On page 2983 line 99076 section make (APPLICATION USAGE), change:
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-2017. The default rules include rules for optional commands in this volume of POSIX.1-2017. Only rules pertaining to commands that are provided are needed in an implementation's default set.
to:
The standard set of default rules use only features provided by other parts of this volume of POSIX.1-2017. They include rules for optional utilities in this volume of POSIX.1-2017, but only rules pertaining to utilities that are provided are needed in an implementation's default set.

Notes
(0005112)
psmith   
2020-11-10 19:49   
I agree that removing the advice altogether is the best plan.




Viewing Issue Advanced Details
1420 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Clarification Requested 2020-11-07 20:27 2021-03-19 09:53
psmith
ajosey  
normal  
Applied  
Accepted As Marked  
   
Paul Smith
GNU Project
make
2979
98879
---
Note: 0005256
Clarification: where are internal macros available?
In the section "Internal Macros" we see:

> The make utility shall maintain five internal macros that can be used in target and inference rules.

It is not clear from this text what is meant by "can be used in ... rules". In GNU make for example, internal macros (called "automatic variables" in the GNU make manual) are available only within the commands of a rule but not available within the prerequisites of a rule.

Does the statement "can be used in" mean to suggest that these macros can be used in the prerequisites list of a given rule as well?

If so, we must clarify what it means when a non-$@ variable is used in the prerequisites list.
Change the text:

The make utility shall maintain five internal macros that can be used in target and inference rules.

to:

The make utility shall maintain five internal macros that can be used in the commands of target and inference rules.
Notes
(0005103)
joerg   
2020-11-07 22:01   
Your seem to miss that the macros $< and $* are undefined in case of explicit rules.

smake does not expand $< or $* for explicit rules.

SunPro Make and gmake both expand these macros, but use completely incompatible rules to expand these macros in case of explicit rules. These rules result in the same expansion for some constraints and give different results for other constraints. Your text thus is inacceptable for standardization.

BTW: The background for this question was a question from a bug-tracking system that has been caused by an incompatibility in the BSD make program and was related to the use of $@ in the dependency list of an explicit target rule.

Make macros seen in the dependency list of a target rule are expanded by the parser already and at that time, $@ is undefined.
(0005104)
psmith   
2020-11-08 13:42   
I am aware of the difference in $< and $* in explicit rules. My suggested change is not related to that, and doesn't make this behavior any more or less defined WRT POSIX than it is now, so that is not relevant as to whether the suggested change is acceptable. If you wanted to make the handing of these internal macros inside of explicit rules more clear than it currently is, please file a separate issue and we can discuss there.

> Make macros seen in the dependency list of a target rule are expanded by the parser already and at that time, $@ is undefined.

You (and I) may _believe_ that, but the text of the standard doesn't _say_ that. Hence my request for clarification.

If you think the standard DOES say that already please quote the text that says so.

My suggested change ONLY makes clear that internal macros are not defined except for inside commands. It is not intended to address any other issue than that.
(0005105)
joerg   
2020-11-08 16:17   
In order to avoid missinterpretations with the dynamic macros, I like to make an alternate proposal that is aligned with the behavior of the UNIX make utility.

Change the following sentence on page 2898 line 97447 from:

      The make utility shall maintain five internal macros that can be used in
      target and inference rules.

into:

      The make utility shall maintain five internal macros that shall be expanded
      in the command sections of rules. Not all of these internal macros are
      expanded with all types of rules, see the detailed description below and
      the rationale section for the the System V dynamic dependency feature.
(0005106)
psmith   
2020-11-08 16:52   
I don't see the point in making this statement, since each explanation of the individual internal macros explains which types of rules it is required for and which it is not required for. For example, the $< macro description already says "The meaning of the $< macro shall be otherwise unspecified." (other than implicit rules and .DEFAULT), etc.

I don't think it's needed to refer to the rationale section from within the standard like this; the existing text is very clear on this point without it.

My concern here is specifically whether internal macros need to be assigned before the prerequisites are expanded, or not. The standard is not clear (enough) on this point, in my opinion.

Perhaps a change like this would be sufficient:

  The make utility shall maintain five internal macros that will be assigned
  while the commands of target and inference rules are evaluated, as described
  below.

Just to clearly point people to the individual macro discussions to follow.
(0005107)
joerg   
2020-11-08 21:30   
The proposed text from Note: 0005106 does not really contain a new
statement, since that information is already available if you
combine existing statements from different locations in the
standard text for the make utility.

On the other side, your proposal still does not seem to directly answer the
related question from your customer in your bug data base.

The dynamic macros are specified as returning values that are only
available while a target rule or an inference rule is evaluated.

On the other side, the standard already mentions that while reading
target rules by the parser, contained macro references in every
target rule need to be expanded immediately. At that time, a value
for $@ however is not available, so the rule

tgt: $@.c

needs to be expanded into

tgt: .c

while specifying

tgt: $$@.c

is required to expand to:

tgt: $@.c

at parse time and that may later be expanded as dynamic dependency
at the time the rule is evaluated. Well, in case the make program
implements support for the dynamic dependency feature that is not
required by POSIX.
(0005109)
psmith   
2020-11-08 23:43   
> At that time, a value for $@ however is not available,

You are _assuming_ that, because that's how implementations of make (that attempt to be POSIX compliant) work today: the standard does not _say_ that they are not available. That's the problem.

If you can find text in the standard that says that $@ is not set before prerequisites are expanded, please quote that text.

There's nothing in the standard that I can find that says that make doesn't have to work like this:

* Read in the rule definition line
* Expand the target
* Assign the internal macro $@ to the name of the target
* Expand the prerequisites

And in fact, the current wording of the standard is ambiguous enough that it could be argued that it IS required: the standard says that internal variables "can be used in target and inference rules". The prerequisites are definitely part of target and inference rules.

All I want in this issue is to clear this one thing up. I'm not trying to add new requirements, discuss $$@, etc. Merely clarifying that internal macros are only required to be available in the commands, not "in target and inference rules" generally, is sufficient and nothing else needs to be added.
(0005256)
geoffclare   
2021-03-04 16:30   
On page 2979 line 98879 change:
The make utility shall maintain five internal macros that can be used in target and inference rules.
to:
The make utility shall maintain five internal macros that can be used in the commands of target and inference rules, as described below.




Viewing Issue Advanced Details
1419 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Error 2020-11-07 20:20 2021-03-19 09:51
psmith
ajosey  
normal  
Applied  
Accepted  
   
Paul Smith
GNU Project
make
2980
98952
---
Missing newline / indentation in .SCCS_GET default rule definition
Apologies for not including the page and line number: I'm not sure where to get a copy of the standard with this information included.


The description of the .SCCS_GET special target says:

he application shall ensure that this special target is specified without prerequisites. If this special target is included in a makefile, the commands specified with this target shall replace the default commands associated with this special target (see Default Rules). The commands specified with this target are used to get all SCCS files that are not found in the current directory.

However, the example provided in the default rules section shows:

.SCCS_GET: sccs $(SCCSFLAGS) get $(SCCSGETFLAGS) $@

This shows the commands as prerequisites of the special target, which is not correct.
Change:

.SCCS_GET: sccs $(SCCSFLAGS) get $(SCCSGETFLAGS) $@


to:

.SCCS_GET:
        sccs $(SCCSFLAGS) get $(SCCSGETFLAGS) $@
There are no notes attached to this issue.




Viewing Issue Advanced Details
1418 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Comment Enhancement Request 2020-11-06 10:32 2021-03-19 09:47
geoffclare
 
normal  
Applied  
Accepted As Marked  
   
Geoff Clare
The Open Group
ulimit
3326-3327
111991-112065
---
See Note: 0005254.
Add options to ulimit to match get/setrlimit()
Currently the ulimit utility only provides the means to query and set the RLIMIT_FSIZE soft limit. It should be able to query and set the hard limit, and also the soft and hard limits for the other resources that are specified for getrlimit() and setrlimit(). The -a option would also be useful.

The proposed additions are widely supported.
Replace the NAME, SYNOPSIS, DESCRIPTION, OPTIONS, and OPERANDS sections on the ulimit page with:

NAME
ulimit -- report or set resource limits

SYNOPSIS
[XSI]ulimit [-H|-S] -a

ulimit [-H|-S] [-cdfnstv] [newlimit][/XSI]

DESCRIPTION
The ulimit utility shall report or set the resource limits in effect in the process in which it is executed.

Soft limits can be changed by a process to any value that is less than or equal to the hard limit. A process can (irreversibly) lower its hard limit to any value that is greater than or equal to the soft limit. Only a process with appropriate privileges can raise a hard limit.

The value unlimited for a resource shall be considered to be larger than any other limit value. When a resource has this limit value, the implementation shall not enforce limits on that resource. In locales other than the POSIX locale, ulimit may support additional non-numeric values with the same meaning as unlimited.

The behavior when resource limits are exceeded shall be as described in the System Interfaces volume of POSIX.1-202x for the setrlimit() function.

OPTIONS
The ulimit utility shall conform to [xref to XBD 12.2].

The following options shall be supported:

-H
Report hard limit(s) or set only a hard limit.
-S
Report soft limit(s) or set only a soft limit.
-a
Report the limit value for all of the resources named below and for any implementation-specific additional resources.
-c
Report, or set if the newlimit operand is present, the core image size limit(s) in units of 512 bytes. [RLIMIT_CORE]
-d
Report, or set if the newlimit operand is present, the data segment size limit(s) in units of 1024 bytes. [RLIMIT_DATA]
-f
Report, or set if the newlimit operand is present, the file size limit(s) in units of 512 bytes. [RLIMIT_FSIZE]
-n
Report, or set if the newlimit operand is present, the limit(s) on the number of open file descriptors, given as a number one greater than the maximum value that the system assigns to a newly-created descriptor. [RLIMIT_NOFILE]
-s
Report, or set if the newlimit operand is present, the stack size limit(s) in units of 1024 bytes. [RLIMIT_STACK]
-t
Report, or set if the newlimit operand is present, the per-process CPU time limit(s) in units of seconds. [RLIMIT_CPU]
-v
Report, or set if the newlimit operand is present, the address space size limit(s) in units of 1024 bytes. [RLIMIT_AS]
Where an option description is followed by [RLIMIT_name] it indicates which resource for the getrlimit() and setrlimit() functions, defined in the System Interfaces volume of POSIX.1-202x, the option corresponds to.

If neither the -H nor -S option is specified:

  • If the newlimit operand is present, it shall be used as the new value for both the hard and soft limits.

  • If the newlimit operand is not present, -S shall be the default.


If no options other than -H or -S are specified, the behavior shall be as if the -f option was (also) specified.

OPERANDS
The following operand shall be supported:

newlimit
Either an integer value to use as the new limit(s) for the specified resource, in the units specified in OPTIONS, or a non-numeric string indicating no limit, as described in the DESCRIPTION section. Numerals in the range 0 to the maximum limit value supported by the implementation for any resource shall be syntactically recognized as numeric values.

Replace the STDOUT section on the ulimit page with:
The standard output shall be used when no newlimit operand is present.

If the -a option is specified, the output written for each resource shall consist of one line that includes:

  • A short phrase identifying the resource (for example "file size").

  • An indication of the units used for the resource.

  • The ulimit option used to specify the resource.

  • The limit value.


The format used within each line is unspecified, except that the format used for the limit value shall be as described below for case where the -a option is not specified.

If the -a option is not specified:

  • If the resource being reported has a numeric limit, the limit value shall be written in the following format:
    "%1d\n", <limit value>
    where <limit value> is the value of the limit in the units specified in OPTIONS.

  • If the resource being reported does not have a numeric limit, in the POSIX locale the following format shall be used:
    "unlimited\n"

Replace the APPLICATION USAGE, EXAMPLES, and RATIONALE sections on the ulimit page with:

APPLICATION USAGE
Since ulimit affects the current shell execution environment, it is always provided as a shell regular built-in. If it is called with an operand in a separate utility execution environment, such as one of the following:
nohup ulimit -f 10000
env ulimit -S -c 10000
it does not affect the limit(s) in the caller's environment.

See also the APPLICATION USAGE for [xref to getrlimit()].

EXAMPLES
Set the hard and soft file size limits to 51200 bytes:
ulimit -f 100

Save and restore a soft resource limit (where X is an option letter specifying a resource):
saved=$(ulimit -X)

...

ulimit -X -S "$saved"

Execute a utility with a CPU limit of 5 minutes (using an asynchronous subshell to ensure the limit is set in a child process):
(ulimit -t 300; exec utility_name </dev/null) &
wait $!

RATIONALE
The ulimit utility has no equivalent of the special values RLIM_SAVED_MAX and RLIM_SAVED_CUR returned by getrlimit(), as ulimit is required to be able to output, and accept as input, all numeric limit values supported by the system.

Add XCU ulimit to the SEE ALSO section on the getrlimit() page.
Notes
(0005110)
geoffclare   
2020-11-09 10:38   
(edited on: 2020-11-24 10:04)
Updated proposal...

Replace the NAME, SYNOPSIS, DESCRIPTION, OPTIONS, and OPERANDS sections on the ulimit page with:

NAME
ulimit -- report or set resource limits

SYNOPSIS
[XSI]ulimit [-H|-S] -a

ulimit [-H|-S] [-cdfnstv] [newlimit][/XSI]

DESCRIPTION
The ulimit utility shall report or set the resource limits in effect in the process in which it is executed.

Soft limits can be changed by a process to any value that is less than or equal to the hard limit. A process can (irreversibly) lower its hard limit to any value that is greater than or equal to the soft limit. Only a process with appropriate privileges can raise a hard limit.

The value unlimited for a resource shall be considered to be larger than any other limit value. When a resource has this limit value, the implementation shall not enforce limits on that resource. In locales other than the POSIX locale, ulimit may support additional non-numeric values with the same meaning as unlimited.

The behavior when resource limits are exceeded shall be as described in the System Interfaces volume of POSIX.1-202x for the setrlimit() function.

OPTIONS
The ulimit utility shall conform to [xref to XBD 12.2], except that:
  • The order in which options other than -H, -S, and -a are specified may be significant.

  • Conforming applications shall specify each option separately; that is, grouping option letters (for example, -fH) need not be recognized by all implementations.

The following options shall be supported:

-H
Report hard limit(s) or set only a hard limit.
-S
Report soft limit(s) or set only a soft limit.
-a
Report the limit value for all of the resources named below and for any implementation-specific additional resources.
-c
Report, or set if the newlimit operand is present, the core image size limit(s) in units of 512 bytes. [RLIMIT_CORE]
-d
Report, or set if the newlimit operand is present, the data segment size limit(s) in units of 1024 bytes. [RLIMIT_DATA]
-f
Report, or set if the newlimit operand is present, the file size limit(s) in units of 512 bytes. [RLIMIT_FSIZE]
-n
Report, or set if the newlimit operand is present, the limit(s) on the number of open file descriptors, given as a number one greater than the maximum value that the system assigns to a newly-created descriptor. [RLIMIT_NOFILE]
-s
Report, or set if the newlimit operand is present, the stack size limit(s) in units of 1024 bytes. [RLIMIT_STACK]
-t
Report, or set if the newlimit operand is present, the per-process CPU time limit(s) in units of seconds. [RLIMIT_CPU]
-v
Report, or set if the newlimit operand is present, the address space size limit(s) in units of 1024 bytes. [RLIMIT_AS]
Where an option description is followed by [RLIMIT_name] it indicates which resource for the getrlimit() and setrlimit() functions, defined in the System Interfaces volume of POSIX.1-202x, the option corresponds to.

If neither the -H nor -S option is specified:

  • If the newlimit operand is present, it shall be used as the new value for both the hard and soft limits.

  • If the newlimit operand is not present, -S shall be the default.

If no options other than -H, -S, or -a are specified, the behavior shall be as if the -f option was (also) specified.

If the newlimit operand is present and more than one option other than -H or -S is specified, the behavior is unspecified.

If any option other than -H or -S is repeated, the behavior is unspecified.

OPERANDS
The following operand shall be supported:

newlimit
Either an integer value to use as the new limit(s) for the specified resource, in the units specified in OPTIONS, or a non-numeric string indicating no limit, as described in the DESCRIPTION section. Numerals in the range 0 to the maximum limit value supported by the implementation for any resource shall be syntactically recognized as numeric values.

Replace the STDOUT section on the ulimit page with:
The standard output shall be used when no newlimit operand is present.

If the -a option is specified, or the -a option is not specified and more than one option other than -H or -S is specified, the output written for each resource shall consist of one line that includes:

  • A short phrase identifying the resource (for example "file size").

  • An indication of the units used for the resource, if the corresponding option description in OPTIONS specifies the units to be used.

  • The ulimit option used to specify the resource.

  • The limit value.

The format used within each line is unspecified, except that the format used for the limit value shall be as described below for the case where a single limit value is written. If -a is not specified and output is written for more than one resource, it is unspecified whether the lines are written in the order that the corresponding options were specified or in the order that the lines would be written for the -a option.

If a single limit value is to be written; that is, the -a option is not specified and at most one option other than -H or -S is specified:

  • If the resource being reported has a numeric limit, the limit value shall be written in the following format:
    "%1d\n", <limit value>
    where <limit value> is the value of the limit in the units specified in OPTIONS.

  • If the resource being reported does not have a numeric limit, in the POSIX locale the following format shall be used:
    "unlimited\n"

Replace the APPLICATION USAGE, EXAMPLES, and RATIONALE sections on the ulimit page with:

APPLICATION USAGE
Since ulimit affects the current shell execution environment, it is always provided as a shell regular built-in. If it is called with an operand in a separate utility execution environment, such as one of the following:
nohup ulimit -f 10000
env ulimit -S -c 10000
it does not affect the limit(s) in the caller's environment.

See also the APPLICATION USAGE for [xref to getrlimit()].

EXAMPLES
Set the hard and soft file size limits to 51200 bytes:
ulimit -f 100

Report the hard limits for file size and core image size (in the verbose format used for -a):
ulimit -H -f -c

Save and restore a soft resource limit (where X is an option letter specifying a resource):
saved=$(ulimit -X)

...

ulimit -X -S "$saved"

Execute a utility with a CPU limit of 5 minutes (using an asynchronous subshell to ensure the limit is set in a child process):
(ulimit -t 300; exec utility_name </dev/null) &
wait $!

RATIONALE
The ulimit utility has no equivalent of the special values RLIM_SAVED_MAX and RLIM_SAVED_CUR returned by getrlimit(), as ulimit is required to be able to output, and accept as input, all numeric limit values supported by the system.

Add XCU ulimit to the SEE ALSO section on the getrlimit() page.

(0005121)
geoffclare   
2020-11-24 10:09   
(edited on: 2020-11-24 10:13)
Following discussions on the mailing list, I have updated Note: 0005110 as follows:

* Applications are required to specify each option separately (as for c99).

* Unspecified behaviour if a resource-selection option is repeated.

* Output lines only need to include the units where the corresponding option description specifies the units to be used.

One issue that remains is whether to keep the current requirement for multiple resource-selection options with no newlimit operand or to make the behaviour unspecified. This needs to be decided in a teleconference.

(0005254)
geoffclare   
2021-03-01 16:41   
(edited on: 2021-03-04 16:17)
Replace the NAME, SYNOPSIS, DESCRIPTION, OPTIONS, and OPERANDS sections on the ulimit page with:

NAME
ulimit -- report or set resource limits

SYNOPSIS
[XSI]ulimit [-H|-S] -a

ulimit [-H|-S] [-c|-d|-f|-n|-s|-t|-v] [newlimit][/XSI]

DESCRIPTION
The ulimit utility shall report or set the resource limits in effect in the process in which it is executed.

Soft limits can be changed by a process to any value that is less than or equal to the hard limit. A process can (irreversibly) lower its hard limit to any value that is greater than or equal to the soft limit. Only a process with appropriate privileges can raise a hard limit.

The value unlimited for a resource shall be considered to be larger than any other limit value. When a resource has this limit value, the implementation shall not enforce limits on that resource. In locales other than the POSIX locale, ulimit may support additional non-numeric values with the same meaning as unlimited.

The behavior when resource limits are exceeded shall be as described in the System Interfaces volume of POSIX.1-202x for the setrlimit() function.

OPTIONS
The ulimit utility shall conform to [xref to XBD 12.2], except that:
  • The order in which options other than -H, -S, and -a are specified may be significant.

  • Conforming applications shall specify each option separately; that is, grouping option letters (for example, -fH) need not be recognized by all implementations.

The following options shall be supported:

-H
Report hard limit(s) or set only a hard limit.
-S
Report soft limit(s) or set only a soft limit.
-a
Report the limit value for all of the resources named below and for any implementation-specific additional resources.
-c
Report, or set if the newlimit operand is present, the core image size limit(s) in units of 512 bytes. [RLIMIT_CORE]
-d
Report, or set if the newlimit operand is present, the data segment size limit(s) in units of 1024 bytes. [RLIMIT_DATA]
-f
Report, or set if the newlimit operand is present, the file size limit(s) in units of 512 bytes. [RLIMIT_FSIZE]
-n
Report, or set if the newlimit operand is present, the limit(s) on the number of open file descriptors, given as a number one greater than the maximum value that the system assigns to a newly-created descriptor. [RLIMIT_NOFILE]
-s
Report, or set if the newlimit operand is present, the stack size limit(s) in units of 1024 bytes. [RLIMIT_STACK]
-t
Report, or set if the newlimit operand is present, the per-process CPU time limit(s) in units of seconds. [RLIMIT_CPU]
-v
Report, or set if the newlimit operand is present, the address space size limit(s) in units of 1024 bytes. [RLIMIT_AS]
Where an option description is followed by [RLIMIT_name] it indicates which resource for the getrlimit() and setrlimit() functions, defined in the System Interfaces volume of POSIX.1-202x, the option corresponds to.

If neither the -H nor -S option is specified:

  • If the newlimit operand is present, it shall be used as the new value for both the hard and soft limits.

  • If the newlimit operand is not present, -S shall be the default.

If no options other than -H or -S are specified, the behavior shall be as if the -f option was (also) specified.

If any option other than -H or -S is repeated, the behavior is unspecified.

OPERANDS
The following operand shall be supported:

newlimit
Either an integer value to use as the new limit(s) for the specified resource, in the units specified in OPTIONS, or a non-numeric string indicating no limit, as described in the DESCRIPTION section. Numerals in the range 0 to the maximum limit value supported by the implementation for any resource shall be syntactically recognized as numeric values.

Replace the STDOUT section on the ulimit page with:
The standard output shall be used when no newlimit operand is present.

If the -a option is specified, the output written for each resource shall consist of one line that includes:

  • A short phrase identifying the resource (for example "file size").

  • An indication of the units used for the resource, if the corresponding option description in OPTIONS specifies the units to be used.

  • The ulimit option used to specify the resource.

  • The limit value.

The format used within each line is unspecified, except that the format used for the limit value shall be as described below for the case where a single limit value is written.

If a single limit value is to be written; that is, the -a option is not specified and at most one option other than -H or -S is specified:

  • If the resource being reported has a numeric limit, the limit value shall be written in the following format:
    "%1d\n", <limit value>
    where <limit value> is the value of the limit in the units specified in OPTIONS.

  • If the resource being reported does not have a numeric limit, in the POSIX locale the following format shall be used:
    "unlimited\n"

Replace the APPLICATION USAGE, EXAMPLES, and RATIONALE sections on the ulimit page with:

APPLICATION USAGE
Since ulimit affects the current shell execution environment, it is always provided as a shell regular built-in. If it is called with an operand in a separate utility execution environment, such as one of the following:
nohup ulimit -f 10000
env ulimit -S -c 10000
it does not affect the limit(s) in the caller's environment.

See also the APPLICATION USAGE for [xref to getrlimit()].

EXAMPLES
Set the hard and soft file size limits to 51200 bytes:
ulimit -f 100

Save and restore a soft resource limit (where X is an option letter specifying a resource):
saved=$(ulimit -X)

...

ulimit -X -S "$saved"

Execute a utility with a CPU limit of 5 minutes (using an asynchronous subshell to ensure the limit is set in a child process):
(ulimit -t 300; exec utility_name </dev/null) &
wait $!

RATIONALE
The ulimit utility has no equivalent of the special values RLIM_SAVED_MAX and RLIM_SAVED_CUR returned by getrlimit(), as ulimit is required to be able to output, and accept as input, all numeric limit values supported by the system.

Implementations differ in their behavior when the -a option is not specified and more than one option other than -H or -S is specified. Some write output for all of the specified resources in the same format as for -a; others write only the value for the last specified option. Both behaviors are allowed by the standard, since the SYNOPSIS lists the options as mutually exclusive.

Add XCU ulimit to the SEE ALSO section on the getrlimit() page.

(0005255)
Don Cragun   
2021-03-04 16:24   
Note: 0005254 was updated to change:
If no options other than -H, -S, or -a are specified, the behavior shall be as if the -f option was (also) specified.
to:
If no options other than -H or -S are specified, the behavior shall be as if the -f option was (also) specified.
(0005286)
geoffclare   
2021-03-19 09:47   
When applying this bug I encountered a minor conflict with bug 0000854, which adds a new first paragraph to the ulimit APPLICATION USAGE. I kept that new paragraph and replaced the rest of APPLICATION USAGE with the content from Note: 0005254.




Viewing Issue Advanced Details
1417 [Issue 8 drafts] Shell and Utilities Editorial Clarification Requested 2020-11-03 17:14 2021-03-12 11:39
joerg
ajosey  
normal  
Applied  
Accepted As Marked  
   
Jörg Schilling
Fraunhofer FOKUS
make
2910
97964
Note: 0005253
Need to make sure that makefiles with += and ?= are portable to all make implementations
In 0000330 we added support for += and ?= but forgot to mention that there need to be a <space> character before *= and ?=.

The background is that some make implementations as an extension support the characters '+' and '?' to appear in macro names and as a result, the parser needs a leading space to properly detect += and ?=.

Note that += is supported (wihth leading space) in SunPro Make since January 1986.
In draft 1.1 on page 2910 after line 97964 add:

Some make implementations (e.g. SunPro Make) support the characters '+' and '?' to appear in macro names and as a result, the parser needs a leading space to properly detect += and ?=. A conforming makefile needs to have a <space> character before += or ?=.
Notes
(0005253)
rhansen   
2021-02-25 17:18   
On page 2895 line 97283 section make (Macros), change:
In all cases the value of string2 is defined as all characters, if any, after the <equals-sign>, up to a comment character ('#') or an unescaped <newline>. Any <blank> characters immediately after the <equals-sign> or immediately before the <plus-sign> shall be ignored.
to:
In all cases the value of string1 is defined as all characters from the first non-<blank> character to the last non-<blank> character, inclusive, before the <tt>=</tt>, <tt>::=</tt>, <tt>?=</tt>, or <tt>+=</tt>. Portable applications shall ensure that a <blank> precedes the <tt>::=</tt>, <tt>?=</tt>, or <tt>+=</tt> in those forms to avoid any parsing ambiguity with implementations that permit <colon>, <question-mark>, or <plus-sign> in macro names as extensions. The value of string2 is defined as all characters from the first non-<blank> character, if any, after the <equals-sign>, up to but not including a comment character ('#') or an unescaped <newline>.

On page 2895 line 97286 section make (Macros) change:
Applications shall select macro names from the set of characters consisting solely of characters from the portable character set (see [xref to XBD 6.1). A macro name shall not contain an <equals-sign>. Implementations may allow other characters in macro names as extensions.
to:
Portable applications shall select macro names from the set of characters consisting solely of characters from the portable filename character set. Implementations may allow other characters in macro names as extensions; however, a macro name shall not contain an <equals-sign>, <blank>, or control character.




Viewing Issue Advanced Details
1416 [1003.1(2016/18)/Issue7+TC2] System Interfaces Editorial Error 2020-11-03 10:45 2021-03-12 11:28
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
getrlimit()
1086
36850-36881
---
Misuses of "may" on the getrlimit() page
The getrlimit() page has some uses of "may" that should be "can" or "shall", as they do not relate to optional behaviour of implementations. (I.e. the word has been used with its informal English-language sense rather than its formal definition in the Terminology section.)

There is some overlap with the bug 0001141 change to the RLIMIT_CORE description, but that is an issue8 tagged bug, and this one should be tagged tc3-2008, so this needs to be retrospectively applied "before" bug 1141.
On page 1086 line 36850 section getrlimit(), change:
Soft limits may be changed by a process to any value that is less than or equal to the hard limit. A process may (irreversibly) lower its hard limit to any value that is greater than or equal to the soft limit.
to:
Soft limits can be changed by a process to any value that is less than or equal to the hard limit. A process can (irreversibly) lower its hard limit to any value that is greater than or equal to the soft limit.

On page 1086 line 36861 section getrlimit(), change:
This is the maximum size of a core file, in bytes, that may be created by a process.
to:
This is the maximum size of a core file, in bytes, that can be created by a process.

(Note to the editor: when merging this with the bug 0001141 change, the end result should be just the change from "may" to "can" in the Issue 8 draft text.)

On page 1086 line 36871 section getrlimit(), change:
This is the maximum size of a file, in bytes, that may be created by a process.
to:
This is the maximum size of a file, in bytes, that can be created by a process.

On page 1086 line 36877 section getrlimit(), change:
This is a number one greater than the maximum value that the system may assign to a newly-created descriptor. If this limit is exceeded, functions that allocate a file descriptor shall fail with errno set to [EMFILE]. This limit constrains the number of file descriptors that a process may allocate.
to:
This is a number one greater than the maximum value that the system shall assign to a newly-created descriptor. If this limit is exceeded, functions that allocate a file descriptor shall fail with errno set to [EMFILE]. This limit constrains the number of file descriptors that a process can allocate.
There are no notes attached to this issue.




Viewing Issue Advanced Details
1414 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Clarification Requested 2020-10-25 17:51 2021-03-12 11:26
kre
 
normal  
Applied  
Accepted As Marked  
   
Robert Elz
XSH 3.rewind
1821 (for info: in 202x d1.1 it is page 1740)
59014 (in 202x d1.1 it is line 57200)
---
See Note: 0005250
rewind() clears the error indicator, but when?
rewind() is defined to be (void) fseek(stream, 0L, SEEK_SET)

(line 90114): except that rewind() shall also clear the error indicator.

That's fine, as it stands, but nothing here says whether the error
indicator is cleared before, or after, the fseek() call (or whatever
equivalent code the implementation uses in its stead).

This matters if the fseek() call sets the error indicator, which it can do.

Now we all know that the error indicator (after a rewind()) is always clear,
so it must be cleared after the fseek() (or equivalent) happens. But what
"we all know" is not in the standard, and should be.
In line 90114 (quoted in the description) insert the word "subsequently"
between the words "also" and "clear" to produce:

   except that rewind() shall also subsequently clear the error indicator.
Notes
(0005064)
geoffclare   
2020-10-26 10:35   
The text in question is derived directly from C99, so we should liaise with the C committee on this issue.
(0005250)
nick   
2021-02-22 16:21   
(edited on: 2021-02-22 16:22)
Proposed wording:
    On page 1821 line 59014 change:
        
except that rewind() shall also clear the error indicator.

to:
    
except rewind() shall also ensure the error indicator is clear when the function returns.






Viewing Issue Advanced Details
1413 [Issue 8 drafts] Shell and Utilities Objection Error 2020-10-24 22:01 2021-03-16 10:01
philip-guenther
 
normal  
Resolution Proposed  
Accepted As Marked  
   
Philip Guenther
OpenBSD
printf's APPLICATION USAGE
3038
102845 - 102848
See Note: 0005248
incorrect description of how a hexadecimal character constant can be terminated in ISO C
The text says:

> In the ISO C standard, the "##" concatenation
> operator can be used to terminate a constant and follow it with a hexadecimal character to be
> written. In the shell, concatenation occurs before the printf utility has a chance to parse the end
> of the hexadecimal constant.

The ## operator is neither necessary nor sufficient. All that's needed is use of string literal concatenation.

Indeed, this was an example in (at least) drafts of the C99 standard, in the specification of string literals lexical elements:

# EXAMPLE This pair of adjacent character string literals
#
# "\x12" "3"
#
# produces a single character string literal containing the two characters whose values are '\x12' and '3',
# because escape sequences are converted into single members of the execution character set just prior to
# adjacent string literal concatenation.
Replace the sentence:
  In the ISO C standard, the "##" concatenation operator can be used to terminate a constant and follow it with a hexadecimal character to be written.

With something like:
  In the ISO C standard, the constant and its following hexadecimal character can be placed in separate string literals as escape sequence processing occurs before string literal concatenation.

(I'm not really happy with that phrasing; better suggestions welcome!)
Notes
(0005248)
nick   
2021-02-18 17:12   
(TC2 page and line numbers) change page 3115 line 104182-104185, after 0000249 is resolved:
        
In the ISO C standard, the "##" concatenation operator can be used to terminate a constant and follow it with a hexadecimal character to be written. In the shell, concatenation occurs before the printf utility has a chance to parse the end of the hexadecimal constant.

to:
      
Note however that a <tt>$'...'</tt> string may be used to embed hexadecimal constants in a format string in a portable way.
(0005274)
mirabilos   
2021-03-15 20:53   
I don’t quite get this. In $'…' strings, \x123 is also unspecified (some current implementations make this into \x23 or even \u0123).

Maybe as $'\x12'3 or, more generally, $'\x12'$'3' … hmm, but that’s not obvious from the wording.
(0005276)
geoffclare   
2021-03-16 10:01   
I see your point. Perhaps it would be better to keep the part about concatenation (with corrected wording) and say that in the shell $'...' can be used in a similar way. Something like:

On 2018 edition page 3115 line 104182-104185, after 0000249 is resolved change:
In the ISO C standard, the "##" concatenation operator can be used to terminate a constant and follow it with a hexadecimal character to be written. In the shell, concatenation occurs before the printf utility has a chance to parse the end of the hexadecimal constant.
to:
In the ISO C standard, string literal concatenation can be used to terminate a constant and follow it with a hexadecimal character to be written. In the shell, similar concatenation can be done using <tt>$'...'</tt> so that the shell converts the hexadecimal sequence before it executes printf.




Viewing Issue Advanced Details
1412 [Online Pubs] Shell and Utilities Editorial Error 2020-10-21 05:50 2021-02-18 16:25
andras_farkas
ajosey  
normal  
Applied  
Accepted  
   
Andras Farkas
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html [^]
pax
Potential missing newline in pax examples section
In the following text on
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html [^]

The following commands:
mkdir newdirpax -rw olddir newdir
copy the olddir directory hierarchy to newdir.

There seems to be a missing newline between newdir and pax.
Fix line to the following:
mkdir newdir
pax -rw olddir newdir
Notes
(0005056)
Don Cragun   
2020-10-21 07:59   
In the PDF for the 2017 edition, the text shown above appears correctly on P3094, L103297-103298
(0005247)
agadmin   
2021-02-18 16:24   
Corrected in the online pubs, and the download bundles have been updated.




Viewing Issue Advanced Details
1411 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Enhancement Request 2020-10-19 22:15 2021-03-08 15:25
rillig
 
normal  
Applied  
Accepted  
   
Roland Illig
here-documents
2362
75375
---
Missing paragraph separator in definition of here-documents
The current text reads:

If the redirection operator is "<<-", all leading <tab> characters shall be stripped from input lines and the line containing the trailing delimiter. If more than one "<<" or "<<-" operator is specified on a line, the here-document associated with the first operator shall be supplied first by the application and shall be read first by the shell.

This looks as if the second sentence would depend on the first sentence, which is not the case. Since these two sentences are completely independent, each sentence should be in a separate paragraph.
Add a paragraph break between the sentences.
There are no notes attached to this issue.




Viewing Issue Advanced Details
1410 [1003.1(2016/18)/Issue7+TC2] System Interfaces Editorial Enhancement Request 2020-10-16 14:56 2021-03-09 09:54
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
asctime(), ctime()
600, 727
20871, 24759
---
Remove asctime_r() and ctime_r()
The obsolescent interfaces removed by bug 0001330 did not include asctime_r() and ctime_r() because they are in the current C2x draft standard. However, in the October 2020 WG14 meeting, the C committee agreed to remove them from C2x, which means we can now go ahead and remove them.

As with the other removals, we don't need to spell out the changes in detail with page and line numbers; the high level instructions in the desired action are sufficient.
Remove the asctime_r() and ctime_r() functions and all references to them (except in change history).
There are no notes attached to this issue.




Viewing Issue Advanced Details
1409 [1003.1(2013)/Issue7+TC1] System Interfaces Editorial Enhancement Request 2020-10-08 16:48 2021-03-08 15:23
alanc
 
normal  
Applied  
Accepted As Marked  
   
Alan Coopersmith
fstatat()
951
32669
---
Note: 0005238
Example code for stat() could use better function name
The example code for stat() currently has:

/* Print out type, permissions, and number of links. */
printf("%10.10s", sperm (statbuf.st_mode));
printf("%4d", statbuf.st_nlink);

It appears that "sperm" is supposed to be a user-provided function to
make a string representing the permission bits of the mode value, but
this isn't clear, and trying to do an internet search for "sperm" to
find if this function exists somewhere is extremely unhelpful.
Use a better function name for the user provided function - perhaps strmode()
that actually exists on some systems, or a clearer made-up-name such as
permission_string() or mode_to_string(). Perhaps update the comment to
note that this is a user-supplied function, not part of the standard.
Notes
(0005039)
geoffclare   
2020-10-09 08:38   
(edited on: 2020-10-09 08:41)
The comment indicates that the type is included, so the new name should include "mode" not "perm". The name strmode() should not be used for a user-supplied function as str[a-z] is a reserved prefix for <string.h>. So I suggest either str_mode() or mode_string().

Also, the %4d is wrong because is assumes nlink_t is int (or promotes to int). That line should change to:
printf(" %4ju", (uintmax_t)statbuf.st_nlink);
The later lines that print st_gid and st_uid have the same problem.

(0005238)
geoffclare   
2021-02-15 16:58   
On C181 (TC2) page 968 lines 32917-32918 change:
printf("%10.10s", sperm (statbuf.st_mode));
printf("%4d", statbuf.st_nlink);
to:
printf("%10.10s", mode_string(statbuf.st_mode));
printf(" %4ju", (uintmax_t)statbuf.st_nlink);


On C181 (TC2) page 968 line 32923 change:
printf(" %-8d", statbuf.st_uid);
to:
printf(" %-8ju", (uintmax_t)statbuf.st_uid);


On C181 (TC2) page 968 line 32928 change:
printf(" %-8d", statbuf.st_gid);
to:
printf(" %-8ju", (uintmax_t)statbuf.st_gid);




Viewing Issue Advanced Details
1408 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Enhancement Request 2020-09-30 20:48 2021-03-08 15:21
steffen
 
normal  
Applied  
Accepted As Marked  
   
steffen
Vol. 3: Shell and Utilities, mailx
2952
97836
---
Note: 0005237
mailx: add mta-bcc-ok internal variable
My mailx clone (will) document(s) it like this:

 mta-bcc-ok
           (Boolean) In violation of RFC 5322 some MTAs do not remove ‘Bcc:’
           header lines from transported messages after having noted the
           respective receivers for addressing purposes. (The MTAs Exim and
           Courier for example require the command line option -t to enforce
           removal.) Setting this variable asserts that the MTA performs
           stripping.
Adapt an internal variable mta-bcc-ok, default unset.
Notes
(0005015)
steffen   
2020-10-01 15:48   
To reiterate what i said on the ML, i think this would be a sensible addition because POSIX mailx allows creation of Bcc: headers via the ~b and ~h command escapes as well as via the askbcc internal variable.
(0005018)
geoffclare   
2020-10-02 13:59   
I'm struggling to understand why any user would want to set this variable. What would they gain from it? Whatever benefit it is, it would need to be weighed against the risk of a Bcc not being stripped if the MTA is later changed (by a system administrator) to one that doesn't strip it. (Or do you expect them to check that the MTA hasn't changed every time they send an email with an embarrassing-if-leaked Bcc?)

As regards adding it to the standard, there is the problem of how would a user decide whether it is safe to set it. We would have to require that the system documentation provides enough information for users to be able to decide. And if the system has multiple MTAs available, the documentation would naturally provide the relevant info for each one, necessitating that the user somehow work out which MTA is installed (or if multiple MTAs are installed, which one mailx will use).
(0005019)
steffen   
2020-10-02 21:51   
But .. first: as of today all mailx codebases known to me (that i looked into the last couple of years) except mine pass the readily prepared message through as-is. This potentially includes Bcc headers if they were generated.

  Remark: it is not only embarrassing-if-leaked, but many people of the free software world work for a very large free mail provider and due to the smartness of their system they easily "detected" that i have created multiple accounts a decade ago, and if suddenly the name of the one account happens to appear as a injection in visible headers of messages sent via another account, then this is not _only_ embarassing, but .. very funny! Heartbleed here.

Of course, "my" MUA has a complete "infrastructure" to allow users to specify the actually used MTA, and in this context the variable as such makes sense.
It would be nice if POSIX would support it, but like i said on the ML

  Important would be an equivalence to or some words about the
  *mta-bcc-ok* setting of my one, since POSIX mailx supports Bcc:
  via ~b, ~h and *askbcc*:

For completeness sake, we support a complete "infrastructure":

     mta Select an alternate Mail-Transfer-Agent by either specifying the
           full pathname of an executable (a ‘file://’ prefix may be given),
           or [Option]ally a SMTP aka SUBMISSION protocol URL:
...lots of text...

     mta-arguments
           Arguments to pass through to a file-based mta[473] (Mail-Transfer-
           Agent), parsed according to Shell-style argument quoting[23] into
           an array of arguments which will be joined onto MTA options from
           other sources, for example ‘? set mta-arguments='-t -X "/tmp/my
           log"'’.

Even if POSIX would offer configuration of the actually used (file-based) MTA, this one here requires a (more or less) complete (and correct) shell-style parser, which is not an easy task.

     mta-no-default-arguments
           (Boolean) Avoids passing standard command line options to a file-
           based mta[473] (please see there).

     mta-no-receiver-arguments
           (Boolean) By default all receiver addresses will be passed as com‐
           mand line options to a file-based mta[473]. Setting this variable
           disables this behaviour to aid those MTAs which employ special
           treatment of such arguments. Doing so can make it necessary to
           pass a -t via mta-arguments[475], to testify the MTA that it should
           use the passed message as a template.

     mta-argv0
           Many systems use a so-called mailwrapper(8)[728] environment to
           ensure compatibility with sendmail(1)[729]. This works by inspect‐
           ing the name that was used to invoke the mail delivery system. If
           this variable is set then the mailwrapper (the program that is
           actually executed when calling the file-based mta[473]) will treat
           its contents as that name.

     mta-bcc-ok
           (Boolean) In violation of RFC 5322 some MTAs do not remove ‘Bcc:’
           header lines from transported messages after having noted the
           respective receivers for addressing purposes. (The MTAs Exim and
           Courier for example require the command line option -t to enforce
           removal.) Setting this variable asserts that the MTA performs
           stripping.

(Maybe i can add a word of description for my MUA here.)
All mailx codebases i know have to duplicate the entire message in order to filter out the Bcc line when passing messages through to the MTA.

It can be made a bit simpler for less feature-rich implementations which do not support signing etc., however, they could just call puthead() without GBCC set,

And it has to be said that many mailx codebases support the internal variable "sendmail" instead of our mta like so

  if ((cp = value("sendmail")) != NOSTR)
    cp = _PATH_SENDMAIL;

(Research Unix v10 uses MAIL as a fallback, which is "/bin/mail".)
(0005020)
steffen   
2020-10-02 21:53   
I said

  It can be made a bit simpler for less feature-rich implementations which do not support signing etc., however, they could just call puthead() without GBCC set,

I have not actually tried it, but .. i think this should do it.
(0005021)
steffen   
2020-10-02 22:14   
(However, for *record* the full message has to be produced...)
(0005024)
geoffclare   
2020-10-05 08:22   
Perhaps the most appropriate solution would be for POSIX simply to state that Bcc is not included in the message that the "mail delivery system" (as it calls the MTA) delivers, and leave how this is achieved up to the implementation.
(0005028)
steffen   
2020-10-05 17:30   
Ok, how about that.

On page 2948, append after line 97657 )

  When the message is typed and the end of the message is encountered, the message shall be passed to the mail delivery software.

)

  The list of blind carbon copy (Bcc) recipients shall not be included as part of the generated message.
(0005029)
steffen   
2020-10-05 17:32   
P.S.: maybe instead "but shall be passed by other means [not covered by this specification]".

P.P.S.: sorry for the false parenthesis.
(0005031)
steffen   
2020-10-05 21:50   
But maybe you are right and this is just beyond the standard, and this issue should be closed as invalid.

It surely is a fault of MTAs aka mail delivery software, unfortunately it is real behaviour of (at least) two widely deployed POSIX/Unix programs around (of the four that i would count as big ones), and this not only affects mailx but also other mail user agents (including the one you, Geoff Clare, use).

Distributions patch(ed) some software to work around this, but applications also get regulary patched/changed to allow dealing with the situation lately.
The behaviour as such is in the world for many years.

Hm.
Maybe instead of the above a word a sentence like

  The mail delivery software shall interpret passed messages according to the rules of RFC 5322.

would be an acceptable way to deal with the situation?
RFC 5322 is very clear (as all standards before were if i recall correctly), and has a discussion in the "Security considerations" section, too:

   Many implementations use the "Bcc:" (blind carbon copy) field,
   described in section 3.6.3, to facilitate sending messages to
   recipients without revealing the addresses of one or more of the
   addressees to the other recipients. Mishandling this use of "Bcc:"
   may disclose confidential information that could eventually lead to
   security problems through knowledge of even the existence of a
   particular mail address.

Good night.
(0005237)
geoffclare   
2021-02-15 16:40   
(edited on: 2021-02-15 16:41)
On page 2943 after line 97448 append the following:
The message shall be passed to the mail delivery software. The mail delivery software shall process passed messages according to the rules of IETF RFC 5322.






Viewing Issue Advanced Details
1407 [Online Pubs] Shell and Utilities Objection Error 2020-09-29 13:17 2020-10-02 10:52
dennisw
 
normal  
Applied  
Accepted  
   
Dennis Wölfing
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/expr.html [^]
expr
HTML edition has expr table in reversed order
In the HTML edition the table in the EXTENDED DESCRIPTION of the expr utility has its cells in the opposite order than the PDF.
Note that the order in the table determines the precedence, so the order matters.
Reverse the order of the table cells so that it matches the PDF.
Notes
(0005017)
agadmin   
2020-10-02 10:52   
The table in extended description has been corrected.




Viewing Issue Advanced Details
1406 [1003.1(2016/18)/Issue7+TC2] System Interfaces Editorial Clarification Requested 2020-09-28 21:26 2021-02-11 18:43
djdelorie
 
normal  
New  
Open  
   
DJ Delorie
Red Hat Inc
open_memstream
https://pubs.opengroup.org/onlinepubs/9699919799/functions/open_memstream.html [^]
n/a
---
clarification of SEEK_END when current pointer doesn't match buffer size
Consider a stream created by open_memstream(), where 16 bytes are written, fseek(0,SEEK_POS) to rewind, then write 4 bytes, and fflush(). At this point, the value pointed to by the sizep argument to open_memstream() should be 4 (please confirm).
At this point in the state of the stream, what are the semantics of SEEK_END? What will be the "file size" if you fclose() at this point?
The example explicitly SEEK_SETs to the buffer size before fclose(), eliding the issue.
Please clarify if SEEK_END is relative to the current position or the current buffer length, and if it's changed by a call to fflush() at that time.
Please clarify if a SEEK_SET to set the current pointer less than the current buffer size, itself (without read/write), changes the SEEK_END semantics, or the value stored in *sizep after fflush().
Notes
(0005011)
carlos   
2020-09-29 17:53   
This isn't an idle request, we are actively trying to harmonize the behaviour of implementations, particularly glibc, musl and FreeBSD to name three. The current wording upstream seems underspecified. At least one Red Hat customer has argued that it should match the behaviour of a normal file-backed stream to avoid confusion. It is clear to me that the intent of open_memstream was *not* to follow the behaviour of file-backed streams because of the special language and programming models that would use the API. Thus this request for guidance and clarification.
(0005012)
Don Cragun   
2020-09-29 20:54   
(edited on: 2020-09-29 20:55)
This bug has been moved from "Base Definitions and Headers" to "System Interfaces".

Noting that the rationale for open_memstream() refers to fmemopen(), I assume that the description of what happens when you use one of the fseek() or fseeko() functions on a memory stream are as described in fmemopen(). Note that in the upcoming revision ot the standard, part of the description of this behavior is changed by the resolution of 0000456.

But, the first paragraph of the description of open_memstream() only says that the stream is opened for writing. It doesn't specify whether it is supposed to use byte mode or text mode (and I believe the mode affects whether of not a NUL byte is written and writing that NUL byte determines whether or not the stream size changes).

(0005013)
djdelorie   
2020-09-29 23:32   
The reference to fmemopen() is noted, but as open_memstream() returns the *current* pointer in *sizep in the example, it clouds the issue of what the "end" of the data is - the API does not give the caller a way to determine the current buffer length if the current pointer is not coincident with it, and the NUL terminator is not specified, so having the "end of file" be somewhere undiscoverable seems problematic.
The example given by the standard explicltly uses ftell/fseek to position the current pointer at the "expected" end of data, implying that that would not otherwise be EOF had this not happened.
It is these differences in spec between open_memstream() and fmemopen() that confuse us, hence our request for clarification.
(0005233)
rhansen   
2021-02-11 17:40   
This was discussed during today's telecon. If I understand correctly, the wording of open_memstream() was originally intended to match glibc's implementation, but it looks like we (the Austin Group) were not successful in crafting wording that unambiguously matches glibc's behavior. We are not very familiar with the various important use cases for this function, so we are not sure what the behavior should be. So, before we can resolve this bug, we need input from the implementors: What do you want the behavior to be?
(0005234)
shware_systems   
2021-02-11 18:43   
It looks to me the intent was that the interface shall track SEEK_END as the size of the buffer, ignoring the appended NUL byte. In the example code, the second seeko() should be equivalent to seeko(stream, 0, SEEK_END).

The wording appears to be as it is for the use case when an application does an initial write, then does a large single realloc() of the buffer in expectation of many more writes not needing to do a realloc per write. In this case an arbitrary seek past SEEK_END is permitted, but should not be reflected in len as current or final position on an immediately following flush or close respectively because nothing has been stored yet. The lesser SEEK_END value is the maximum known length so that gets stored. The parameter name probably should be sizeorposp to better reflect this, not sizep, but I don't see a rewind and rewrite affecting SEEK_END, only writes past the current SEEK_END.




Viewing Issue Advanced Details
1405 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Clarification Requested 2020-09-25 11:12 2021-02-23 15:44
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
mailx
2944-2965
97476-98335
---
mailx header terminology needs to change to match RFC5322
The terminology used in relation to message headers is described in the first paragraph under "Commands in mailx" as follows:
In the following list, header refers to lines from the message header, as shown in the OUTPUT FILES section. Header-line refers to lines within the header that begin with one or more non-white-space characters, immediately followed by a <colon> and white space and continuing until the next line beginning with a non-white-space character or an empty line. Header-field refers to the portion of a header line prior to the first <colon> in that line.

This is confusingly different from the terminology used in RFC5322 (where "header field" means what the above calls "header-line", and "field name" means what the above calls "header-field") and also does not match many of the uses of the terms later in the mailx description. For example the description of the "discard" and "ignore" commands says:
Suppress the specified header fields when writing messages.

By a strict reading, this requires that the part prior to the first <colon> is suppressed, leaving the colon and the remainder of the header-line.

There are also some uses of "headers" where either "header-lines" or "header summaries" is intended, and uses of "line" where "header-line" is intended.

Finally, there is inconsistency as to whether the ":" is included when specifying header fields by name.
Everywhere on the mailx page, change all occurrences of "header-line" to "header field".

On page 2944 line 97476 section mailx (-F option), change:
... found first on the To: line in the mail header.
to:
... found first in the To field in the message header.

On page 2945 line 97536 section mailx (LC_CTYPE), change:
header-field comparisons
to:
header field name comparisons

On page 2946 line 97573 section mailx (LC_CTYPE), change:
screenful of headers
to:
screenful of header summaries

On page 2949 line 97706 section mailx (deleted state), change:
search the subject lines of messages
to:
search the Subject header fields of messages

On page 2950 line 97733 section mailx (/string message specification), change:
All messages with string in the subject line (case ignored).
to:
All messages with string in the Subject header field (case ignored).

On page 2951 line 97779 section mailx (ask variable), change:
Prompt for a subject line on outgoing mail
to:
Prompt for a value for the Subject header field on outgoing mail

On page 2953 line 97862 section mailx (showto variable), change:
write the information from the To: line instead of the From: line in the header summary
to:
write the information from the To field instead of the From field in the header summary

On page 2953 line 97876 section mailx (Commands in mailx), change:
In the following list, header refers to lines from the message header, as shown in the OUTPUT FILES section. Header-line refers to lines within the header that begin with one or more non-white-space characters, immediately followed by a <colon> and white space and continuing until the next line beginning with a non-white-space character or an empty line. Header-field refers to the portion of a header line prior to the first <colon> in that line.
to:
In the following list, header refers to lines from the message header, as shown in the OUTPUT FILES section. Header field refers to a line or set of lines within the header that begins with one or more non-white-space characters immediately followed by a <colon> and white space, and continuing up to and including a <newline> that immediately precedes either the next line beginning with a non-white-space character or an empty line. Field name refers to the portion of a header field prior to the first <colon>.

On page 2955 line 97943,97944 section mailx (discard command), change:
header-field
to:
field-name

On page 2955 line 97945 section mailx (discard command), change:
Suppress the specified header fields when writing messages. Specified header-fields shall be added to the list of suppressed header fields. Examples of header fields to ignore are status and cc. The fields shall be included when the message is saved. The Print and Type commands shall override this command. The comparison of header fields shall be in a case-insensitive manner. If no arguments are specified, write a list of the currently suppressed header fields to standard output; the listing need not reflect the same order of header fields that were entered.
to:
Suppress header fields with the specified field names when writing messages. Specified field-name arguments shall be added to the list of suppressed field names. Examples of field names to ignore are status and cc. The header fields shall be included when the message is saved. The Print and Type commands shall override this command. The comparison of field names shall be performed in a case-insensitive manner. If no arguments are specified, write a list of the currently suppressed field names to standard output; the listing need not reflect the same order of field names that were entered.

On page 2956 line 97999 section mailx (followup command), change:
The subject line shall be taken from the first message
to:
The Subject header field shall be taken from the first message

On page 2957 line 98006 section mailx (headers command), change:
Display Header Summary
to:
Display Header Summaries

On page 2957 line 98008-98011 section mailx (headers command), change three occurrences of "headers" to "header summaries".

On page 2958 line 98062 section mailx (Print command), change:
Display Message with Headers
to:
Display Message with Header

On page 2958 line 98065 section mailx (Print command), change:
Write the specified messages, including all header lines, to standard output. Override suppression of lines by ...
to:
Write the specified messages, including all header fields, to standard output. This command shall override suppression of header fields by ...

On page 2959 line 98085 section mailx (Reply command), change:
The subject line shall be formed by concatenating Re:<space> (unless it already begins with that string) and the subject from the first message.
to:
The value for the Subject header field shall be formed by concatenating Re:<space> (unless it already begins with that string) and the value of the Subject header field from the first message.

On page 2959 line 98093 section mailx (reply command), change:
The subject line shall be formed by concatenating Re:<space> (unless it already begins with that string) and the subject from the message.
to:
The value for the Subject header field shall be formed by concatenating Re:<space> (unless it already begins with that string) and the value of the Subject header field from the message.

On page 2959 line 98099 section mailx (retain command), change:
header-field
to:
field-name

On page 2959 line 98100 section mailx (retain command), change:
Retain the specified header fields when writing messages. This command shall override all discard and ignore commands. The comparison of header fields shall be in a case-insensitive manner. If no arguments are specified, write a list of the currently retained header fields to standard output; the listing need not reflect the same order of header fields that were entered.
to:
Retain header fields with the specified field names when writing messages. This command shall override all discard and ignore commands. The comparison of field names shall be performed in a case-insensitive manner. If no arguments are specified, write a list of the currently retained field names to standard output; the listing need not reflect the same order of field names that were entered.

On page 2961 line 98170 section mailx (z command), change:
The number of headers written
to:
The number of header summaries written

On page 2962 line 98210 section mailx (~f command escape), change:
The specified messages shall be inserted into the current message without alteration. This command escape also shall insert message headers into the message with field selection affected by ...
to:
The specified messages, including their headers, shall be inserted into the current message without alteration. The header fields included in each header shall be affected by ...

On page 2963 line 98214 section mailx (~F command escape), change:
except that all headers shall be included in the message
to:
except that all header fields shall be included in the message headers

On page 2963 line 98217 section mailx (~h command escape), change:
If standard input is a terminal, prompt for a Subject line and the To, Cc, and Bcc lists. Other implementation-defined headers may also be presented for editing. If the field is written with an initial value, it can be edited as if it had just been typed.
to:
If standard input is a terminal, prompt for values for the Subject, To, Cc, and Bcc header fields. Other implementation-defined header fields may also be presented for editing. If the header field is written with an initial value, it can be edited as if it had just been typed.

On page 2963 line 98222 section mailx (~m command escape), change:
Insert the specified messages into the message, prefixing non-empty lines with the string in the indentprefix variable. This command escape also shall insert message headers into the message, with field selection affected by ...
to:
Insert the specified messages, including their headers, into the current message, prefixing non-empty lines with the string in the indentprefix variable. The header fields included in each header shall be affected by ...

On page 2963 line 98226 section mailx (~M command escape), change:
except that all headers shall be included in the message
to:
except that all header fields shall be included in the message headers

On page 2963 line 98241 section mailx (~s command escape), change:
Set the subject line to string.
to:
Set the value for the Subject header field to string.

On page 2964 line 98293 section mailx (APPLICATION USAGE), change:
The retain command discards all header-fields except those explicitly retained. The discard command keeps all header-fields except those explicitly discarded. If headers exist on the retained header list, discard and ignore commands are ignored.
to:
The retain command discards all header fields except those explicitly retained. The discard command keeps all header fields except those explicitly discarded. If field names exist on the retained field names list, discard and ignore commands are ignored.

On page 2965 line 98321 section mailx (RATIONALE), change:
The restriction on a subject line being ...
to:
The restriction on the value for a Subject header field being ...

On page 2965 line 98335 section mailx (RATIONALE), change:
Some headers found in incoming mail
to:
Some header fields found in incoming mail
Notes
(0005006)
kre   
2020-09-28 15:03   
This isn't specifically about the issue (I have no problems with the
proposed changes) but since the paragraphs that relate to the discard/ignore
and retain commands are being rewritten anyway, it might be worth also fixing
them to take one consistent view of what they do.

The most obvious example of the issue is shown above (the discard cmd):

    Suppress header fields with the specified field names when writing
    messages. Specified field-name arguments shall be added to the list of
    suppressed field names. Examples of field names to ignore are status
    and cc. The header fields shall be included when the message is saved.
    The Print and Type commands shall override this command.

If the discard command adds field names to a list, it makes no sense for the
Print and Type commands to override the command (what would that mean
exactly?) What those commands would do is ignore the list, they don't
affect anything related to adding field names to the list (which still exists
unaltered for other commands, even after a Print command has "overridden"
the discard command).

Alternatively, it would be possible to skip the list implementation detail
and simply specify that the commands cause the field names listed to be
ignored when they would otherwise be written by other commands, in which case
the P/T commands can override it (though if going that route, care needs to
be taken to allow the command to be issued multiple times, and that all
of them still apply).

This split personality of how these things work appears all over the place,
including in the relationship with the retain command.

It might also be worth being more precise about what "written" means, I
believe these only apply to messages being displayed on stdout, right?

Just list the commands to which these lists (or commands) apply, and then
the sentence about "The header fields shall be included when the message
is saved." can be deleted, which would be a good thing, as it kind of
suggests that only the fields named in discard commands shall be included
when a message is saved, and that's certainly not what is intended ... but
if that isn't what it means, why the different wording style for saving
messages and the "override" for the P/T commands?

Note: all of this is just about the way the text is written, I don't think
there's any real doubt here as to what is supposed to actually happen.
(0005251)
geoffclare   
2021-02-23 15:44   
When applying this bug I noticed that the section given for page 2946 line 97573 is wrong. It should say "mailx (TERM)" not "mailx (LC_CTYPE)".




Viewing Issue Advanced Details
1404 [1003.1(2016/18)/Issue7+TC2] System Interfaces Editorial Clarification Requested 2020-09-24 00:44 2021-03-08 15:19
dalias
 
normal  
Applied  
Accepted As Marked  
   
Rich Felker
musl libc
pthread_mutex_destroy
(page or range of pages)
(Line or range of lines)
---
Note: 0005232
Is there a requirement to destroy mutex before object lifetime ends?
The specification of pthread_mutex_destroy establishes conditions under which behavior of call to pthread_mutex_destroy is undefined, but does not cover whether there are conditions under which failure to call it is undefined. If the lifetime of a pthread_mutex_t object with automatic or allocated storage duration (or mmap/MAP_ANON) ends (end of execution of block, call to free, munmap, etc.) without a call to pthread_mutex_destroy, is or should the behavior be undefined?

I tend to believe it should be undefined, because the intent of having init/destroy functions seems to be to allow implementation flexibility that would include things like keeping a linked list of all existant objects for error-checking (necessary for diagnostic of double init, etc.), using allocation in pthread_mutex_init (in which failure to call pthread_mutex_destroy is a memory leak, which although not inherently fatal, is bad), and so on.
Possibly add text to description:

"If the lifetime of an initialized pthread_mutex_t object ends without a call to pthread_mutex_destroy, the behavior is undefined."

It's likely that this proposal needs further discussion, particularly for the case of process-shared objects living in MAP_SHARED (and maybe also MAP_ANON) memory where the end of the object lifetime is not well-defined, and where it may be desirable to allow omission of pthread_mutex_destroy because of software that relies on the shared memory ceasing to exist when the last user unmaps it.

If an action is taken on this, similar actions are probably needed for other pthread object types.
Notes
(0005232)
geoffclare   
2021-02-11 16:37   
On page 471 line 16206 section 2.1.1, change:
If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer), the behavior is undefined.
to:
If an argument to a function has an invalid value, such as a value outside the domain of the function, a pointer to an object whose lifetime has ended (even if a new object now has the same address), a pointer outside the address space of the program, or a null pointer, the behavior is undefined.




Viewing Issue Advanced Details
1403 [Online Pubs] System Interfaces Editorial Error 2020-09-20 01:46 2020-09-23 05:32
andras_farkas
 
normal  
Applied  
Accepted  
   
Andras Farkas
https://pubs.opengroup.org/onlinepubs/9699919799/functions/psignal.html [^]
psiginfo
psiginfo page has broken links to siginfo.h header
On
https://pubs.opengroup.org/onlinepubs/9699919799/functions/psignal.html [^]
there are two links to a siginfo.h header in the Rationale section. They don't go to the right location. Most likely, they simply shouldn't be hyperlinks at all
Remove both hyperlinks, or make them point to the right page.
Notes
(0004998)
andras_farkas   
2020-09-20 01:49   
Oops, I linked psignal.html
https://pubs.opengroup.org/onlinepubs/9699919799/functions/psiginfo.html [^]
But it is on psiginfo.html too.
(0005001)
agadmin   
2020-09-23 05:24   
These corrections have been made and the online spec updated including download bundles.




Viewing Issue Advanced Details
1402 [Aardvark Bugs] Aardvark Mk IV Editorial Enhancement Request 2020-09-20 01:42 2021-02-08 16:27
andras_farkas
 
normal  
Applied  
Accepted As Marked  
   
Andras Farkas
No 2018 project for bugs, on Aardvark here
Hi! I've been meaning to mark a new bug. However, when selecting a project here on this website, I can select 2008, 2013, and 2016, but not 2017! (2018?)
This means I can't quite select the most accurate descriptor for what a bug applies to.

My apologies if the project selected (Aardvark Bugs) is incorrect. By the way, the category selections (for aardvark bugs) doesn't contain an Aardvark Mark IV category, only III, and earlier.
Add project for 2018 version of standard into the bug tracker.
Notes
(0004999)
geoffclare   
2020-09-21 08:28   
The 2016 and 2018 editions are both "Issue7+TC2"; they have identical page and line numbers. (The only difference after the frontmatter is that they refer to themselves as POSIX.1-2008 and POSIX.1-2017, respectively).

I have renamed the project so it has "2016/18" instead of "2016" in the name.

The addition of an Aardvark Mark IV category still needs to be done.
(0005042)
geoffclare   
2020-10-09 11:21   
Changing category to (newly created) Aardvark Mk IV.
(0005043)
msbrown   
2020-10-09 21:00   
I can make a new Project if needed, please advise.
(0005044)
shware_systems   
2020-10-09 21:43   
For the odd instance where a report may be filed about the frontmatter, procedurally I think it is better to have separate tags for the editions to handle the different roman numeral page numbers also. Where a tag is relevant to a specific OpenGroup pdf file name for page and line numbers, such as C181 for 2018 edition, that could be incorporated in the name too.
(0005046)
geoffclare   
2020-10-12 08:09   
(edited on: 2020-10-12 08:13)
Re: Note: 0005043 Please don't add a new project. As I said in my first bug note, the 2016 and 2018 editions are both "Issue7+TC2", so having separate projects for them makes no sense. The change I made to the project name is sufficient to solve the problem.

Re: Note: 0005044 Frontmatter bugs are very rare (8 out of over 1400, but none so far against Issue7+TC2), and in any case the frontmatter doesn't have line numbers so submitters have to be more descriptive of where the problem text is. We often have bugs submitted with no page and line numbers and we handle those by setting the fields later. If anyone submits an Issue7+TC2 frontmatter bug, we can easily set the page number to, e.g. "xlv (2016), xl (2018)" if we feel the need.

(0005230)
geoffclare   
2021-02-08 16:27   
Fixes applied as per Note: 0004999




Viewing Issue Advanced Details
1401 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Enhancement Request 2020-09-19 18:35 2021-02-23 15:48
steffen
 
normal  
Applied  
Accepted As Marked  
   
Steffen Nurpmeso
Vol. 3: Shell and Utilities, Issue 7, mailx
2959
98093
---
Note: 0005004
reply command uses obsolete wording
As has come up on the list, the included

  Mail a reply message to all recipients included in the header of the message.

is based upon thirty and more years old code, which also always contradicted the email RFCs, from RFC 822 on.
BSD Mail has been corrected to use RFC 822 compatible handling with

  Author: Craig Leres <leres>
  AuthorDate: 1983-06-05 17:20:23 -0800
  Commit: Craig Leres <leres>
  CommitDate: 1983-06-05 17:20:23 -0800

    Modified to use the "From:" line (if one exists) when replying rather
    than the "From" line (i.e. the first line in the message).

Also the handling of Reply-To: (same standard) has been introduced even earlier (meaning that it replaced all recipients, not only the entries of From:)

  Author: Kurt Shoens <kas>
  AuthorDate: 1981-02-06 09:35:41 -0800
  Commit: Kurt Shoens <kas>
  CommitDate: 1981-02-06 09:35:41 -0800

    Changed reply to send only to reply-to field if such given
On line 98093, change

  Mail a reply message to all recipients included in the header of the message.

to

  Mail a reply message to the sender and all recipients included in the header of the message.
Notes
(0005004)
geoffclare   
2020-09-28 09:28   
(edited on: 2020-10-02 16:07)
The desired action only corrects the additional fourth problem raised on the mailing list after the initial three. Here is a proposal that corrects all four...

On page 2952 line 97834 section mailx (metoo variable), change:
Suppress the deletion of the login name of the user from the recipient list when replying to a message or sending to a group.
to:
Suppress the deletion of the user's login name and any alternative addresses from the recipient list when replying to a message or sending to a group.

On page 2954 line 97918 section mailx (alternates command), change:
(See also the metoo variable.) Declare a list of alternative names for the user's login. When responding to a message, these names shall be removed from the list of recipients for the response. The comparison of names shall be in a case-insensitive manner. With no arguments, alternates shall write the current list of alternative names.
to:
Declare a list of alternative addresses for the address consisting of the user's login name. When responding to a message or sending to a group, if the metoo variable is unset these alternative addresses shall be removed from the list of recipients. The comparison of addresses shall be performed in a case-insensitive manner. With no arguments, alternates shall write the current list of alternative addresses.

On page 2956 line 97996 section mailx (followup command), after applying bug 1405 change:
In the lowercase form, respond to a message, recording the response in a file whose name is derived from the author of the message. See also the save and copy commands and outfolder.

In the capitalized form, respond to the first message in the msglist, sending the message to the author of each message in the msglist. The Subject header field shall be taken from the first message and the response shall be recorded in a file whose name is derived from the author of the first message. See also the Save and Copy commands and outfolder.

Both forms shall override the record variable, if set.
to:
The followup and Followup commands shall be equivalent to reply and Reply, respectively, except that:
  • They shall ignore the record variable.

  • The followup command shall record the response in a file whose name is derived from the author of the message.

  • The Followup command shall record the response in a file whose name is derived from the author of the first message in the msglist.

See also the save and copy commands and outfolder.

On page 2959 line 98082 section mailx, after applying bug 0001405 change:
Reply to a Message List

Synopsis:
R[eply] [msglist]
R[espond] [msglist]
Mail a reply message to the sender of each message in the msglist. The value for the Subject header field shall be formed by concatenating Re:<space> (unless it already begins with that string) and the value of the Subject header field from the first message. If record is set to a filename, the response shall be saved at the end of that file.

See also the flipr variable.

Reply to a Message

Synopsis:
r[eply] [message]
r[espond] [message]
Mail a reply message to all recipients included in the header of the message. The value for the Subject header field shall be formed by concatenating Re:<space> (unless it already begins with that string) and the value of the Subject header field from the message. If record is set to a filename, the response shall be saved at the end of that file.

See also the flipr variable.
to:
Reply to a Message or a Message List

Synopsis:
r[eply] [message]
r[espond] [message]
R[eply] [msglist]
R[espond] [msglist]
Mail a reply message to one or more addresses taken from certain header fields in the specified message or message list. If the flipr variable is unset, these commands shall behave as described below. If the flipr variable is set, commands in the lowercase form shall behave as described below for commands in the capitalized form, and vice versa; the synopsis forms shown above shall also be swapped accordingly.

The recipients of the reply message shall be determined by first constructing an initial list of recipients and then modifying it to form the list that is in effect when mailx enters input mode.

In the capitalized form, the initial list of recipients shall be taken from the header of each message in the msglist as follows:
  • If the header contains a Reply-To field, the address or addresses in that field shall be added to the list.

  • Otherwise, the address or addresses in the From field of the header shall be added to the list.

In the lowercase form, the initial list of recipients shall be taken from the header of the message as follows:
  • If the header does not contain a Reply-To field, all of the addresses in the From, To, and Cc fields shall be included in the list.

  • Otherwise, it is implementation-defined whether all of the addresses in the Reply-To, To, and Cc fields are included in the list or only the address or addresses in the Reply-To field.

The initial list of recipients shall be marked for placement in the header fields of the reply message as follows. Recipient addresses taken from a From or Reply-To header field shall be marked for placement in the To field of the reply message. Recipient addresses taken from a Cc header field shall be marked for placement in the Cc field of the reply message. Recipient addresses taken from a To header field shall be marked for placement in either the To or the Cc field of the reply message. Implementations shall provide a way to place them in the To field. Implementations may, but need not, provide an implementation-defined way to place them in the Cc field.

The modifications applied to the initial list of recipients shall be as follows:
  • If the metoo variable is unset, addresses consisting of the login name of the user and any alternative addresses declared using the alternates command shall be removed from the list.

  • The set of recipients marked for placement in the To header field of the reply message shall have duplicates within that set removed.

  • The set of recipients marked for placement in the Cc header field of the reply message shall have duplicates within that set removed and may have recipients that are also marked for placement in the To field removed.

The values for the To and Cc header fields of the reply message shall be constructed from the addresses in the modified list of recipients that are marked for placement in each of those fields.

The value for the Subject header field of the reply message shall be formed from the value of the Subject header field of the message or the first message in msglist by prefixing it with Re:<space>, unless it already begins with that string.

The values of the To, Cc, and Subject header fields set as described above can be modified by the user after mailx enters input mode through the use of the ~t, ~c, ~s, and ~h command escapes.

If record is set to a pathname, the response shall be saved at the end of that file.


(0005005)
kre   
2020-09-28 14:16   
Re Note: 0005004

I would suggest swapping the order of the "The initial list of recipients"
and "The modifications applied to the initial list" paragraphs, the logical
order is to first collect the addresses, then remove any that should be
removed, and then place them in their appropriate outgoing fields.

To:
    The set of recipients marked for placement in each header field of the reply
    message shall have duplicates removed.

I'd suggest adding
    Where duplicate addresses originated from different header fields in
    the original message(s) retain the copy that originated from any
    Reply-To header field, and if none did, from the From header field,
    and if none, from the To header field, and finally from the Cc
    header field.

That is for the purposes of assigning addresses to outgoing fields, mailx
shouldn't be replying to a message that is
      From: addr1
      To: addr2
      cc: addr1
and constructing a reply with addr1 in the cc field, because that's
where it was seen when the duplicate from the From field was deleted.

Aside from that, this looks fine, though (unrelated to the issue in the
bug report) it might be better to be clearer in the text...

    Mail a reply message to one or more addresses ...

that these commands don't simply mail a reply message, they construct a
template reply message, to which the user is expected to add the actual
reply, and after that's done, they mail the reply message (if it wasn't
aborted). This is hinted at with phrases like "after mailx enters input mode"
but nothing ever says why that would happen, or even that it should.

That should probably be somewhere generic (not part of the R/r command descr)
as it also applies to the "m" and "followup" commands, something perhaps like

     When commanded to mail a message, mailx shall construct a template
     message, and then prompt the user to complete it, by supplying the
     body of the message, and optionally modifying the template header.
     See [xref whatever section] for the commands available in input mode.

It may also be worth considering whether something should also be done with
the "followup" (fo/F) commands akin to what is being done with reply/respond.
(I didn't even know followup existed -- it has been about 40 years since I
last seriously used mailx (then just called Mail)).
(0005007)
steffen   
2020-09-28 20:34   
I do not understand

  Otherwise, it is implementation-defined whether all of the addresses in the Reply-To, To, and Cc fields are included in the list or only the address or addresses in the Reply-To field.

given that already RFC 822 states in 4.4.4 that Reply-To: is meant to replace the content of From:. The examples in A.2 ORIGINATOR ITEMS support this.

It is true this misuse of Reply-To: was advocated and such examples have been seen, i imagined because of missing standardization of the Mail-Followup-To: header which is meant to define an exclusive list of reply addresses, but given that already the email standard RFC 822 from 1982 was clear i would not standardize undefined behaviour in POSIX in 2020.
Software should follow the RFC.

Regarding metoo/alternates i have no time to look the next couple of days.
But it is clear that metoo processing historically _only_ applied to the login name of the user, not to alternates or even full email address matching.
(0005008)
geoffclare   
2020-09-29 10:57   
Re Note: 0005007 As I pointed out in the mailing list discussion, RFC 5322 explicitly states that it does not require any particular behaviour here. It says (in 3.6.3 after it describes how the destination fields should be set when creating a reply):
Note: Some mail applications have automatic reply commands that include the destination addresses of the original message in the destination addresses of the reply. How those reply commands behave is implementation dependent and is beyond the scope of this document. In particular, whether or not to include the original destination addresses when the original message had a "Reply-To:" field is not addressed here.
(0005009)
kre   
2020-09-29 13:52   
Re Note: 0005007 - I agree with Geoff (Note: 0005008) - but aside from that
we should not be legislating here, so regardless of what the RFCs (or any
other standards from any other bodies) say, what this standard should
reflect is what the implementations actually do, unless they are clearly buggy.

For this, it is clear that there are differences in the ways that the
various mailx implementations treat Reply-To ... I wish there weren't
and that everyone used it properly, but they don't, so the standard
cannot pretend that they do.
(0005010)
steffen   
2020-09-29 16:00   
Regarding metoo: neither in BSD Mail nor in Tenth Edition Research Unix is there any relationship in between metoo and alternates. metoo only control elimination of "myself" ($LOGNAME in POSIX) from alias expansions.

Having said that, it is much more useful if metoo is extended and covers the vaporisation of the user including any alternates and expanded aliases!
I think i will implement this when i have time.

Also, undocumented and non-standardized is the convention present in BSD-Mail and Research Unix mailx that a reverse solidus prefix of entries of alias lists prevents further alias expansion. I think i'll add an issue at times.
(0005014)
geoffclare   
2020-10-01 10:44   
I have updated Note: 0005004 to clarify the de-duplication requirement and allow cross-header de-duplication. It seemed simpler to specify this in terms of which outgoing header they are marked for placement in, instead of (as kre suggested) where they came from.




Viewing Issue Advanced Details
1400 [1003.1(2016/18)/Issue7+TC2] System Interfaces Editorial Error 2020-09-17 06:10 2021-02-23 15:35
mkerrisk
 
normal  
Applied  
Accepted  
   
Michael Kerrisk
man7.org
getgroups()
1042
35515
---
Typo in variable name (nogroups ==> ngroups)
In the EXAMPLES section of getgroups(), there is the following:

[[
gid_t *group;
int nogroups;
long ngroups_max;
ngroups_max = sysconf(_SC_NGROUPS_MAX) + 1;
group = (gid_t *)malloc(ngroups_max *sizeof(gid_t));
ngroups = getgroups(ngroups_max, group);
]]

A variable called "nogroups" is declared, but later the variable used in line 35519 is called "ngroups". To fix this (in a way that employs variable names that are also consistent with line 35516), "nogroups" should be changed to "ngroups".

Note that the same issue is present in Issue 8, draft 1, and reported as https://austingroupbugs.net/view.php?id=1399 [^]
 In line 35515, change "nogroups" to "ngroups".
There are no notes attached to this issue.




Viewing Issue Advanced Details
1398 [Issue 8 drafts] System Interfaces Editorial Omission 2020-09-03 15:30 2020-10-08 10:41
nick
 
normal  
Applied  
Accepted  
   
Nick Stoughton
USENIX
nms-missing-redirect
mkostemp
1283
43007
New API mkostemp() needs redirect page
The mkdtemp() function also documents mkostemp() and mkstemp(). The latter of these has a redirect page (page 1294) but the new mkostemp() function, which is alphabetically between mkdtemp() and mkstemp() has none.
Add a new page before page 1294:

NAME
  mkostemp - create a unique file

[CX]
SYNOPSIS
  #include <stdlib.h>
  
  int mkostemp(char *template, int flag);
[/CX]

DESCRIPTION
  Refer to [xref]mkdtemp()[/xref].
There are no notes attached to this issue.




Viewing Issue Advanced Details
1396 [1003.1(2016/18)/Issue7+TC2] System Interfaces Editorial Enhancement Request 2020-08-28 12:24 2021-02-23 15:32
rillig
 
normal  
Applied  
Accepted As Marked  
   
Roland Illig
basename()
625
21595-21596
---
Note: 0004966
Table cells are incorrect
The page for basename contains a table with examples.

The table has a border and separating lines between the cells.
Some of these lines go straight through what should be a single cell.
The headings are split into 4 rows each, but that should be 1 row.
The last example is split over 2 rows.
Does the last example really contain a line break in the pathname?
Fix the formatting of the table.

The marked cell "" should contain the words "empty string" instead, without the quotes, to align with the syntax of the other cells at the right half of the table.
2020-08-28 14_22_07-basename.png (23 KB) 2020-08-28 12:24
Notes
(0004950)
agadmin   
2020-08-28 19:00   
I made layout changes to mirror the pdf version. I think the bug wants further changes. Note the download bundles have not yet been updated.
(0004951)
rillig   
2020-08-28 20:38   
Thank you, that looks much better now.

At the bottom of the table, the example looks as if basename() had to trim spaces. This looks unintended. Furthermore, the space before "test" is missing on the right side, but it is there on the left side.
(0004954)
agadmin   
2020-08-29 07:12   
I'll need some interpretation of what the last line in the table is as its unclear from the document source and pdf output

Is it

"/home/dwc// test"

or

"/home/dwc//
test"

or

"home/dwc//test"
(0004961)
geoffclare   
2020-09-01 08:27   
Column 1 in the last line should contain "home/dwc//test" (same as column 4 except for the quotes).
(0004962)
geoffclare   
2020-09-01 08:27   
I agree with the request in the Desired Action to change «""» to «empty string» but this needs to change in the PDF and therefore can't be handled in the "Online Pubs" project.

I suggest that once the table formatting has been dealt with, we move this bug to the Issue7+TC2 project to address this other change.
(0004964)
agadmin   
2020-09-01 18:39   
I have now updated the table formatting. I have still to update the download bundles
(0004965)
agadmin   
2020-09-02 05:38   
The download bundles have been updated
(0004966)
geoffclare   
2020-09-02 08:53   
I have moved this bug from Online Pubs to Issue7+TC2.

Proposed change ...

On page 625 line 21588 section basename(), change column 4 from:
""
to:
empty string




Viewing Issue Advanced Details
1395 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Error 2020-08-26 14:36 2021-03-25 14:22
geoffclare
 
normal  
Applied  
Accepted As Marked  
   
Geoff Clare
The Open Group
awk
2486
79925-79930
Approved
Note: 0005225
awk radix character in alternative conversion to atof()
In POSIX.2-1992 awk was required to convert string values to numeric values by the equivalent of:
setlocale(LC_NUMERIC, "");
numeric_value = atof(string_value);
Later when atof() was required to support hex floating point, "INF", and "NAN", this was changed to make the support of those new things optional in awk by saying the conversion is done either as above or by an alternative conversion that is a description of how atof() used to work in C90.

At least, that's what was intended. Unfortunately, the description of this alternative conversion refers to <period> instead of the radix character.
On page 2486 line 79925 section awk, change:
... optionally containing a <period>
to:
... optionally containing a radix character

On page 2486 line 79928 section awk, change:
The sequence starting with the first digit or the <period> (whichever occurs first) is interpreted as a floating constant of the C language, and if neither an exponent part nor a <period> appears, a <period> is assumed to follow the last digit in the string.
to:
The sequence starting with the first digit or the radix character (whichever occurs first) is interpreted as a floating constant of the C language, except that the radix character shall be used in place of a <period>, and if neither an exponent part nor a radix character appears, a radix character is assumed to follow the last digit in the string.

Notes
(0004946)
shware_systems   
2020-08-26 15:32   
(edited on: 2020-08-26 15:33)
A floating constant of the C language, as a subset of strings in general, does presume <period> is always the radix character, according to the C grammar. POSIX extending the definition, to allow other chars, it seems should be CX shaded, in interface and utility descriptions, or these be reworded to defer directly to strtod(), which has appropriate text and shading already.

(0005225)
rhansen   
2021-02-04 17:31   
Interpretation response
------------------------
The standard states the requirements for string to number conversion in awk, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor.

Rationale:
-------------
As stated in the RATIONALE the intent was to allow implementations to recognize floating-point constants according to either the ISO/IEC 9899: 1990 standard or ISO/IEC 9899: 1999 standard. The use of <period> in the text was an oversight.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
On page 2486 line 79925 section awk, change:
... optionally containing a <period>
to:
... optionally containing a radix character


On page 2486 line 79928 section awk, change:
The sequence starting with the first digit or the <period> (whichever occurs first) is interpreted as a floating constant of the C language, and if neither an exponent part nor a <period> appears, a <period> is assumed to follow the last digit in the string.
to:
The sequence starting with the first digit or the radix character (whichever occurs first) is interpreted as a floating constant of the C language, except that the radix character shall be used in place of a <period>, and if neither an exponent part nor a radix character appears, a radix character is assumed to follow the last digit in the string.


On page 2487 lines 79966-79967, change:
Each occurrence of the decimal point character from the current locale is changed to a <period>.
to:
Each occurrence of the radix character from the current locale is changed to a <period>.


On page 2507 line 80823, add a sentence:
Note that these forms do not use the radix character from the current locale; they always use a <period>.
(0005240)
agadmin   
2021-02-16 14:36   
Interpretation proposed: 16 Feb 2021
(0005289)
agadmin   
2021-03-19 11:42   
Interpretation approved: 19 March 2021




Viewing Issue Advanced Details
1394 [Issue 8 drafts] System Interfaces Objection Omission 2020-08-26 09:18 2020-10-08 10:39
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
getenv()
1011
34750
Another way the getenv() return string is modifiable
Bug 0000188 added some text that acknowledges the application can modify the string returned by getenv() if it is part of a string previously added to the environment using putenv().

However, applications can also arrange for getenv() to return a known-modifiable string by setting environ to point to a suitable array of strings.
Change:
The application shall ensure that it does not modify the string pointed to by the getenv() function, [XSI]unless it is part of a string previously added to the environment using putenv()[/XSI].
to:
The application shall ensure that it does not modify the string pointed to by the getenv() function, [CX]unless it is part of a modifiable object previously placed in the environment by assigning a new value to environ[/CX] [XSI]or by using putenv()[/XSI].

There are no notes attached to this issue.




Viewing Issue Advanced Details
1393 [Issue 8 drafts] Shell and Utilities Objection Error 2020-08-24 19:15 2020-10-08 10:37
McDutchie
 
normal  
Applied  
Accepted As Marked  
   
Martijn Dekker
https://github.com/ksh93 [^]
XCU 3
2510
82523-82525
Note: 0005003
'command' should not be treated as a declaration utility
The current POSIX draft adds three lines to the specification of the 'command' utility, lines 82523-82525:

| The command utility shall be treated as a declaration utility if the
| first argument passed to the utility is recognized as a declaration
| utility. In this case, subsequent words of the form name=word shall
| be expanded in an assignment context. See Section 2.9.1.1 (on page
| 2292).

(As an aside, if I were to be pedantic, I could argue that the phrasing "if the first argument passed to the utility is recognized as a declaration utility" effectively makes this behaviour unspecified; a 'command' utility implementation could be written not to recognise any utility as such and this phrasing would allow that. I am assuming that this is not the intended meaning.)

This addition effectively makes the 'command' utility into a kind of "Schrödinger's declaration utility" that is simultaneously a declaration utility and not a declaration utility. I think that is a bad idea, for the following three reasons:


***1.*** In the currently published release version of POSIX, 'command' is a regular utility (grammatically no different from, say, 'ls' or 'printf'), and there is nothing that allows regular utilities to treat their arguments specially in a shell grammar sense. So it follows that declaration utility behaviour *must* be disabled along with all other special behaviour by the 'command' utility as specified in the release version.

Consequently, the behaviour specified in the draft is incompatible with the behaviour specified in the current release version, as it is not possible to be simultaneously compliant with both.

(A similar argument could be made for 'export' and 'readonly' themselves, but at least they are already special built-in utilities, so the inconsistently is not so serious.)


***2.*** It does not specify sufficiently widespread current practice. For the following test:

   $shell -c 'v="a y=b"; command export x=$v; echo "[$x] [$y]"'

bash, bosh (Schily), dash < 0.5.11, NetBSD sh, pdksh (including OpenBSD (k)sh), yash, and 'zsh --emulate sh' output:

   [a] [b]

meaning they do *not* treat 'command export' as a declaration utility.

Dash >= 0.5.11, its derivative gwsh, FreeBSD sh, ksh93, and mksh output

   [a y=b] []

meaning they do treat 'command export' as a declaration utility. But together they are not enough to establish a de facto standard behaviour.


***3.*** Since 'command' is specified as a regular utility, both of the following *must* work:

    c='command'; "$c" export foo=bar
    set -- command export; "$@" foo=bar

So, in the draft version, this effectively means that the shell must determine at runtime whether to treat 'command' as a declaration utility, and not at parse time. And that requirement is both innovative and unreasonable.

For the following test:

    $shell -c 'v="a y=b"; set -- command export; "$@" x=$v; echo "[$x] [$y]"'

only dash 0.5.11 and its derivative gwsh currently manage to output '[a y=b] []' meaning they recognise 'command export' as a declaration utility at runtime, and all other shells (except ksh93 which breaks completely[*]) output '[a] [b]' meaning they don't.

[*] ksh93 (which I currently maintain the only actively and openly developed fork of) has a bug that breaks this test case altogether -- the 'export' utility is not run at all; instead, the equivalent of 'command -v export' is run. It would be good if I could implement a clean fix, which would disassociate the 'command' utility from the parser altogether and treat it as a regular built-in utility as currently specified in the release version.
Delete lines 82523-82525.

Alternatively, change these lines to the following:

"If the first argument passed to the command utility is the name of a declaration utility (see Section 2.9.1.1 on page 2292), it is unspecified whether subsequent words of the form name=word are expanded in an assignment context."
Notes
(0004943)
McDutchie   
2020-08-24 19:16   
Argh. Could someone please edit the summary to say "'command' should NOT be treated as a declaration utility"? Thanks and apologies.
(0004944)
Don Cragun   
2020-08-24 23:09   
Re Note: 0004943: Done,
(0004945)
geoffclare   
2020-08-25 08:25   
I have moved this to the Issue 8 drafts project and set the product version to Draft 1.
(0004971)
McDutchie   
2020-09-04 03:53   
I had written: "So, in the draft version, this effectively means that the shell must determine at runtime whether to treat 'command' as a declaration utility, and not at parse time. And that requirement is both innovative and unreasonable."

I'd just like to expound this point a little. On shells where shell assignments allow special grammar like "a=(foo bar)" (which are bash, ksh93, mksh and zsh), the 'command' utility must be integrated into the parser if it is to preserve a declaration command's assignment behaviour including grammatical properties. ksh93 does this; bash, mksh, and zsh do not. So

    command typeset a=(1 2 3)

works on ksh93, but throws a syntax error on the others (zsh attempts and fails to interpret it as some kind of zsh-style pattern).

Of course this can only work on ksh93 because its command builtin is integrated into the parser (in ways that also cause multiple bugs including one serious bug, see footnote above). The assignments are recognised at parse time, not at runtime. If assignments can use special grammar such as parentheses, then it is not feasible or even possible to do this at runtime. Dash manages it because it doesn't support assignments with special syntax.

So, I think ksh93 is a case study on the reasons why it is a bad idea for 'command' to be anything else than a plain old regular builtin utility.
(0004972)
geoffclare   
2020-09-04 09:34   
Re: Note: 0004971 There is no requirement for this to be determined at runtime. The APPLICATION USAGE on page 2513 line 82660 says that the shell need only perform lexical analysis of the next argument when deciding if command should be treated as a declaration utility.

(There is an editorial error here: "command" should be in italics. We should fix that if the text here is otherwise unchanged by this bug.)
(0004973)
joerg   
2020-09-04 11:43   
Re: Note: 0004971

bosh only looks at the flags in it's builtin command data structures if a builtin is a special builtin and in this case does not make variable assignments a push operation that is popped after the builtin command terminated.

My impression is that this best fits to the previous shell behavior.

BTW: is there a list with all ksh93 related problems?
(0005002)
joerg   
2020-09-24 14:55   
It seems that before 0000351 no shell had a special treatment for quoting for the arguments of "export".

So a requirement for this behavior looks like invention.
(0005003)
geoffclare   
2020-09-24 15:55   
On page 2332 line 75618 section 2.14 export (APPLICATION USAGE), add a new paragraph:
In shells that support extended assignment syntax, for example to allow an array to be populated with a single assignment, such extensions can typically only be used in assignments specified as arguments to export if the command word is literally export, and not if it is some other word that expands to export. For example:
# Shells that support array assignment as an extension generally support this:
export x=(1 2 3); echo ${x[0]}  # outputs 1
# But generally do not support this:
e=export; $e x=(1 2 3); echo ${x[0]}  # syntax error

On page 2332 line 75637 section 2.14 export (RATIONALE), add a new paragraph:
Some implementations extend the shell's assignment syntax, for example to allow an array to be populated with a single assignment, and in order for such an extension to be usable in assignments specified as arguments to export these shells have export as a separate token in their grammar. This standard only permits an extension of this nature when the input to the shell would contain a syntax error according to the standard grammar. Note that although export can be a separate token in the shell's grammar, it cannot be a reserved word since export is a candidate for alias substitution whereas reserved words are not (see [xref to 2.3.1]).

On page 2335 line 75721 section 2.14 readonly (APPLICATION USAGE), change:
None.
to:
In shells that support extended assignment syntax, for example to allow an array to be populated with a single assignment, such extensions can typically only be used in assignments specified as arguments to readonly if the command word is literally readonly, and not if it is some other word that expands to readonly. For example:
# Shells that support array assignment as an extension generally support this:
readonly x=(1 2 3); echo ${x[0]}  # outputs 1
# But generally do not support this:
r=readonly; $r x=(1 2 3); echo ${x[0]}  # syntax error

On page 2335 line 75739 section 2.14 readonly (RATIONALE), add a new paragraph:
Some implementations extend the shell's assignment syntax, for example to allow an array to be populated with a single assignment, and in order for such an extension to be usable in assignments specified as arguments to readonly these shells have readonly as a separate token in their grammar. This standard only permits an extension of this nature when the input to the shell would contain a syntax error according to the standard grammar. Note that although readonly can be a separate token in the shell's grammar, it cannot be a reserved word since readonly is a candidate for alias substitution whereas reserved words are not (see [xref to 2.3.1]).

On page 2514 line 82700 section command (RATIONALE), change:
... or that prevents function lookup on b or c.
to:
... or that prevents function lookup on b or c. However, some implementations extend the shell's assignment syntax, for example to allow an array to be populated with a single assignment, and in order for such an extension to be usable in assignments specified as arguments to export and readonly these shells have those utility names as separate tokens in their grammar. When command is used to execute these utilities it also needs to be a separate token in the grammar so that the same extended assignment syntax can still be recognized in this case. This standard only permits an extension of this nature when the input to the shell would contain a syntax error according to the standard grammar, and therefore it cannot affect how '|' and ';' are parsed in the example above. Note that although command can be a separate token in the shell's grammar, it cannot be a reserved word since command is a candidate for alias substitution whereas reserved words are not (see [xref to 2.3.1]).




Viewing Issue Advanced Details
1392 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Clarification Requested 2020-08-14 12:55 2021-03-25 14:19
mohd_akram
 
normal  
Applied  
Accepted As Marked  
   
Mohamed Akram
find
2797
91951-91956
Approved
Note: 0005224
find(1): clarify whether -perm ops - and + should follow chmod
Currently, BSD/macOS find(1) behave like chmod when it comes to the - and + operators of -perm:

$ umask
0022
$ touch file
$ chmod +w file
$ find file -perm -+w
file

GNU find behaves differently (https://savannah.gnu.org/bugs/?58654): [^]

$ umask
0002
$ touch file
$ chmod +w
$ find file -perm -+w

GNU find treats = and + as equivalent, while BSD find doesn't (which is IMO more useful).
Clarify the behavior of find(1) -perm with respect to the - and + operators.
Notes
(0004925)
joerg   
2020-08-15 11:15   
My interpretation of the standard matches the one from BSD even though that differs from Solaris. But Solaris uses the man page text from POSIX....

BTW: libfind behaves the same as BSD with this detail.

Given that the standard mentions the mask, I believe it is exact enough.
(0004926)
geoffclare   
2020-08-19 09:22   
> Given that the standard mentions the mask, I believe it is exact enough.

I disagree. It only mentions the mask in the statement about '=':
'=' shall set the appropriate mode bits, without regard to the contents of the file mode creation mask of the process.
It does not mention the mask in the statements about '+' and '-', therefore it is implicitly unspecified whether the mask is used for those.

I think we should issue a "standard is silent" interpretation, thus allowing both behaviours for Issue 7, but we should make a change in Issue 8 to require the BSD behaviour.
(0004929)
joerg   
2020-08-19 10:32   
Given that the find man page points to chmod(1) and that it explicitly mentions '=' to differ somehow from '+', I see this as a hint that -perm must behave similar to chmod(1) which includes the file creation mask.

BTW: When I wrote my parser in July 2004 for libfind, I did not check existing find implementations but only the POSIX standard. The background for writing libfindhas been the missing usability of gfind and find from Solaris at that time. So the behavior of libfind is just a consequence of following the standard and what is expected for orthogonal behavior.

Regardless of the way you interpret this, we seem to basically agree that the libfind/BSD behavior is the right way to go for the future.

P.S. The Solaris implementation behaves the same as gfind for this detail, but I am happy to change this.
(0004930)
geoffclare   
2020-08-19 11:32   
(edited on: 2020-08-19 11:34)
Re: Note: 0004929

1. The find man page only points to chmod for the "format" of the mode operand, i.e. the syntax not the semantics.

2. '=' and '+' do indeed differ, but only in that '=' is required to ignore the mask whereas '+' can either use it or ignore it.

3. I'm not sure there is even a hint here; readers not sufficiently familiar with standardese might think so, but those experienced in interpreting the standard should see that there is nothing at all said about the mask in relation to '+'. Anyway, a "hint" is not a requirement.

(0004941)
mohd_akram   
2020-08-21 16:47   
(edited on: 2020-08-21 16:53)
I think the title I put should be tweaked - the issue is actually + and = (- seems to behave the same due to the 000 starting point). I had posted the = example in the filed GNU bug but forgot about it - hopefully this link will work: https://savannah.gnu.org/bugs/?58654 [^]

On macOS:

$ chmod =w file
$ find file -perm =w
file

On Fedora:

$ chmod =w file
$ find file -perm =w

It seems that macOS does not ignore the mask even with =, mimicking chmod's behavior. It feels like it would be simpler to defer to chmod in both syntax and semantics because the "symbolic_mode" operand is fairly complicated. This could entail removing the "without regard to the contents of the file mode creation mask of the process" clause (letting "appropriate" do all the heavy-lifting instead) and adding at the end that it is "implementation-defined whether + and = ignore the file mode creation mask when `who` is not specified".

(0004942)
shware_systems   
2020-08-21 17:12   
Yes, link works this time :-)
(0005224)
rhansen   
2021-02-01 17:01   
(edited on: 2021-02-04 16:30)
Interpretation response
------------------------

The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.

Rationale:
-------------
None.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------

On page 2797 lines 91951-91959 change:
The mode argument is used to represent file mode bits. It shall be identical in format to the symbolic_mode operand described in chmod, and shall be interpreted as follows. To start, a template shall be assumed with all file mode bits cleared. An op symbol of <tt>'+'</tt> shall set the appropriate mode bits in the template; <tt>'−'</tt> shall clear the appropriate bits; <tt>'='</tt> shall set the appropriate mode bits, without regard to the contents of the file mode creation mask of the process. The op symbol of <tt>'−'</tt> cannot be the first character of mode; this avoids ambiguity with the optional leading <hyphen-minus>. Since the initial mode is all bits off, there are not any symbolic modes that need to use <tt>'−'</tt> as the first character.
to:
The mode argument is used to represent file mode bits. It shall be processed in an identical matter to the symbolic_mode operand described in chmod, except that:
  1. The changes to file mode bits shall be applied to a template instead of to any files. The template shall initially have all file mode bits cleared.
  2. The op symbol <tt>'-'</tt> cannot be the first character of mode; this avoids ambiguity with the optional leading <hyphen-minus>. Since the initial mode is all bits off, there are not any symbolic modes that need to use <tt>'-'</tt> as the first character.


On page 2801 lines 92128-92130 (find example #3), change:
find . −perm −o+w,+s
prints (−print is assumed) the names of all files in or below the current directory, with all of the file permission bits S_ISUID, S_ISGID, and S_IWOTH set.
to:
find . −perm −o+w,+s
prints (−print is assumed) the names of all files in or below the current directory, with all of the file permission bits S_ISUID, S_ISGID, and S_IWOTH set, regardless of the value of the file creation mask. (Note that the file creation mask is only specified for the file permission bits, and not S_ISUID, S_ISGID or S_ISVTX.)


On page 2801 after line 92130 insert a new example #4 and renumber the remaining examples:
The following command:
find . −perm −+w
prints (−print is assumed) the names of all files in or below the current directory, with S_IWUSR set if the file creation mask does not have S_IWUSR set (otherwise the S_IWUSR bit is ignored), S_IWGRP set if the file creation mask does not have S_IWGRP set (otherwise S_IWGRP is ignored), and S_IWOTH set if the file creation mask does not have S_IWOTH set (otherwise S_IWOTH is ignored).


(0005239)
agadmin   
2021-02-16 14:36   
Interpretation proposed: 16 Feb 2021
(0005290)
agadmin   
2021-03-19 11:42   
Interpretation approved: 19 March 2021
(0005300)
geoffclare   
2021-03-25 14:19   
When applying this bug I corrected a typographic error in the new text: "in an identical matter" should be "in an identical manner".




Viewing Issue Advanced Details
1391 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Error 2020-08-13 19:58 2021-02-12 16:40
kre
 
normal  
Applied  
Accepted As Marked  
   
Robert Elz
2.9.1.1 1.c (2.9.1.4 1.c in Issue 8 draft 1)
2367 (2294 in Issue 8 draft 1)
75564-7 (74159-62 in Issue 8 draft 1)
---
Note: 0004922
Unclear language in specification of utilities implemented as functions
I do not believe there is likely to be any disagreement over what
should be done here, though there may be some over whether the
current language is unclear. My opinion on that is that if anyone
can reasonably read the text in a way different from what is intended,
and if it is easily possible to correct the text to improve clarity,
then that should always be done.

Anyway, 2.9.1.1 1.c (unchanged in Issue 8, other than the section number)
states
If the command name matches the name of a function known to
this shell, the function shall be invoked as described in Section 2.9.5.
If the implementation has provided a standard utility in the form of a
function, it shall not be recognized at this point. It shall be invoked
in conjunction with the path search in step 1e.


While this is somewhat fanciful, as to the best of my knowledge, no
shell implements any standard utilities as functions, the issue is
if the shell did implement some standard utility as a function (something
like dirname might be a possibility) and the user (application) has
also defined a function of the same name (overriding the implementation
provided definition), what should happen.

My expectation is that the "If the implementation has provided a standard
utility in the form of a function, it shall not be recognized at this point."
text means that the standard utility, implemented as a function, should
not be recognised, but that a user defined function of the same name still
should be.

However, it is not unreasonable to read it as prohibiting (at this point)
invoking any function with the same name as that of a standard utility
implemented as a function ("it shall not be recognized at this point",
is the antecedent of "it" the "command name" or the "standard utility
implemented as a function". While the latter is almost certainly what
was intended, either is actually a justifiable reading of the text.

This becomes problematic, as if a user defined function is not
invoked in 2.9.1.1 1.c then it never is, as 2.9.1.1 1.e.i only allows
for two cases, a where "If the system has implemented the utility as a
built-in or as a shell function, ..." or b "Otherwise, the shell executes
the utility in a separate utility environment" (the text here has altered
in Issue 8 draft 1, but the effect is the same). Neither of those
allow invoking a user defined function. Further, it would be strange
if any user defined function (regardless of its name) depended upon a
successful PATH search before it could be invoked.

Clarifying the language of 2.9.1.1 1.c will avoid this problem.

Note that if the resolution of 0001389 is to accept the proposed
text, or something substantially similar, then this issue becomes
moot, as all references to standard utilities implemented as
functions will have been removed, leaving 2.9.1.1 1.c simply
specifying the invocation of a function.

It should also be noted, that while the standard attempts to
specify what should be done with standard utilities implemented
as functions, it is not actually documenting any known standard
behaviour there, as there are no known (to me anyway) instances
of standard utilities implemented as functions. Rather than
documenting the standard behaviour, what happened is an attempt to
specify how such things should behave, if any ever were to exist.
That's not the standard, that's a flight of fancy.
Option 1.

In section 2.9.1.1 1.c (2.9.1.4 1.c in Issue 8 draft 1) delete
all after the first sentence. That is retain

If the command name matches the name of a function known to
this shell, the function shall be invoked as described in Section 2.9.5.

and delete the rest, viz:

If the implementation has provided a standard utility in the form of a function,
it shall not be recognized at this point. It shall be invoked in conjunction
with the path search in step 1e.

It would also probably make sense to delete the reference to standard
utilities implemented as functions from 2.9.1.1 1.e but that is not
essential for the purposes of this issue.

This option recognises that absent implementation, it is premature to
standardise the behaviour of standard utilities implemented as functions,
as no-one has any idea what that behaviour would be.

Option 2:

In 2.9.1.1 1.c change the words:
it shall not be recognized at this point.
to:
that standard utility shall not be recognized at this
point, whereas an application defined function of the same name is.


Also be change the word
It

in the following sentence (line 75567) into
Standard utilities implemented as functions
.

I recommend option 1.
Notes
(0004922)
geoffclare   
2020-08-14 09:21   
(edited on: 2020-08-14 09:24)
I think there is a misunderstanding here of what "If the implementation has provided a standard utility in the form of a function" means. The description talks about "if the shell did implement some standard utility as a function" which has implications that are not quite the same.

I believe the thinking behind "the implementation has provided a standard utility in the form of a function" is that an implementation could define a function in an implementation-provided shell startup file. Some implementations do this with aliases (such as the misguided alias rm='rm -i'); the standard allows a similar thing with functions. I suppose a function could also be predefined internally by the shell itself. However, the crucial thing is that it is just a function definition like any other; it is not special (other than being already defined by the time the shell reads commands from the user/script, and the requirement about when it is recognised). So if the application defines a function of the same name, it simply replaces the one provided by the implementation. The application could also delete the function using "unset -f".

I think a suitable change to clarify this would be to change:
If the implementation has provided a standard utility in the form of a function, it shall not be recognized at this point.
to:
If the implementation has provided a standard utility in the form of a function, and that function definition still exists (i.e. has not been removed using unset -f or replaced via another function definition with the same name), it shall not be recognized at this point.






Viewing Issue Advanced Details
1388 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Omission 2020-08-11 14:17 2021-02-12 16:47
geoffclare
 
normal  
Applied  
Accepted As Marked  
   
Geoff Clare
The Open Group
yacc
3456
116732
---
Note: 0005220
yacc description does not say who declares yyerror() and yylex()
The description of yacc talks about the functions yyerror() and yylex() in various places, but nowhere does it state who is responsible for declaring them. This means that, in practice, a portable application has to declare them in the .y file (if it does not define them) in case yacc does not provide declarations of them in the code file and the compiler that will be used treats calls to undeclared functions as an error.

It doesn't take much thought about the reasons why prototypes were added to the C language to come to the conclusion that the greatly preferable solution is for yacc to be required to supply prototypes for yyerror() and yylex() that match the yyerror() definition in its library and the yylex() definition produced by lex, even (some might say especially) if the .y file includes definitions of those functions to be used instead of the library version of yyerror() and a lex-generated yylex().

There is also no statement about a declaration of main(), but the situation for main() is quite different from the above two functions. Although in theory an application could call yacc's library version of main() from code in a .y file, it is questionable why any application (other than a test suite) would do so, in particular because that version of main() does not accept any arguments and it calls exit() -- it does not return -- and therefore is of little use recursively. An application that provides its own main() could call it recursively, but can reasonably be expected to ensure it does not call main() without previously defining or declaring it. In addition, since main() has multiple different allowed prototypes, if yacc were to output a declaration it would have to be a non-prototype one:

int main();

so that there is no risk of a clash with a definition of main() that has a different prototype, but there does not seem much point in it producing such a declaration. (Or it could check whether the .y file contains a definition of main() and output a prototype declaration if it does not contain one, but that seems impractical.)

The simplest solution is just not to allow yacc to provide a declaration of main().
On page 3456 line 116732 section yacc (Code File), change:
It also shall contain a copy of the #define statements in the header file.
to:
It also shall contain prototype declarations of the yyerror() and yylex() functions, and a copy of the #define statements in the header file, prior to any code copied from within <tt>%{</tt> and <tt>%}</tt> in the declarations section in grammar.

On page 3456 line 116734 section yacc (Code File), add a new paragraph:
The code file shall not contain a declaration of the main() function, unless one is present within <tt>%{</tt> and <tt>%}</tt> in the declarations section in grammar.

On page 3469 line 117335 section yacc (RATIONALE), add new paragraphs:
Earlier versions of this standard did not require the code file created by yacc to contain declarations of yyerror() and yylex(). This meant that portable applications that did not define them had to declare them in the grammar file, to ensure they would not be diagnosed by the compiler as being called without being declared, but this was not stated in those versions of the standard either. The standard developers decided it was preferable for yacc to include the declarations in the code file and this is now a requirement.

Earlier versions of this standard were also silent about a declaration of main(). However, the equivalent solution was not adopted since a declaration of main() would only be needed if it is called recursively by an application. Although in theory an application could call the yacc library version of main() from code in a grammar file, it is questionable why any application (other than a test suite) would do so, in particular because that version of main() does not accept any arguments and it calls exit() -- it does not return -- and therefore is of little use recursively. An application that includes its own definition of main() could call it recursively, but can reasonably be expected to ensure it does not call main() without previously defining or declaring it. An additional complication is that main() has multiple different allowed prototypes. The standard developers decided the simplest solution was not to allow yacc to provide a declaration of main() in the code file.

Notes
(0004919)
shware_systems   
2020-08-11 16:53   
A collateral issue is ensuring yyin is declared as a FILE *, if yyparse() is linked to a yylex() generated by lex, in a manner accessible to code calling yyparse(). This adds an implied requirement on the .c or .h file produced to do a #include <stdio.h> to get the defining declaration of FILE.

The example main() for lex assumes such a declaration of yyin is produced at the top or bottom of the %% section, but there is no requirement this be an extern the header produced by yacc could reference. The lex description just has it shall be used, nothing on how it is to be declared, actually. The main() example for yacc doesn't declare or assign stdin to it either, assuming yylex() does this by default somehow on first call if generated by lex, or accesses stdin directly in a yylex() implemented in the programs section of the .y file.

Maybe this has been addressed as part of some other bug, but I don't remember any such discussion offhand.
(0004928)
Konrad_Schwarz   
2020-08-19 10:08   
Aren't default implementations of these symbols defined in the -ly library?
(0004931)
shware_systems   
2020-08-19 16:42   
(edited on: 2020-08-19 16:44)
Yes, but when a compiler requires the absence of any main() to be found to format an a.out as a dynamic library, rather than a utility executable, the use of liby and libl is precluded so the compile doesn't see the main() in those libraries. As such, the output of yacc or lex needs to be compile-able in a manner that doesn't require any library to provide those prototypes implicitly.

(0005205)
rhansen   
2021-01-21 17:17   
On page 3456 line 116732 section yacc (Code File), change:
It also shall contain a copy of the #define statements in the header file.
to:
It also shall contain function prototypes for the yyerror(), yylex(), and yyparse() functions, and a copy of the #define statements in the header file, prior to any code copied from within <tt>%{</tt> and <tt>%}</tt> in the declarations section in grammar.


On page 3456 line 116734 section yacc (Code File), add a new paragraph:
The code file shall not contain a declaration of the main() function, unless one is present within <tt>%{</tt> and <tt>%}</tt> in the declarations section in grammar.


On page 3469 line 117335 section yacc (RATIONALE), add new paragraphs:
Earlier versions of this standard did not require the code file created by yacc to contain declarations of yyerror(), yylex(), and yyparse(). This meant that portable applications that did not define them had to declare them in the grammar file, to ensure they would not be diagnosed by the compiler as being called without being declared, but this was not stated in those versions of the standard either. The standard developers decided it was preferable for yacc to include the declarations in the code file and this is now a requirement.

Earlier versions of this standard were also silent about a declaration of main(). However, the equivalent solution was not adopted because a declaration of main() would only be needed if it is called recursively by an application. Although in theory an application could call the yacc library version of main() from code in a grammar file, it is questionable why any application (other than a test suite) would do so, in particular because that version of main() does not accept any arguments and it calls exit()—it does not return—and therefore is of little use recursively. An application that includes its own definition of main() could call it recursively, but can reasonably be expected to ensure it does not call main() without previously defining or declaring it. An additional complication is that main() has multiple different allowed prototypes. The standard developers decided the simplest solution was to disallow yacc from providing a declaration of main() in the code file.
(0005206)
nick   
2021-01-21 21:17   
From Akim Demaille (maintainer of GNU Bison):


I agree that yyparse should be part of the declarations in the header
file (or in the implementation file if there is no header).

However I dislike that yylex and yyerror be prototyped. We don't do
it in Bison because:

- the user might decide that yylex be static, and it's actually not
  unfrequent that it is. The user might want yylex to return an enum
  of the valid expected tokens. The parser itself simply does not
  care, and forcing a prototype onto the user will just be more
  constraints for her. She might even have played with #define
  yylex() to pass additional arguments, or re#defined yylex to foolex,
  etc.

  In my humble opinion the parser is merely a consumer of
  yylex, it is not the provider. It is up to the provider to provide
  the prototype. For instance *lex* should be in charge of declaring
  yylex, not Yacc.

- the user provides her yyerror and she is perfectly welcome to
  make it a variadic function that starts with a format string,
  instead of a plain string. The parser itself only calls this
  function with a single argument, but what if the user wanted
  something more generic for some other calls to yyerror that she
  wrote herself.

  Granted, there is something dangerous here if the parser was to
  pass a message with percent-signs in it. But Yacc does not
  issue such messages.

  Again, Yacc does not provide this function, it *requires* it.
  So I disagree that Yacc should provide the prototype.

Pushing prototypes onto the user restricts her freedom. Her
freedom to make things static, her freedom to use attributes
to defeat warnings about ignored arguments, her freedom to
simply comply with a contract the way she wants. Call it
duck-typing if you want, but my opinion is that the contract
between the user and yyparse is much weaker than what a
prototype would actually enforce.

(Not to mention things that are outside the scope of Yacc,
such as passing additional arguments to yylex to avoid, for
instance, the use of globals for semantic values. But yes,
this out of the scope of Yacc.)


Note that since people are currently providing the prototypes
themselves, there's a good chance that the ones provided by
new Yaccs might be incompatible. There will be backward
compatibility issues. And portability issues when from one
machine to another you get–or don't get–the prototype,
because of varying versions of Yacc.



The routines provided in the library are merely an instance of
the set of possibles. And to be clear, I think -ly is vastly
useless. It is simply not worth the trouble to have to find a
library for main and yyerror. Someone who is ready to
spend time learning Yacc to generate a parser for a grammar is
certainly competent enough to write main and yyerror.


I also see references to yyin. I'm not sure I understand
exactly what is suggested, but yyin is out of scope. Yacc
does not care about yyin at all. yyparse knows nothing
about chars, it only knows about tokens. People routinely
make parser of strings, not just FILE*. yyin is irrelevant
to Yacc and should not be referred to in Yacc's specifications.
(0005207)
dickey   
2021-01-21 22:17   
Without a prototype, a C compiler cannot provide useful diagnostics when the number or type of parameters differs from what yacc requires.

Deciding whether to require that a prototype be static or extern is outside the scope of this question, because it's possible to provide prototyping information conditionally, e.g., by a macro which defines the return type and parameters. This is an example of what has been defined by Berkeley yacc starting in 2010:

/* Parameters sent to lex. */
#ifdef YYLEX_PARAM
# define YYLEX_DECL() yylex(void *YYLEX_PARAM)
# define YYLEX yylex(YYLEX_PARAM)
#else
# define YYLEX_DECL() yylex(void)
# define YYLEX yylex()
#endif

/* Parameters sent to yyerror. */
#ifndef YYERROR_DECL
#define YYERROR_DECL() yyerror(const char *s)
#endif
#ifndef YYERROR_CALL
#define YYERROR_CALL(msg) yyerror(msg)
#endif

Those are generated, and for some non-yacc features the macros differ, but provide an application developer with a way to refer to yylex and yyerror consistently with the parser's assumptions.
(0005208)
eggert   
2021-01-22 23:04   
Akim's points are persuasive. Bison formerly used Berkeley yacc-style YYLEX_PARAM etc. but this feature was awkward and was withdrawn in Bison 3.0 (2013) in favor of GNU extensions like %lex-param that are cleaner and more general. If POSIX were to standardize in this area, %lex-param would be a good thing to look at as part of a separate bug report.

In the meantime, the original proposal goes too far in that it prohibits users from declaring yylex and yyparse with APIs that work just fine even if they don't exactly match the yacc default. Instead, I suggest modifying the standard only to require a yyparse() prototype in the header and code files (which is fine as yacc generates the yyparse code, so it specifies yyparse's API), and to document existing practice for yylex and yyerror.

A proposed change follows. I don't have the PDF so page and line numbers are approximate.

-----

 On page 3456 line 116732 section yacc (Code File), change:

    It also shall contain a copy of the #define statements in the header file.

to:

    It also shall contain a copy of the #define statements and yyparse() declaration in the header file, prior to any code copied from within <tt>%{</tt> and <tt>%}</tt> in the declarations section in grammar.

 On page 345? line 116??? section yacc (Header File), add a new sentence:

    The header file shall also declare the yyparse() function, using a function prototype.

 On page 3456 line 116734 section yacc (Code File), add a new paragraph:

    The code file shall not contain a declaration of the main(), yyerror() or yylex() functions, unless such a declaration is present within the declarations or programs section.

On page 3469 line 117335 section yacc (RATIONALE), add new paragraphs:

    Because the code and header files do not declare the yyerror() or yylex() functions, a portable application should declare these functions in the declarations section, as these two functions are typically supplied by the application and it is the application's responsibility to declare them. The current standard follows historical practice in requiring the application to declare these functions even in the rare case where an application uses the yacc library.

    Earlier versions of this standard did not require the code or header file created by yacc to declare yyparse(), which meant that portable applications had to declare yyparse() themselves. The current standard lets applications declare yyparse() by including the header file.
(0005210)
geoffclare   
2021-01-26 10:55   
There are existing implementations that include declarations for yyerror() and yylex() in the code file. The ones we know about are Solaris and its derivatives (Illumos, etc.), but it may be all SVR4-derived implementations. This means that:

1. Forbidding these declarations in Issue 8, as suggested by Paul Eggert in Note: 0005208, is not a viable solution as it would make these implementations non-conforming.

2. Applications that include their own declaration of yyerror() or yylex() with a different prototype are already non-portable (unless they also define a macro of the same name - see below).

In yesterday's teleconference it was pointed out that Solaris protects these declarations with #ifndef to avoid a clash with any prior macro definition. This could provide the key to a compromise solution. If we require the declarations in Issue 8 but also require them to be protected so that they are not visible if a macro exists, then applications that include their own declaration of yyerror() or yylex() with a different prototype would just need to arrange for a macro of the same name to be defined in order to be portable to Issue 8 systems. This could be done by putting, e.g.
#define yylex yylex
in the declaration section or by adding -Dyylex=yylex to the compiler options used to compile y.tab.c. It could even be done just in the configuration step for such systems by adding the -D to the configured compiler options.

Of course the Bison maintainers could, if they wish, choose to have it write the yyerror() and yylex() declarations only if it is invoked by the yacc wrapper script (or with the option(s) passed by that script), or only if POSIXLY_CORRECT is set in the environment, in order to reduce the number of applications that need to do this.
(0005215)
eggert   
2021-01-28 03:33   
I just now checked Solaris 10, and its yacc is a bit of a mess. First, for C it declares only yylex (its yyerror declaration is conditionalized on C++). Second, it declares neither the renamed yyerror nor the renamed yylex if yacc's -p option is used.

Berkeley yacc (2.0 20210109) is similarly in a mess. It does not declare yyerror. It declares yylex, but not if you use -p or have #defined either yylex or YYSTATE.

We could use the "#define yylex yylex" trick as a compromise that will likely require minor changes to all three yacc implementations. The basic idea is as follows:

 * y.tab.c declares yyerror unless yyerror is already defined as a macro. (None of the three implementations declare yyerror now.)

 * y.tab.c declares yylex unless yylex is already defined as a macro. (Solaris yacc and byacc do this, Bison does not.)

 * y.tab.h declares yyparse (Bison does this, Solaris yacc and byacc do not.)

 * All of the "yy"s in the above are consistently changed to some other prefix P if the "-p P" option is used. (None of the three implementations do this now.)

Here’s a proposed change to implement this suggestion. I don't have the PDF so page and line numbers are approximate.
-----


 On page 3456 line 116732 section yacc (Code File), change:

    It also shall contain a copy of the #define statements in the header file. If a %union declaration is used, the declaration for YYSTYPE shall also be included in this file.

to:

    It also shall contain a copy of the declarations and #define directives of the header file, prior to any code copied from within <tt>%{</tt> and <tt>%}</tt> in the declarations section in grammar.

 On page 345? line 116??? section yacc (Header File), add a new sentence:

    The header file shall also contain a declaration that is compatible with ‘int yyparse (void);’.

 On page 3456 line 116734 section yacc (Code File), add a new paragraph:

    The code file shall also contain declaration that are compatible with ‘void yyerror(const char *);’ and ‘int yylex(void);’. These declarations shall be placed after any code copied from within <tt>%{</tt> and <tt>%}</tt> in the declarations section, and shall be omitted if that copied code defines the preprocessor macros yyerror and yylex, respectively, where the yy in the preprocessor macro names is replaced by sym_prefix if the -p sym_prefix option is used.

On page 3469 line 117335 section yacc (RATIONALE), add new paragraphs:

    If the yyerror() and yylex() functions are not defined within <tt>%{</tt> and <tt>%}</tt> in the declarations section or in the programs section, suggested practice is to declare these functions into a separate header file and include the file in the declarations section, followed by ‘#define yyerror yyerror’ and ‘#define yylex yylex’ if the identifiers are not already macros. This lets the separate header file be the definitive API for all code defining or using these functions.

    Earlier versions of this standard did not specify whether the code or header file created by yacc should declare yyerror(), yylex() and yyparse(). The current version specifies when and where these declarations should appear.
(0005216)
dickey   
2021-01-28 09:32   
(edited on: 2021-01-28 10:04)
The comment about byacc is inaccurate. Here's a slice for the yyparse (the behavior with the -p option appears to be consistent with https://pubs.opengroup.org/onlinepubs/9699919799/utilities/yacc.html): [^]

/* compatibility with bison */
#ifdef YYPARSE_PARAM
/* compatibility with FreeBSD */
# ifdef YYPARSE_PARAM_TYPE
# define YYPARSE_DECL() yyparse(YYPARSE_PARAM_TYPE YYPARSE_PARAM)
# else
# define YYPARSE_DECL() yyparse(void *YYPARSE_PARAM)
# endif
#else
# define YYPARSE_DECL() yyparse(void)
#endif

extern int YYPARSE_DECL();

which a compiler will see as "extern int yyparse(void)".

Regarding the on-topic details, yylex and yyerror are provided in byacc as macros (see my first comment), but not used directly as in that last line of the yyparse, because it would interfere with being able to make one or both of those static. Whether the macro names are suitable for standardization hasn't been brought up yet.

(0005217)
dickey   
2021-01-28 09:34   
Short: the suggested change to "On page 3456 line 116734" does not take into account the possibility of declaring yylex/yyerror as "static".
(0005218)
dickey   
2021-01-28 10:02   
typo to fix here: "The code file shall also contain declaration"
should be: "The code file shall also contain declarations" (missing plural)
(0005219)
dickey   
2021-01-28 10:03   
The suggested change "On page 3469 line 117335 section" does not mention that those symbols may already be macros. Some expansion/revision is probably in order.
(0005220)
rhansen   
2021-01-28 16:44   
(edited on: 2021-01-28 16:45)
On page 3456 line 116732 section yacc (Code File), change:
It also shall contain a copy of the #define statements in the header file.
to:
It also shall contain a copy of the #define statements in the header file, prior to any code copied from semantic actions in grammar, and the following function prototypes for the yyerror(), yylex(), and yyparse() functions, after any code copied from within <tt>%{</tt> and <tt>%}</tt> in the declarations section in grammar and before any code copied from semantic actions in grammar:
void yyerror(const char *);
int yylex(void);
int yyparse(void);

The declarations of yyerror() and yylex() shall be protected by #ifndef or #if preprocessor statements such that each is only visible if a preprocessor macro with the name yyerror or yylex, respectively, is not already defined, where the yy in the macro names is replaced by sym_prefix if the -p sym_prefix option is used.


On page 3456 line 116734 section yacc (Code File), add a new paragraph:
The code file shall not contain a declaration of the main() function, unless one is present within <tt>%{</tt> and <tt>%}</tt> in the declarations section in grammar.


On page 3456 line 116739 section yacc (Header File), add a new sentence:
The header file may also declare the yyparse() function, using a function prototype. It shall not declare the yyerror() and yylex() functions.


On page 3465 line 117139 section yacc (Yacc Library), change:
int yyerror(const char *s)
to:
void yyerror(const char *s)



On page 3467 line 117217 section yacc (APPLICATION USAGE), add new paragraph:
If yyerror() and yylex() are not defined within <tt>%{</tt> and <tt>%}</tt> in the declarations section as functions or macros, nor in the programs section as functions, recommended practice is to declare them as functions in a separate header file and include that file in the declarations section, followed by <tt>#define yyerror yyerror</tt> and <tt>#define yylex yylex</tt>. This lets the separate header file be the definitive API for all code defining or using these functions.


On page 3467 line 117239 section yacc (EXAMPLES), change:
int yyerror(const char *msg)
to:
void yyerror(const char *msg)


On page 3469 line 117335 section yacc (RATIONALE), add new paragraphs:
Earlier versions of this standard did not require the code file created by yacc to contain declarations of yyerror(), yylex(), and yyparse(). This meant that portable applications that did not define them had to declare them in the grammar file, to ensure they would not be diagnosed by the compiler as being called without being declared, but this was not stated in those versions of the standard either. The standard developers decided it was preferable for yacc to include the declarations in the code file and this is now a requirement. However, the declarations of yyerror() and yylex() are only visible if a macro of the same name is not defined, which provides application writers with a way to suppress the declaration if desired (for example, in order to provide their own declaration that would conflict with the one written by yacc()). These functions are not declared in the header file because a macro definition in the declaration section would not be be able to suppress them there.

Earlier versions of this standard were also silent about a declaration of main(). However, the equivalent solution was not adopted because a declaration of main() would only be needed if it is called recursively by an application. Although in theory an application could call the yacc library version of main() from code in a grammar file, it is questionable why any application (other than a test suite) would do so, in particular because that version of main() does not accept any arguments and it calls exit()—it does not return—and therefore is of little use recursively. An application that includes its own definition of main() could call it recursively, but can reasonably be expected to ensure it does not call main() without previously defining or declaring it. An additional complication is that main() has multiple different allowed prototypes. The standard developers decided the simplest solution was to disallow yacc from providing a declaration of main() in the code file.


(0005236)
geoffclare   
2021-02-12 16:47   
When applying this bug, I removed the extraneous "()" from "written by yacc()".




Viewing Issue Advanced Details
1387 [1003.1(2008)/Issue 7] System Interfaces Editorial Clarification Requested 2020-08-10 16:46 2021-03-08 15:18
rhansen
ajosey  
normal  
Applied  
Accepted As Marked  
   
Richard Hansen
malloc
1295 (Issue 7 2018 edition)
43161 (Issue 7 2018 edition)
Approved
Note: 0005203
Should EAGAIN be acceptable for malloc failure?
On failure, the implementations of malloc from Solaris, OpenSolaris, OpenIndiana, illumos, etc. set errno to either ENOMEM or EAGAIN (see https://illumos.org/man/3c/malloc [^] ). It seems to me that EAGAIN is used for at least a subset of ordinary out-of-memory conditions, so on the surface these implementations appear to be non-conforming.

I am unfamiliar with the implementation details, and the phrase "Insufficient storage space is available" could be interpreted in a few subtly different ways, so perhaps one could argue that EAGAIN is only used for error cases other than "Insufficient storage space is available" (which is permitted by the standard).

IIUC, Solaris has behaved this way for a very long time. If the implementations are considered to be non-conforming, then it might make more sense to change the standard to permit EAGAIN than to change the implementations.

Link to HTML version of Issue 7 2018 edition: https://pubs.opengroup.org/onlinepubs/9699919799/functions/malloc.html [^]
On line page 1295 line 43161, change:

  [ENOMEM] Insufficient storage space is available.

to:

  [ENOMEM], [EAGAIN] Insufficient storage space is available.

A similar change would be required for every other function that allocates memory, assuming the implementations of those functions on Solaris and friends use malloc and leave errno unmodified on malloc failure.
Notes
(0004914)
rhansen   
2020-08-10 17:09   
A problem arises if we were to replace all instances of [ENOMEM] with [ENOMEM], [EAGAIN]: Some functions already specify [EAGAIN] for other error conditions. These include:
  • accept
  • fclose
  • fflush
  • fgetc
  • fgetwc
  • fork
  • fputc
  • fputwc
  • mlock
  • mlockall
  • mmap
  • mprotect
  • open
  • openat
  • posix_trace_create
  • posix_trace_create_withlog
  • pread
  • pthread_barrier_init
  • pthread_cond_init
  • pthread_key_create
  • pthread_mutex_init
  • pthread_rwlock_init
  • pthread_rwlockattr_init
  • pthread_spin_init
  • read
  • recv
  • recvfrom
  • recvmsg
  • sendmsg
  • sendto
(0004915)
Don Cragun   
2020-08-10 17:39   
Rather than:

      [ENOMEM], [EAGAIN] Insufficient storage space is available.

I would prefer to see:

     [EAGAIN] Allocating the requested storage space would cause the thread to be blocked.
     [ENOMEM] Insufficient storage space is available.
(0004916)
alanc   
2020-08-10 17:45   
I believe the Solaris behavior originally came from passing through sbrk() failures without checking/changing the reported errno value, and thus distinguishes between hitting some limit, for which trying again is not worthwhile, vs. waiting for other processes to exit or otherwise free up memory.

(0004918)
shware_systems   
2020-08-11 01:08   
EAGAIN, if added as Don proposes, should be a may fail case, not both as shall fail. As ENOMEM is currently synonymous with a null return with most platforms, adding a symbolic non-NULL ptr, i.e. AGAIN_PTR, would be in keeping with the C standard only using the return value to indicate errors. The implementation-defined errno possible with 0 size allocs also needs wording that it doesn't conflict with either of these, as well.
(0004923)
joerg   
2020-08-14 09:50   
(edited on: 2020-08-14 09:51)
Re:Note: 0004916

Hi Alan, do you know where EAGAIN is created in the Solaris kernel while running sbrk()?

Due to the object oriented design of the address space administration in SunOS, it is hard to find the right location in the code.

What I however can say is that since SunOS-4.0 (from late 1987), kmem_alloc() with a flag of KM_NOSLEEP returns EAGAIN in case that the operation would result in a sleep.

The anon pages segment driver vm_anon.c however only returns ENOMEM, the sgvn driver seg_vn.c returns ENOMEM in plenty of cases (e.g. with shared mappings that are not expected to apply to sbrk()), but also ENOMEM in other cases.

(0004927)
Konrad_Schwarz   
2020-08-19 09:53   
Shouldn't this fall under the following provision in https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_03? [^]

"Implementations may support additional errors not included in this list, may generate errors included in this list under circumstances other than those described here, or may contain extensions or limitations that prevent some errors from occurring."
(0004932)
rhansen   
2020-08-19 19:57   
> Shouldn't this fall under the following provision in [...]

Yes, if you interpret illumos's EAGAIN case to be distinct from "insufficient storage space is available." To me, it doesn't feel any different, but I can see how others would feel otherwise.

If I saw Don's suggested wording (Note: 0004915) in the standard, then I would interpret "insufficient storage space is available" more narrowly than I do now.
(0004933)
Konrad_Schwarz   
2020-08-20 07:23   
But isn't this a distinction without a difference? In vast majority of
cases, resolution of the EAGAIN error depends on the actions of other
processes in the system over which the application has no control.

For fork(), I think a case can be made that in Unix, many processes are
short lived and therefore a retry after a limited period can be worthwhile
(given a fixed-size process table). Similar for open file descriptors.

For memory, in a system with long-lived, memory hogging processes
(e.g., large databases), retry after memory allocation failure
does not seem worthwhile.

If POSIX lists EAGAIN as an alternative for ENOMEM everywhere
ENOMEM is documented, scrupulous application programmers will
have to handle EAGAIN explicitly, presumably differently from the ENOMEM
case (i.e., by sleeping and then retrying).

As it is now, if malloc() returns EAGAIN, this would be
handled by fully-conforming code under the "additional errors"
case, e.g., with perror(). This gives the system administrator the
input that more memory or more swap space needs to be installed --
it's not something that the application can handle in a useful way.
(0004935)
rhansen   
2020-08-20 17:58   
(edited on: 2020-08-20 18:10)
> But isn't this a distinction without a difference?

I agree with your analysis. That's why it feels wrong to me that Solaris-based systems use EAGAIN—they should use ENOMEM instead.

I see these options:
  • Change Solaris-based systems to use ENOMEM instead of EAGAIN. I prefer this option, but it is unlikely to happen.
  • Declare Solaris-based systems to be non-conforming and live with that.
  • Try to convince ourselves that the Solaris EAGAIN error condition is completely different than "insufficient storage space is available", and therefore the behavior does not run afoul of "Implementations shall not generate a different error number from one required by this volume of POSIX.1-2017 for an error condition described in this volume of POSIX.1-2017." I don't like this option because I don't think the error condition is completely different, for the reasons you state in your note.
  • Change the standard to mention EAGAIN as a possible error with a subtly different meaning ("insufficient storage space right now, but it might succeed if you try again later" vs. "a hard limit would be exceeded so there will never be sufficient storage space"). I don't like this option because retries are not generally useful so why make the distinction? In my opinion this makes the standard slightly less useful. The only reason to choose this option is to allow Solaris to be declared conforming without changing its implementation.


(0004936)
alanc   
2020-08-20 18:14   
There is an open bug report against Solaris for this:
15109791 malloc(3C) fails with EAGAIN where ENOMEM is expected
and it could be fixed if needed, it's just never been a high priority
since few applications do anything differently for EAGAIN vs. ENOMEM
return values - most just print the error message from them.

That bug notes the historical distinction was:

     ENOMEM
           The physical limits of the system are exceeded by size
           bytes of memory which cannot be allocated.

     EAGAIN
           There is not enough memory available to allocate size
           bytes of memory; but the application could try again
           later.

but also notes Solaris has multiple malloc implementations, and not all
of them made this distinction. (We're currently up to 8 different malloc
library options in Solaris 11.4 - see the ALTERNATIVE IMPLEMENTATIONS section
at the end of:
https://docs.oracle.com/cd/E88353_01/html/E37843/malloc-3c.html#scrolltoc [^] .)
(0004937)
rhansen   
2020-08-20 18:24   
(edited on: 2020-08-20 19:44)
"So you're telling me there's a chance. YEAH!" :)
(reference: https://www.imdb.com/title/tt0109686/quotes/qt0995799 [^] )

Joking aside, it's good news that Oracle isn't totally opposed to changing the behavior.

(0004938)
rhansen   
2020-08-20 18:30   
Is that Solaris bug report publicly accessible?
(0004939)
alanc   
2020-08-20 19:42   
Sorry, Oracle only makes Solaris bug reports accessible to customers with
support contracts, not to the general public.

(And yes, there's a chance, given a good reason, but that would only affect
 future support updates to Solaris 11.4, not decades of past releases that
 have had this behavior in.)
(0004940)
rhansen   
2020-08-20 19:48   
(edited on: 2020-08-20 19:49)
> there's a chance, given a good reason

Do you know if POSIX conformance would be a good enough reason by itself?

> that would only affect future support updates to Solaris 11.4,
> not decades of past releases that have had this behavior

From a POSIX perspective that's OK—only changing new releases is good enough to avoid rewording the standard.

(0005203)
geoffclare   
2021-01-21 16:11   
(edited on: 2021-01-22 09:30)
Interpretation response
------------------------
The standard clearly states that implementations may use any error number that is applicable to a particular failure, and conforming implementations must conform to this.

Rationale:
-------------
Some implementations return EAGAIN if the resource (memory) is temporarily unavailable. This is acceptable under the general rules for error numbers in section 2.3 of XSH.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
On page 637 line 22025 (calloc() rationale), change:
None.
to:
See the RATIONALE for [xref to malloc()].

On page 1295 line 43167 (malloc() rationale), change:
None.
to:
Some implementations set errno to [EAGAIN] to signal memory allocation failures that might succeed if retried and [ENOMEM] for failures that are unlikely to ever succeed, for example due to configured limits. XSH section 2.3 permits this behavior, since when multiple error conditions described there are simultaneously true there is no precedence between them.

On page 1788 line 57907 (realloc() rationale), change:
None.
to:
See the RATIONALE for [xref to malloc()].


(0005204)
agadmin   
2021-01-21 16:25   
Interpretation proposed: 21 Jan 2021
(0005249)
agadmin   
2021-02-22 13:52   
Interpretation approved: 22nd February 2021




Viewing Issue Advanced Details
1386 [Issue 8 drafts] System Interfaces Objection Error 2020-08-08 19:43 2020-10-08 10:32
eggert
 
normal  
Applied  
Accepted As Marked  
   
Paul Eggert
UCLA
strftime
1964-1965
63876-63887
Note: 0005000
strftime RETURN VALUE and ERRORS problems
The RETURN VALUE and ERRORS section of strftime have been revised recently, and when I changed the tzdb reference implementation to support these revisions I found some problems.

1. The [EOVERFLOW] description requires strftime to fail if the requested time does not fit into time_t. This disallows a strftime implementation that internally uses an integer wider than time_t, e.g., a strftime operating in a mixed 32- and 64-bit time_t environment that uses 64 bits internally even when called via a 32-bit API. [EOVERFLOW] should be a "may fail", not a "shall fail".

2. No errno value is specified if strftime fails due to exhausting the output buffer. This is a longstanding problem with strftime: portable code has no way to distinguish success from failure when strftime returns 0, and this is a real problem in practice. The simplest way I can see to fix this is to require that errno is unchanged when 0 is returned on success. I've just now changed the reference strftime implementation in tzdb to do this, which was an easy thing to do while adding support for the other errno changes in draft POSIX; see <https://mm.icann.org/pipermail/tz/2020-August/029187.html>. [^]

3. Unnecessary terminology switching between "null byte" and "NUL character".
In lines 63887-63878, change "If the total number of resulting bytes including the terminating null byte is not more than _maxsize_" to "If successful".

After line 63880, add "If successful and 0 is returned, errno is unchanged."

After line 63882, add (as a "shall fail"):

  [ERANGE] The total number of resulting bytes including the terminating NUL character is more than _maxsize_.

Move lines 63883-63884 to just after line 63887, so that [EOVERFLOW] is a "may fail" rather than a "shall fail".

After line 63906 "APPLICATION USAGE" add:

A return value of 0 may indicate either success or failure if a format consists entirely of conversion specifiers like "%z" that happen to be replaced by no characters. To distinguish between success and failure when strftime() returns 0, an application can set errno to 0 before calling strftime() and test whether errno is 0 afterwards.
Notes
(0004904)
eggert   
2020-08-08 19:53   
(edited on: 2020-08-08 22:43)
Also see 0001353, where I've commented on the technical differences between the desired action there and the one here.

(0004905)
shware_systems   
2020-08-08 21:39   
Re: #1
It does not matter the internal implementation, it can use a 128-bit long double if it wants, if the calculated value is not in the symbolic range, as integral seconds, TIME_MIN to TIME_MAX it is a shall fail condition. Perhaps other phrasing than "fit in" that better reflects this range is warranted but a section change is not, that I see.
(0004906)
kre   
2020-08-08 21:47   
(edited on: 2020-08-09 16:55)
Trivia, a %z conversion can never result in 0 bytes, I think you meant %Z
but a much better (more likely) example is %p.

The ERANGE error isn't needed, it is easy to handle the ambiguity, by
simply never providing a conversion that can legitimately result in 0
bytes as the result. That simply means supplying an irrelevant prefix
character (like a space) at the start of the format if there is any possibility
that a successful return might be 0 bytes, or even always), and then ignoring
it (using s+1 as the resulting string, and result-1 as the length) when a
result >= 1 is returned (with 0 meaning one of the error cases, always).

(0004907)
eggert   
2020-08-09 07:19   
"it can use a 128-bit long double if it wants, if the calculated value is not in the symbolic range, as integral seconds, TIME_MIN to TIME_MAX it is a shall fail condition."

Yes I know that is what the current draft spec says. However, there is no reason for the spec to say that, and that is why I objected. If the strftime implementation can output the correct string for %s even though the represented value is outside of time_t range, there's no good reason for POSIX to require the implementation to fail.
(0004909)
eggert   
2020-08-09 07:27   
"That simply means supplying an irrelevant prefix character (like a space) at the start of the format if there is any possibility that a successful return might be 0"

That is not such a simple thing in a general-purpose subroutine such as a one that accepts a strftime format, generates a date string with that format, and puts the date string in a user-specified buffer. Such a subroutine would have to allocate a buffer to store a near-copy of the format, and another buffer to store a near-copy of the returned string. This is awkward and inefficient and hardly anybody does this. It's more common to use code like this:

        cp[0] = '\1';
        result = strftime(cp, size, format, tmp);
        if (result != 0 || cp[0] == '\0')
            /* strftime worked */;

(this is code taken from tzdb date.c) which "generally" works (although it relies on undocumented strftime internals) and which we hope is good enough. It would be much better if the strftime API gave us a straightforward way to distinguish success from failure. And this is very easy for implementations to do.

"I think you meant %Z" - You're right, thanks.
(0004910)
shware_systems   
2020-08-09 12:06   
(edited on: 2020-08-09 21:57)
Re: Note: 0004907

The type for "seconds since the epoch" is time_t, so values outside its range are not valid specifications for that platform. For 32-bit time_t's this is the 2038 rollover issue. That you need 60 bits or so to represent seconds since the Big Bang, and counting, is a known bug of many implementations in not being able to represent all times of scientific interest in a time_t. You certainly need more than 32 bits if the range of tm_year is 32 bits, and these don't even cover the age of the planets, as a similar defect of most tm struct definitions. Yes, doing the conversion as if by mktime() is somewhat arbitrary, but it is consistent with other uses of "seconds since the epoch" elsewhere in the standard.

(0004911)
kre   
2020-08-09 16:45   
(edited on: 2020-08-09 16:47)
Re Note: 0004905 Note: 0004907 and Note: 0004910

Paul is correct, there is no reason to prohibit an implementation of strftime()
from accepting a struct tm that cannot be converted into a time_t. The spec
should allow an implementation to fail in that case, not require it to do so.
The purpose of strftime() is not tm validation (if it were so, then the shall
fail would make sense, but it isn't, so it doesn't).

(0004912)
kre   
2020-08-09 16:51   
Re Note: 0004909

You're right, the workaround can be difficult to handle in a poorly
designed subroutine. Redesigining the subroutine API can allow it to
be handled simply however. In practice there are few such interfaces,
and even fewer exist in places where a 0 length valid result is
plausible, so most of the time, handling strftime() as it now exists
is not a issue worth complaining about.
(0004913)
shware_systems   
2020-08-10 11:40   
(edited on: 2020-08-10 14:52)
Re: Note: 0004911
If a platform wants that functionality it can add a char *func(const tm *arg) interface for it. A proposal for adding this using a %Os specification might get support also, if implemented.

Apparently enough platforms that added %s as an extension were using mktime() as part of the code for the conversions so the standard reflects this as the existing practice. Someone that was part of the discussions would need to verify that. Since mktime() does validate the structure, strftime() also is required to validate it now, if %s is used.

(0004917)
kre   
2020-08-10 17:45   
(edited on: 2020-08-10 23:49)
Re Note: 0004913

    [...] extension were using mktime() as part of the code for the
    conversions so the standard reflects this as the existing practice.

That's fine, and allowing the error is fine too.

But:

    Since mktime() does validate the structure, strftime() also is
    required to validate it now, if %s is used.

In the specification of the 's' conversion, after "as if by a call to mktime()"
we should add

    except that errors that may be generated by mktime need not be
    detected, and no actual time_t value need be generated.

It is "as if" by mktime() - nothing requires that mktime() actually be
used (even for %s) - especially as:

    determined using the LC_TIME category of the current locale and by the
    values of zero or more members of the broken-down time structure pointed
    to by timeptr, as specified in brackets in the description. If any of the
    specified values are outside the normal range, the characters stored are
    unspecified.

That is, struct tm normalisation is not required of strftime() (even though
mktime() does that) as if any values are out of range, the results are
unspecified. So an implementation could calculate the number of seconds
by simply usig a series of multiplications and additions based upon the
fields of the tm struct (with appropriate checks for month lengths, leap years
etc) with the results in any integral type it chooses.

There should be no requirement for an EOVERFLOW to be generated, that error
should be moved into the "may fail" section. Forcing implementations to
be defective, just because old ones were is not desirable or productive.

(0005000)
rhansen   
2020-09-21 15:29   
(edited on: 2020-09-21 15:31)
On page 1961 line 63753 fix the shading bug.

On page 1962 line 63784 section strftime(), change:
Replaced by the number of seconds since the Epoch as a decimal number (see XBD Section 4.17, on page 93). [all members, as if by a call to mktime()]
to:
Replaced by the number of seconds since the Epoch as a decimal number, calculated as described for mktime(). [all members]

On page 1964 lines 63877-63878, change:
If the total number of resulting bytes including the terminating null byte is not more than maxsize
to:
If successful

On page 1964 line 63879, change:
Otherwise
to:
If successful, errno shall not be changed. Otherwise

On page 1964, after line 63882, add (as a "shall fail"):
[ERANGE] The total number of resulting bytes including the terminating NUL character is more than maxsize.

On page 1965, move lines 63883-63884 to just after line 63887, so that [EOVERFLOW] is a "may fail" rather than a "shall fail".

On page 1965 after line 63906 "APPLICATION USAGE" add:
A return value of 0 may indicate either success or failure if a format is the empty string or consists of conversion specifications such as <tt>%p</tt> or <tt>%Z</tt> that are replaced by no characters in the current locale or because of the current setting of tzname[], respectively. To distinguish between success and failure when strftime() returns 0, an application can set errno to 0 before calling strftime() and test whether errno is 0 afterwards.






Viewing Issue Advanced Details
1385 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Error 2020-07-29 10:44 2021-01-29 11:30
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
unlink()
2197
70220
---
unlink() text needs updating to account for mmap()
The mmap() description says:
The mmap() function shall add an extra reference to the file associated with the file descriptor fildes which is not removed by a subsequent close() on that file descriptor. This reference shall be removed when there are no more mappings to the file.
I believe the intention of this is that when unlink() removes the last link to the file, the space it occupies is not freed until no process has the file open and no process has it mapped. However, this is not reflected in the description of unlink(), which only refers to processes having the file open.
Change:
When the file's link count becomes 0 and no process has the file open, the space occupied by the file shall be freed and the file shall no longer be accessible. If one or more processes have the file open when the last link is removed, the link shall be removed before unlink() returns, but the removal of the file contents shall be postponed until all references to the file are closed.
to:
When the file's link count becomes 0 and no process has a reference to the file via an open file descriptor or a memory mapping (see [xref to mmap()]), the space occupied by the file shall be freed and the file shall no longer be accessible. If one or more processes have such a reference to the file when the last link is removed, the link shall be removed before unlink() returns, but the removal of the file contents shall be postponed until there are no such references to the file.

There are no notes attached to this issue.




Viewing Issue Advanced Details
1384 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Omission 2020-07-29 09:02 2021-01-29 11:27
geoffclare
 
normal  
Applied  
Accepted As Marked  
   
Geoff Clare
The Open Group
2.12 Shell Execution Environment
2382
76195-76202
---
Note: 0005198
Subshell of an interactive shell is effectively non-interactive
The standard is missing a statement to the effect that a subshell of an interactive shell behaves as a non-interactive shell (despite the fact that $- and "set +o" indicate it is interactive).

For example, in all shells I tried, the subshell in the following is terminated by SIGTERM. (Some wrote "Terminated" between the two lines, others didn't, but the $? value in all of them indicated termination with SIGTERM and none of them wrote "foo".)
$ (pid=$(sh -c 'echo $PPID'); kill -s TERM "$pid"; echo foo)
$ echo $?
If the subshell was behaving as per the standard's requirements for an interactive shell, the SIGTERM would be ignored, the echo would be executed, and $? would be 0.

The current statement about traps in 2.12 is also out of date with respect to the description of the trap utility.
On page 2382 line 76195 section 2.12 Shell Execution Environment,
after applying bug 1247 change:
A subshell environment shall be created as a duplicate of the shell environment, except that traps that are not being ignored shall be set to the default action.
to:
A subshell environment shall be created as a duplicate of the shell environment, except that:
  • Unless specified otherwise (see [xref to trap]), traps that are not being ignored shall be set to the default action.

  • If the shell is interactive, the subshell shall behave as a non-interactive shell in all respects other than the expansion of the special parameter '-' and the output of <tt>set -o</tt> and <tt>set +o</tt>, which shall continue to indicate that it is interactive.

Notes
(0005198)
rhansen   
2021-01-11 16:45   
(edited on: 2021-01-14 16:30)
On page 2382 line 76195 section 2.12 Shell Execution Environment,
after applying bug 1247 change:
A subshell environment shall be created as a duplicate of the shell environment, except that traps that are not being ignored shall be set to the default action.
to:
A subshell environment shall be created as a duplicate of the shell environment, except that:
  • Unless specified otherwise (see [xref to trap]), traps that are not being ignored shall be set to the default action.
  • If the shell is interactive, the subshell shall behave as a non-interactive shell in all respects except:
    • The expansion of the special parameter '-' may continue to indicate that it is interactive.
    • The <tt>set -n</tt> option may be ignored.

On page 2411 line 77159 (XCU 2.14 set -n) change:
An interactive shell may ignore this option.
to:
Interactive shells and subshells of interactive shells, recursively, may ignore this option.


(0005200)
rhansen   
2021-01-14 16:31   
(edited on: 2021-01-14 16:37)
Note: 0005198 was edited to change "and the output of <tt>set -o</tt> and <tt>set +o</tt> shall" to "may" in response to a comment on the mailing list:

https://www.mail-archive.com/austin-group-l@opengroup.org/msg07384.html [^]





Viewing Issue Advanced Details
1383 [Issue 8 drafts] System Interfaces Editorial Enhancement Request 2020-07-25 11:24 2020-10-08 10:27
dannyniu
 
normal  
Applied  
Accepted As Marked  
   
DannyNiu/NJF
Fork
878
29985
Note: 0004997
Make "Application Usage" less confusing.
The "Application Usage" section has new content that's
added in response to Bug 62, but right now it has a
confusing (at least on the first sight) wording that's
unfriendly to new readers not familiar to the modification
made to fork.

Specifically, it says:

> processing performed in the child before fork() returns

On the first sight, it seems nonsensical as child doesn't
even exist before fork returns, however, when reminded of
pthread_atfork handlers, it makes sense.
Change

> processing performed in the child before fork() returns

To

> processing performed in the child by the pthread_atfork()
> handlers before fork() returns
Notes
(0004900)
geoffclare   
2020-07-27 09:07   
This change was not made as a result of bug 0000062, it is from the unrelated bug 0001114.

Where the new text refers to "processing performed in the child before fork() returns" it means everything that the implementation of fork() does in the child between the point where it creates the child process and the point where it returns in the child process. This includes any processing related to the bullet list on lines 29903-29957.

Rather than adding a reference to pthread_atfork() (which would incorrectly imply that the text only applies to processing performed by atfork handlers) we should make it clear that the text applies to both fork() and _Fork().
(0004901)
geoffclare   
2020-07-27 09:13   
Suggested change...

On page 878 line 29980 section fork(), change:
When a multi-threaded process calls fork(), ...
to:
When a multi-threaded process calls fork() or _Fork(), ...

On page 878 line 29985 section fork(), change:
the processing performed in the child before fork() returns
to:
the processing performed in the child before fork() or _Fork() returns in the child
(0004902)
shware_systems   
2020-07-27 14:40   
Upon rereading 1114, I'm more inclined second change in Note 4901 should start 'any processing', not 'the processing', to be inclusive of any implementations that set up the child's data space entirely before handing it off to the process scheduler, where this is plausible. Use of 'the' implies there will always be post handoff manipulations.
(0004997)
rhansen   
2020-09-17 16:03   
On page 878 line 29980 (fork() application usage), change:
When a multi-threaded process calls fork(), although all memory that is addressable in the calling thread remains addressable in the child, there is no guarantee that the contents of thread-specific memory, such as stacks or thread-local storage, that was specific to other threads in the parent will still be the same in the child. This is because such memory could be treated as available in the child given that the threads it related to do not exist in the child, and consequently the processing performed in the child before fork() returns could make use of that memory. Therefore applications should avoid using in the child any pointers to thread-specific memory that were passed to the calling thread from other threads in the parent.
to:
When a multi-threaded process calls fork() or _Fork(), there is no guarantee that thread-specific memory (such as stacks or thread-local storage) associated with threads in the parent other than the calling thread will still be available in the child. This is because threads in the parent other than the calling thread do not exist in the child. Consequently, the implementation of fork() and _Fork() could remove that memory from the address space in the child, or reuse it for other purposes before returning or (in the case of fork()) calling any of the fork handlers registered by pthread_atfork(). Therefore, applications should avoid using any pointers to thread-specific memory in the child that were passed to the calling thread from other threads in the parent.




Viewing Issue Advanced Details
1382 [1003.1(2016/18)/Issue7+TC2] System Interfaces Editorial Clarification Requested 2020-07-24 15:16 2021-01-29 11:25
tydeman
 
normal  
Applied  
Accepted As Marked  
   
Fred J. Tydeman
Tydeman Consulting
2018 edition of Issue 7 of Base Specifications
XSH: system interfaces: asin()
603 (or 651 of 3952)
20997
---
Note: 0005187
Ambiguous statement in asin() and other math functions
In looking at asin(), I am confused by the wording in line 20997
"If x is not returned,....."
Which x is it talking about? The one on line 20995 or any x?

Is line 20997 supposed to be a continuation of line 20996?

If yes, but it cannot be because of MX vs MXX shading,
then line 20997 should be changed to
"If a subnormal result is not returned,...."

I believe the same problem exists for many other math functions: at least:
asinh, atan, atanh, expm1, log1p, sin, sinh, tan, tanh
Clean up the wording. nextafter() might be a way to show both MX and MXX shading as continuous.
Notes
(0004899)
geoffclare   
2020-07-24 15:39   
This text came from bug 0000068 where it is shown as one paragraph:

    [MX] If x is subnormal, a range error may occur[/MX] [MXX] and x
    should be returned.[/MXX]
    [MX] If x is not returned, asin(), asinf(), and asinl() shall
    return an implementation-defined value no greater in magnitude
    than DBL_MIN, FLT_MIN, and LDBL_MIN, respectively.[/MX]

So the paragraph break is an editorial mistake in applying bug 68. If the paragraph break is changed to a line break, the result would look like the current change from MX to MXX on the previous line, where the shading is continuous.

Changing to "If a subnormal result is not returned,...." won't work because the standard allows a different subnormal (implementation-defined) value to be returned.

The other cases are presumably also all the result of incorrectly applied bug 68 edits.
(0005187)
geoffclare   
2020-12-18 10:16   
In the Dec 17th teleconference it was felt that changing the wording so there is only one shading change instead of two would improve the readability, but we ran out of time to check for all of the affected places. I have now looked through the resolution of bug 0000068 and can confirm that the functions listed in the description here are the only ones where an unwanted paragraph break was inserted when the shading changed from one margin code to another.

Proposed changes...

At P603 L20995 (asin), P605 L21059 (asinh), P609 L21166 (atan),
P615 L21324 (atanh), P802 L27261 (expm1), P1276 L42602 (log1p),
P1993 L64163 (sin), P1995 L64237 (sinh), P2112 L67777 (tan) and
P2115 L67865 (tanh), change:
[MX] If x is subnormal, a range error may occur[/MX]
[MXX] and x should be returned.[/MXX]

[MX] If x is not returned, asin(), asinf(), and asinl() shall return an implementation-defined value no greater in magnitude than DBL_MIN, FLT_MIN, and LDBL_MIN, respectively.[/MX]
to (substituting the appropriate function names for asin(), asinf() and asinl()):
[MXX]If x is subnormal, x should be returned.[/MXX]
[MX]If x is subnormal, a range error may occur and, if x is not returned, asin(), asinf(), and asinl() shall return an implementation-defined value no greater in magnitude than DBL_MIN, FLT_MIN, and LDBL_MIN, respectively.[/MX]

Note to the editor: where the shading changes from MXX to MX, use a line break (.br) not a paragraph break (.P).




Viewing Issue Advanced Details
1381 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Omission 2020-07-23 09:34 2021-01-15 16:26
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
ftruncate()
980
33344
---
ftruncate() missing EINVAL from POSIX.1-1996
POSIX.1-1996 specified the following error for ftruncate():
[EINVAL] The fildes argument does not refer to a file on which this operation is possible.
This was omitted when POSIX.1-1996 and SUSv2 were merged to form POSIX.1-2001/SUSv3.

For consistency, truncate() should also have an equivalent EINVAL error.
On page 980 line 33344 section ftruncate() EINVAL, change:
The length argument was less than 0.
to:
The length argument is less than 0 or the fildes argument refers to a file on which this operation is not possible (for example, a pipe, FIFO or socket).

On page 2178 line 69765 section truncate() EINVAL, change:
The length argument was less than 0.
to:
The length argument is less than 0 or the path argument refers to a file, other than a directory, on which this operation is not possible (for example, a FIFO or socket).

(The editors may also want to rearrange both ERRORS sections into alphabetical order.)
There are no notes attached to this issue.




Viewing Issue Advanced Details
1380 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Objection Clarification Requested 2020-07-22 14:23 2021-01-15 16:23
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
3.192 Hard Link, 3.208 Link
64, 66
1891, 1951
---
Definitions of Link and Hard Link don't match some usage
The term "link" is defined in XBD 3.208 as a synonym for "directory entry", and "hard link" is defined in XBD 3.192 is "The relationship between two directory entries that represent the same file"; it also says that a hard link is "the result of an execution of the ln utility (without the -s option) or the link() function".

This does not match how these terms are often used in the standard. There are many places where it uses "link" to refer to both hard links and symbolic links, e.g. in this paragraph on the fstatat() page:
The lstat() function shall be equivalent to stat(), except when path refers to a symbolic link. In that case lstat() shall return information about the link, while stat() shall return information about the file the link references.
(In the second sentence both uses of "the link" do not fit the definition; they are being used to refer back to "symbolic link" in the previous sentence.)

Also, by a strict reading of the definition, the term "hard link" should be used only in contexts where a file has multiple links, but the standard uses it to refer to cases that include the possibility of a file with only one directory entry, e.g. on the <sys/stat.h> page where st_nlink is described as the "number of hard links".

There are, of course, also places where the terms are used correctly (mainly in text that dates back to before symbolic links were added).

There are two ways the problem could be fixed:

1. Keep the current definitions and change the text in places where it misuses the terms.

2. Change the definitions, and the text in places where changing the definitions changed the meaning.

The proposed changes do the latter. This is mainly because the current definitions are at odds with the way "link" and "hard link" are commonly used outside the context of the standard. I believe changing the definitions would make the text more natural and easier to understand.
On page 53 line 1648 section 3.130 Directory Entry, change:
Directory Entry (or Link)
to:
Directory Entry (or Hard Link)

On page 56 line 1697 section 3.144 Empty Directory, change:
A directory that contains, at most, directory entries for dot and dot-dot, and has exactly one link to it (other than its own dot entry, if one exists), in dot-dot. No other links to the directory may exist.
to:
A directory that contains, at most, directory entries for dot and dot-dot, and has exactly one hard link to it other than its own dot entry (if one exists), in dot-dot. No other hard links to the directory can exist.

On page 64 line 1891 section 3.192 Hard Link, change:
The relationship between two directory entries that represent the same file; see also Section 3.130 (on page 53). The result of an execution of the ln utility (without the -s option) or the link() function.
to:
See Directory Entry in Section 3.130 (on page 53). A file can have multiple hard links as a result of an execution of the ln utility (without the -s option) or the link() function.

On page 66 line 1951 section 3.208 Link, change:
See Directory Entry in Section 3.130 (on page 53).
to:
In the context of the file hierarchy, either a hard link or a symbolic link.

In the context of the c99 utility, the action performed by the link editor (or linker).

<small>Note:
The c99 utility is defined in detail in the Shell and Utilities volume of POSIX.1-2017.</small>

On page 235 line 7917 section <errno.h>, change:
[EMLINK] Too many links.
to:
[EMLINK] Too many hard links.

On page 236 line 7967 section <errno.h>, change:
[EXDEV] Cross-device link.
to:
[EXDEV] Improper hard link.

On page 413 line 14030 section <tar.h> LNKTYPE, change:
Link.
to:
Hard link.


Cross-volume changes to XSH ...

On page 484 line 16712 section 2.3 Error Numbers (EMLINK), change:
Too many links.
to:
Too many hard links.

On page 488 line 16865 section 2.3 Error Numbers (EXDEV), change:
Improper link. A link to a file on another file system was attempted.
to:
Improper hard link. Creation of a hard link to a file on another file system was attempted.

On page 965 line 32816 section fstatat(), change:
st_nlink shall be set to the number of links to the file
to:
st_nlink shall be set to the number of hard links to the file

On page 965 line 32823 section fstatat(), change:
the number of (hard) links to the symbolic link
to:
the number of hard links to the symbolic link

On page 1243 line 41492 section link(), change:
link one file to another file
to:
hard link one file to another file

On page 1243 line 41500,41503,41507,41525,41531 section link(), change:
a new link
to:
a new hard link

On page 1244 line 41545 section link(), change:
The number of links
to:
The number of hard links

On page 1244 line 41568 section link() EXDEV, change:
The link named by path2 and the file named by path1 are on different file systems and the implementation does not support links between file systems
to:
The file named by path1 and the directory in which the directory entry named by path2 is to be created are on different file systems and the implementation does not support hard links between file systems.

On page 1245 line 41590 section link() EXAMPLES, change:
Creating a Link to a File

The following example shows how to create a link to a file
to:
Creating a Hard Link to a File

The following example shows how to create an additional hard link to a file

On page 1245 line 41599 section link() EXAMPLES, change:
Creating a Link to a File Within a Program

In the following program example, the link() function links the
to:
Creating a Hard Link to a File Within a Program

In the following program example, the link() function hard links the

On page 1246 line 41617 section link() APPLICATION USAGE, change:
Some implementations do allow links between file systems.
to:
Some implementations do allow hard links between file systems.

On page 1246 line 41621 section link() RATIONALE, change:
Linking to a directory
to:
Creating additional hard links to a directory

On page 1246 line 41625 section link() RATIONALE, change:
allow linking of files on different file systems
to:
allow hard linking of files on different file systems

On page 1246 line 41627 section link() RATIONALE, change:
The exception for cross-file system links is intended to apply only to links that are programmatically indistinguishable from ``hard'' links.
to:
The exception for cross-file system hard links is intended to apply only to links that are programmatically indistinguishable from traditional hard links.

On page 1246 line 41634 section link() RATIONALE, change:
The AT_SYMLINK_FOLLOW flag allows for implementing both common behaviors of the link() function. The POSIX specification requires that if path1 is a symbolic link, a new link for the target of the symbolic link is created. Many systems by default or as an alternative provide a mechanism to avoid the implicit symbolic link lookup and create a new link for the symbolic link itself.

Earlier versions of this standard specified only the link() function, and required it to behave like linkat() with the AT_SYMLINK_FOLLOW flag. However, historical practice from SVR4 and Linux kernels had link() behaving like linkat() with no flags, and many systems that attempted to provide a conforming link() function did so in a way that was rarely used, and when it was used did not conform to the standard (e.g., by not being atomic, or by dereferencing the symbolic link incorrectly). Since applications could not rely on link() following links in practice, the linkat() function was added taking a flag to specify the desired behavior for the application.
to:
Earlier versions of this standard specified only the link() function, and required it to behave like linkat() with the AT_SYMLINK_FOLLOW flag. However, historical practice from SVR4 and Linux kernels had link() behaving like linkat() with no flags, and many systems that attempted to provide a conforming link() function did so in a way that was rarely used, and when it was used did not conform to the standard (e.g., by not being atomic, or by dereferencing the symbolic link incorrectly). Since applications could not rely on link() following symbolic links in practice, the linkat() function was added taking a flag to specify the desired behavior for the application.

On page 1816 line 58819 section rename(), change:
If the old argument points to the pathname of a file that is not a directory, the new argument shall not point to the pathname of a directory. If the link named by the new argument exists, it shall be removed and old renamed to new. In this case, a link named new shall remain visible to other threads throughout the renaming operation and refer either to the file referred to by new or old before the operation began. Write access permission is required for both the directory containing old and the directory containing new.

If the old argument points to the pathname of a directory, the new argument shall not point to the pathname of a file that is not a directory. If the directory named by the new argument exists, it shall be removed and old renamed to new. In this case, a link named new shall exist throughout the renaming operation and shall refer either to the directory referred to by new or old before the operation began. If new names an existing directory, it shall be required to be an empty directory.
to:
If the old argument names a file that is not a directory and the new argument names a directory, or old names a directory and new names a file that is not a directory, or new names a directory that is not empty, rename() shall fail. Otherwise, if the directory entry named by new exists, it shall be removed and old renamed to new. In this case, a directory entry named new shall remain visible to other threads throughout the renaming operation and refer either to the file referred to by new or old before the operation began.

(Note that the sentence about write access permission is intentionally
dropped as it duplicates line 58834.)

On page 1816 line 58837 section rename(), change:
If the link named by the new argument exists and the file's link count becomes 0
to:
If the new argument names an existing file and the file's link count becomes 0

On page 1817 line 58871 section rename() EEXIST, change:
The link named by new is a directory that is not an empty directory.
to:
The new argument names a directory that is not empty.

On page 1818 line 58883 section rename() ENOENT, change:
The link named by old does not name an existing file
to:
The old argument does not name an existing file

On page 1818 line 58905 section rename() EXDEV, change:
The links named by new and old are on different file systems and the implementation does not support links between file systems.
to:
The file named by old and the directory in which the directory entry named by new is to be created or replaced are on different file systems and the implementation does not support hard links between file systems.

On page 2197 line 70216 section unlink(), change:
The unlink() function shall remove a link to a file. 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. Otherwise, unlink() shall remove the link named by the pathname pointed to by path and shall decrement the link count of the file referenced by the link.
to:
The unlink() function shall remove the directory entry named by path and shall decrement the link count of the file referenced by the directory entry. If path names a symbolic link, unlink() shall remove the symbolic link and shall not affect any file named by the contents of the symbolic link.


Cross-volume changes to XCU ...

On page 2897 line 95692 section ln, change:
In the first synopsis form, the ln utility shall create a new directory entry (link) at the destination path specified by the target_file operand. If the -s option is specified, a symbolic link shall be created for the file specified by the source_file operand.
to:
In the first synopsis form, the ln utility shall create a new directory entry at the destination path specified by the target_file operand. If the -s option is specified, a symbolic link shall be created with the contents specified by the source_file operand (which need not name an existing file); otherwise, a hard link shall be created to the file named by the source_file operand.

On page 2897 line 95697 section ln, change:
In the second synopsis form, the ln utility shall create a new directory entry (link), or if the -s option is specified a symbolic link, for each file specified by a source_file operand, at a destination path in the existing directory named by target_dir.
to:
In the second synopsis form, the ln utility shall create a new directory entry for each source_file operand, at a destination path in the existing directory named by target_dir. If the -s option is specified, a symbolic link shall be created with the contents specified by each source_file operand (which need not name an existing file); otherwise, a hard link shall be created to each file named by a source_file operand.

On page 2899 line 95743,95745 section ln (-L & -P options), change:
create a (hard) link
to:
create a hard link

On page 3075 line 102555 section pax (-u option), change:
In copy mode, the file in the destination hierarchy shall be replaced by the file in the source hierarchy or by a link to the file in the source hierarchy if the file in the source hierarchy is newer.
to:
In copy mode, the file in the destination hierarchy shall be replaced if the file in the source hierarchy is newer.

On page 3087 line 103039 section pax (ustar Interchange Format), change:
1 (a link) or 2 (a symbolic link)
to:
1 (a hard link) or 2 (a symbolic link)

On page 3093 line 103232 section pax (CONSEQUENCES OF ERRORS), change:
cannot create a link to a file
to:
cannot create a hard link to a file

On page 3101 line 103596 section pax (RATIONALE), change:
Links are recorded in the fashion described here because a link can be to any file type. It is desirable in general to be able to restore part of an archive selectively and restore all of those files completely. If the data is not associated with each link, it is not possible to do this. However, the data associated with a file can be large, and when selective restoration is not needed, this can be a significant burden. The archive is structured so that files that have no associated data can always be restored by the name of any link name of any link, and the user may choose whether data is recorded with each instance of a file that contains data. The format permits mixing of both types of links in a single archive; this can be done for special needs, and pax is expected to interpret such archives on input properly, despite the fact that there is no pax option that would force this mixed case on output.
to:
Hard links are recorded in the fashion described here because a hard link can be to any file type. It is desirable in general to be able to restore part of an archive selectively and restore all of those files completely. If the data is not associated with each hard link, it is not possible to do this. However, the data associated with a file can be large, and when selective restoration is not needed, this can be a significant burden. The archive is structured so that files that have no associated data can always be restored by the name of any link name of any hard link, and the user can choose whether data is recorded with each instance of a file that contains data. The format permits mixing of hard links with data and hard links without data in a single archive; this can be done for special needs, and pax is expected to interpret such archives on input properly, despite the fact that there is no pax option that would force this mixed case on output.

On page 3200 line 107351 section rm (APPLICATION USAGE), change:
do not permit the removal of the last link
to:
do not permit the removal of the last hard link


Cross-volume changes to XRAT ...

On page 3491 line 117998 section A.3 Definitions, delete:
Directory Entry

Throughout POSIX.1-2017, the term ``link'' is used (about the link() function, for example) in describing the objects that point to files from directories.

There are no notes attached to this issue.




Viewing Issue Advanced Details
1379 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Error 2020-07-20 08:36 2021-01-15 15:55
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
pax
3078
102671-102680
---
pax environment variables and affirmative responses
The pax utility has the usual boilerplate in the ENVIRONMENT VARIABLES section that utilities which read yes/no responses have. However, it doesn't prompt for that type of response. (The responses for -i are pathnames, not a y/n response.)

Also, LC_COLLATE refers to the pattern operand and the -s option in the part about equivalence classes, but they are missing from the corresponding LC_CTYPE text about character classes.
On page 3078 line 102671 section pax, change:
... used in the pattern matching expressions for the pattern operand, the basic regular expression for the -s option, and the extended regular expression defined for the yesexpr locale keyword in the LC_MESSAGES category.
to:
... used in the pattern matching expressions for the pattern operand and the basic regular expression for the -s option.

On page 3078 line 102674 section pax, change:
Determine the locale for the interpretation of sequences of bytes of text data as characters (for example, single-byte as opposed to multi-byte characters in arguments and input files), the behavior of character classes used in the extended regular expression defined for the yesexpr locale keyword in the LC_MESSAGES category, and pattern matching.
to:
Determine the locale for the interpretation of sequences of bytes of text data as characters (for example, single-byte as opposed to multi-byte characters in arguments and input files), and the behavior of character classes used in the pattern matching expressions for the pattern operand and the basic regular expression for the -s option.

On page 3078 line 102680 section pax, change:
Determine the locale used to process affirmative responses, and the locale used ...
to:
Determine the locale used ...

There are no notes attached to this issue.




Viewing Issue Advanced Details
1378 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Omission 2020-07-17 15:39 2021-01-15 15:53
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
ex
2699
88112
---
ex LC_MESSAGES and affirmative responses
Utilities that read yes/no responses have some boilerplate in the LC_MESSAGES entry in ENVIRONMENT VARIABLES that is missing from the ex page.

It is needed because the s command has a c flag that asks for confirmation.

(Note that the LC_COLLATE and LC_CTYPE entries do not need to mention yesexpr explicitly the way some utilities do, since they already cover that as part of their general statement about regular expressions.)
Change:
Determine the locale that ...
to:
Determine the locale used to process affirmative responses, and the locale that ...

There are no notes attached to this issue.




Viewing Issue Advanced Details
1377 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Error 2020-07-17 09:32 2021-01-15 15:51
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
at
2474
79386
---
at -q addition from POSIX.2b incorrectly applied
The description of the at -q option says:
If -q is specified along with either of the -t time_arg or timespec arguments, the results are unspecified.

This text is the result of an editorial mistake when applying the changes from POSIX.2b, where the addition to be made was given as:
If -q b is specified ...

I.e. this is about what happens if you specify the batch queue and also specify a time/date.
Change:
If -q is specified
to:
If -q b is specified

There are no notes attached to this issue.




Viewing Issue Advanced Details
1376 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Error 2020-07-16 08:19 2021-01-13 16:06
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
asctime(), ctime(), gmtime(), localtime()
600, 727, 1113, 1265
20907, 24771, 37681, 42218
---
CX shading on C99 time conversion functions
The descriptions of asctime(), ctime(), gmtime(), and localtime() should not have CX shading on this paragraph:
The asctime(), ctime(), gmtime(), and localtime() functions shall return values in one of two static objects: a broken-down time structure and an array of type char. Execution of any of the functions may overwrite the information returned in either of these objects by any of the other functions.

The text is derived from the introductory paragraph for time conversion functions in C99 (7.23.3 para 1 in N1256). There is also a wording difference with C99 that is worth fixing.
On page 600 line 20907 section asctime(),
page 727 line 24771 section ctime(),
page 1113 line 37681 section gmtime(),
page 1265 line 42218 section localtime(), remove CX shading from:
The asctime(), ctime(), gmtime(), and localtime() functions shall return values in one of two static objects: a broken-down time structure and an array of type char. Execution of any of the functions may overwrite the information returned in either of these objects by any of the other functions.
and change it to:
The asctime(), ctime(), gmtime(), and localtime() functions shall return values in one of two static objects: a broken-down time structure and an array of type char. Execution of any of the functions that return a pointer to one of these object types may overwrite the information in any object of the same type pointed to by the value returned from any previous call to any of them.

There are no notes attached to this issue.




Viewing Issue Advanced Details
1375 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Error 2020-07-15 14:08 2021-01-13 16:03
geoffclare
 
normal  
Applied  
Accepted As Marked  
   
Geoff Clare
The Open Group
scanf(), fwscanf()
950, 1004, 1006
32272, 34177, 34248, 34263
---
See Note: 0005183
*scanf() 'm' allocation char v. wchar_t problems
Various parts of the text relating to the 'm' allocation character on the fscanf() and fwscanf() pages do not correctly account for the difference between conversions that use the 'l' modifier and those that don't.

In some cases the text is improved by bug 0001173 but is still affected.
On page 950 line 32272 section fscanf(), after applying bug 1173 change:
... terminating null character.
to:
... terminating null character or wide character.

On page 1004 line 34177 section fwscanf(), after applying bug 1173 change:
... terminating null wide character.
to:
... terminating null character or wide character.

On page 1006 line 34248,34263 section fwscanf(), change two occurrences of:
wchar_t
to:
char
(This results in 's' and '[' each having one char and one wchar_t, the same as 'c'.)
Notes
(0005183)
nick   
2020-12-17 16:36   
On page 950 line 32272 section fscanf(), after applying bug 1173 change:...
... terminating null character.

to:
    
... terminating null character (or wide character).

    
On page 1004 line 34177 section fwscanf(), after applying bug 1173 change:
    
... terminating null wide character.

to:
    
... terminating null character (or wide character).

    
On page 1006 line 34248,34263 section fwscanf(), change two occurrences of:
wchar_t

to:
char




Viewing Issue Advanced Details
1374 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Error 2020-07-15 09:30 2021-01-13 16:01
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
ungetwc()
2195
70178
---
Value of file-position indicator after ungetwc()
The ungetwc() page says "The file-position indicator is decremented (by one or more) by each successful call to ungetwc(); if its value was 0 before a call, its value is unspecified after the call."

(Bug 0000701 changes "indicator is decremented" to "indicator for the stream shall be decremented".)

This implies that if the position is at 1 byte and ungetwc() pushes back a wide character that converts to 2 bytes, then the position is required to be set to -1.

The current text derives from XPG4 and does not match C99 (and is not CX shaded). The C99 text is the same as the original (1995) MSE spec. It says "the value of its file position indicator after a successful call to the ungetwc function is unspecified until all pushed-back wide characters are read or discarded".

It appears that when the MSE was incorporated into SUSv2 this discrepancy went unnoticed and the defective XPG4 text has been retained until now.
After applying bug 701, change:
The file-position indicator for the stream shall be decremented (by one or more) by each successful call to ungetwc(); if its value was 0 before a call, its value is unspecified after the call. The value of the file-position indicator after all pushed-back characters have been read shall be the same as it was before the characters were pushed back.
to:
The value of the file-position indicator for the stream after a successful call to ungetwc() is unspecified until all pushed-back wide characters are read or discarded; its value after all pushed-back wide characters have been read shall be the same as it was before the wide characters were pushed back.

Notes
(0004897)
shware_systems   
2020-07-15 14:22   
I think both XPG4 and the C standard are in error. The behavior is nominally unspecified only when the effective file position is less than the number of chars to be pushed back. Otherwise the position will be greater than or equal to zero. The ungetc() description reflects this generalization for its particular case where the char count is 1; 0 as position on entry is the only problematic value for most physical media.

Note both descriptions are only valid for the limiting case where the bit width for a byte of physical media equals the CHAR_BITS value. Additional complications neither standard addresses exist when this isn't the case. As exemplified by the <termios.h> header this isn't the general case for serial ports accessed via FILE * records, where the bit width may be from 5 to 8. For the C standard, where CHAR_BITS may be up to 15, this applies also when physical media uses 8 bit bytes, the expected behavior is left undefined, not even unspecified.




Viewing Issue Advanced Details
1373 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Error 2020-07-14 09:01 2021-01-13 15:58
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
test
3288
110620
---
The '[' utility does not conform to syntax guidelines 1 and 2
As noted in Note: 0004769 in bug 252, the description of the '[' form of the test utility needs to be updated to reflect the fact that it does not conform to Guidelines 1 and 2.
After:
The test utility shall not recognize the "--" argument in the manner specified by Guideline 10 in XBD Section 12.2 (on page 216).
add a new sentence:
In addition, when the utility name used is [ the utility does not conform to Guidelines 1 and 2.

There are no notes attached to this issue.




Viewing Issue Advanced Details
1372 [1003.1(2016/18)/Issue7+TC2] Rationale Comment Error 2020-07-13 09:25 2021-01-13 15:57
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
A.3 (Mount Point)
3498
118283
---
Rationale says there is no mount point definition, but there is
XRAT A.3 has an entry for "Mount Point" with an asterisk, indicating that there is no definition for "Mount Point". This entry should have been removed when the definition of "Mount Point" was added to XBD.

There is also a cross-reference to this entry under "Root of a File System".
On page 3498 line 118283 section A.3, delete:
Mount Point*

The directory on which a ``mounted file system'' is mounted. This term, like mount() and umount(), was not included because it was implementation-defined.

On page 3501 line 118411 section A.3, change:
Implementation-defined; see Mount Point* (on page 3498).
to:
Commonly used to refer to a mount point; this standard uses the latter.
There are no notes attached to this issue.




Viewing Issue Advanced Details
1371 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Objection Clarification Requested 2020-07-10 14:29 2020-12-18 09:16
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
3.370 Stream
93
2583
---
Definition of stream is XSH-specific
The definition of the term "stream" says it is a "file access object [...] as described by the ISO C standard" and says these objects can be created using fdopen(), etc.

This is XSH-specific, but the term needs to apply to XCU as well. In particular, the current definitions of "standard error", "standard input" and "standard output" are the ones from POSIX.2-1992 and they use the word "stream". In that standard, the definition of "stream" was:
An ordered sequence of characters, as described by the C Standard
which, although it also refers to the C Standard, does not associate "stream" with a file access object.

The definition also says streams are "associated with a file descriptor", but this is not true for streams opened with fmemopen() or open_memstream().
Change:
Appearing in lowercase, a stream is a file access object that allows access to an ordered sequence of characters, as described by the ISO C standard. Such objects can be created by the fdopen(), fmemopen(), fopen(), open_memstream(), or popen() functions, and are associated with a file descriptor.
to:
Appearing in lowercase, a stream is an ordered sequence of bytes, as described by the ISO C standard.

In the shell command language, each stream is associated with a file descriptor. These can be opened using redirection operators.

<small>Note:
Redirection is defined in detail in [xref to XCU 2.7].</small>
In the C language, each stream is accessed via a file access object and is either a stream associated with a file descriptor or a memory stream. A file access object associated with a file descriptor can be created by the fdopen(), fopen(), or popen() functions. A file access object for a memory stream can be created by the fmemopen() or open_memstream() functions.
There are no notes attached to this issue.




Viewing Issue Advanced Details
1370 [Issue 8 drafts] Rationale Editorial Error 2020-07-10 09:21 2020-09-30 14:27
geoffclare
 
normal  
Applied  
Accepted As Marked  
   
Geoff Clare
The Open Group
B.1.1, C.1.1
3433, 3555
117421, 122714
See Note: 0004992.
Where change history starts
XRAT B.1.1 says:
The CHANGE HISTORY section for each entry details the technical changes that have been made to that entry from Issue 5. Changes between earlier versions of the base document and Issue 5 are not included.

and C.1.1 says:
The CHANGE HISTORY section for each utility describes technical changes made to that utility from Issue 5. Changes between earlier versions of the base document and Issue 5 are not included.

These statements are not actually true. The change history starts with an "Issue 5" subheading, but changes listed under that subheading give the changes made in Issue 5, not the changes from Issue 5. So the changes between Issue 4 Version 2 and Issue 5 are included, contrary to what the second sentence of each of those paragraphs says.

However, rather than fixing this text, perhaps what we should do is make it true. I.e. remove change history before the "Issue 6" subheading.

Looking back at how much change history was included in old versions:
  • XPG4 only had 1 heading: "Issue 4"
  • SUSv1 had 2: "Issue 4" and "Issue 4, Version 2"
  • SUSv2 had 3: "Issue 4", "Issue 4, Version 2", and "Issue 5"
  • SUSv3 had 2: "Issue 5" and "Issue 6"
  • SUSv4 had 3: "Issue 5", "Issue 6" and "Issue 7"
If we don't remove "Issue 5" in SUSv5, it will have 4 headings which is more than any previous version. Also, since Issue 6 was the POSIX.1/SUS merge, it seems like a good place to start the change history.
On each header, function, built-in utility, and utility page that has an "Issue 5" subheading under CHANGE HISTORY, delete from that heading down to (but not including) the next subheading.
Notes
(0004992)
rhansen   
2020-09-14 15:57   
On page 3433 line 117421 (XRAT B.1.1) change:
The CHANGE HISTORY section for each entry details the technical changes that have been made to that entry from Issue 5. Changes between earlier versions of the base document and Issue 5 are not included.
to:
The CHANGE HISTORY section for each entry details the technical changes that have been made in Issue 5 and later. Changes made before Issue 5 are not included.

On page 3555 line 122714 (XRAT C.1.1) change:
The CHANGE HISTORY section for each utility describes technical changes made to that utility from Issue 5. Changes between earlier versions of the base document and Issue 5 are not included.
to:
The CHANGE HISTORY section for each utility describes technical changes made to that utility in Issue 5 and later. Changes made before Issue 5 are not included.




Viewing Issue Advanced Details
1369 [Issue 8 drafts] Rationale Comment Error 2020-07-09 11:11 2020-09-30 14:25
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
A.8.3
3407
116496
COLUMNS and LINES rationale
Bug 0001185 made changes to the descriptions of COLUMNS and LINES in XBD, but did not change XRAT to match.
Change:
The default values for the number of column positions, COLUMNS, and screen height, LINES, are unspecified because historical implementations use different methods to determine values corresponding to the size of the screen in which the utility is run. This size is typically known to the implementation through the value of TERM, or by more elaborate methods such as extensions to the stty utility or knowledge of how the user is dynamically resizing windows on a bit-mapped display terminal.
to:
The default values for the number of column positions when COLUMNS is unset or null, and screen height when LINES is unset or null, are unspecified if the terminal window size cannot be obtained (from tcgetwinsize()) because historical implementations use different methods to determine the values.

There are no notes attached to this issue.




Viewing Issue Advanced Details
1368 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Enhancement Request 2020-07-08 23:10 2021-01-29 11:32
steffen
 
normal  
Applied  
Accepted As Marked  
   
Steffen Nurpmeso
Vol. 3: Shell and Utilities, at, batch
2479, 2523
79636 ff., 81458 ff.
---
Note: 0005168
Unworldly use of redirection and mailx(1) in at(1) and batch(1) examples.
The sequence

 at now + 1 hour <<!
 diff file1 file2 2>&1 >outfile | mailx mygroup
 !

(likewise for batch(1)) sends out a possibly empty message to the work group "mygroup", which is a very low quality example that seems unworldly.
If the -E option of mailx(1) becomes standardized (as requested in issue #1367) the above could become wonderful examples for the power of the *X shell environment, and simply be changed to

 at now + 1 hour <<!
 diff file1 file2 2>&1 >outfile | mailx -E mygroup
 !

(likewise for batch(1)). Otherwise change

 at now + 1 hour <<!
 diff file1 file2 2>&1 >outfile | mailx -E mygroup
 !

to

 2. This sequence, which demonstrates redirecting standard error to a pipe, and carefully avoiding of false conditional status codes, is useful in a command procedure (the sequence of output redirection specifications is significant),

 at now + 1 hour <<!
 exec >errfile
 diff file1 file2 2>&1 >outfile
 if [ -s errfile ]; then
   < errfile mailx mygroup
 fi
 !
Notes
(0005168)
rhansen   
2020-12-14 16:43   
(edited on: 2021-01-14 16:43)
After applying the changes from 0001347 make the following changes:

On page 2479 lines 79638-79640 (XCU at EXAMPLES) change:
at now + 1 hour <<!
diff file1 file2 2>&1 >outfile | mailx mygroup
!
to:
at now + 1 hour <<EOF
diff file1 file2 2>&1 >outfile | mailx -s "outfile update" mygroup
EOF
Note that this always sends mail when there has been an attempt to update outfile and the body of the message will be empty unless an error occurred.

3. The following shows how to capture both standard error and standard output:
at now + 1 hour <<EOF
{
    run-batch-procesing |
        mailx -s "batch processing output" mygroup
} 2>&1 | mailx -E -s "errors during batch processing" mygroup
EOF
and renumber the later examples.

On page 2523 lines 81460-81462 (XCU batch EXAMPLES) change:
batch <<!
diff file1 file2 2>&1 >outfile | mailx mygroup
!
to:
batch <<EOF
diff file1 file2 2>&1 >outfile | mailx -s "outfile update" mygroup
EOF
Note that this always sends mail when there has been an attempt to update outfile and the body of the message will be empty unless an error occurred.

3. The following shows how to capture both standard error and standard output:
batch <<EOF
{
    run-batch-procesing |
        mailx -s "batch processing output" mygroup
} 2>&1 | mailx -E -s "errors during batch processing" mygroup
EOF


(0005201)
rhansen   
2021-01-14 16:46   
Note: 0005168 was updated to address feedback sent to the mailing list:

https://www.mail-archive.com/austin-group-l@opengroup.org/msg07304.html [^]




Viewing Issue Advanced Details
1367 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Enhancement Request 2020-07-08 22:55 2020-12-16 16:41
steffen
 
normal  
Applied  
Accepted As Marked  
   
Steffen Nurpmeso
Vol. 3: Shell and Utilities, mailx
2943, 2944
97431, 97471 ff.
---
Note: 0005162
mailx: add -E option to discard (not send) empty messages
The mailx variants of Apple, NetBSD, OpenBSD as well as other Open Source incarnations, support a command line option -E that rejects sending empty messages, successfully.

This is very helpful in scripted use cases since possible error notifications will only be send out if necessary.

The backing value ("INTERNAL VARIABLE") is different (skipemptybody, dontsendempty, skipempty, to name a few), but the behaviour of the -E option itself is identical.

The only known mailx incarnation which does not support -E is Solaris (OpenIndiana inspected), but the implementation is simplicistic since mailx warns on empty messages, the code change would need to turn

  if (fsize(mtf) == 0 && hp->h_subject == NOSTR) {
    printf(gettext("No message !?!\n"));
    goto out;
  }

into

  if (fsize(mtf) == 0) {
    if (value("dontsendempty") != NOSTR)
      goto jout;
    if (hp->h_subject == NOSTR) {
      printf(gettext("No message !?!\n"));
      goto out;
    }
  }
On page 2943, line 97431, change

  mailx [−s subject] address...

into

  mailx [-E] [−s subject] address...

On page 2944, insert after line 97471

  -E Discard messages with an empty message body, successfully.
Notes
(0004895)
geoffclare   
2020-07-09 08:01   
Line 98259 in EXIT STATUS also needs to change. I suggest changing:
Successful completion; note that this status implies that all messages were sent, ...
to:
Successful completion; note that this status implies that all messages were sent, or successfully discarded (see -E), ...


(0004896)
steffen   
2020-07-09 13:25   
..and the Solaris / OpenIndiana should allow all-empty messages by default, nothing is wrong with them, they are the shortest possible mail-based notification ("ping"), which in practice is nice since in practice the MTA / LDA (Mail-Transfer-Agent, Local-Delivery-Agent) adds at least a so-called From_, but especially the former also a From: line, for example

  #?0|kent:steffen$ </dev/null mailx -:/ root
  mailx: No message, no subject; hope that's ok
  #?0|kent:steffen$ tail -n 13 /var/spool/mail/steffen

  From steffen@localhost Thu Jul 9 15:22:56 2020
  Received: from steffen (uid 1000)
          (envelope-from steffen@localhost)
          id a791
          by kent (DragonFly Mail Agent v0.13);
          Thu, 09 Jul 2020 15:22:56 +0200
  Date: Thu, 09 Jul 2020 15:22:56 +0200
  To: root
  User-Agent: mailx v14.9.19
  Message-Id: <5f071a30.a791.1071c30e@kent>
  From: <steffen@localhost>

  #?0|kent:steffen$

The BSD based code does

        if (fsize(mtf) == 0) {
                if (value("skipempty") != NULL)
                        goto out;
                if (hp->h_subject == NULL || *hp->h_subject == '\0')
                        puts("No message, no subject; hope that's ok");
                else
                        puts("Null message body; hope that's ok");
        }

Which, finally, and as an off-topic note, makes me think the root of the related issue 0001368 was caused by experiences with SysV based mail.
(0005162)
rhansen   
2020-12-10 17:23   
On page 2943 line 97431 (mailx SYNOPSIS) change:
<tt>mailx [−s subject] address...</tt>
to:
<tt>mailx [-E] [−s subject] address...</tt>

On page 2944, insert after line 97471:
-E Discard messages with an empty message body.

On page 2964 line 98259 (mailx EXIT STATUS) change:
Successful completion; note that this status implies that all messages were sent, ...
to:
Successful completion; note that in Send Mode this status implies that all messages were either sent or successfully discarded (see -E), ...
(0005182)
geoffclare   
2020-12-16 16:41   
When applying this bug I also made an editorial change to page 2944 line 97467 from:
(Only the -s subject option shall be required on all systems...
to:
(Only the -E and -s subject options are required on all systems...




Viewing Issue Advanced Details
1366 [Issue 8 drafts] Rationale Comment Error 2020-07-08 15:20 2020-09-30 14:24
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
A.3 Definitions (XSI)
3379
115320
Out of date rationale for XSI definition
The rationale for the XSI definition says:
The term ``XSI'' has been used for 10 years in connection with the XPG series and the first and second versions of the base volumes of the Single UNIX Specification. The XSI margin code was introduced to denote the extended or more restrictive semantics beyond POSIX that are applicable to UNIX systems.
The use of "has" was okay when the text was written (for Issue 6), but is now a problem.
Change:
The term ``XSI'' has been used for 10 years ...
to:
When POSIX.1 and the Single UNIX Specification were merged, the term ``XSI'' had been used for over 10 years ...
There are no notes attached to this issue.




Viewing Issue Advanced Details
1365 [Issue 8 drafts] Shell and Utilities Objection Error 2020-07-07 09:36 2020-09-30 14:22
geoffclare
 
normal  
Applied  
Accepted  
   
Geoff Clare
The Open Group
rm
3066
103824
rm -v description implies only operands are reported
The changes from bug 0001154 to add rm -v were supposed to require that rm reports each file that it removes. However, the description of -v is:
After file has been removed, write a message to standard output indicating that it has been removed.
which implies that rm -rv only reports the removal of file operands and does not report the removal of files within a directory specified as an operand.

The changes at line 103806 correctly state that each removed file is reported.

Line 103858 in STDOUT also has two minor problems:
  • Use of "the file" is odd, as if rm only ever removes one file.
  • The phrase "being removed" implies that something could be written before the removal attempt is made, rather than (as per the other changes) only after successful removal.

On page 3066 line 103824 section rm, change:
After file has been removed
to:
After each file has been removed

On page 3067 line 103858 section rm, change:
information about the file being removed
to:
information about each removed file
There are no notes attached to this issue.