[Issue 8 drafts 0001824]: cp: directories and symlinks
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1824
==
Reported By:dag-erling
Assigned To:
==
Project:Issue 8 drafts
Issue ID: 1824
Category: Shell and Utilities
Type: Clarification Requested
Severity: Editorial
Priority: normal
Status: New
Name: Dag-Erling Smørgrav
Organization:
User Reference:
Section:Utilities
Page Number:2741-2748
Line Number:90593-90715, 90876-90880
Final Accepted Text:
==
Date Submitted: 2024-04-01 15:31 UTC
Last Modified: 2024-06-10 18:16 UTC
==
Summary:cp: directories and symlinks
==
--
(0006807) eblake (manager) - 2024-06-10 18:16
https://austingroupbugs.net/view.php?id=1824#c6807
--
A lot of this stems from Linux's intentional decision years ago that when
readlink("dangling") returns "newdir" but stat("dangling") fails with
ENOENT, then rename("olddir", "dangling/") should fail with ENOTDIR,
instead of leaving "dangling" intact as a symlink and renaming "olddir" to
"newdir". It is not just rename() affected; mkdir(), unlink(), and several
other Linux syscalls intentionally refuse to dereference through a symlink
followed by a trailing slash on the grounds that it is somewhat ambiguous
on whether you wanted to act on a (potential) directory name or on the
symlink itself.
Is it time to recognize the Linux syscall behaviors on dangling symlinks as
a valid alternative to traditional Unix behavior (a much bigger change to
identify all of those affected interfaces, but would make it easier for
Linux to finally comply with POSIX), or are we only wanting to paper over
this scenario at the command line interface of cp despite Linux being
unwilling to change kernel behavior at the C level, or something else
altogether?
Issue History
Date ModifiedUsername FieldChange
==
2024-04-01 15:31 dag-erling New Issue
2024-04-01 15:31 dag-erling Name => Dag-Erling
Smørgrav
2024-04-01 15:31 dag-erling Section => Utilities
2024-04-01 15:31 dag-erling Page Number => 2741-2748
2024-04-01 15:31 dag-erling Line Number => 90593-90715,
90876-90880
2024-04-02 06:19 dannyniu Note Added: 0006731
2024-04-02 06:20 dannyniu Note Added: 0006732
2024-04-02 06:21 dannyniu Note Deleted: 0006732
2024-04-02 06:22 dannyniu Note Edited: 0006731
2024-04-02 15:51 geoffclare Note Added: 0006734
2024-04-04 14:30 geoffclare Note Added: 0006737
2024-04-04 16:01 dag-erling Note Added: 0006739
2024-04-04 16:59 geoffclare Note Added: 0006740
2024-04-04 18:19 geoffclare Note Edited: 0006740
2024-04-05 08:16 geoffclare Note Edited: 0006740
2024-04-05 11:33 dag-erling Note Added: 0006741
2024-04-08 08:39 geoffclare Note Added: 0006743
2024-04-08 08:42 geoffclare Note Edited: 0006737
2024-04-08 08:44 geoffclare Note Edited: 0006743
2024-05-20 09:26 geoffclare Note Added: 0006788
2024-05-20 09:28 geoffclare Note Edited: 0006788
2024-06-10 18:16 eblake Note Added: 0006807
==
[Issue 8 drafts 0001832]: Add preadv() and pwritev()
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1832 == Reported By:alanc Assigned To: == Project:Issue 8 drafts Issue ID: 1832 Category: System Interfaces Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Alan Coopersmith Organization: User Reference: Section:System Interfaces Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text: == Date Submitted: 2024-05-24 21:48 UTC Last Modified: 2024-05-27 20:04 UTC == Summary:Add preadv() and pwritev() == -- (0006806) steffen (reporter) - 2024-05-27 20:04 https://austingroupbugs.net/view.php?id=1832#c6806 -- This remark surely belongs to Rich Felker of musl, also because he wrote the Linux kernel patch, i think (to remember), but i want to add a note .. or, let me paste parts of a musl commit message instead: POSIX requires pwrite to honor the explicit file offset where the write should take place even if the file was opened as O_APPEND. however, linux historically defined the pwrite syscall family as honoring O_APPEND. this cannot be changed on the kernel side due to stability policy, but the addition of the pwritev2 syscall with a flags argument opened the door to fixing it this patch changes the pwrite function to first attempt using the pwritev2 syscall with RWF_NOAPPEND, falling back to using the old pwrite syscall only after checking that O_APPEND is not set for the open file. if O_APPEND is set, the operation fails with EOPNOTSUPP, reflecting that the kernel does not support the correct behavior. this is an extended error case needed to avoid the wrong behavior that happened before (writing the data at the wrong location), and is aligned with the spirit of the POSIX requirement that "An attempt to perform a pwrite() on a file that is incapable of seeking shall result in an error." since the pwritev2 syscall interprets the offset of -1 as a request to write at the current file offset, it is mapped to a different negative value that will produce the expected error. pwritev, though not governed by POSIX at this time, is adjusted to match pwrite in honoring the offset. Issue History Date ModifiedUsername FieldChange == 2024-05-24 21:48 alanc New Issue 2024-05-24 21:48 alanc Name => Alan Coopersmith 2024-05-24 21:48 alanc Section => System Interfaces 2024-05-24 21:48 alanc Page Number => (page or range of pages) 2024-05-24 21:48 alanc Line Number => (Line or range of lines) 2024-05-24 21:56 Guy Harris Note Added: 0006800 2024-05-25 23:10 alanc Note Added: 0006803 2024-05-26 00:03 philip-guentherNote Added: 0006804 2024-05-26 02:43 Guy Harris Note Added: 0006805 2024-05-27 20:04 steffenNote Added: 0006806 ==
[Issue 8 drafts 0001832]: Add preadv() and pwritev()
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1832 == Reported By:alanc Assigned To: == Project:Issue 8 drafts Issue ID: 1832 Category: System Interfaces Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Alan Coopersmith Organization: User Reference: Section:System Interfaces Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text: == Date Submitted: 2024-05-24 21:48 UTC Last Modified: 2024-05-26 02:43 UTC == Summary:Add preadv() and pwritev() == -- (0006805) Guy Harris (reporter) - 2024-05-26 02:43 https://austingroupbugs.net/view.php?id=1832#c6805 -- > and even to have a future direction that they be forbidden from being cancellation points. Given that macOS has both "preadv" and "preadv_nocancel" system calls, and that the GNU libc used in most Linux systems has both "preadv()" and "__preadv_nocancel()" routines, it's likely that "preadv()" is a cancellation point on both those OSes, so that might cause problems. Furthermore, on both those OSes (and most if not all other UN*Xes), "slow" operation scan occur on special files other than ttys, *and* those special files might use the seek offset, so there might well be cases where making pthreadv() not a cancellation point would cause problems, even if it doesn't cause problems for POSIX-conformant programs. So I would recommend against that. Instead, if there is a demand for non-cancellation-point calls, I would recommend, for a future direction, that _nocancel versions of calls be added. I don't know why neither macOS nor GNU(libc)/Linux provide _nocanncel versions of those APIs, but, other than the namespace pollution issues, it would be trivial to provide them, at least in those OSes. Issue History Date ModifiedUsername FieldChange == 2024-05-24 21:48 alanc New Issue 2024-05-24 21:48 alanc Name => Alan Coopersmith 2024-05-24 21:48 alanc Section => System Interfaces 2024-05-24 21:48 alanc Page Number => (page or range of pages) 2024-05-24 21:48 alanc Line Number => (Line or range of lines) 2024-05-24 21:56 Guy Harris Note Added: 0006800 2024-05-25 23:10 alanc Note Added: 0006803 2024-05-26 00:03 philip-guentherNote Added: 0006804 2024-05-26 02:43 Guy Harris Note Added: 0006805 ==
[Issue 8 drafts 0001832]: Add preadv() and pwritev()
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1832 == Reported By:alanc Assigned To: == Project:Issue 8 drafts Issue ID: 1832 Category: System Interfaces Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Alan Coopersmith Organization: User Reference: Section:System Interfaces Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text: == Date Submitted: 2024-05-24 21:48 UTC Last Modified: 2024-05-25 23:10 UTC == Summary:Add preadv() and pwritev() == -- (0006803) alanc (reporter) - 2024-05-25 23:10 https://austingroupbugs.net/view.php?id=1832#c6803 -- If added, preadv() and pwritev() should also be considered to be added to the list of Cancellation Points in the Thread Cancellation section, to match readv/writev/pread/pwrite. Issue History Date ModifiedUsername FieldChange == 2024-05-24 21:48 alanc New Issue 2024-05-24 21:48 alanc Name => Alan Coopersmith 2024-05-24 21:48 alanc Section => System Interfaces 2024-05-24 21:48 alanc Page Number => (page or range of pages) 2024-05-24 21:48 alanc Line Number => (Line or range of lines) 2024-05-24 21:56 Guy Harris Note Added: 0006800 2024-05-25 23:10 alanc Note Added: 0006803 ==
[Issue 8 drafts 0001832]: Add preadv() and pwritev()
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1832 == Reported By:alanc Assigned To: == Project:Issue 8 drafts Issue ID: 1832 Category: System Interfaces Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Alan Coopersmith Organization: User Reference: Section:System Interfaces Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text: == Date Submitted: 2024-05-24 21:48 UTC Last Modified: 2024-05-26 00:03 UTC == Summary:Add preadv() and pwritev() == -- (0006804) philip-guenther (reporter) - 2024-05-26 00:03 https://austingroupbugs.net/view.php?id=1832#c6804 -- I suggest that preadv/pwritev be documented to MAY be cancellation points and not MUST be, and even to have a future direction that they be forbidden from being cancellation points. The argument is that being a cancellation point is proper for 'slow' operations, which may block for an arbitrary length of time and where EINTR would otherwise be an appropriate return-value**. For read/write those conditions can occur on sockets, pipes, FIFOs, and ttys...but none of those are valid for preadv/pwritev! Yes, this argument applies to pread/pwrite too. IMHO, I think that the standard's current requirement for them should be weakened to a MAY as well with a future direction to completely remove permission for them to be cancellation points. Compare this with fcntl() which is only required to be a cancellation point when the cmd is F_SETLKW, the only 'unbounded blocking' call. For pread/pwrite/preadv/pwritev we know they can't exhibit that: why is it natural for them to be cancellation points? ** Yes, yes, that's not the precise statement of when cancellation would be expected to be tested, but hopefully the point it clear Issue History Date ModifiedUsername FieldChange == 2024-05-24 21:48 alanc New Issue 2024-05-24 21:48 alanc Name => Alan Coopersmith 2024-05-24 21:48 alanc Section => System Interfaces 2024-05-24 21:48 alanc Page Number => (page or range of pages) 2024-05-24 21:48 alanc Line Number => (Line or range of lines) 2024-05-24 21:56 Guy Harris Note Added: 0006800 2024-05-25 23:10 alanc Note Added: 0006803 2024-05-26 00:03 philip-guentherNote Added: 0006804 ==
[Issue 8 drafts 0001832]: Add preadv() and pwritev()
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1832 == Reported By:alanc Assigned To: == Project:Issue 8 drafts Issue ID: 1832 Category: System Interfaces Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Alan Coopersmith Organization: User Reference: Section:System Interfaces Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text: == Date Submitted: 2024-05-24 21:48 UTC Last Modified: 2024-05-25 23:10 UTC == Summary:Add preadv() and pwritev() == -- (0006803) alanc (reporter) - 2024-05-25 23:10 https://austingroupbugs.net/view.php?id=1832#c6803 -- If added, preadv() and pwritev() should also be considered to be added to the list of Cancellation Points in the Thread Cancellation section, to match readv/writev/pread/pwrite. Issue History Date ModifiedUsername FieldChange == 2024-05-24 21:48 alanc New Issue 2024-05-24 21:48 alanc Name => Alan Coopersmith 2024-05-24 21:48 alanc Section => System Interfaces 2024-05-24 21:48 alanc Page Number => (page or range of pages) 2024-05-24 21:48 alanc Line Number => (Line or range of lines) 2024-05-24 21:56 Guy Harris Note Added: 0006800 2024-05-25 23:10 alanc Note Added: 0006803 ==
[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1797 == Reported By:eggert Assigned To: == Project:Issue 8 drafts Issue ID: 1797 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Paul Eggert Organization: UCLA Computer Science Dept. User Reference: strftime-%s Section:strftime Page Number:2136 Line Number:69836-69837 Final Accepted Text: == Date Submitted: 2024-01-15 23:56 UTC Last Modified: 2024-05-25 17:12 UTC == Summary:strftime "%s" should be able to examine tm_gmtoff == Relationships ID Summary -- related to 0001533 struct tm: add tm_gmtoff (and tm_zone) ... related to 0001816 daylight, timezone, tzname do not work ... child of0001612 XSH strftime() new (I8) %s conversion r... child of169 date utility needs ``%s'' == -- (0006802) kre (reporter) - 2024-05-25 17:12 https://austingroupbugs.net/view.php?id=1797#c6802 -- Re https://austingroupbugs.net/view.php?id=1797#c6801 there are many ways a conforming C application can set tm_zone. There cannot be, as C does not have such a field, any attempt to reference it, in any way, directly or indirectly, would be non-conforming. [...] I cited in https://austingroupbugs.net/view.php?id=1797#c6793 all set tm_zone by calling gmtime That's not the application setting tm_zone (etc) it is the implementation. That's allowed, as an extension to the standard. And while the application certainly knows it called gmtime() there is no way (assuming it is a conforming C application) that it can deduce from doing so that tm_zone (or tm_gmtoff which is more relevant for %s) was set by that call. Such a program should be able to be compiled and run on a system in which gmtime() does not set those fields, which is perfectly allowable for implementations of the C standard (it will not be for POSIX applications after the new standard appears, at least for implementations claiming conformance). On such a system the (conforming) program should run and produce the same results as on a system that happens to set the new fields. Furthermore, strftime() needs to work correctly when the struct tm passed to it has never seen the results of any previous implementation provided function, and also when it has, but that was in some previous incarnation, whose use has been completed, and the struct has now been repurposed to be used just for strftime, with values entirely unrelated to the one it was previously used for, and only the required values for the format string used assigned (new) values. Unless you can provide me with text in the C or POSIX standard which says that gmtime() localtime() or something equivalent must have generated (or updated, perhaps via mktime()) any struct tm which is to be passed to strftime() then the implementation of strftime() simply *must* work when that has not happened. "work" means producing the correct result, which then is obviously also required to be the result if struct tm with the same required field values had been produced by localtime() or gmtime() - two different results cannot both be correct (normally anyway). It makes no difference how common it might be for strftime() to be called with a struct tm returned from localtime() or gmtime(). Unless there is a requirement somewhere making that mandatory for applications, then we cannot assume that it has happened. Nor can we require that tm_gmtoff or tm_zone be set by the application, as conforming C applications cannot do that, and strftime() is a C standard interface (it would be different were it one added by POSIX.) It is irrelevant how many non-conforming, extended, or simply buggy, implementations, or applications which depend upon them, you can find. And I'd note, that until earlier this year, your implementation (or ado's or whoever it was who added strftime()), which I suspect is, or is the basis of, most real world implementation
[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1797 == Reported By:eggert Assigned To: == Project:Issue 8 drafts Issue ID: 1797 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Paul Eggert Organization: UCLA Computer Science Dept. User Reference: strftime-%s Section:strftime Page Number:2136 Line Number:69836-69837 Final Accepted Text: == Date Submitted: 2024-01-15 23:56 UTC Last Modified: 2024-05-24 22:56 UTC == Summary:strftime "%s" should be able to examine tm_gmtoff == Relationships ID Summary -- related to 0001533 struct tm: add tm_gmtoff (and tm_zone) ... related to 0001816 daylight, timezone, tzname do not work ... child of0001612 XSH strftime() new (I8) %s conversion r... child of169 date utility needs ``%s'' == -- (0006801) eggert (reporter) - 2024-05-24 22:56 https://austingroupbugs.net/view.php?id=1797#c6801 -- > A conforming C application cannot set tm_zone as no such thing exists. No, there are many ways a conforming C application can set tm_zone. The several real-world applications I cited in https://austingroupbugs.net/view.php?id=1797#c6793 all set tm_zone by calling gmtime, and these apps work fine on GNU/Linux, macOS, z/OS, etc. This is common practice. Obviously we disagree about how to interpret POSIX. I find the overly-strict interpretation unconvincing because (a) significant real-world implementations have disagreed with that interpretation for decades, (b) it's easy to find real-world applications that rely on these implementations' behavior, and (c) it's hard to find real-world applications that rely on the overly-strict interpretation. This is not a new issue. What's new is that this lack of clarity or glitch in the standards is being brought to the standardization bodies' attention. Issue History Date ModifiedUsername FieldChange == 2024-01-15 23:56 eggert New Issue 2024-01-15 23:56 eggert Name => Paul Eggert 2024-01-15 23:56 eggert Organization => UCLA Computer Science Dept. 2024-01-15 23:56 eggert User Reference=> strftime-%s 2024-01-15 23:56 eggert Section => strftime 2024-01-15 23:56 eggert Page Number => 2136 2024-01-15 23:56 eggert Line Number => 69836-69837 2024-01-16 01:29 steffenNote Added: 0006623 2024-01-16 01:42 steffenNote Added: 0006624 2024-01-16 01:42 steffenNote Deleted: 0006623 2024-02-01 16:42 nick Relationship added related to 0001533 2024-02-12 16:11 eblake Note Added: 0006651 2024-02-25 06:50 kreNote Added: 0006677 2024-02-25 06:54 kreNote Edited: 0006677 2024-02-26 18:28 eggert Note Added: 0006688 2024-02-26 19:23 eblake Relationship added related to 0001816 2024-02-26 19:32 eblake Note Added: 0006689 2024-02-26 19:52 eblake Relationship added child of 0001612 2024-02-26 19:55 eblake Relationship added child of 169 2024-02-26 20:02 eblake Note Added: 0006690 2024-02-29 12:10 geoffclare Note Added: 0006691 2024-02-29 12:15 geoffclare Note Added: 0006692 2024-02-29 16:19 shware_systems Note Added: 0006693 2024-03-01 10:09 geoffclare Note Added: 0006698 2024-03-02 09:02 eggert Note Added:
[Issue 8 drafts 0001832]: Add preadv() and pwritev()
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1832 == Reported By:alanc Assigned To: == Project:Issue 8 drafts Issue ID: 1832 Category: System Interfaces Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Alan Coopersmith Organization: User Reference: Section:System Interfaces Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text: == Date Submitted: 2024-05-24 21:48 UTC Last Modified: 2024-05-24 21:48 UTC == Summary:Add preadv() and pwritev() Description: Many implementations offer preadv() and pwritev() interfaces, which are like the existing readv() and writev() APIs, except that they use specified positions instead of the current file offsets, just like the existing pread() and pwrite() versions of read() and write(). FreeBSD: - https://man.freebsd.org/cgi/man.cgi?query=preadv - https://man.freebsd.org/cgi/man.cgi?query=pwritev illumos: - https://illumos.org/man/2/preadv - https://illumos.org/man/2/pwritev Linux (GNU libc): - https://man7.org/linux/man-pages/man2/preadv.2.html NetBSD: - https://man.netbsd.org/preadv.2 - https://man.netbsd.org/pwritev.2 OpenBSD: - https://man.openbsd.org/preadv.2 - https://man.openbsd.org/pwritev.2 Solaris: - (man pages not online yet, just added in 11.4.69 in May 2024) Known consumers include PostgreSQL and libuv, as discussed in the thread at https://twitter.com/MengTangmu/status/1729704220368990235 . Desired Action: Add preadv() and pwritev() to the System Interfaces in Issue 9. == Issue History Date ModifiedUsername FieldChange == 2024-05-24 21:48 alanc New Issue 2024-05-24 21:48 alanc Name => Alan Coopersmith 2024-05-24 21:48 alanc Section => System Interfaces 2024-05-24 21:48 alanc Page Number => (page or range of pages) 2024-05-24 21:48 alanc Line Number => (Line or range of lines) ==
[Issue 8 drafts 0001832]: Add preadv() and pwritev()
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1832 == Reported By:alanc Assigned To: == Project:Issue 8 drafts Issue ID: 1832 Category: System Interfaces Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Alan Coopersmith Organization: User Reference: Section:System Interfaces Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text: == Date Submitted: 2024-05-24 21:48 UTC Last Modified: 2024-05-24 21:56 UTC == Summary:Add preadv() and pwritev() == -- (0006800) Guy Harris (reporter) - 2024-05-24 21:56 https://austingroupbugs.net/view.php?id=1832#c6800 -- macOS has it as well (formatted man pages not online at an Apple site, but their GitHub repository has it in the read(2) man page at https://opensource.apple.com/source/xnu/xnu-7195.60.75/bsd/man/man2/read.2.auto.html). Issue History Date ModifiedUsername FieldChange == 2024-05-24 21:48 alanc New Issue 2024-05-24 21:48 alanc Name => Alan Coopersmith 2024-05-24 21:48 alanc Section => System Interfaces 2024-05-24 21:48 alanc Page Number => (page or range of pages) 2024-05-24 21:48 alanc Line Number => (Line or range of lines) 2024-05-24 21:56 Guy Harris Note Added: 0006800 ==
[Issue 8 drafts 0001832]: Add preadv() and pwritev()
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1832 == Reported By:alanc Assigned To: == Project:Issue 8 drafts Issue ID: 1832 Category: System Interfaces Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Alan Coopersmith Organization: User Reference: Section:System Interfaces Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text: == Date Submitted: 2024-05-24 21:48 UTC Last Modified: 2024-05-24 21:48 UTC == Summary:Add preadv() and pwritev() Description: Many implementations offer preadv() and pwritev() interfaces, which are like the existing readv() and writev() APIs, except that they use specified positions instead of the current file offsets, just like the existing pread() and pwrite() versions of read() and write(). FreeBSD: - https://man.freebsd.org/cgi/man.cgi?query=preadv - https://man.freebsd.org/cgi/man.cgi?query=pwritev illumos: - https://illumos.org/man/2/preadv - https://illumos.org/man/2/pwritev Linux (GNU libc): - https://man7.org/linux/man-pages/man2/preadv.2.html NetBSD: - https://man.netbsd.org/preadv.2 - https://man.netbsd.org/pwritev.2 OpenBSD: - https://man.openbsd.org/preadv.2 - https://man.openbsd.org/pwritev.2 Solaris: - (man pages not online yet, just added in 11.4.69 in May 2024) Known consumers include PostgreSQL and libuv, as discussed in the thread at https://twitter.com/MengTangmu/status/1729704220368990235 . Desired Action: Add preadv() and pwritev() to the System Interfaces in Issue 9. == Issue History Date ModifiedUsername FieldChange == 2024-05-24 21:48 alanc New Issue 2024-05-24 21:48 alanc Name => Alan Coopersmith 2024-05-24 21:48 alanc Section => System Interfaces 2024-05-24 21:48 alanc Page Number => (page or range of pages) 2024-05-24 21:48 alanc Line Number => (Line or range of lines) ==
[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1797 == Reported By:eggert Assigned To: == Project:Issue 8 drafts Issue ID: 1797 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Paul Eggert Organization: UCLA Computer Science Dept. User Reference: strftime-%s Section:strftime Page Number:2136 Line Number:69836-69837 Final Accepted Text: == Date Submitted: 2024-01-15 23:56 UTC Last Modified: 2024-05-24 21:32 UTC == Summary:strftime "%s" should be able to examine tm_gmtoff == Relationships ID Summary -- related to 0001533 struct tm: add tm_gmtoff (and tm_zone) ... related to 0001816 daylight, timezone, tzname do not work ... child of0001612 XSH strftime() new (I8) %s conversion r... child of169 date utility needs ``%s'' == -- (0006799) kre (reporter) - 2024-05-24 21:32 https://austingroupbugs.net/view.php?id=1797#c6799 -- Re https://austingroupbugs.net/view.php?id=1797#c6798 But we are talking about what strftime should do with struct tm values outside the normal range. No, we aren't. strftime() is clear the results are unspecified if the relevant fields aren't within the normal range(s). You can do what you like in that case (but only the relevant fields, when converting %a for example, it isirrelevant what tn_mday or tm_mon or ... are set to, just tm_wday). The same goes for all of the conversions. The C standard says that strftime can consult tm_isdst for %Z. I don't have that one in front of me, but I doubt it says anything much different than posix says, which is: The appropriate characters are 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. What that means is that the specified fields of the struct tm (the "broken-down time structure") are all that the application needs to ensure are set in order to perform a specific conversion. While you're certainly correct that the implementation can look at other data, that other data cannot come from the struct, as there's no expectation that any of that will have been set by the application, and there's no field in the struct (which would need to be some kind of checksum to detect changes to other fields made by the application) by which it is possible to determine that other fields have consistent values with the fields of interest to the conversion. But yes, you can certainly use what is in TZ, or anything obtained from its use, and anything you can get from the LC_TIME locale. And while: tm_zone is an extension to the C standard and the C standard has nothing to say about what tm_zone’s contents can or should be. is certainly true, this conclusion: And requiring tm_zone to have sensible contents is not a violation either: is incorrect. A conforming C application cannot set tm_zone as no such thing exists. Hence an implementation which is supposed to support conforming C applications cannot use data from that field, as it has no way to know if anything is there or not (or anything relevant for sure). The implementation is certainly allowed to set that field (as in localtime() for example), a conforming application will never look there, and so will never care if it is set or not. POSIX is intended to support conforming C applications. And finally: When the standard isn’t clear on a matter it’s better to clear it up; That's right, but in this case it is clear. Always has been (even if the wording was a bit bizarre in some places). Furthermore, since this affects C programs, it should be fixed, if any fixing is needed, by the C standard first, not by some end-run performed here. Issue History Date ModifiedUsername FieldChange
[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1797 == Reported By:eggert Assigned To: == Project:Issue 8 drafts Issue ID: 1797 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Paul Eggert Organization: UCLA Computer Science Dept. User Reference: strftime-%s Section:strftime Page Number:2136 Line Number:69836-69837 Final Accepted Text: == Date Submitted: 2024-01-15 23:56 UTC Last Modified: 2024-05-24 18:59 UTC == Summary:strftime "%s" should be able to examine tm_gmtoff == Relationships ID Summary -- related to 0001533 struct tm: add tm_gmtoff (and tm_zone) ... related to 0001816 daylight, timezone, tzname do not work ... child of0001612 XSH strftime() new (I8) %s conversion r... child of169 date utility needs ``%s'' == -- (0006798) eggert (reporter) - 2024-05-24 18:59 https://austingroupbugs.net/view.php?id=1797#c6798 -- Re Note 0006797: > That example doesn’t use gmtime, so it is not completely on point. > > But it is exactly on point. I wrote “on point” because I thought the example was a program in the wild. But it now appears that it was a test program written to address this issue. Although I’ve cited several real-world programs using gmtime + strftime + %s/%z/%Z, we haven’t seen a similar set of programs using strptime + tm_isdst=-1 + strftime + %s/%z/%Z, so the real-world programs we’ve seen suggest that strftime should consult tm_gmtoff+tm_zone rather than global state. > How is the implementation of strftime() intended to learn whether or > not its caller used gmtime(), or localtime() or neither of those. Note 0006794 suggests that strftime use tm_gmtoff (for %s and %z) and tm_zone (for %Z). > It doesn't matter that this might be an unusual thing to do Unfortunately it does matter, because so many real-world implementations and programs disagree with a reading of the standard that requires strftime to ignore tm_gmtoff/tm_zone when processing %s/%z/%Z. When the standard isn’t clear on a matter it’s better to clear it up; and when clearing it up, it’s better to minimize disruption to common practice; and to do that, we need to know what common practice is. Although a test app that we write might be useful for other things, it does not help us discern common practice in apps. > it was previously agreed that strftime(%s) and mktime() > should produce the same result Yes, when the struct tm values are inside the normal range (that is, when they could have been produced by localtime). But we are talking about what strftime should do with struct tm values outside the normal range. > Similarly for %z and %Z - both C and POSIX have promised application > writers that all they need do is set tm_isdst, in an otherwise completely > randomly filled (or unfilled) struct tm, and results will be produced. I don’t see that written down. The C standard says that strftime can consult tm_isdst for %Z. It does not say that the output of %Z is completely determined by tm_isdst’s value. Implementations can also look elsewhere when generating %Z output, and they can impose additional requirements on the “elsewhere”. This is true even for POSIX.1-2017, which says that if TZNAME_MAX is 6 and you set TZ='ABCDEFG0' in the environment, strftime with %Z is allowed to dump core because the time zone abbreviation is too long. This provision of POSIX.1-2017 does not violate the C standard, even though it is an additional requirement above and beyond strftime’s caller setting tm_isdst. And requiring tm_zone to have sensible contents is not a violation either: tm_zone is an extension to the C standard and the C standard has nothing to say about what tm_zone’s contents can or should be. Issue History Date ModifiedUsername FieldChange == 2024-01-15 23:56 eggert
[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1797
==
Reported By:eggert
Assigned To:
==
Project:Issue 8 drafts
Issue ID: 1797
Category: System Interfaces
Type: Error
Severity: Objection
Priority: normal
Status: New
Name: Paul Eggert
Organization: UCLA Computer Science Dept.
User Reference: strftime-%s
Section:strftime
Page Number:2136
Line Number:69836-69837
Final Accepted Text:
==
Date Submitted: 2024-01-15 23:56 UTC
Last Modified: 2024-05-23 16:57 UTC
==
Summary:strftime "%s" should be able to examine tm_gmtoff
==
Relationships ID Summary
--
related to 0001533 struct tm: add tm_gmtoff (and tm_zone) ...
related to 0001816 daylight, timezone, tzname do not work ...
child of0001612 XSH strftime() new (I8) %s conversion r...
child of169 date utility needs ``%s''
==
--
(0006797) kre (reporter) - 2024-05-23 16:57
https://austingroupbugs.net/view.php?id=1797#c6797
--
Re https://austingroupbugs.net/view.php?id=1797#c6793 and
https://austingroupbugs.net/view.php?id=1797#c6794
I really believe that those notes show a lack of understanding of the
issue here.
The following comment in https://austingroupbugs.net/view.php?id=1797#c6793
demonstrates that:
> Here's one, with all of the error handling, #includes, etc, removed to
> save space here (they exist in the real thing, naturally):
That example doesn’t use gmtime, so it is not completely on point.
But it is exactly on point. How is the implementation of strftime()
intended to learn whether or not its caller used gmtime(), or localtime()
or neither of those.
Let me give that example again, with one more minor addition, to make
the underlying difficulty more obvious:
main(int argc, char **argv)
{
time_t now;
struct tm tm;
char *p;
int i;
char buf[64];
(void)time();/* or fill in "now" however you like */
tm = *gmtime();
/* do something with the tm, doesn't matter what */
p = strptime(argv[1], "%Y-%m-%d %H:%M:%S", );
tm.tm_isdst = -1;
for (i = 2; i < argc; i++) {
setenv("TZ", argv[i], 1);
tzset();
strftime(buf, sizeof buf, "%s", );
printf("%s %s\n", buf, argv[i]);
}
exit(0);
}
nb: same caveat about missing error handling, #includes, etc, as when
the earlier version of this was in
https://austingroupbugs.net/view.php?id=1797#c6701
Now the program has called gmtime() - that call just happens to be 100%
irrelevant to the calls of strftime() (using a struct tm which had the
results from gmtime() copied into it, some time in the past). How does
your implementation propose to generate sensible results here.
Even without the call to gmtime() there, how does your implementation
propose to tell whether there was one or not?
It doesn't matter that this might be an unusual thing to do, the fields
that the strptime() call filled in (along with tm_isdst which is set
separately) are all that is required for mktime() to work on the data,
and I think it was previously agreed that strftime(%s) and mktime()
should produce the same result (one as a string, the other as a time_t
but that's immaterial).That's certainly how it has always been
specified. Applications are entitled to operate that way.
Similarly for %z and %Z - both C and POSIX have promised application
writers that all they need do is set tm_isdst, in an otherwise completely
randomly filled (or unfilled) struct tm, and results will be produced.
Certainly the standards do not, and should not, tell the implementers how
to generate the results, but those implementers need to make things work
when the application does the bare minimum required of it by the
standards,
regardless of how many other applications do things differently.
We simply cannot ignore what has been promised before, and change the
state of the world, requiring
[Issue 8 drafts 0001774]: Support ' as a format specifier flag character in utilities
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1774 == Reported By:eblake Assigned To: == Project:Issue 8 drafts Issue ID: 1774 Category: Base Definitions and Headers Type: Omission Severity: Editorial Priority: normal Status: New Name: Eric Blake Organization: Red Hat User Reference: ebb.file format Section:XBD 5 File Format Notation Page Number:114 Line Number:3581 Final Accepted Text: == Date Submitted: 2023-08-31 17:45 UTC Last Modified: 2024-05-23 14:38 UTC == Summary:Support ' as a format specifier flag character in utilities == Relationships ID Summary -- related to 0001771 support or reserve %q as printf-utility... == -- (0006796) geoffclare (manager) - 2024-05-23 14:38 https://austingroupbugs.net/view.php?id=1774#c6796 -- I searched the (Issue 8) troff source for cross-references to File Format Notation and the only ones where it is used to specify how a utility processes a format string are in: awk printf statement pax -o listopt=format printf utility Since printf and awk have already been mentioned, the only new one to consider is pax. I could see it being a useful feature in pax for things like: pax -v -o listopt=" %'(size)i " Issue History Date ModifiedUsername FieldChange == 2023-08-31 17:45 eblake New Issue 2023-08-31 17:45 eblake Name => Eric Blake 2023-08-31 17:45 eblake Organization => Red Hat 2023-08-31 17:45 eblake User Reference=> ebb.file format 2023-08-31 17:45 eblake Section => XBD 5 File Format Notation 2023-08-31 17:45 eblake Page Number => 114 2023-08-31 17:45 eblake Line Number => 3581 2023-08-31 17:46 eblake Relationship added related to 0001771 2024-05-23 14:38 geoffclare Note Added: 0006796 ==
[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1797 == Reported By:eggert Assigned To: == Project:Issue 8 drafts Issue ID: 1797 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Paul Eggert Organization: UCLA Computer Science Dept. User Reference: strftime-%s Section:strftime Page Number:2136 Line Number:69836-69837 Final Accepted Text: == Date Submitted: 2024-01-15 23:56 UTC Last Modified: 2024-05-23 08:07 UTC == Summary:strftime "%s" should be able to examine tm_gmtoff == Relationships ID Summary -- related to 0001533 struct tm: add tm_gmtoff (and tm_zone) ... related to 0001816 daylight, timezone, tzname do not work ... child of0001612 XSH strftime() new (I8) %s conversion r... child of169 date utility needs ``%s'' == -- (0006794) eggert (reporter) - 2024-05-23 08:07 https://www.austingroupbugs.net/view.php?id=1797#c6794 -- Although the resolution proposed in Note: 0006691 has a lot to like, we need to do better with %s, %z, and %Z, as discussed in my previous comment. One thing that’s not clearly nailed down is that the implementation should be consistent in this area. That is, whatever it does for %s should be consistent with what it does for %z, and likewise for %Z. This is a “should” not a “must” because not every implementation is consistent, but intuitively it makes sense that the three formats should expand to consistent output. Interpretation response The standard states that when the input is in the normal range the strftime() %s conversion calculates the number of seconds since the Epoch as described for mktime(), and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: - In previous editions of POSIX, struct tm lacked tm_gmtoff and tm_zone members, so strftime needed to inspect global state to process %z and %Z. The current version allows strftime to instead inspect tm_gmtoff for %z, and tm_zone for %Z, as is common practice. For consistency it also allows strftime to inspect tm_gmtoff to process %s, a newly-required format. A strftime that inspects tm_gmtoff and tm_zone works better with applications that use geographical timezones, or that fill in struct tm members by calling gmtime or equivalent. Conversely, a strftime that inspects global state is more compatible with previous editions of POSIX when programs use the second TZ format in XBD Section 8.3 and fill in struct tm members individually without calling localtime or equivalent. A strftime implementation can do both: that is, it can inspect global state when the second TZ format is used, and use tm_gmtoff and tm_zone when a geographical timezone is used. This edition of the standard does not say whether the abovementioned global state consists of the contents of the variables tzname and timezone, or some other part of the system state that user code cannot modify directly. Modifying tzname and timezone therefore might (but might not) affect the global state that in turn might affect strftime’s behavior with %s, %z, and %Z, or might not if strftime inspects tm_gmtoff and tm_zone instead. Regardless of implementation method, implementations should process the conversion specifications %s, %z, and %Z consistently. For example, if strftime uses tm_gmtoff to process %z, it should also use tm_gmtoff to process %s and should use tm_zone to process %Z. Conversely, if strftime uses global state to determine one of the the three conversion specifications, it should use the same global state to determine the other two. Notes to the Editor (not part of this interpretation): --- Using draft 4.0 line numbering: On page 452 lines 15762-15763 section XBD , add CX shading to the lines for tm_gmtoff and tm_zone. On page
[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1797 == Reported By:eggert Assigned To: == Project:Issue 8 drafts Issue ID: 1797 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Paul Eggert Organization: UCLA Computer Science Dept. User Reference: strftime-%s Section:strftime Page Number:2136 Line Number:69836-69837 Final Accepted Text: == Date Submitted: 2024-01-15 23:56 UTC Last Modified: 2024-05-23 10:47 UTC == Summary:strftime "%s" should be able to examine tm_gmtoff == Relationships ID Summary -- related to 0001533 struct tm: add tm_gmtoff (and tm_zone) ... related to 0001816 daylight, timezone, tzname do not work ... child of0001612 XSH strftime() new (I8) %s conversion r... child of169 date utility needs ``%s'' == -- (0006795) geoffclare (manager) - 2024-05-23 10:47 https://austingroupbugs.net/view.php?id=1797#c6795 -- >> For %z and %Z, requiring applications to set tm_zone and tm_gmtoff would create a conflict with the C standard. C17 says that the only member used by %z and %Z is tm_isdst. >There’s no conflict here. C17 does not specify the method used to deduce the time zone used for %z and %Z. An implementation is free to use whatever screwy method it likes. Only the C committee can give a definitive answer on what C17 requires here. We cannot finalise new wording for %z and %Z until we liaise with them. Therefore our next step on this bug should be to prepare a paper for Nick to submit for consideration by the C committee. Issue History Date ModifiedUsername FieldChange == 2024-01-15 23:56 eggert New Issue 2024-01-15 23:56 eggert Name => Paul Eggert 2024-01-15 23:56 eggert Organization => UCLA Computer Science Dept. 2024-01-15 23:56 eggert User Reference=> strftime-%s 2024-01-15 23:56 eggert Section => strftime 2024-01-15 23:56 eggert Page Number => 2136 2024-01-15 23:56 eggert Line Number => 69836-69837 2024-01-16 01:29 steffenNote Added: 0006623 2024-01-16 01:42 steffenNote Added: 0006624 2024-01-16 01:42 steffenNote Deleted: 0006623 2024-02-01 16:42 nick Relationship added related to 0001533 2024-02-12 16:11 eblake Note Added: 0006651 2024-02-25 06:50 kreNote Added: 0006677 2024-02-25 06:54 kreNote Edited: 0006677 2024-02-26 18:28 eggert Note Added: 0006688 2024-02-26 19:23 eblake Relationship added related to 0001816 2024-02-26 19:32 eblake Note Added: 0006689 2024-02-26 19:52 eblake Relationship added child of 0001612 2024-02-26 19:55 eblake Relationship added child of 169 2024-02-26 20:02 eblake Note Added: 0006690 2024-02-29 12:10 geoffclare Note Added: 0006691 2024-02-29 12:15 geoffclare Note Added: 0006692 2024-02-29 16:19 shware_systems Note Added: 0006693 2024-03-01 10:09 geoffclare Note Added: 0006698 2024-03-02 09:02 eggert Note Added: 0006700 2024-03-03 01:20 kreNote Added: 0006701 2024-03-07 10:44 geoffclare Note Added: 0006706 2024-03-07 11:04 geoffclare Note Added: 0006707 2024-03-11 09:55
[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1797 == Reported By:eggert Assigned To: == Project:Issue 8 drafts Issue ID: 1797 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Paul Eggert Organization: UCLA Computer Science Dept. User Reference: strftime-%s Section:strftime Page Number:2136 Line Number:69836-69837 Final Accepted Text: == Date Submitted: 2024-01-15 23:56 UTC Last Modified: 2024-05-23 08:04 UTC == Summary:strftime "%s" should be able to examine tm_gmtoff == Relationships ID Summary -- related to 0001533 struct tm: add tm_gmtoff (and tm_zone) ... related to 0001816 daylight, timezone, tzname do not work ... child of0001612 XSH strftime() new (I8) %s conversion r... child of169 date utility needs ``%s'' == -- (0006793) eggert (reporter) - 2024-05-23 08:04 https://www.austingroupbugs.net/view.php?id=1797#c6793 -- Re Note: 0006701 > The code in that report was simply wrong, even > with the wording in Note: 0006689 it would still be broken. That code is unportable, not “wrong” or “broken”. The wording in Note: 0006689 would let implementations do what the code’s author intended. For this use case, that’s better than requiring implementations to not follow the intent. I continue to be skeptical that typical developers would expect strftime(buf, size, "%F %T %Z", gmtime()) to do anything other than output a string representing UTC. > In contrast, we don’t know of programs that would benefit from the > resolution in Note: 0006691, and these programs are less plausible. > > Here's one, with all of the error handling, #includes, etc, removed to > save space here (they exist in the real thing, naturally): That example doesn’t use gmtime, so it is not completely on point. I accept that one can contrive programs that prefer the other interpretation. However, I continue to maintain that the vast majority of programs assume the interpretations used by TZDB for %z and %Z. To check this, I did a GitHub code search today with the query “strftime gmtime path:*.c”. Most matches were irrelevant, because the output of gmtime was not passed to strftime, or because the strftime format string did not use %s, %z, or %Z. In a few matches it was hard to see what’s going on, so I ignored them. However, all the relevant matches I found (listed below) preferred the proposed interpretation: that is, they expected strftime to format the gmtime output as UTC, not as local time. In many cases this was because they let the user specify an arbitrary strftime format to be applied to the result of gmtime, and users would naturally expect gmtime to output GMT aka UTC. Here are the matches I found: https://github.com/davidmoreno/onion/blob/de8ea938342b36c28024fd8393ebc27b8442a161/src/onion/shortcuts.c#L350 https://github.com/erlang/otp/blob/945c940f6bc6c0bcb026cdc6ae8f3ce358e859bb/erts/etc/unix/run_erl.c#L583 https://github.com/esnet/iperf/blob/93c60bf2ea8aa52e98399223ec04a95f65f00f7b/src/iperf_api.c#L948 https://github.com/jonas/tig/blob/587a59abab3f2ebe7612bc69f44c22df570b2ee3/src/util.c#L208 https://github.com/openwall/john/blob/9f913a734055aae2606c68851a5a16b0d50a2060/src/logger.c#L324 https://github.com/RediSearch/RediSearch/blob/10261d2f93e77a3d1118ccded01fb4fa0e1c9cca/src/aggregate/functions/date.c#L36 https://github.com/RMerl/asuswrt-merlin.ng/blob/466f5aee9e274971480a19497573c4264f865019/release/src/router/aws-iot/src/time_util.c#L56 https://github.com/RMerl/asuswrt-merlin.ng/blob/466f5aee9e274971480a19497573c4264f865019/release/src/router/rc/conn_diag_log.c#L334 https://github.com/root-project/root/blob/333f042a16525e746da4ec56c3a5a3ed79ceb677/tutorials/graphs/timeonaxis3.C#L25 https://github.com/cheat-engine/cheat-engine/blob/54f90a22bfc9d4981f414a7917d70d3d17f190e5/lua/src/loslib.c#L129 > The reason that strftime() needs in range values in > general, is not because
[1003.1(2008)/Issue 7 0000786]: pathconfat() is missing
The following issue has been CLOSED. == https://www.austingroupbugs.net/view.php?id=786 == Reported By:joerg Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 786 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: Closed Name: Jörg Schilling Organization: FOKUS Fraunhofer User Reference: Section:3 System Interfaces Page Number:893 Line Number:29895-29905 Interp Status: --- Final Accepted Text: Resolution: Duplicate Duplicate: 0 Fixed in Version: == Date Submitted: 2013-11-04 21:57 UTC Last Modified: 2024-05-20 16:25 UTC == Summary:pathconfat() is missing == Relationships ID Summary -- duplicate of0001831 how do you get the timestamp resolution... == Issue History Date ModifiedUsername FieldChange == 2013-11-04 21:57 joerg New Issue 2013-11-04 21:57 joerg Status New => Under Review 2013-11-04 21:57 joerg Assigned To => ajosey 2013-11-04 21:57 joerg Name => Jörg Schilling 2013-11-04 21:57 joerg Organization => FOKUS Fraunhofer 2013-11-04 21:57 joerg Section => 3 System Interfaces 2013-11-04 21:57 joerg Page Number => 893 2013-11-04 21:57 joerg Line Number => 29895-29905 2013-11-04 22:12 eblake Note Added: 0001957 2013-11-05 08:34 shware_systems Note Added: 0001958 2013-11-05 08:35 shware_systems Note Edited: 0001958 2013-11-07 14:16 joerg Note Added: 0001966 2013-11-07 16:30 dalias Note Added: 0001967 2013-12-19 16:57 eblake Interp Status => --- 2013-12-19 16:57 eblake Note Added: 0002086 2013-12-19 16:57 eblake Resolution Open => Future Enhancement 2013-12-19 17:02 eblake Note Edited: 0002086 2014-01-08 14:23 shware_systems Note Added: 0002095 2015-09-11 15:47 geoffclare Note Added: 0002827 2024-05-20 16:21 nick Relationship added related to 0001831 2024-05-20 16:22 nick Relationship replacedduplicate of 0001831 2024-05-20 16:25 Don Cragun Status Under Review => Closed 2024-05-20 16:25 Don Cragun Resolution Future Enhancement => Duplicate ==
[1003.1(2016/18)/Issue7+TC2 0001831]: how do you get the timestamp resolution of a symlink?
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1831 == Reported By:philip-guenther Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1831 Category: System Interfaces Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Philip Guenther Organization: OpenBSD User Reference: Section:pathconf Page Number:902-907 Line Number:30519 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-05-15 08:10 UTC Last Modified: 2024-05-20 16:25 UTC == Summary:how do you get the timestamp resolution of a symlink? == Relationships ID Summary -- has duplicate 786 pathconfat() is missing == -- (0006792) nick (manager) - 2024-05-20 16:25 https://austingroupbugs.net/view.php?id=1831#c6792 -- Closing 786 as a duplicate of this, since this is more up to date and refers to an implementation that is expected to exist by the time this is standardized. Issue History Date ModifiedUsername FieldChange == 2024-05-15 08:10 philip-guentherNew Issue 2024-05-15 08:10 philip-guentherName => Philip Guenther 2024-05-15 08:10 philip-guentherOrganization => OpenBSD 2024-05-15 08:10 philip-guentherSection => pathconf 2024-05-15 08:10 philip-guentherPage Number => 902-907 2024-05-15 08:10 philip-guentherLine Number => 30519 2024-05-15 17:11 philip-guentherNote Added: 0006780 2024-05-18 05:57 philip-guentherNote Added: 0006783 2024-05-20 16:21 nick Relationship added related to 786 2024-05-20 16:22 nick Relationship replacedhas duplicate 786 2024-05-20 16:25 nick Note Added: 0006792 ==
[1003.1(2008)/Issue 7 0000786]: pathconfat() is missing
The following issue has been set as RELATED TO issue 0001831. == https://austingroupbugs.net/view.php?id=786 == Reported By:joerg Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 786 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: Jörg Schilling Organization: FOKUS Fraunhofer User Reference: Section:3 System Interfaces Page Number:893 Line Number:29895-29905 Interp Status: --- Final Accepted Text: == Date Submitted: 2013-11-04 21:57 UTC Last Modified: 2015-09-11 15:47 UTC == Summary:pathconfat() is missing == Relationships ID Summary -- related to 0001831 how do you get the timestamp resolution... == Issue History Date ModifiedUsername FieldChange == 2013-11-04 21:57 joerg New Issue 2013-11-04 21:57 joerg Status New => Under Review 2013-11-04 21:57 joerg Assigned To => ajosey 2013-11-04 21:57 joerg Name => Jörg Schilling 2013-11-04 21:57 joerg Organization => FOKUS Fraunhofer 2013-11-04 21:57 joerg Section => 3 System Interfaces 2013-11-04 21:57 joerg Page Number => 893 2013-11-04 21:57 joerg Line Number => 29895-29905 2013-11-04 22:12 eblake Note Added: 0001957 2013-11-05 08:34 shware_systems Note Added: 0001958 2013-11-05 08:35 shware_systems Note Edited: 0001958 2013-11-07 14:16 joerg Note Added: 0001966 2013-11-07 16:30 dalias Note Added: 0001967 2013-12-19 16:57 eblake Interp Status => --- 2013-12-19 16:57 eblake Note Added: 0002086 2013-12-19 16:57 eblake Resolution Open => Future Enhancement 2013-12-19 17:02 eblake Note Edited: 0002086 2014-01-08 14:23 shware_systems Note Added: 0002095 2015-09-11 15:47 geoffclare Note Added: 0002827 2024-05-20 16:21 nick Relationship added related to 0001831 ==
[1003.1(2016/18)/Issue7+TC2 0001831]: how do you get the timestamp resolution of a symlink?
The following issue has been set as RELATED TO issue 786. == https://austingroupbugs.net/view.php?id=1831 == Reported By:philip-guenther Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1831 Category: System Interfaces Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Philip Guenther Organization: OpenBSD User Reference: Section:pathconf Page Number:902-907 Line Number:30519 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-05-15 08:10 UTC Last Modified: 2024-05-20 16:21 UTC == Summary:how do you get the timestamp resolution of a symlink? == Relationships ID Summary -- related to 786 pathconfat() is missing == Issue History Date ModifiedUsername FieldChange == 2024-05-15 08:10 philip-guentherNew Issue 2024-05-15 08:10 philip-guentherName => Philip Guenther 2024-05-15 08:10 philip-guentherOrganization => OpenBSD 2024-05-15 08:10 philip-guentherSection => pathconf 2024-05-15 08:10 philip-guentherPage Number => 902-907 2024-05-15 08:10 philip-guentherLine Number => 30519 2024-05-15 17:11 philip-guentherNote Added: 0006780 2024-05-18 05:57 philip-guentherNote Added: 0006783 2024-05-20 16:21 nick Relationship added related to 786 ==
[1003.1(2016/18)/Issue7+TC2 0001829]: symlink() and terminating null bytes
The following issue has been RESOLVED. == https://www.austingroupbugs.net/view.php?id=1829 == Reported By:geoffclare Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1829 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: Resolved Name: Geoff Clare Organization: The Open Group User Reference: Section:symlink() Page Number:2095 Line Number:67093 Interp Status: --- Final Accepted Text:See https://www.austingroupbugs.net/view.php?id=1829#c6791. Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2024-05-02 16:48 UTC Last Modified: 2024-05-20 16:06 UTC == Summary:symlink() and terminating null bytes == Issue History Date ModifiedUsername FieldChange == 2024-05-02 16:48 geoffclare New Issue 2024-05-02 16:48 geoffclare Name => Geoff Clare 2024-05-02 16:48 geoffclare Organization => The Open Group 2024-05-02 16:48 geoffclare Section => symlink() 2024-05-02 16:48 geoffclare Page Number => 2095 2024-05-02 16:48 geoffclare Line Number => 67093 2024-05-02 16:48 geoffclare Interp Status => --- 2024-05-02 16:52 geoffclare Note Added: 0006776 2024-05-20 16:05 Don Cragun Note Added: 0006791 2024-05-20 16:06 Don Cragun Final Accepted Text => See https://www.austingroupbugs.net/view.php?id=1829#c6791. 2024-05-20 16:06 Don Cragun Status New => Resolved 2024-05-20 16:06 Don Cragun Resolution Open => Accepted As Marked ==
[1003.1(2016/18)/Issue7+TC2 0001829]: symlink() and terminating null bytes
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1829 == Reported By:geoffclare Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1829 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section:symlink() Page Number:2095 Line Number:67093 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-05-02 16:48 UTC Last Modified: 2024-05-20 16:05 UTC == Summary:symlink() and terminating null bytes == -- (0006791) Don Cragun (manager) - 2024-05-20 16:05 https://www.austingroupbugs.net/view.php?id=1829#c6791 -- Make the changes suggested in the Desired Action and in https://www.austingroupbugs.net/view.php?id=1829#c6776. Issue History Date ModifiedUsername FieldChange == 2024-05-02 16:48 geoffclare New Issue 2024-05-02 16:48 geoffclare Name => Geoff Clare 2024-05-02 16:48 geoffclare Organization => The Open Group 2024-05-02 16:48 geoffclare Section => symlink() 2024-05-02 16:48 geoffclare Page Number => 2095 2024-05-02 16:48 geoffclare Line Number => 67093 2024-05-02 16:48 geoffclare Interp Status => --- 2024-05-02 16:52 geoffclare Note Added: 0006776 2024-05-20 16:05 Don Cragun Note Added: 0006791 ==
[1003.1(2016/18)/Issue7+TC2 0001828]: Rationale is out of date
The following issue has been RESOLVED. == https://www.austingroupbugs.net/view.php?id=1828 == Reported By:nick Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1828 Category: Base Definitions and Headers Type: Clarification Requested Severity: Editorial Priority: low Status: Resolved Name: Nick Stoughton Organization: User Reference: Section:sys/stat.h Page Number:395 Line Number:13468 Interp Status: --- Final Accepted Text: Resolution: Accepted Fixed in Version: == Date Submitted: 2024-05-02 16:23 UTC Last Modified: 2024-05-20 15:59 UTC == Summary:Rationale is out of date == Issue History Date ModifiedUsername FieldChange == 2024-05-02 16:23 nick New Issue 2024-05-02 16:23 nick Name => Nick Stoughton 2024-05-02 16:23 nick Section => sys/stat.h 2024-05-02 16:23 nick Page Number => 395 2024-05-02 16:23 nick Line Number => 13468 2024-05-02 16:23 nick Interp Status => --- 2024-05-20 15:59 Don Cragun Status New => Resolved 2024-05-20 15:59 Don Cragun Resolution Open => Accepted ==
[Issue 8 drafts 0001825]: Does releasing a reader lock carries a "release" memory order semantic?
The following issue has been CLOSED. == https://austingroupbugs.net/view.php?id=1825 == Reported By:dannyniu Assigned To: == Project:Issue 8 drafts Issue ID: 1825 Category: System Interfaces Type: Clarification Requested Severity: Comment Priority: normal Status: Closed Name: DannyNiu/NJF Organization: User Reference: Section:pthread_rwlock_* Page Number:1787-1804 Line Number:59262-59785 Final Accepted Text: Resolution: Withdrawn Fixed in Version: == Date Submitted: 2024-04-02 06:44 UTC Last Modified: 2024-05-20 15:26 UTC == Summary:Does releasing a reader lock carries a "release" memory order semantic? == Issue History Date ModifiedUsername FieldChange == 2024-04-02 06:44 dannyniu New Issue 2024-04-02 06:44 dannyniu Name => DannyNiu/NJF 2024-04-02 06:44 dannyniu Organization => 2024-04-02 06:44 dannyniu Section => pthread_rwlock_* 2024-04-02 06:44 dannyniu Page Number => 1787-1804 2024-04-02 06:44 dannyniu Line Number => 59262-59785 2024-04-02 15:28 geoffclare Note Added: 0006733 2024-04-03 04:11 dannyniu Note Added: 0006735 2024-04-04 09:09 geoffclare Note Added: 0006736 2024-04-04 14:34 dannyniu Note Added: 0006738 2024-05-20 15:26 nick Status New => Closed 2024-05-20 15:26 nick Resolution Open => Withdrawn ==
[Issue 8 drafts 0001827]: Standardize gzip(1) cli interface instead of adding it to compress(1)
The following issue has been CLOSED. == https://www.austingroupbugs.net/view.php?id=1827 == Reported By:nrk Assigned To: == Project:Issue 8 drafts Issue ID: 1827 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: Closed Name: NRK Organization: User Reference: Section:compress(1) utility Page Number:n/a Line Number:n/a Final Accepted Text: Resolution: Rejected Fixed in Version: == Date Submitted: 2024-04-15 03:23 UTC Last Modified: 2024-05-20 15:55 UTC == Summary:Standardize gzip(1) cli interface instead of adding it to compress(1) == -- (0006790) Don Cragun (manager) - 2024-05-20 15:55 https://www.austingroupbugs.net/view.php?id=1827#c6790 -- Bug 1041 was resolved more than 7 years ago and had been included in draft versions of the standard for more than 4 years before bug 1827 was submitted. Filing a bug to reverse this after the IEEE and The Open Group ballots have been completed and while the ISO ballot on the current version of the standard is in its final stage is way too late to make the requested changes. Furthermore, these issues were discussed before the changes were approved seven years ago and the standard developers believed then and still believe that including the changes to compress was better than adding several other sets of compression utilities. Therefore, this bug is rejected. Issue History Date ModifiedUsername FieldChange == 2024-04-15 03:23 nrkNew Issue 2024-04-15 03:23 nrkName => NRK 2024-04-15 03:23 nrkSection => compress(1) utility 2024-04-15 03:23 nrkPage Number => n/a 2024-04-15 03:23 nrkLine Number => n/a 2024-04-15 03:24 nrkIssue Monitored: nrk 2024-04-16 05:57 dannyniu Note Added: 0006752 2024-04-16 05:58 dannyniu Note Edited: 0006752 2024-04-16 18:39 steffenNote Added: 0006753 2024-04-16 22:51 nrkNote Added: 0006754 2024-04-16 23:03 nrkNote Added: 0006755 2024-04-16 23:32 oguzismailuysalNote Added: 0006756 2024-04-17 00:10 steffenNote Added: 0006757 2024-04-17 00:32 nrkNote Added: 0006758 2024-04-17 01:36 larryv Note Added: 0006759 2024-04-17 06:16 oguzismailuysalNote Added: 0006760 2024-04-17 06:18 oguzismailuysalNote Edited: 0006760 2024-04-17 06:19 oguzismailuysalNote Edited: 0006760 2024-04-17 07:47 nrkNote Added: 0006761 2024-04-17 11:03 oguzismailuysalNote Added: 0006762 2024-04-17 18:01 steffenNote Added: 0006763 2024-05-20 15:55 Don Cragun Note Added: 0006790 2024-05-20 15:55 Don Cragun Status New => Closed 2024-05-20 15:55 Don Cragun Resolution Open => Rejected ==
[Issue 8 drafts 0001825]: Does releasing a reader lock carries a "release" memory order semantic?
The following issue has been CLOSED. == https://austingroupbugs.net/view.php?id=1825 == Reported By:dannyniu Assigned To: == Project:Issue 8 drafts Issue ID: 1825 Category: System Interfaces Type: Clarification Requested Severity: Comment Priority: normal Status: Closed Name: DannyNiu/NJF Organization: User Reference: Section:pthread_rwlock_* Page Number:1787-1804 Line Number:59262-59785 Final Accepted Text: Resolution: Withdrawn Fixed in Version: == Date Submitted: 2024-04-02 06:44 UTC Last Modified: 2024-05-20 15:26 UTC == Summary:Does releasing a reader lock carries a "release" memory order semantic? == Issue History Date ModifiedUsername FieldChange == 2024-04-02 06:44 dannyniu New Issue 2024-04-02 06:44 dannyniu Name => DannyNiu/NJF 2024-04-02 06:44 dannyniu Organization => 2024-04-02 06:44 dannyniu Section => pthread_rwlock_* 2024-04-02 06:44 dannyniu Page Number => 1787-1804 2024-04-02 06:44 dannyniu Line Number => 59262-59785 2024-04-02 15:28 geoffclare Note Added: 0006733 2024-04-03 04:11 dannyniu Note Added: 0006735 2024-04-04 09:09 geoffclare Note Added: 0006736 2024-04-04 14:34 dannyniu Note Added: 0006738 2024-05-20 15:26 nick Status New => Closed 2024-05-20 15:26 nick Resolution Open => Withdrawn ==
[1003.1(2016/18)/Issue7+TC2 0001822]: Define splitting using a null field separator
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=1822 == Reported By:mortoneccc Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1822 Category: Shell and Utilities Type: Enhancement Request Severity: Comment Priority: normal Status: Resolved Name: Ed Morton Organization: User Reference: Section:awk Page Number:0 Line Number:0 Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1822#c6789 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2024-03-14 11:50 UTC Last Modified: 2024-05-20 15:09 UTC == Summary:Define splitting using a null field separator == Issue History Date ModifiedUsername FieldChange == 2024-03-14 11:50 mortoneccc New Issue 2024-03-14 11:50 mortoneccc Name => Ed Morton 2024-03-14 11:50 mortoneccc Section => awk 2024-03-14 11:50 mortoneccc Page Number => 0 2024-03-14 11:50 mortoneccc Line Number => 0 2024-05-20 15:08 geoffclare Note Added: 0006789 2024-05-20 15:09 geoffclare Interp Status => --- 2024-05-20 15:09 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1822#c6789 2024-05-20 15:09 geoffclare Status New => Resolved 2024-05-20 15:09 geoffclare Resolution Open => Accepted As Marked ==
[1003.1(2016/18)/Issue7+TC2 0001822]: Define splitting using a null field separator
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1822 == Reported By:mortoneccc Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1822 Category: Shell and Utilities Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Ed Morton Organization: User Reference: Section:awk Page Number:0 Line Number:0 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-03-14 11:50 UTC Last Modified: 2024-05-20 15:08 UTC == Summary:Define splitting using a null field separator == -- (0006789) geoffclare (manager) - 2024-05-20 15:08 https://austingroupbugs.net/view.php?id=1822#c6789 -- Page and line numbers are for issue 8 draft 4.1. On P2617, L85671 section awk (EXTENDED DESCRIPTION) change: If FS is a null string, the behavior is unspecified. to: If FS is a null string, each character shall become a separate field. Issue History Date ModifiedUsername FieldChange == 2024-03-14 11:50 mortoneccc New Issue 2024-03-14 11:50 mortoneccc Name => Ed Morton 2024-03-14 11:50 mortoneccc Section => awk 2024-03-14 11:50 mortoneccc Page Number => 0 2024-03-14 11:50 mortoneccc Line Number => 0 2024-05-20 15:08 geoffclare Note Added: 0006789 ==
[Issue 8 drafts 0001824]: cp: directories and symlinks
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1824 == Reported By:dag-erling Assigned To: == Project:Issue 8 drafts Issue ID: 1824 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Dag-Erling Smørgrav Organization: User Reference: Section:Utilities Page Number:2741-2748 Line Number:90593-90715, 90876-90880 Final Accepted Text: == Date Submitted: 2024-04-01 15:31 UTC Last Modified: 2024-05-20 09:26 UTC == Summary:cp: directories and symlinks == -- (0006788) geoffclare (manager) - 2024-05-20 09:26 https://austingroupbugs.net/view.php?id=1824#c6788 -- Before we can work on wording, we need to decide what behaviour(s) to require/allow for -P. We should be guided by existing practice. I tried a few tests on the systems I have access to. - First I tried this:mkdir targdir; ln -s targdir destdir echo src > src cp -RP src destdirand cp created src in targdir (on Solaris, Linux, and macOS). - Then I tried this:mkdir destdir; cd destdir; echo targ > targ; ln -s targ src cd ..; echo src > src cp -RP src destdirand cp copied src contents into the targ file (on Solaris, Linux, and macOS). - Then I tried this:mkdir subdir destdir; cd destdir; mkdir targdir; ln -s targdir subdir cd ../subdir; echo src > src; cd .. cp -RP subdir destdirSolaris and macOS created src in targdir. Linux failed with "cannot overwrite non-directory 'destdir/subdir' with directory 'subdir'" Conclusion: Solaris and macOS consistently follow destination symlinks, as does historical FreeBSD according to the bug description, but Linux (GNU coreutils 9.1 on a Debian system) is inconsistent; it follows destination symlinks in two out of three of my test cases but does not in the other case. Issue History Date ModifiedUsername FieldChange == 2024-04-01 15:31 dag-erling New Issue 2024-04-01 15:31 dag-erling Name => Dag-Erling Smørgrav 2024-04-01 15:31 dag-erling Section => Utilities 2024-04-01 15:31 dag-erling Page Number => 2741-2748 2024-04-01 15:31 dag-erling Line Number => 90593-90715, 90876-90880 2024-04-02 06:19 dannyniu Note Added: 0006731 2024-04-02 06:20 dannyniu Note Added: 0006732 2024-04-02 06:21 dannyniu Note Deleted: 0006732 2024-04-02 06:22 dannyniu Note Edited: 0006731 2024-04-02 15:51 geoffclare Note Added: 0006734 2024-04-04 14:30 geoffclare Note Added: 0006737 2024-04-04 16:01 dag-erling Note Added: 0006739 2024-04-04 16:59 geoffclare Note Added: 0006740 2024-04-04 18:19 geoffclare Note Edited: 0006740 2024-04-05 08:16 geoffclare Note Edited: 0006740 2024-04-05 11:33 dag-erling Note Added: 0006741 2024-04-08 08:39 geoffclare Note Added: 0006743 2024-04-08 08:42 geoffclare Note Edited: 0006737 2024-04-08 08:44 geoffclare Note Edited: 0006743 2024-05-20 09:26 geoffclare Note Added: 0006788 ==
[1003.1(2016/18)/Issue7+TC2 0001830]: off-by-one error regarding offset maximum
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1830 == Reported By:lacos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1830 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: László Érsek Organization: User Reference: Section:pwrite, write Page Number:? Line Number:? Interp Status: --- Final Accepted Text: == Date Submitted: 2024-05-03 06:55 UTC Last Modified: 2024-05-20 08:16 UTC == Summary:off-by-one error regarding offset maximum == -- (0006786) geoffclare (manager) - 2024-05-20 08:16 https://austingroupbugs.net/view.php?id=1830#c6786 -- Good catch that my proposed fix doesn't work for pwrite(). Having looked into it some more, I notice that the wording of the associated EFBIG error works fine for both:[EFBIG]The file is a regular file, nbyte is greater than 0, and the starting position is greater than or equal to the offset maximum established in the open file description associated with fildes. So I think the text in the description should be worded in a similar way. The only difference is that the description needs to allow for writes that start before the offset maximum but would extend beyond it (if all requested bytes were written). Change:For regular files, no data transfer shall occur past the offset maximum established in the open file description associated with fildes.to:For regular files, no data shall be written at positions greater than or equal to the offset maximum established in the open file description associated with fildes. If the starting position is greater than or equal to the offset maximum (and nbyte is greater than 0), the request shall fail; otherwise, only as many bytes as there is room for shall be written. Issue History Date ModifiedUsername FieldChange == 2024-05-03 06:55 lacos New Issue 2024-05-03 06:55 lacos Name => László Érsek 2024-05-03 06:55 lacos Section => pwrite, write 2024-05-03 06:55 lacos Page Number => ? 2024-05-03 06:55 lacos Line Number => ? 2024-05-13 09:10 geoffclare Note Added: 0006778 2024-05-19 10:20 lacos Note Added: 0006784 2024-05-19 10:26 lacos Note Added: 0006785 2024-05-20 08:16 geoffclare Note Added: 0006786 ==
[1003.1(2016/18)/Issue7+TC2 0001830]: off-by-one error regarding offset maximum
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1830 == Reported By:lacos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1830 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: László Érsek Organization: User Reference: Section:pwrite, write Page Number:? Line Number:? Interp Status: --- Final Accepted Text: == Date Submitted: 2024-05-03 06:55 UTC Last Modified: 2024-05-19 10:26 UTC == Summary:off-by-one error regarding offset maximum == -- (0006785) lacos (reporter) - 2024-05-19 10:26 https://www.austingroupbugs.net/view.php?id=1830#c6785 -- My reason for covering pwrite() as well is the following: an application may maintain a separate off_t variable for recording the exclusive end offset of a successful pwrite() call -- effectively the same offset to which an equivalent write() call would set the file offset inside the underlying open file description. Given that the spec intends to prevent the file offset inside the open file description from overflowing upon a write(), the same guarantee should be extended to an application that captures the same "exclusive end of successful data transfer" concept in an off_t object. Issue History Date ModifiedUsername FieldChange == 2024-05-03 06:55 lacos New Issue 2024-05-03 06:55 lacos Name => László Érsek 2024-05-03 06:55 lacos Section => pwrite, write 2024-05-03 06:55 lacos Page Number => ? 2024-05-03 06:55 lacos Line Number => ? 2024-05-13 09:10 geoffclare Note Added: 0006778 2024-05-19 10:20 lacos Note Added: 0006784 2024-05-19 10:26 lacos Note Added: 0006785 ==
[1003.1(2016/18)/Issue7+TC2 0001830]: off-by-one error regarding offset maximum
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1830 == Reported By:lacos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1830 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: László Érsek Organization: User Reference: Section:pwrite, write Page Number:? Line Number:? Interp Status: --- Final Accepted Text: == Date Submitted: 2024-05-03 06:55 UTC Last Modified: 2024-05-19 10:20 UTC == Summary:off-by-one error regarding offset maximum == -- (0006784) lacos (reporter) - 2024-05-19 10:20 https://www.austingroupbugs.net/view.php?id=1830#c6784 -- The proposed update entirely clarifies the requirement for write(), however I think it applies less to pwrite() than before, because pwrite() does not change the file offset at all. (In retrospect, I suspect the original "data transfer [...] past the offset maximum" language may have specifically aimed at covering pwrite() at the same time as write().) Can we perhaps use semi-formal syntax, such as: "For regular files, no data transfer shall occur such that, using zero-based byte offsets, /byte[offmax]/ of the file, or any byte thereafter, be overwritten, where offmax is the offset maximum established in the open file description associated with fildes." Issue History Date ModifiedUsername FieldChange == 2024-05-03 06:55 lacos New Issue 2024-05-03 06:55 lacos Name => László Érsek 2024-05-03 06:55 lacos Section => pwrite, write 2024-05-03 06:55 lacos Page Number => ? 2024-05-03 06:55 lacos Line Number => ? 2024-05-13 09:10 geoffclare Note Added: 0006778 2024-05-19 10:20 lacos Note Added: 0006784 ==
[1003.1(2016/18)/Issue7+TC2 0001831]: how do you get the timestamp resolution of a symlink?
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1831 == Reported By:philip-guenther Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1831 Category: System Interfaces Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Philip Guenther Organization: OpenBSD User Reference: Section:pathconf Page Number:902-907 Line Number:30519 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-05-15 08:10 UTC Last Modified: 2024-05-18 05:57 UTC == Summary:how do you get the timestamp resolution of a symlink? == -- (0006783) philip-guenther (reporter) - 2024-05-18 05:57 https://austingroupbugs.net/view.php?id=1831#c6783 -- OpenBSD 7.6 will have long pathconfat(int fd, const char *path, int name, int flag); where the flag argument supports AT_SYMLINK_NOFOLLOW. Issue History Date ModifiedUsername FieldChange == 2024-05-15 08:10 philip-guentherNew Issue 2024-05-15 08:10 philip-guentherName => Philip Guenther 2024-05-15 08:10 philip-guentherOrganization => OpenBSD 2024-05-15 08:10 philip-guentherSection => pathconf 2024-05-15 08:10 philip-guentherPage Number => 902-907 2024-05-15 08:10 philip-guentherLine Number => 30519 2024-05-15 17:11 philip-guentherNote Added: 0006780 2024-05-18 05:57 philip-guentherNote Added: 0006783 ==
[1003.1(2016/18)/Issue7+TC2 0001823]: The impact of changing NR and/or FNR should be defined
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=1823 == Reported By:mortoneccc Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1823 Category: Shell and Utilities Type: Enhancement Request Severity: Comment Priority: normal Status: Resolved Name: Ed Morton Organization: User Reference: Section:awk Page Number:0 Line Number:0 Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1823#c6782 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2024-03-14 12:26 UTC Last Modified: 2024-05-16 15:55 UTC == Summary:The impact of changing NR and/or FNR should be defined == Relationships ID Summary -- related to 0001821 Define the values of $0, $1, etc. in th... == Issue History Date ModifiedUsername FieldChange == 2024-03-14 12:26 mortoneccc New Issue 2024-03-14 12:26 mortoneccc Name => Ed Morton 2024-03-14 12:26 mortoneccc Section => awk 2024-03-14 12:26 mortoneccc Page Number => 0 2024-03-14 12:26 mortoneccc Line Number => 0 2024-03-14 12:27 mortoneccc Note Added: 0006720 2024-05-16 15:54 eblake Relationship added related to 0001821 2024-05-16 15:54 geoffclare Note Added: 0006782 2024-05-16 15:55 geoffclare Interp Status => --- 2024-05-16 15:55 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1823#c6782 2024-05-16 15:55 geoffclare Status New => Resolved 2024-05-16 15:55 geoffclare Resolution Open => Accepted As Marked ==
[1003.1(2016/18)/Issue7+TC2 0001823]: The impact of changing NR and/or FNR should be defined
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1823 == Reported By:mortoneccc Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1823 Category: Shell and Utilities Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Ed Morton Organization: User Reference: Section:awk Page Number:0 Line Number:0 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-03-14 12:26 UTC Last Modified: 2024-05-16 15:54 UTC == Summary:The impact of changing NR and/or FNR should be defined == Relationships ID Summary -- related to 0001821 Define the values of $0, $1, etc. in th... == -- (0006782) geoffclare (manager) - 2024-05-16 15:54 https://austingroupbugs.net/view.php?id=1823#c6782 -- After applying bug https://austingroupbugs.net/view.php?id=1821, make the following change: Page and line numbers are for Issue 8 draft 4.1. After page 2642 line 86769 section awk (FUTURE DIRECTIONS), add a new paragraph: A future version of this standard may specify the behavior when an application assigns a value to NR or FNR. Issue History Date ModifiedUsername FieldChange == 2024-03-14 12:26 mortoneccc New Issue 2024-03-14 12:26 mortoneccc Name => Ed Morton 2024-03-14 12:26 mortoneccc Section => awk 2024-03-14 12:26 mortoneccc Page Number => 0 2024-03-14 12:26 mortoneccc Line Number => 0 2024-03-14 12:27 mortoneccc Note Added: 0006720 2024-05-16 15:54 eblake Relationship added related to 0001821 2024-05-16 15:54 geoffclare Note Added: 0006782 ==
[1003.1(2016/18)/Issue7+TC2 0001821]: Define the values of $0, $1, etc. in the END section
The following issue has been set as RELATED TO issue 0001823. == https://austingroupbugs.net/view.php?id=1821 == Reported By:mortoneccc Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1821 Category: Shell and Utilities Type: Enhancement Request Severity: Comment Priority: normal Status: Interpretation Required Name: Ed Morton Organization: User Reference: Section:awk Page Number:0 Line Number:0 Interp Status: Pending Final Accepted Text:https://austingroupbugs.net/view.php?id=1821#c6781 == Date Submitted: 2024-03-14 11:42 UTC Last Modified: 2024-05-16 15:33 UTC == Summary:Define the values of $0, $1, etc. in the END section == Relationships ID Summary -- related to 0001823 The impact of changing NR and/or FNR sh... == Issue History Date ModifiedUsername FieldChange == 2024-03-14 11:42 mortoneccc New Issue 2024-03-14 11:42 mortoneccc Name => Ed Morton 2024-03-14 11:42 mortoneccc Section => awk 2024-03-14 11:42 mortoneccc Page Number => 0 2024-03-14 11:42 mortoneccc Line Number => 0 2024-03-14 12:03 geoffclare Note Added: 0006719 2024-05-16 15:31 geoffclare Note Added: 0006781 2024-05-16 15:33 geoffclare Interp Status => Pending 2024-05-16 15:33 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1821#c6781 2024-05-16 15:33 geoffclare Status New => Interpretation Required 2024-05-16 15:33 geoffclare Resolution Open => Accepted As Marked 2024-05-16 15:33 geoffclare Tag Attached: tc1-2024 2024-05-16 15:54 eblake Relationship added related to 0001823 ==
[1003.1(2016/18)/Issue7+TC2 0001823]: The impact of changing NR and/or FNR should be defined
The following issue has been set as RELATED TO issue 0001821. == https://austingroupbugs.net/view.php?id=1823 == Reported By:mortoneccc Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1823 Category: Shell and Utilities Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Ed Morton Organization: User Reference: Section:awk Page Number:0 Line Number:0 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-03-14 12:26 UTC Last Modified: 2024-05-16 15:54 UTC == Summary:The impact of changing NR and/or FNR should be defined == Relationships ID Summary -- related to 0001821 Define the values of $0, $1, etc. in th... == Issue History Date ModifiedUsername FieldChange == 2024-03-14 12:26 mortoneccc New Issue 2024-03-14 12:26 mortoneccc Name => Ed Morton 2024-03-14 12:26 mortoneccc Section => awk 2024-03-14 12:26 mortoneccc Page Number => 0 2024-03-14 12:26 mortoneccc Line Number => 0 2024-03-14 12:27 mortoneccc Note Added: 0006720 2024-05-16 15:54 eblake Relationship added related to 0001821 ==
[1003.1(2016/18)/Issue7+TC2 0001821]: Define the values of $0, $1, etc. in the END section
The following issue NEEDS AN INTERPRETATION. == https://austingroupbugs.net/view.php?id=1821 == Reported By:mortoneccc Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1821 Category: Shell and Utilities Type: Enhancement Request Severity: Comment Priority: normal Status: Interpretation Required Name: Ed Morton Organization: User Reference: Section:awk Page Number:0 Line Number:0 Interp Status: Pending Final Accepted Text:https://austingroupbugs.net/view.php?id=1821#c6781 == Date Submitted: 2024-03-14 11:42 UTC Last Modified: 2024-05-16 15:33 UTC == Summary:Define the values of $0, $1, etc. in the END section == Issue History Date ModifiedUsername FieldChange == 2024-03-14 11:42 mortoneccc New Issue 2024-03-14 11:42 mortoneccc Name => Ed Morton 2024-03-14 11:42 mortoneccc Section => awk 2024-03-14 11:42 mortoneccc Page Number => 0 2024-03-14 11:42 mortoneccc Line Number => 0 2024-03-14 12:03 geoffclare Note Added: 0006719 2024-05-16 15:31 geoffclare Note Added: 0006781 2024-05-16 15:33 geoffclare Interp Status => Pending 2024-05-16 15:33 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1821#c6781 2024-05-16 15:33 geoffclare Status New => Interpretation Required 2024-05-16 15:33 geoffclare Resolution Open => Accepted As Marked ==
[1003.1(2016/18)/Issue7+TC2 0001821]: Define the values of $0, $1, etc. in the END section
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1821 == Reported By:mortoneccc Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1821 Category: Shell and Utilities Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Ed Morton Organization: User Reference: Section:awk Page Number:0 Line Number:0 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-03-14 11:42 UTC Last Modified: 2024-05-16 15:31 UTC == Summary:Define the values of $0, $1, etc. in the END section == -- (0006781) geoffclare (manager) - 2024-05-16 15:31 https://austingroupbugs.net/view.php?id=1821#c6781 -- 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: - The standard requires that the value of NF is retained in an END section, but does not state what the values of the fields $1 through $NF are, despite requiring them to exist. Notes to the Editor (not part of this interpretation): --- Page and line numbers are for Issue 8 draft 4.1. At page 2614 line 85574 (FILENAME), delete: Inside an END action the value shall be the name of the last input file processed. At page 2614 line 85578 (FNR), change: Inside an END action the value shall be the number of the last record processed in the last file processed. to: If an application changes the value of FNR, the results are unspecified. At page 2614 line 85581 (NF), change: The number of fields in the current record. Inside a BEGIN action, the use of NF is undefined unless a getline function without a var argument is executed previously. Inside an END action, NF shall retain the value it had for the last record read, unless a subsequent, redirected, getline function without a var argument is performed prior to entering the END action. to: The number of fields in the current record. Inside the first BEGIN action, the value shall initially be zero, except that if the -v option was used to assign a value to NF it is unspecified whether that value is retained or the value is reset to zero. At page 2614 line 85587 (NR), change: Inside an END action the value shall be the number of the last record processed. to: If an application changes the value of NR, the results are unspecified. At page 2618 after line 85708 (Special Patterns), add: Entering an END action shall not alter the value of any fields or variables that had previously been set. Issue History Date ModifiedUsername FieldChange == 2024-03-14 11:42 mortoneccc New Issue 2024-03-14 11:42 mortoneccc Name => Ed Morton 2024-03-14 11:42 mortoneccc Section => awk 2024-03-14 11:42 mortoneccc Page Number => 0 2024-03-14 11:42 mortoneccc Line Number => 0 2024-03-14 12:03 geoffclare Note Added: 0006719 2024-05-16 15:31 geoffclare Note Added: 0006781 ==
[1003.1(2016/18)/Issue7+TC2 0001831]: how do you get the timestamp resolution of a symlink?
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1831 == Reported By:philip-guenther Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1831 Category: System Interfaces Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Philip Guenther Organization: OpenBSD User Reference: Section:pathconf Page Number:902-907 Line Number:30519 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-05-15 08:10 UTC Last Modified: 2024-05-15 08:10 UTC == Summary:how do you get the timestamp resolution of a symlink? Description: The description of pathconf() doesn't contain any specific wording about how it should handle a path which names a symlink. Contrast rename()'s description which says If either the old or new argument names a symbolic link, rename() shall operate on the symbolic link itself, and shall not resolve the last component of the argument. and unlink()'s description which says If path names a symbolic link, unlink() shall remove the symbolic link named by path and shall not affect any file or directory named by the contents of the symbolic link. It thus appears that pathconf() is expected to completely follow symlinks and report the values appropriate for the final result of the pathname resolution. However, it would be useful to be able to get the timestamp resolution (_PC_TIMESTAMP_RESOLUTION) for a symlink, even if it's dangling or points to a path on a filesystem with a different timestamp resolution. (This was encountered when trying to fix a pax implementation's handling of timestamp comparison for -u when the target filesystem had courser resolution that the source filesystem by using pathconf(_PC_TIMESTAMP_RESOLUTION) on the target path to handle the loss of high-precision time info...but the symlink pointed to a location with high-precision timestamps so it couldn't know to round the times when doing the comparison...) Desired Action: Got me! Change pathconf() to never follow a final symlink, ala rename(), unlink(), open(O_NOFOLLOW)? Never follow a terminal symlink when the second argument is _PC_TIMESTAMP_RESOLUTION? A new _PC_TIMESTAMP_RESOLUTION_NOFOLLOW??? (cries) == Issue History Date ModifiedUsername FieldChange == 2024-05-15 08:10 philip-guentherNew Issue 2024-05-15 08:10 philip-guentherName => Philip Guenther 2024-05-15 08:10 philip-guentherOrganization => OpenBSD 2024-05-15 08:10 philip-guentherSection => pathconf 2024-05-15 08:10 philip-guentherPage Number => 902-907 2024-05-15 08:10 philip-guentherLine Number => 30519 ==
[1003.1(2016/18)/Issue7+TC2 0001831]: how do you get the timestamp resolution of a symlink?
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1831 == Reported By:philip-guenther Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1831 Category: System Interfaces Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Philip Guenther Organization: OpenBSD User Reference: Section:pathconf Page Number:902-907 Line Number:30519 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-05-15 08:10 UTC Last Modified: 2024-05-15 17:11 UTC == Summary:how do you get the timestamp resolution of a symlink? == -- (0006780) philip-guenther (reporter) - 2024-05-15 17:11 https://austingroupbugs.net/view.php?id=1831#c6780 -- With a fresh cup of coffee, it's 'obvious' the correct action is to use pathconfat(AT_FDCWD, path, _PC_TIMESTAMP_RESOLUTION, AT_SYMLINK_NOFOLLOW) This was touched on in https://austingroupbugs.net/view.php?id=786 (c.f. Geoff's comment 2827 from 2015) so maybe I should just implement this in OpenBSD and drag everyone else along from there. :) Issue History Date ModifiedUsername FieldChange == 2024-05-15 08:10 philip-guentherNew Issue 2024-05-15 08:10 philip-guentherName => Philip Guenther 2024-05-15 08:10 philip-guentherOrganization => OpenBSD 2024-05-15 08:10 philip-guentherSection => pathconf 2024-05-15 08:10 philip-guentherPage Number => 902-907 2024-05-15 08:10 philip-guentherLine Number => 30519 2024-05-15 17:11 philip-guentherNote Added: 0006780 ==
[1003.1(2016/18)/Issue7+TC2 0001831]: how do you get the timestamp resolution of a symlink?
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1831 == Reported By:philip-guenther Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1831 Category: System Interfaces Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Philip Guenther Organization: OpenBSD User Reference: Section:pathconf Page Number:902-907 Line Number:30519 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-05-15 08:10 UTC Last Modified: 2024-05-15 08:10 UTC == Summary:how do you get the timestamp resolution of a symlink? Description: The description of pathconf() doesn't contain any specific wording about how it should handle a path which names a symlink. Contrast rename()'s description which says If either the old or new argument names a symbolic link, rename() shall operate on the symbolic link itself, and shall not resolve the last component of the argument. and unlink()'s description which says If path names a symbolic link, unlink() shall remove the symbolic link named by path and shall not affect any file or directory named by the contents of the symbolic link. It thus appears that pathconf() is expected to completely follow symlinks and report the values appropriate for the final result of the pathname resolution. However, it would be useful to be able to get the timestamp resolution (_PC_TIMESTAMP_RESOLUTION) for a symlink, even if it's dangling or points to a path on a filesystem with a different timestamp resolution. (This was encountered when trying to fix a pax implementation's handling of timestamp comparison for -u when the target filesystem had courser resolution that the source filesystem by using pathconf(_PC_TIMESTAMP_RESOLUTION) on the target path to handle the loss of high-precision time info...but the symlink pointed to a location with high-precision timestamps so it couldn't know to round the times when doing the comparison...) Desired Action: Got me! Change pathconf() to never follow a final symlink, ala rename(), unlink(), open(O_NOFOLLOW)? Never follow a terminal symlink when the second argument is _PC_TIMESTAMP_RESOLUTION? A new _PC_TIMESTAMP_RESOLUTION_NOFOLLOW??? (cries) == Issue History Date ModifiedUsername FieldChange == 2024-05-15 08:10 philip-guentherNew Issue 2024-05-15 08:10 philip-guentherName => Philip Guenther 2024-05-15 08:10 philip-guentherOrganization => OpenBSD 2024-05-15 08:10 philip-guentherSection => pathconf 2024-05-15 08:10 philip-guentherPage Number => 902-907 2024-05-15 08:10 philip-guentherLine Number => 30519 ==
[1003.1(2016/18)/Issue7+TC2 0001820]: The impact of changing NF should be stated
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=1820 == Reported By:mortoneccc Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1820 Category: Shell and Utilities Type: Enhancement Request Severity: Comment Priority: normal Status: Resolved Name: Ed Morton Organization: User Reference: Section:awk Page Number:0 Line Number:0 Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1820#c6779 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2024-03-14 11:36 UTC Last Modified: 2024-05-13 15:08 UTC == Summary:The impact of changing NF should be stated == Issue History Date ModifiedUsername FieldChange == 2024-03-14 11:36 mortoneccc New Issue 2024-03-14 11:36 mortoneccc Name => Ed Morton 2024-03-14 11:36 mortoneccc Section => awk 2024-03-14 11:36 mortoneccc Page Number => 0 2024-03-14 11:36 mortoneccc Line Number => 0 2024-03-15 13:50 salewski Issue Monitored: salewski 2024-05-13 15:07 geoffclare Note Added: 0006779 2024-05-13 15:08 geoffclare Interp Status => --- 2024-05-13 15:08 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1820#c6779 2024-05-13 15:08 geoffclare Status New => Resolved 2024-05-13 15:08 geoffclare Resolution Open => Accepted As Marked ==
[1003.1(2016/18)/Issue7+TC2 0001820]: The impact of changing NF should be stated
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1820 == Reported By:mortoneccc Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1820 Category: Shell and Utilities Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Ed Morton Organization: User Reference: Section:awk Page Number:0 Line Number:0 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-03-14 11:36 UTC Last Modified: 2024-05-13 15:07 UTC == Summary:The impact of changing NF should be stated == -- (0006779) geoffclare (manager) - 2024-05-13 15:07 https://austingroupbugs.net/view.php?id=1820#c6779 -- On Issue 8 draft 4.1 page 2613 line 85507, change: Field variables shall be designated by a '$' followed by a number or numerical expression. The effect of the field number expression evaluating to anything other than a non-negative integer is unspecified; uninitialized variables or string values need not be converted to numeric values in this context. New field variables can be created by assigning a value to them. References to nonexistent fields (that is, fields after $NF), shall evaluate to the uninitialized value. Such references shall not create new fields. However, assigning to a nonexistent field (for example, $(NF+2)=5) shall increase the value of NF; create any intervening fields with the uninitialized value; and cause the value of $0 to be recomputed, with the fields being separated by the value of OFS. Each field variable shall have a string value or an uninitialized value when created. Field variables shall have the uninitialized value when created from $0 using FS and the variable does not contain any characters. If appropriate, the field variable shall be considered a numeric string (see Expressions in awk, on page 2608). to: Field variables shall be designated by a '$' followed by a number or numerical expression. The effect of the field number expression evaluating to anything other than a non-negative integer is unspecified; uninitialized variables or string values need not be converted to numeric values in this context. Each field variable shall have a string value or an uninitialized value when created. Field variables shall have the uninitialized value when created from $0 using FS and the variable does not contain any characters. If appropriate, the field variable shall be considered a numeric string (see Expressions in awk, on page 2608). New field variables can be created by assigning a value to them. References to nonexistent fields (that is, fields after $NF), shall evaluate to the uninitialized value. Such references shall not create new fields. However, assigning to a nonexistent field (for example, $(NF+2)=5) shall increase the value of NF; create any intervening fields with the uninitialized value; and cause the value of $0 to be recomputed, with the fields being separated by the value of OFS. Directly increasing the value of NF (for example, NF += 2) shall have the same effect as assigning an empty string to $NF (where NF has its new value). Decreasing the value of NF to a non-negative value shall remove all fields after $NF and cause the value of $0 to be recomputed, with the fields being separated by the value of OFS. Assigning to NF without changing its value (for example, NF = NF) shall cause the value of $0 to be recomputed, with the fields being separated by the value of OFS. Issue History Date ModifiedUsername FieldChange == 2024-03-14 11:36 mortoneccc New Issue 2024-03-14 11:36 mortoneccc Name => Ed Morton 2024-03-14 11:36 mortoneccc Section => awk 2024-03-14 11:36 mortoneccc Page Number => 0 2024-03-14 11:36 mortoneccc Line Number => 0 2024-03-15 13:50 salewski Issue Monitored: salewski 2024-05-13 15:07 geoffclare Note Added: 0006779
[1003.1(2016/18)/Issue7+TC2 0001830]: off-by-one error regarding offset maximum
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1830 == Reported By:lacos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1830 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: László Érsek Organization: User Reference: Section:pwrite, write Page Number:? Line Number:? Interp Status: --- Final Accepted Text: == Date Submitted: 2024-05-03 06:55 UTC Last Modified: 2024-05-13 09:10 UTC == Summary:off-by-one error regarding offset maximum == -- (0006778) geoffclare (manager) - 2024-05-13 09:10 https://austingroupbugs.net/view.php?id=1830#c6778 -- This seems to be a difference in understanding of what the standard means when it refers to data transfer past a given offset. My understanding matches the way I believe that the author(s) of that text intended it to be read. Taking the example of offset 127, to me this code: lseek(fd, 127, SEEK_SET); write(fd, "X", 1); results in data transfer past the offset 127, because the new offset is 128 which is greater than 127. It appears that other people understand the phrase differently. This should be solved by changing the phrasing to something that can't be understood in different ways. For example:For regular files, no data transfer shall occur that would result in the file offset being set to a value greater than the offset maximum established in the open file description associated with fildes. Issue History Date ModifiedUsername FieldChange == 2024-05-03 06:55 lacos New Issue 2024-05-03 06:55 lacos Name => László Érsek 2024-05-03 06:55 lacos Section => pwrite, write 2024-05-03 06:55 lacos Page Number => ? 2024-05-03 06:55 lacos Line Number => ? 2024-05-13 09:10 geoffclare Note Added: 0006778 ==
[1003.1(2016/18)/Issue7+TC2 0001817]: lseek(2) - "size of a file" undefined
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=1817 == Reported By:kre Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1817 Category: System Interfaces Type: Omission Severity: Objection Priority: normal Status: Resolved Name: Robert Elz Organization: User Reference: Section:XSH 13 lseek Page Number:1292-3 Line Number:43059, 43061-2 43070-2 Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1817#c6777 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2024-02-25 05:34 UTC Last Modified: 2024-05-09 15:12 UTC == Summary:lseek(2) - "size of a file" undefined == Issue History Date ModifiedUsername FieldChange == 2024-02-25 05:34 kreNew Issue 2024-02-25 05:34 kreName => Robert Elz 2024-02-25 05:34 kreSection => XSH 13 lseek 2024-02-25 05:34 krePage Number => 1292-3 2024-02-25 05:34 kreLine Number => 43059, 43061-2 43070-2 2024-04-11 11:12 geoffclare Note Added: 0006745 2024-04-11 12:53 kreNote Added: 0006746 2024-05-02 16:00 eblake Note Added: 0006775 2024-05-09 15:10 geoffclare Note Added: 0006777 2024-05-09 15:12 geoffclare Interp Status => --- 2024-05-09 15:12 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1817#c6777 2024-05-09 15:12 geoffclare Status New => Resolved 2024-05-09 15:12 geoffclare Resolution Open => Accepted As Marked ==
[1003.1(2016/18)/Issue7+TC2 0001830]: off-by-one error regarding offset maximum
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1830 == Reported By:lacos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1830 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: László Érsek Organization: User Reference: Section:pwrite, write Page Number:? Line Number:? Interp Status: --- Final Accepted Text: == Date Submitted: 2024-05-03 06:55 UTC Last Modified: 2024-05-03 06:55 UTC == Summary:off-by-one error regarding offset maximum Description: (Sorry for not providing page and line numbers; I've not been following POSIX development for a good while, and don't remember where I could download a PDF version.) The open() specification contains: "The largest value that can be represented correctly in an object of type off_t shall be established as the offset maximum in the open file description." The write() / pwrite() spec states the following, *consistently* with the open() spec: """ [EFBIG] The file is a regular file, nbyte is greater than 0, and the starting position is greater than or equal to the offset maximum established in the open file description associated with fildes. """ However, the write() / pwrite() spec also states the following, *inconsistently* with the above references: "For regular files, no data transfer shall occur past the offset maximum established in the open file description associated with fildes." This last statement is not strict enough; a data transfer even precisely *at* the offset maximum, not just past it, should not occur. Otherwise, the resultant offset will not be representable in off_t. Footnote 1: for simplicity, assume that off_t is identical to int8_t; in that case, the off_t maximum, hence the offset maximum, is 127. If we allowed lseek(fd, 127, SEEK_SET); write(fd, "X", 1); to succeed, then the next call to lseek(fd, 0, SEEK_CUR); would have to fail with -1/EOVERFLOW. The EFBIG description in write() actually forbids the above write() from succeeding -- correctly so --, however the "no data transfer shall occur past the offset maximum" language would permit this write() to succeed (because the data transfer would occur precisely *at* the offset maximum), and that's what's wrong.) Footnote 2: this is an interesting difference from pointer arithmetic in the C standard. In, C, the following is valid: char x[10]; char *p; p = x + 9; *p++ = 'X'; p; That is, pointing one past the array is valid -- evaluating such a pointer is valid (while dereferencing it is undefined behavior). In contrast, with the file position, we cannot point one past the max representable off_t, and therefore we cannot transfer to/from the byte in the file *at* the max representable off_t. Desired Action: In write()/pwrite(), change "For regular files, no data transfer shall occur past the offset maximum established in the open file description associated with fildes." to "For regular files, no data transfer shall occur at or past the offset maximum established in the open file description associated with fildes." == Issue History Date ModifiedUsername FieldChange == 2024-05-03 06:55 lacos New Issue 2024-05-03 06:55 lacos Name => László Érsek 2024-05-03 06:55 lacos Section => pwrite, write 2024-05-03 06:55 lacos Page Number => ? 2024-05-03 06:55 lacos Line Number => ? ==
[1003.1(2016/18)/Issue7+TC2 0001817]: lseek(2) - "size of a file" undefined
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1817 == Reported By:kre Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1817 Category: System Interfaces Type: Omission Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XSH 13 lseek Page Number:1292-3 Line Number:43059, 43061-2 43070-2 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-02-25 05:34 UTC Last Modified: 2024-05-09 15:10 UTC == Summary:lseek(2) - "size of a file" undefined == -- (0006777) geoffclare (manager) - 2024-05-09 15:10 https://austingroupbugs.net/view.php?id=1817#c6777 -- On page 965 line 32823 section fstatat(), change: The value of the st_size member shall be set to the length of the pathname contained in the symbolic link to: The value of the st_size member shall be set to the length of the contents of the symbolic link On page 1292 line 43059 section lseek(), change: the file offset shall be set to the size of the file plus offset. to: the file offset shall be set to the size of the file (as would be returned in st_size by the fstat() function) plus offset; except that for block special files, it is unspecified whether the offset is relative to the start of the file or to the corresponding device's capacity in bytes. On page 1293 line 43104 section lseek(), add fstat() to SEE ALSO. Issue History Date ModifiedUsername FieldChange == 2024-02-25 05:34 kreNew Issue 2024-02-25 05:34 kreName => Robert Elz 2024-02-25 05:34 kreSection => XSH 13 lseek 2024-02-25 05:34 krePage Number => 1292-3 2024-02-25 05:34 kreLine Number => 43059, 43061-2 43070-2 2024-04-11 11:12 geoffclare Note Added: 0006745 2024-04-11 12:53 kreNote Added: 0006746 2024-05-02 16:00 eblake Note Added: 0006775 2024-05-09 15:10 geoffclare Note Added: 0006777 ==
[1003.1(2016/18)/Issue7+TC2 0001830]: off-by-one error regarding offset maximum
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1830 == Reported By:lacos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1830 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: László Érsek Organization: User Reference: Section:pwrite, write Page Number:? Line Number:? Interp Status: --- Final Accepted Text: == Date Submitted: 2024-05-03 06:55 UTC Last Modified: 2024-05-03 06:55 UTC == Summary:off-by-one error regarding offset maximum Description: (Sorry for not providing page and line numbers; I've not been following POSIX development for a good while, and don't remember where I could download a PDF version.) The open() specification contains: "The largest value that can be represented correctly in an object of type off_t shall be established as the offset maximum in the open file description." The write() / pwrite() spec states the following, *consistently* with the open() spec: """ [EFBIG] The file is a regular file, nbyte is greater than 0, and the starting position is greater than or equal to the offset maximum established in the open file description associated with fildes. """ However, the write() / pwrite() spec also states the following, *inconsistently* with the above references: "For regular files, no data transfer shall occur past the offset maximum established in the open file description associated with fildes." This last statement is not strict enough; a data transfer even precisely *at* the offset maximum, not just past it, should not occur. Otherwise, the resultant offset will not be representable in off_t. Footnote 1: for simplicity, assume that off_t is identical to int8_t; in that case, the off_t maximum, hence the offset maximum, is 127. If we allowed lseek(fd, 127, SEEK_SET); write(fd, "X", 1); to succeed, then the next call to lseek(fd, 0, SEEK_CUR); would have to fail with -1/EOVERFLOW. The EFBIG description in write() actually forbids the above write() from succeeding -- correctly so --, however the "no data transfer shall occur past the offset maximum" language would permit this write() to succeed (because the data transfer would occur precisely *at* the offset maximum), and that's what's wrong.) Footnote 2: this is an interesting difference from pointer arithmetic in the C standard. In, C, the following is valid: char x[10]; char *p; p = x + 9; *p++ = 'X'; p; That is, pointing one past the array is valid -- evaluating such a pointer is valid (while dereferencing it is undefined behavior). In contrast, with the file position, we cannot point one past the max representable off_t, and therefore we cannot transfer to/from the byte in the file *at* the max representable off_t. Desired Action: In write()/pwrite(), change "For regular files, no data transfer shall occur past the offset maximum established in the open file description associated with fildes." to "For regular files, no data transfer shall occur at or past the offset maximum established in the open file description associated with fildes." == Issue History Date ModifiedUsername FieldChange == 2024-05-03 06:55 lacos New Issue 2024-05-03 06:55 lacos Name => László Érsek 2024-05-03 06:55 lacos Section => pwrite, write 2024-05-03 06:55 lacos Page Number => ? 2024-05-03 06:55 lacos Line Number => ? ==
[1003.1(2016/18)/Issue7+TC2 0001829]: symlink() and terminating null bytes
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1829 == Reported By:geoffclare Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1829 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section:symlink() Page Number:2095 Line Number:67093 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-05-02 16:48 UTC Last Modified: 2024-05-02 16:52 UTC == Summary:symlink() and terminating null bytes == -- (0006776) geoffclare (manager) - 2024-05-02 16:52 https://austingroupbugs.net/view.php?id=1829#c6776 -- Also on page 965 line 32824 section fstatat(), delete:not including any terminating null byte Issue History Date ModifiedUsername FieldChange == 2024-05-02 16:48 geoffclare New Issue 2024-05-02 16:48 geoffclare Name => Geoff Clare 2024-05-02 16:48 geoffclare Organization => The Open Group 2024-05-02 16:48 geoffclare Section => symlink() 2024-05-02 16:48 geoffclare Page Number => 2095 2024-05-02 16:48 geoffclare Line Number => 67093 2024-05-02 16:48 geoffclare Interp Status => --- 2024-05-02 16:52 geoffclare Note Added: 0006776 ==
[1003.1(2016/18)/Issue7+TC2 0001829]: symlink() and terminating null bytes
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1829 == Reported By:geoffclare Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1829 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section:symlink() Page Number:2095 Line Number:67093 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-05-02 16:48 UTC Last Modified: 2024-05-02 16:48 UTC == Summary:symlink() and terminating null bytes Description: The description of symlink() says the created symbolic link contains "the string pointed to by path1". Since a string by definition has a terminating null byte, by a strict reading this implies the null is included in the symbolic link, but that's not the intended requirement, nor how systems behave. Desired Action: On page 2095 line 67093 section symlink(), change:The symlink() function shall create a symbolic link called path2 that contains the string pointed to by path1 (path2 is the name of the symbolic link created, path1 is the string contained in the symbolic link).to:The symlink() function shall create a symbolic link called path2 that contains the string pointed to by path1, excluding the terminating null byte. (That is, path2 specifies the pathname of the symbolic link created; path1 specifies the contents of the symbolic link.) == Issue History Date ModifiedUsername FieldChange == 2024-05-02 16:48 geoffclare New Issue 2024-05-02 16:48 geoffclare Name => Geoff Clare 2024-05-02 16:48 geoffclare Organization => The Open Group 2024-05-02 16:48 geoffclare Section => symlink() 2024-05-02 16:48 geoffclare Page Number => 2095 2024-05-02 16:48 geoffclare Line Number => 67093 2024-05-02 16:48 geoffclare Interp Status => --- ==
[1003.1(2016/18)/Issue7+TC2 0001828]: Rationale is out of date
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1828 == Reported By:nick Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1828 Category: Base Definitions and Headers Type: Clarification Requested Severity: Editorial Priority: low Status: New Name: Nick Stoughton Organization: User Reference: Section:sys/stat.h Page Number:395 Line Number:13468 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-05-02 16:23 UTC Last Modified: 2024-05-02 16:23 UTC == Summary:Rationale is out of date Description: The rationale for sys/stat.h states This version of the standard specifies the traditional encoding, in recognition that nearly 20 years after the first publication of this standard numeric file modes are still in widespread use by application developers, and that all conforming implementations still use the traditional encoding. However, at this point we are around 36 years after the first publication, and numeric file modes are still in widespread use. Desired Action: on lines 13467-13468 (Issue 7 TC2) change in recognition that nearly 20 years after the first publication ... to in recognition that many years after the first publication ... == Issue History Date ModifiedUsername FieldChange == 2024-05-02 16:23 nick New Issue 2024-05-02 16:23 nick Name => Nick Stoughton 2024-05-02 16:23 nick Section => sys/stat.h 2024-05-02 16:23 nick Page Number => 395 2024-05-02 16:23 nick Line Number => 13468 2024-05-02 16:23 nick Interp Status => --- ==
[1003.1(2016/18)/Issue7+TC2 0001817]: lseek(2) - "size of a file" undefined
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1817 == Reported By:kre Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1817 Category: System Interfaces Type: Omission Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XSH 13 lseek Page Number:1292-3 Line Number:43059, 43061-2 43070-2 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-02-25 05:34 UTC Last Modified: 2024-05-02 16:00 UTC == Summary:lseek(2) - "size of a file" undefined == -- (0006775) eblake (manager) - 2024-05-02 16:00 https://austingroupbugs.net/view.php?id=1817#c6775 -- https://github.com/util-linux/util-linux/blob/master/lib/blkdev.c#L92 is an example of an #ifdef chain for several ioctl attempts that tries to get block dev size across several systems, given the fact that neither st_size nor lseek(SEEK_END) are universally reliable for the purpose. Issue History Date ModifiedUsername FieldChange == 2024-02-25 05:34 kreNew Issue 2024-02-25 05:34 kreName => Robert Elz 2024-02-25 05:34 kreSection => XSH 13 lseek 2024-02-25 05:34 krePage Number => 1292-3 2024-02-25 05:34 kreLine Number => 43059, 43061-2 43070-2 2024-04-11 11:12 geoffclare Note Added: 0006745 2024-04-11 12:53 kreNote Added: 0006746 2024-05-02 16:00 eblake Note Added: 0006775 ==
[Issue 8 drafts 0001816]: daylight, timezone, tzname do not work with location-based TZ
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1816 == Reported By:eggert Assigned To: == Project:Issue 8 drafts Issue ID: 1816 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Paul Eggert Organization: UCLA Computer Science User Reference: Section:daylight, timezone, tzname Page Number:2310-2311 Line Number:75175-75207 Final Accepted Text: == Date Submitted: 2024-02-23 08:54 UTC Last Modified: 2024-04-29 15:42 UTC == Summary:daylight, timezone, tzname do not work with location-based TZ == Relationships ID Summary -- related to 0001797 strftime %s should be able ... == -- (0006774) Don Cragun (manager) - 2024-04-29 15:42 https://www.austingroupbugs.net/view.php?id=1816#c6774 -- DESCRIPTION page 454 line 15841, change XSI to OB XSI. line 15843, change CX to OB CX. FUTURE DIRECTIONS page 454 line 15856, change "None" to:The variables daylight, timezone, and tzname are planned to be removed in a future version of this standard, as they have unspecified values unless the environment variable TZ is of the second format. daylight SYNOPSIS page 801 line 27445, change XSI to OB XSI. strptime DESCRIPTION page 2160 lines 70602-70606: add OB shading to "If this name matches ... shall be set to 0." timezone SYNOPSIS page 2279 line 74382, change XSI to OB XSI. Also remove the "()" after timezone in the page heading. tzset SYNOPSIS page 2310 line 75167: change XSI to OB XSI line 75169: change CX to OB CX line 75170: add CX margin marker tzset DESCRIPTION page 2310 lines 75175-75178 add OB margin marker and shading line 75175: Prepend "If the value of TZ is of the second format," line 75178: change "as described in XBD Chapter 8 (on page 167)" to "as described for the second TZ format in XBD Section 8.3 (on page 174)" line 75179: change XSI to OB XSI line 75179: Also prepend "If the value of TZ is of the second format," Line 75182: Append the following paragraph:[OB]If the value of TZ is not of the second format, the tzset() function shall set the array elements of the external variable tzname to point to unspecified string values[/OB] [OB XSI]and shall set the external variables daylight and timezone to unspecified values.[/OB XSI] line 75183: change XSI to OB XSI line 75199 (APPLICATION USAGE) Append the following paragraph:The values of the variables daylight, timezone, and tzname can only be relied upon to reflect the local timezone information if the environment variable TZ value is of the second format. Applications should use the tm_zone member of the tm structure instead of tzname and the tm_gmtoff member instead of timezone. When using tm_zone and tm_gmtoff there is no need for the information that is available in daylight. page 2311 line 75207 (tzset() FUTURE DIRECTIONS), change "None" to:The variables daylight, timezone, and tzname are planned to be removed in a future version of this standard, as they have unspecified values unless the environment variable TZ is of the second format. page 2311 line 75210 (tzset() SEE ALSO), change:XBD Chapter 8 (on page 167)to:XBD Section 8.3 (on page 174) Issue History Date ModifiedUsername FieldChange == 2024-02-23 08:54 eggert New Issue 2024-02-23 08:54 eggert Name => Paul Eggert 2024-02-23 08:54 eggert Organization => UCLA Computer Science 2024-02-23 08:54 eggert Section => daylight, timezone, tzname 2024-02-23 08:54 eggert Page Number => 2310-2311 2024-02-23 08:54 eggert Line Number => 75175-75207 2024-02-25 07:07 kreNote Added: 0006678 2024-02-26 18:06 eggert Note Added: 0006687
[Issue 8 drafts 0001806]: ambiguous description of which attributes `unset` unsets in case of readonly attribute being set
The following issue has been UPDATED. == https://austingroupbugs.net/view.php?id=1806 == Reported By:calestyo Assigned To: == Project:Issue 8 drafts Issue ID: 1806 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Resolution Proposed Name: Christoph Anton Mitterer Organization: User Reference: Section:Shell Command Language Page Number:2571 Line Number:83916, ff. Final Accepted Text:https://austingroupbugs.net/view.php?id=1806#c6727 == Date Submitted: 2024-02-02 22:53 UTC Last Modified: 2024-04-25 15:09 UTC == Summary:ambiguous description of which attributes `unset` unsets in case of readonly attribute being set == Issue History Date ModifiedUsername FieldChange == 2024-02-02 22:53 calestyo New Issue 2024-02-02 22:53 calestyo Name => Christoph Anton Mitterer 2024-02-02 22:53 calestyo Section => Shell Command Language 2024-02-02 22:53 calestyo Page Number => 2571 2024-02-02 22:53 calestyo Line Number => 83916, ff. 2024-02-03 00:30 larryv Note Added: 0006647 2024-02-13 20:10 mirabilos Note Added: 0006653 2024-02-13 20:25 mirabilos Note Added: 0006654 2024-02-13 22:48 calestyo Note Added: 0006655 2024-02-13 22:55 calestyo Note Added: 0006656 2024-02-25 07:34 kreNote Added: 0006679 2024-02-25 21:50 calestyo Note Added: 0006680 2024-02-25 22:36 larryv Note Added: 0006681 2024-02-25 23:00 calestyo Note Added: 0006682 2024-02-25 23:16 larryv Note Added: 0006683 2024-02-25 23:22 larryv Note Added: 0006684 2024-03-25 16:29 geoffclare Note Added: 0006727 2024-03-25 16:30 geoffclare Note Edited: 0006727 2024-03-25 16:31 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1806#c6727 2024-03-25 16:31 geoffclare Status New => Resolution Proposed 2024-03-25 16:31 geoffclare Resolution Open => Accepted As Marked 2024-03-25 16:31 geoffclare Tag Attached: tc1-2024 2024-04-25 15:09 eblake Summary ambiguous description of which attribtes `unset` unsets in case of readonly attribute being set => ambiguous description of which attributes `unset` unsets in case of readonly attribute being set ==
[1003.1(2016/18)/Issue7+TC2 0001808]: Add option -a to getconf utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1808 == Reported By:cquike Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1808 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Resolved Name: Enrique Garcia Organization: User Reference: Section:getconf Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1808#c6747 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2024-02-03 01:44 UTC Last Modified: 2024-04-23 13:57 UTC == Summary:Add option -a to getconf utility == -- (0006773) kre (reporter) - 2024-04-23 13:57 https://austingroupbugs.net/view.php?id=1808#c6773 -- Re: https://austingroupbugs.net/view.php?id=1808#c6772 POSIX can only standardise existing practice, we cannot invent a new format I agree, pity the people who invented all of those posix_abcdefg() interfaces (and a whole bunch more) apparently do not. That's why I suggested doing nothing right now. This issue is already tagged as issue9 (which seems correct to me) - which means it isn't going to appear in a standard for a decade or more (just consider the time between when issue7 was published, and whenever it eventually happens, issue8). Now the issues are known, there is plenty of time for the implementers to implement something better (safer) that what now exists. If that doesn't happen, then what is proposed can be accepted sometime much closer to the issue9 deadline. Note, I am not suggesting this for everything - in general there's a benefit to knowing (being able to find out) what the next standard will say about something - allows new implementers to match the existing (appropriate) behaviour, which just happens to not yet be standardised. But here, existing behaviour seems to be unsafe, and not good to specify, however unlikely you believe it to be that it will actually cause problems. Just wait. Change the status back to just "open". Issue History Date ModifiedUsername FieldChange == 2024-02-03 01:44 cquike New Issue 2024-02-03 01:44 cquike Name => Enrique Garcia 2024-02-03 01:44 cquike Section => getconf 2024-02-03 01:44 cquike Page Number => (page or range of pages) 2024-02-03 01:44 cquike Line Number => (Line or range of lines) 2024-02-25 05:48 kreNote Added: 0006674 2024-03-06 10:40 cquike Note Added: 0006705 2024-04-11 15:19 geoffclare Note Added: 0006747 2024-04-11 15:21 geoffclare Note Edited: 0006747 2024-04-11 15:21 geoffclare Interp Status => --- 2024-04-11 15:21 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1808#c6747 2024-04-11 15:21 geoffclare Status New => Resolved 2024-04-11 15:21 geoffclare Resolution Open => Accepted As Marked 2024-04-11 15:22 geoffclare Tag Attached: issue9 2024-04-17 19:27 eblake Note Added: 0006764 2024-04-18 01:04 philip-guentherNote Added: 0006765 2024-04-18 09:36 geoffclare Note Added: 0006766 2024-04-19 12:28 kreNote Added: 0006768 2024-04-19 13:40 geoffclare Note Added: 0006769 2024-04-19 15:33 kreNote Edited: 0006768 2024-04-19 15:37 kreNote Added: 0006770 2024-04-23 09:59 geoffclare Note Added: 0006772 2024-04-23 13:57 kreNote Added: 0006773
[Issue 8 drafts 0001812]: Support xargs -P 0
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1812 == Reported By:dwheeler Assigned To:ajosey == Project:Issue 8 drafts Issue ID: 1812 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Resolved Name: David A. Wheeler Organization: The Linux Foundation User Reference: Section:xargs Page Number:3600-3601 Line Number:123252 Final Accepted Text:https://austingroupbugs.net/view.php?id=1812#c6751 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2024-02-15 20:53 UTC Last Modified: 2024-04-19 20:49 UTC == Summary:Support xargs -P 0 == Relationships ID Summary -- related to 0001801 xargs: add -P option == -- (0006771) mohd_akram (reporter) - 2024-04-19 20:49 https://austingroupbugs.net/view.php?id=1812#c6771 -- FYI, I didn't add this in the other issue despite wanting it because of what hvd and gabravier mentioned. The option does not seem to behave reasonably in current implementations and IMO shouldn't be included because of that. This description is misleading because the current behavior is to maximize the number of processes without regard to runtime or anything else which can lead to hundreds of processes that slow down the entire OS. A user who is simply looking for a "parallelize this" flag can use `-P$(getconf NPROCESSORS_ONLN)`. Issue History Date ModifiedUsername FieldChange == 2024-02-15 20:53 dwheeler New Issue 2024-02-15 20:53 dwheeler Status New => Under Review 2024-02-15 20:53 dwheeler Assigned To => ajosey 2024-02-15 20:53 dwheeler Name => David A. Wheeler 2024-02-15 20:53 dwheeler Organization => The Linux Foundation 2024-02-15 20:53 dwheeler Section => xargs 2024-02-15 20:53 dwheeler Page Number => 3600-3601 2024-02-15 20:53 dwheeler Line Number => 123252 2024-02-16 10:28 geoffclare Note Added: 0006659 2024-02-16 11:39 kreNote Added: 0006661 2024-02-19 19:58 dwheeler Note Added: 0006667 2024-02-19 21:28 steffenNote Added: 0006668 2024-02-19 22:44 hvdNote Added: 0006669 2024-02-21 00:41 gabravier Note Added: 0006671 2024-03-01 11:48 geoffclare Project 1003.1(2008)/Issue 7 => Issue 8 drafts 2024-04-15 16:04 geoffclare Relationship added related to 0001801 2024-04-15 16:29 geoffclare Note Added: 0006751 2024-04-15 16:30 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1812#c6751 2024-04-15 16:30 geoffclare Status Under Review => Resolved 2024-04-15 16:30 geoffclare Resolution Open => Accepted As Marked 2024-04-15 16:31 geoffclare Tag Attached: issue9 2024-04-19 20:49 mohd_akram Note Added: 0006771 ==
[1003.1(2016/18)/Issue7+TC2 0001808]: Add option -a to getconf utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1808 == Reported By:cquike Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1808 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Resolved Name: Enrique Garcia Organization: User Reference: Section:getconf Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1808#c6747 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2024-02-03 01:44 UTC Last Modified: 2024-04-19 15:37 UTC == Summary:Add option -a to getconf utility == -- (0006770) kre (reporter) - 2024-04-19 15:37 https://austingroupbugs.net/view.php?id=1808#c6770 -- While what you say in https://austingroupbugs.net/view.php?id=1808#c6769 is probably right, and real systems wouldn't do that, systems looking for holes in the spec, and/or applications would - it is the kind of thing that santitzers do all the time. Garbage, but legal, input, generated for the whole purpose of defeating the system. Since it is known now (and also as nothing about what is resolved in this issue is going to see the light of day for years) it would make sense to me to defer this, and look for a good solution, and eventually specify that, rather than specify something which is just "extremely unlikely" to fail, when we already know how to make that happen. Issue History Date ModifiedUsername FieldChange == 2024-02-03 01:44 cquike New Issue 2024-02-03 01:44 cquike Name => Enrique Garcia 2024-02-03 01:44 cquike Section => getconf 2024-02-03 01:44 cquike Page Number => (page or range of pages) 2024-02-03 01:44 cquike Line Number => (Line or range of lines) 2024-02-25 05:48 kreNote Added: 0006674 2024-03-06 10:40 cquike Note Added: 0006705 2024-04-11 15:19 geoffclare Note Added: 0006747 2024-04-11 15:21 geoffclare Note Edited: 0006747 2024-04-11 15:21 geoffclare Interp Status => --- 2024-04-11 15:21 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1808#c6747 2024-04-11 15:21 geoffclare Status New => Resolved 2024-04-11 15:21 geoffclare Resolution Open => Accepted As Marked 2024-04-11 15:22 geoffclare Tag Attached: issue9 2024-04-17 19:27 eblake Note Added: 0006764 2024-04-18 01:04 philip-guentherNote Added: 0006765 2024-04-18 09:36 geoffclare Note Added: 0006766 2024-04-19 12:28 kreNote Added: 0006768 2024-04-19 13:40 geoffclare Note Added: 0006769 2024-04-19 15:33 kreNote Edited: 0006768 2024-04-19 15:37 kreNote Added: 0006770 ==
[1003.1(2016/18)/Issue7+TC2 0001808]: Add option -a to getconf utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1808 == Reported By:cquike Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1808 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Resolved Name: Enrique Garcia Organization: User Reference: Section:getconf Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1808#c6747 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2024-02-03 01:44 UTC Last Modified: 2024-04-19 12:28 UTC == Summary:Add option -a to getconf utility == -- (0006768) kre (reporter) - 2024-04-19 12:28 https://austingroupbugs.net/view.php?id=1808#c6768 -- wrt biugnote:6766 confstr() returns the implementation's standard PATH, that's fine, but: so the value will not contain any newlines, How does that follow? What if the implementation's standard PATH contains the directory whose name is obtained from printf '%s\n%s' "/usr/" "POSIX" as a directory no-one would normally include in PATH, which contains versions of various standard utilities to replace the ones the implementation normally uses which differ from the standard in some way. Is there something somewhere which prohibits an implementation like that? If not, your conclusion doesn't follow. Issue History Date ModifiedUsername FieldChange == 2024-02-03 01:44 cquike New Issue 2024-02-03 01:44 cquike Name => Enrique Garcia 2024-02-03 01:44 cquike Section => getconf 2024-02-03 01:44 cquike Page Number => (page or range of pages) 2024-02-03 01:44 cquike Line Number => (Line or range of lines) 2024-02-25 05:48 kreNote Added: 0006674 2024-03-06 10:40 cquike Note Added: 0006705 2024-04-11 15:19 geoffclare Note Added: 0006747 2024-04-11 15:21 geoffclare Note Edited: 0006747 2024-04-11 15:21 geoffclare Interp Status => --- 2024-04-11 15:21 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1808#c6747 2024-04-11 15:21 geoffclare Status New => Resolved 2024-04-11 15:21 geoffclare Resolution Open => Accepted As Marked 2024-04-11 15:22 geoffclare Tag Attached: issue9 2024-04-17 19:27 eblake Note Added: 0006764 2024-04-18 01:04 philip-guentherNote Added: 0006765 2024-04-18 09:36 geoffclare Note Added: 0006766 2024-04-19 12:28 kreNote Added: 0006768 ==
[Issue 8 drafts 0001813]: generic xargs description cleanups
The following issue has a PROPOSED RESOLUTION. == https://austingroupbugs.net/view.php?id=1813 == Reported By:kre Assigned To: == Project:Issue 8 drafts Issue ID: 1813 Category: Shell and Utilities Type: Error Severity: Editorial Priority: normal Status: Resolution Proposed Name: Robert Elz Organization: User Reference: Section:XCU 3 / xargs Page Number:3600-3603 Line Number:123177-8 123183 123184-6 123228-32 123233-7 123252-3 123263 123304-6 Final Accepted Text:https://austingroupbugs.net/view.php?id=1813#c6767 == Date Submitted: 2024-02-16 14:42 UTC Last Modified: 2024-04-18 16:25 UTC == Summary:generic xargs description cleanups == Issue History Date ModifiedUsername FieldChange == 2024-02-16 14:42 kreNew Issue 2024-02-16 14:42 kreName => Robert Elz 2024-02-16 14:42 kreSection => XCU 3 / xargs 2024-02-16 14:42 krePage Number => 3600-3603 2024-02-16 14:42 kreLine Number => 123177-8 123183 123184-6 123228-32 123233-7 123252-3 123263 123304-6 2024-04-18 16:24 geoffclare Note Added: 0006767 2024-04-18 16:25 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1813#c6767 2024-04-18 16:25 geoffclare Status New => Resolution Proposed 2024-04-18 16:25 geoffclare Resolution Open => Accepted As Marked ==
[Issue 8 drafts 0001813]: generic xargs description cleanups
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1813
==
Reported By:kre
Assigned To:
==
Project:Issue 8 drafts
Issue ID: 1813
Category: Shell and Utilities
Type: Error
Severity: Editorial
Priority: normal
Status: New
Name: Robert Elz
Organization:
User Reference:
Section:XCU 3 / xargs
Page Number:3600-3603
Line Number:123177-8 123183 123184-6 123228-32 123233-7 123252-3
123263 123304-6
Final Accepted Text:
==
Date Submitted: 2024-02-16 14:42 UTC
Last Modified: 2024-04-18 16:24 UTC
==
Summary:generic xargs description cleanups
==
--
(0006767) geoffclare (manager) - 2024-04-18 16:24
https://austingroupbugs.net/view.php?id=1813#c6767
--
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:
-
None.
Notes to the Editor (not part of this interpretation):
---
On page 3600 line 123176, change:
the application shall ensure that arguments in the standard
input are delimited by unquoted characters, unescaped
characters, or characters
to:
the application shall ensure that arguments in the standard
input are delimited by characters that are neither quoted nor
escaped, or by unescaped characters
After page 3600 line 123183, add two bullet items:
Quoting and escaping characters shall not be included in the arguments
passed to utility. Escaped characters shall be included in
the arguments.
It shall be an error if an attempt is made to quote a
character.
On page 3601 line 123231, change:
or {LINE_MAX} if there is no −s option
to:
or the default command line length if there is no −s
option
On page 3601 line 123232, change:
The last iteration has fewer than number, but not zero,
operands remaining.
to:
The last iteration has fewer than number operands
remaining, or zero arguments were read from standard input (and the
-r option is not specified).
On page 3602 line 123263, change:
The name of the utility to be invoked, found by search path
using ...
to:
The name of the utility to be invoked. If the name does not
contain a character, the utility shall be found by search path
using ...
On page 3603 line 123302, change:
If the −t option is specified, the utility and its
constructed argument list shall be written to standard error, as it will be
invoked, prior to invocation.
to:
If the −t option is specified, the utility and its
constructed argument list, with a character preceding each argument
and a terminating , shall be written to standard error, as it will
be invoked, prior to invocation. Implementations may insert quoting and
escaping characters in the output produced by -t such that the
output (minus the utility name) can be unambiguously used as input to a
subsequent xargs command and result in the same constructed argument
list.
On page 3603 line 123304, change:
a prompt of the following format shall be written (in the POSIX
locale):
"?..."
at the end of the line of the output from −t.
to:
a prompt shall be written at the end of the line of the output
from −t. In the POSIX locale, the format of the prompt shall be:
"?..."
Issue History
Date ModifiedUsername FieldChange
==
2024-02-16 14:42 kreNew Issue
2024-02-16 14:42 kreName => Robert Elz
2024-02-16 14:42 kreSection => XCU 3 / xargs
2024-02-16 14:42 krePage Number => 3600-3603
2024-02-16 14:42 kreLine Number => 123177-8 123183
123184-6 123228-32 123233-7 123252-3 123263 123304-6
2024-04-18 16:24 geoffclare Note Added: 0006767
==
[1003.1(2016/18)/Issue7+TC2 0001808]: Add option -a to getconf utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1808 == Reported By:cquike Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1808 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Resolved Name: Enrique Garcia Organization: User Reference: Section:getconf Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1808#c6747 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2024-02-03 01:44 UTC Last Modified: 2024-04-18 01:04 UTC == Summary:Add option -a to getconf utility == -- (0006765) philip-guenther (reporter) - 2024-04-18 01:04 https://austingroupbugs.net/view.php?id=1808#c6765 -- To agree with https://austingroupbugs.net/view.php?id=1808#c6764, that (the ambiguities) were part of why on OpenBSD we did -l and -L, documented currently as: -L List the system variables that can be used with the getconf utility that require a pathname argument. -l List the system variables that can be used with the getconf utility without a pathname argument. So, there's existing practice for that. Issue History Date ModifiedUsername FieldChange == 2024-02-03 01:44 cquike New Issue 2024-02-03 01:44 cquike Name => Enrique Garcia 2024-02-03 01:44 cquike Section => getconf 2024-02-03 01:44 cquike Page Number => (page or range of pages) 2024-02-03 01:44 cquike Line Number => (Line or range of lines) 2024-02-25 05:48 kreNote Added: 0006674 2024-03-06 10:40 cquike Note Added: 0006705 2024-04-11 15:19 geoffclare Note Added: 0006747 2024-04-11 15:21 geoffclare Note Edited: 0006747 2024-04-11 15:21 geoffclare Interp Status => --- 2024-04-11 15:21 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1808#c6747 2024-04-11 15:21 geoffclare Status New => Resolved 2024-04-11 15:21 geoffclare Resolution Open => Accepted As Marked 2024-04-11 15:22 geoffclare Tag Attached: issue9 2024-04-17 19:27 eblake Note Added: 0006764 2024-04-18 01:04 philip-guentherNote Added: 0006765 ==
[1003.1(2016/18)/Issue7+TC2 0001808]: Add option -a to getconf utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1808 == Reported By:cquike Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1808 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Resolved Name: Enrique Garcia Organization: User Reference: Section:getconf Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1808#c6747 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2024-02-03 01:44 UTC Last Modified: 2024-04-17 19:27 UTC == Summary:Add option -a to getconf utility == -- (0006764) eblake (manager) - 2024-04-17 19:27 https://austingroupbugs.net/view.php?id=1808#c6764 -- In https://sourceware.org/bugzilla/show_bug.cgi?id=22099, the glibc developers were worried that the use of a colon is ambiguous because some confstr options might be related to PATH which itself uses a colon. We may be better off trying to standardize 'getopt -l' as a means of listing just the query names, and leave 'getopt -a' unstandardized. Issue History Date ModifiedUsername FieldChange == 2024-02-03 01:44 cquike New Issue 2024-02-03 01:44 cquike Name => Enrique Garcia 2024-02-03 01:44 cquike Section => getconf 2024-02-03 01:44 cquike Page Number => (page or range of pages) 2024-02-03 01:44 cquike Line Number => (Line or range of lines) 2024-02-25 05:48 kreNote Added: 0006674 2024-03-06 10:40 cquike Note Added: 0006705 2024-04-11 15:19 geoffclare Note Added: 0006747 2024-04-11 15:21 geoffclare Note Edited: 0006747 2024-04-11 15:21 geoffclare Interp Status => --- 2024-04-11 15:21 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1808#c6747 2024-04-11 15:21 geoffclare Status New => Resolved 2024-04-11 15:21 geoffclare Resolution Open => Accepted As Marked 2024-04-11 15:22 geoffclare Tag Attached: issue9 2024-04-17 19:27 eblake Note Added: 0006764 ==
[Issue 8 drafts 0001827]: Standardize gzip(1) cli interface instead of adding it to compress(1)
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1827 == Reported By:nrk Assigned To: == Project:Issue 8 drafts Issue ID: 1827 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: NRK Organization: User Reference: Section:compress(1) utility Page Number:n/a Line Number:n/a Final Accepted Text: == Date Submitted: 2024-04-15 03:23 UTC Last Modified: 2024-04-17 11:03 UTC == Summary:Standardize gzip(1) cli interface instead of adding it to compress(1) == -- (0006762) oguzismailuysal (reporter) - 2024-04-17 11:03 https://austingroupbugs.net/view.php?id=1827#c6762 -- Re: https://austingroupbugs.net/view.php?id=1827#c6761 Both the gzip file-format and the underlying algorithm (DEFLATE) are *entirely different* to LZW. Most other compression algorithms (bzip2, zstandard etc) in use are in similar boat where they are all vastly different to one another. Doesn't matter as long as they can be used for compressing arbitrary data. They all take a parameter specifying the compression level which can be relayed through the option -b if compress were to be implemented as a wrapper for standalone utilities. POSIX defines the interface, how it is implemented is outside the standard's scope. So in cases where an implementation wants to support both algorithms, the current state of compress(1) is not "less demanding" and saves them no work. It does, though. The interface is already there, implementing only the algorithm is less work than implementing both the algorithm and a separate interface. Documenting a single option argument is also less work than documenting a whole new utility. Not to mention, any implementation that wants to be useful in practice will need to ship gzip(1) anyways. That's an opinion. Currently if I want to provide a posix-compliant compress(1) tool, I only need to worry about LZW. Or if gzip(1) was standardized, and I wanted to provide posix-compliant gzip(1) I'd only need to worry about DEFLATE. But in the current draft, implementating a posix-compliant compress(1) requires me to both implement LZW and DEFLATE. I don't see a problem here. You can choose to comply with an older version of POSIX or not comply with POSIX at all. You keep mentioning "distros", I assume you mean Linux distributions. No Linux distribution is certified to be POSIX-conformant and I doubt any of them try to be so. So, what "distros" do is irrelevant here. Issue History Date ModifiedUsername FieldChange == 2024-04-15 03:23 nrkNew Issue 2024-04-15 03:23 nrkName => NRK 2024-04-15 03:23 nrkSection => compress(1) utility 2024-04-15 03:23 nrkPage Number => n/a 2024-04-15 03:23 nrkLine Number => n/a 2024-04-15 03:24 nrkIssue Monitored: nrk 2024-04-16 05:57 dannyniu Note Added: 0006752 2024-04-16 05:58 dannyniu Note Edited: 0006752 2024-04-16 18:39 steffenNote Added: 0006753 2024-04-16 22:51 nrkNote Added: 0006754 2024-04-16 23:03 nrkNote Added: 0006755 2024-04-16 23:32 oguzismailuysalNote Added: 0006756 2024-04-17 00:10 steffenNote Added: 0006757 2024-04-17 00:32 nrkNote Added: 0006758 2024-04-17 01:36 larryv Note Added: 0006759 2024-04-17 06:16 oguzismailuysalNote Added: 0006760 2024-04-17 06:18 oguzismailuysalNote Edited: 0006760 2024-04-17 06:19 oguzismailuysalNote Edited: 0006760 2024-04-17 07:47 nrkNote Added: 0006761
[Issue 8 drafts 0001827]: Standardize gzip(1) cli interface instead of adding it to compress(1)
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1827 == Reported By:nrk Assigned To: == Project:Issue 8 drafts Issue ID: 1827 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: NRK Organization: User Reference: Section:compress(1) utility Page Number:n/a Line Number:n/a Final Accepted Text: == Date Submitted: 2024-04-15 03:23 UTC Last Modified: 2024-04-17 07:47 UTC == Summary:Standardize gzip(1) cli interface instead of adding it to compress(1) == -- (0006761) nrk (reporter) - 2024-04-17 07:47 https://austingroupbugs.net/view.php?id=1827#c6761 -- > Extending an existing utility with basic support for an additional input format is less demanding Both the gzip file-format and the underlying algorithm (DEFLATE) are *entirely different* to LZW. LZW builds up a dictionary on the go whereas DEFLATE is a combination of Huffman code + LZ77. Adding DEFLATE support to existing LZW implementation would be just as much work as writing a DEFLATE implementation from scratch because they share almost *nothing in common*. Most other compression algorithms (bzip2, zstandard etc) in use are in similar boat where they are all vastly different to one another. Only exceptional case where a monolithic tool would save work is for xz, lzip and 7z; all of which uses a variant of LZMA. So in cases where an implementation wants to support both algorithms, the current state of compress(1) is not "less demanding" and saves them no work. Not to mention, any implementation that wants to be useful in practice will need to ship gzip(1) anyways. So in practice, it's *more* work, not less. (This is all ignoring the glaring fact that gzip has multiple implementations and is already shipped nearly everywhere. So in practice, standardizing gzip(1) would've required *no work* - both for developers and users/script-authors). > as if POSIX mandates the exclusion of individual compression utilities, which is not true It doesn't exclude it but it doesn't standardize it either, despite being the de facto standard. And it's hostile towards developers who want to provide standalone tools. Currently if I want to provide a posix-compliant compress(1) tool, I only need to worry about LZW. Or if gzip(1) was standardized, and I wanted to provide posix-compliant gzip(1) I'd only need to worry about DEFLATE. But in the current draft, implementating a posix-compliant compress(1) requires me to both implement LZW and DEFLATE. > This is not a good place to advertise our toy programs. I'm not sure why you think pigz(1) is a toy program. It's written and maintained by Mark Adler (one of the two original authors of the gzip format), is available in repos of many distros and some distros also offer using pigz(1) as a drop-in replacement for gzip(1) (such as gentoo via app-alternatives/gzip). This is the type of customizability and control the user would lose if instead everything was crammed into a single binary. --- But in any case, putting all other arguments aside, what is unarguable is that standards that are not well adopted are next to useless. And by going for a monolithic compress(1) tool, POSIX is heading in a direction that is opposite of what the existing practice is. And in doing so, it's asking people (both system developers and users/script-authors) to put in work in order to be compliant with the spec rather than making the spec compliant with existing practices; which is not a good direction to be heading in, if wide adoption is to be desired. Issue History Date ModifiedUsername FieldChange == 2024-04-15 03:23 nrkNew Issue 2024-04-15 03:23 nrkName => NRK 2024-04-15 03:23 nrkSection => compress(1) utility 2024-04-15 03:23 nrkPage Number => n/a 2024-04-15 03:23 nrkLine Number =>
[Issue 8 drafts 0001827]: Standardize gzip(1) cli interface instead of adding it to compress(1)
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1827 == Reported By:nrk Assigned To: == Project:Issue 8 drafts Issue ID: 1827 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: NRK Organization: User Reference: Section:compress(1) utility Page Number:n/a Line Number:n/a Final Accepted Text: == Date Submitted: 2024-04-15 03:23 UTC Last Modified: 2024-04-17 01:36 UTC == Summary:Standardize gzip(1) cli interface instead of adding it to compress(1) == -- (0006759) larryv (reporter) - 2024-04-17 01:36 https://www.austingroupbugs.net/view.php?id=1827#c6759 -- Re: https://www.austingroupbugs.net/view.php?id=1827#c6754:If gzip(1) cannot be added, can the changes to compress(1) be reverted at least?Almost certainly not; draft 4.1 was submitted to the IEEE Standards Review Committee over four weeks ago. Issue History Date ModifiedUsername FieldChange == 2024-04-15 03:23 nrkNew Issue 2024-04-15 03:23 nrkName => NRK 2024-04-15 03:23 nrkSection => compress(1) utility 2024-04-15 03:23 nrkPage Number => n/a 2024-04-15 03:23 nrkLine Number => n/a 2024-04-15 03:24 nrkIssue Monitored: nrk 2024-04-16 05:57 dannyniu Note Added: 0006752 2024-04-16 05:58 dannyniu Note Edited: 0006752 2024-04-16 18:39 steffenNote Added: 0006753 2024-04-16 22:51 nrkNote Added: 0006754 2024-04-16 23:03 nrkNote Added: 0006755 2024-04-16 23:32 oguzismailuysalNote Added: 0006756 2024-04-17 00:10 steffenNote Added: 0006757 2024-04-17 00:32 nrkNote Added: 0006758 2024-04-17 01:36 larryv Note Added: 0006759 ==
[Issue 8 drafts 0001827]: Standardize gzip(1) cli interface instead of adding it to compress(1)
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1827 == Reported By:nrk Assigned To: == Project:Issue 8 drafts Issue ID: 1827 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: NRK Organization: User Reference: Section:compress(1) utility Page Number:n/a Line Number:n/a Final Accepted Text: == Date Submitted: 2024-04-15 03:23 UTC Last Modified: 2024-04-17 00:32 UTC == Summary:Standardize gzip(1) cli interface instead of adding it to compress(1) == -- (0006758) nrk (reporter) - 2024-04-17 00:32 https://www.austingroupbugs.net/view.php?id=1827#c6758 -- > Standardizing a single frontend for various compression formats makes more sense than standardizing a separate utility for each format. I fail to see how it "makes more sense", especially in the face of all the issues I've raised (none of which has been countered). But let's imagine that a single monolithic tool becomes standard. Now let's imagine that there's a script/program that needs to decompress both X and Y file. Something like: uncompress -m X ... uncompress -m Y ... Now if my system's uncompress(1) only support X but doesn't support Y this will not work. And if I try to replace my system's uncompress(1) with a separate implementation which supports Y but doesn't support Z (which may be needed elsewhere) then what's the solution to this? Continually keep symlinking uncompress(1) to whatever implementation happens to work for the moment? Having separate compression utility that deal with separate formats avoids such issues. I can have gzip(1), bzip2(1), zstd(1) etc, all installed at once. I can even use pigz(1) and symlink it to gzip(1) (which I do in my system) since it's a compatible alternative which also has multi-threaded compression. A standalone tool like pigz(1) would not be able to exist - and be easily used system wide by simply symlinking it to gzip(1) - if the convention was a single monolithic tool for all algorithm. And what happens if someone comes up with a new algorithm? Convention of a single monolithic tool forces him to either go add his algorithm to this one monolithic tool or to fork it. The current convention of different tool allows him to just release his own tool without worrying about getting it into the monolithic compress(1) implementation. Moreover, people who use that tool do not have to worry about whether their system's monolithic compress(1) supports it or not, because each tool can co-exist separately. And so I don't think a monolithic tool "makes sense", it is a direct downgrade that: * Goes against existing convention and practices. * Makes it impossible for a user to pick and choose which utility and/or specific implementation they want to use. * Makes it difficult for implementations to provide standalone tool focusing on a single format. * Makes a mess out of the cli options where different algorithms have different parameters. * Makes the manpage and documentation either a clustered mess or a small subset which doesn't offer any way to tune algorithm specific params. Issue History Date ModifiedUsername FieldChange == 2024-04-15 03:23 nrkNew Issue 2024-04-15 03:23 nrkName => NRK 2024-04-15 03:23 nrkSection => compress(1) utility 2024-04-15 03:23 nrkPage Number => n/a 2024-04-15 03:23 nrkLine Number => n/a 2024-04-15 03:24 nrkIssue Monitored: nrk 2024-04-16 05:57 dannyniu Note Added: 0006752 2024-04-16 05:58 dannyniu Note Edited: 0006752 2024-04-16 18:39 steffenNote Added: 0006753 2024-04-16 22:51 nrkNote Added: 0006754 2024-04-16 23:03 nrk
[Issue 8 drafts 0001827]: Standardize gzip(1) cli interface instead of adding it to compress(1)
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1827 == Reported By:nrk Assigned To: == Project:Issue 8 drafts Issue ID: 1827 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: NRK Organization: User Reference: Section:compress(1) utility Page Number:n/a Line Number:n/a Final Accepted Text: == Date Submitted: 2024-04-15 03:23 UTC Last Modified: 2024-04-17 00:10 UTC == Summary:Standardize gzip(1) cli interface instead of adding it to compress(1) == -- (0006757) steffen (reporter) - 2024-04-17 00:10 https://www.austingroupbugs.net/view.php?id=1827#c6757 -- Then the issue should be closed, because why standardizing yet another compression format that will see less and lesser usage because of its properties. It is *much* worse for text files, and it is *much* worse for balls as of pax(1) (and if via tar(1)). In my opinion, of course. Plain is only that compress(1) is not even installed anymore on a lot of boxes. *And* that i agree that placing new algorithms under a compress(1) interface does seem to not make any sense. And that a the xxhash64 of BTRFS or zstd (but even xxhash32) is still better than CRC-32, if you go the mathematical approach, people go away from CRC32, they do, standards do, too, and even though i know that SHA-1 and MD5 are still used for checksumming even if they are broken cryptographically. Issue History Date ModifiedUsername FieldChange == 2024-04-15 03:23 nrkNew Issue 2024-04-15 03:23 nrkName => NRK 2024-04-15 03:23 nrkSection => compress(1) utility 2024-04-15 03:23 nrkPage Number => n/a 2024-04-15 03:23 nrkLine Number => n/a 2024-04-15 03:24 nrkIssue Monitored: nrk 2024-04-16 05:57 dannyniu Note Added: 0006752 2024-04-16 05:58 dannyniu Note Edited: 0006752 2024-04-16 18:39 steffenNote Added: 0006753 2024-04-16 22:51 nrkNote Added: 0006754 2024-04-16 23:03 nrkNote Added: 0006755 2024-04-16 23:32 oguzismailuysalNote Added: 0006756 2024-04-17 00:10 steffenNote Added: 0006757 ==
[Issue 8 drafts 0001827]: Standardize gzip(1) cli interface instead of adding it to compress(1)
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1827 == Reported By:nrk Assigned To: == Project:Issue 8 drafts Issue ID: 1827 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: NRK Organization: User Reference: Section:compress(1) utility Page Number:n/a Line Number:n/a Final Accepted Text: == Date Submitted: 2024-04-15 03:23 UTC Last Modified: 2024-04-16 23:32 UTC == Summary:Standardize gzip(1) cli interface instead of adding it to compress(1) == -- (0006756) oguzismailuysal (reporter) - 2024-04-16 23:32 https://www.austingroupbugs.net/view.php?id=1827#c6756 -- Standardizing a single frontend for various compression formats makes more sense than standardizing a separate utility for each format. If anything, POSIX should encourage supporting other popular algorithms such as lzip, bzip2, and xz. Issue History Date ModifiedUsername FieldChange == 2024-04-15 03:23 nrkNew Issue 2024-04-15 03:23 nrkName => NRK 2024-04-15 03:23 nrkSection => compress(1) utility 2024-04-15 03:23 nrkPage Number => n/a 2024-04-15 03:23 nrkLine Number => n/a 2024-04-15 03:24 nrkIssue Monitored: nrk 2024-04-16 05:57 dannyniu Note Added: 0006752 2024-04-16 05:58 dannyniu Note Edited: 0006752 2024-04-16 18:39 steffenNote Added: 0006753 2024-04-16 22:51 nrkNote Added: 0006754 2024-04-16 23:03 nrkNote Added: 0006755 2024-04-16 23:32 oguzismailuysalNote Added: 0006756 ==
[Issue 8 drafts 0001827]: Standardize gzip(1) cli interface instead of adding it to compress(1)
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1827 == Reported By:nrk Assigned To: == Project:Issue 8 drafts Issue ID: 1827 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: NRK Organization: User Reference: Section:compress(1) utility Page Number:n/a Line Number:n/a Final Accepted Text: == Date Submitted: 2024-04-15 03:23 UTC Last Modified: 2024-04-16 23:03 UTC == Summary:Standardize gzip(1) cli interface instead of adding it to compress(1) == -- (0006755) nrk (reporter) - 2024-04-16 23:03 https://www.austingroupbugs.net/view.php?id=1827#c6755 -- > a new compression format should be added. zstd is nice and I do like it. But IMO this is off-topic for this issue which is more regarding compress(1) and gzip(1). > Regarding checksums [...] Blake2 Are we talking about checksum utilities or the checksum present in the compressed archive? I view both as off-topic for this issue, but if it's the latter then I'd like to point out that using a cryptographic hash as checksum in compressed archive has *no security benefits*. If an attacker can modify the compressed data stream then he can also modify the hash which is stored in the same file. Lzip's choice of CRC32 is a perfectly fine decision to detect non-malicious data corruptions. If you want to detect malicious modification then the hash needs to be stored elsewhere outside the attacker's control. Issue History Date ModifiedUsername FieldChange == 2024-04-15 03:23 nrkNew Issue 2024-04-15 03:23 nrkName => NRK 2024-04-15 03:23 nrkSection => compress(1) utility 2024-04-15 03:23 nrkPage Number => n/a 2024-04-15 03:23 nrkLine Number => n/a 2024-04-15 03:24 nrkIssue Monitored: nrk 2024-04-16 05:57 dannyniu Note Added: 0006752 2024-04-16 05:58 dannyniu Note Edited: 0006752 2024-04-16 18:39 steffenNote Added: 0006753 2024-04-16 22:51 nrkNote Added: 0006754 2024-04-16 23:03 nrkNote Added: 0006755 ==
[Issue 8 drafts 0001827]: Standardize gzip(1) cli interface instead of adding it to compress(1)
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1827 == Reported By:nrk Assigned To: == Project:Issue 8 drafts Issue ID: 1827 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: NRK Organization: User Reference: Section:compress(1) utility Page Number:n/a Line Number:n/a Final Accepted Text: == Date Submitted: 2024-04-15 03:23 UTC Last Modified: 2024-04-16 22:51 UTC == Summary:Standardize gzip(1) cli interface instead of adding it to compress(1) == -- (0006754) nrk (reporter) - 2024-04-16 22:51 https://www.austingroupbugs.net/view.php?id=1827#c6754 -- > and it's just one implementation had already implemented gzip compression in the `compress` utility in the current form AFAIK, that implementation is openbsd: https://man.openbsd.org/compress.1 But openbsd also provides gzip(1), with the familiar -0..9 cli flag for compression level: https://man.openbsd.org/gzip.1 And so IMO, deciding to add gzip support to compress(1) - which is followed by a single implementation - instead of standarizing gzip(1) which is followed by nearly all implementation is very poor and is leading to many of the concerns outlined above. > the `compress` utility can (if I didn't interpret it wrong) report "unsupported" for some combinations of the options. It may, but my point was about poor and confusing interface. A flag doing one thing in one case and something completely different in another is usually not good design. Furthermore, consider the hassle when trying to look through the manpage. Currently I can do `man gzip` and only see gzip(1) specific options or `man compress` and only see compress(1) specific options. Merging gzip and lzw into a single utility means the documentation will be cluttered with both even when I'm only looking for one. > the current draft 4 has passed a stage where we can make normative changes to, so we might have to settle with an application usage or rationale section That's unfortunate. If gzip(1) cannot be added, can the changes to compress(1) be reverted at least? > some linux distros don't ship `pax` by default, but instead `cpio` and `tar`. This is one more reason why I believe the compress(1) change should be reverted. gzip(1) is so ubiquitous that the chances that people start using compress(1) for it is HIGHLY unlikely - especially when you consider the "Hurdles for script authors" issues I raised above. As such, I would not be surprised at all if distributions continue to not ship compress(1) or if compress(1) implementations simply not add gzip support (aside from openbsd which already has it). And so a very likely outcome is a more complicated compress(1) specification which benefits no one. Issue History Date ModifiedUsername FieldChange == 2024-04-15 03:23 nrkNew Issue 2024-04-15 03:23 nrkName => NRK 2024-04-15 03:23 nrkSection => compress(1) utility 2024-04-15 03:23 nrkPage Number => n/a 2024-04-15 03:23 nrkLine Number => n/a 2024-04-15 03:24 nrkIssue Monitored: nrk 2024-04-16 05:57 dannyniu Note Added: 0006752 2024-04-16 05:58 dannyniu Note Edited: 0006752 2024-04-16 18:39 steffenNote Added: 0006753 2024-04-16 22:51 nrkNote Added: 0006754 ==
[Issue 8 drafts 0001827]: Standardize gzip(1) cli interface instead of adding it to compress(1)
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1827 == Reported By:nrk Assigned To: == Project:Issue 8 drafts Issue ID: 1827 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: NRK Organization: User Reference: Section:compress(1) utility Page Number:n/a Line Number:n/a Final Accepted Text: == Date Submitted: 2024-04-15 03:23 UTC Last Modified: 2024-04-16 18:39 UTC == Summary:Standardize gzip(1) cli interface instead of adding it to compress(1) == -- (0006753) steffen (reporter) - 2024-04-16 18:39 https://www.austingroupbugs.net/view.php?id=1827#c6753 -- To be a stinker, i do not. In my opinion, if anything, a new compression format should be added. For example zstd is RFC standardized as RFC 8878, and has the capability to either be incredible fast, or to offer a compression almost as good as xz. Decompression is always incredible fast. It uses fast XXH64 (xxHash is BSD 2-clause licensed) checksums which "survive smhasher testing". zstd is (optionally) BSD 3-clause licensed, and has gained more and more momentum over the years: you find it everywhere, and where not now today, surely at the time when the next POSIX standard appears. There is also plzip, which is the tenth of the size of zstd (static linkage easily doable), and with at least the library also being BSD 2-clause licensed. It compresses even better than zstd in best mode, or xz, but is pretty slow. It uses a CRC-32 checksum, which seems to be a fixed decision. It has a very easy programming interface (i am working on getting either memory hooking or buffer passing to him, but will likely fail). He is trying for years to get this standardized as an RFC at the IETF: nothing but silence first (iirc), but last time, not too many weeks ago, he got some responses which he was thankful for, being able to improve the documents' formalism. plzip is even elder than zstd (at least fifteen years), stable for many years, and used by noticeable packages like the IANA TZ distribution. Regarding checksums it seems the ship is sailing towards xxhash (with siphash having traction) on the one hand, and Blake2 (RFC 7693) on the other (very noticeable in the Argon2 "monster" (RFC 9106) that gets traction almost everywhere as the new password encryption scheme of choice). Blake2 is also part of OpenSSL. Issue History Date ModifiedUsername FieldChange == 2024-04-15 03:23 nrkNew Issue 2024-04-15 03:23 nrkName => NRK 2024-04-15 03:23 nrkSection => compress(1) utility 2024-04-15 03:23 nrkPage Number => n/a 2024-04-15 03:23 nrkLine Number => n/a 2024-04-15 03:24 nrkIssue Monitored: nrk 2024-04-16 05:57 dannyniu Note Added: 0006752 2024-04-16 05:58 dannyniu Note Edited: 0006752 2024-04-16 18:39 steffenNote Added: 0006753 ==
[Issue 8 drafts 0001827]: Standardize gzip(1) cli interface instead of adding it to compress(1)
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1827 == Reported By:nrk Assigned To: == Project:Issue 8 drafts Issue ID: 1827 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: NRK Organization: User Reference: Section:compress(1) utility Page Number:n/a Line Number:n/a Final Accepted Text: == Date Submitted: 2024-04-15 03:23 UTC Last Modified: 2024-04-16 05:57 UTC == Summary:Standardize gzip(1) cli interface instead of adding it to compress(1) == -- (0006752) dannyniu (reporter) - 2024-04-16 05:57 https://www.austingroupbugs.net/view.php?id=1827#c6752 -- I totally agree that `gzip` should've been standardized, however, I have a few observations on this: 1. some linux distros don't ship `pax` by default, but instead `cpio` and `tar`. 2. the current draft 4 has passed a stage where we can make normative changes to, so we might have to settle with an application usage or rationale section. 3. I once asked in a note if avoiding the `gzip` name had anything to do with potential trademark infringement, luckily when of the maintainers said it isn't, and it's just one implementation had already implemented gzip compression in the `compress` utility in the current form. 4. the `compress` utility can (if I didn't interpret it wrong) report "unsupported" for some combinations of the options. Issue History Date ModifiedUsername FieldChange == 2024-04-15 03:23 nrkNew Issue 2024-04-15 03:23 nrkName => NRK 2024-04-15 03:23 nrkSection => compress(1) utility 2024-04-15 03:23 nrkPage Number => n/a 2024-04-15 03:23 nrkLine Number => n/a 2024-04-15 03:24 nrkIssue Monitored: nrk 2024-04-16 05:57 dannyniu Note Added: 0006752 ==
[Issue 8 drafts 0001812]: Support xargs -P 0
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=1812 == Reported By:dwheeler Assigned To:ajosey == Project:Issue 8 drafts Issue ID: 1812 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Resolved Name: David A. Wheeler Organization: The Linux Foundation User Reference: Section:xargs Page Number:3600-3601 Line Number:123252 Final Accepted Text:https://austingroupbugs.net/view.php?id=1812#c6751 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2024-02-15 20:53 UTC Last Modified: 2024-04-15 16:30 UTC == Summary:Support xargs -P 0 == Relationships ID Summary -- related to 0001801 xargs: add -P option == Issue History Date ModifiedUsername FieldChange == 2024-02-15 20:53 dwheeler New Issue 2024-02-15 20:53 dwheeler Status New => Under Review 2024-02-15 20:53 dwheeler Assigned To => ajosey 2024-02-15 20:53 dwheeler Name => David A. Wheeler 2024-02-15 20:53 dwheeler Organization => The Linux Foundation 2024-02-15 20:53 dwheeler Section => xargs 2024-02-15 20:53 dwheeler Page Number => 3600-3601 2024-02-15 20:53 dwheeler Line Number => 123252 2024-02-16 10:28 geoffclare Note Added: 0006659 2024-02-16 11:39 kreNote Added: 0006661 2024-02-19 19:58 dwheeler Note Added: 0006667 2024-02-19 21:28 steffenNote Added: 0006668 2024-02-19 22:44 hvdNote Added: 0006669 2024-02-21 00:41 gabravier Note Added: 0006671 2024-03-01 11:48 geoffclare Project 1003.1(2008)/Issue 7 => Issue 8 drafts 2024-04-15 16:04 geoffclare Relationship added related to 0001801 2024-04-15 16:29 geoffclare Note Added: 0006751 2024-04-15 16:30 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1812#c6751 2024-04-15 16:30 geoffclare Status Under Review => Resolved 2024-04-15 16:30 geoffclare Resolution Open => Accepted As Marked ==
[Issue 8 drafts 0001812]: Support xargs -P 0
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1812 == Reported By:dwheeler Assigned To:ajosey == Project:Issue 8 drafts Issue ID: 1812 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: David A. Wheeler Organization: The Linux Foundation User Reference: Section:xargs Page Number:3600-3601 Line Number:123252 Final Accepted Text: == Date Submitted: 2024-02-15 20:53 UTC Last Modified: 2024-04-15 16:29 UTC == Summary:Support xargs -P 0 == Relationships ID Summary -- related to 0001801 xargs: add -P option == -- (0006751) geoffclare (manager) - 2024-04-15 16:29 https://austingroupbugs.net/view.php?id=1812#c6751 -- After making the page 3601 line 123232 change from bug 1801, change: If the value of maxprocs is non-positive, the behavior is unspecified. to: If the value of maxprocs is zero, the system heuristically attempts to minimize total runtime by executing multiple invocations of utility without waiting for previous executions to complete (e.g., by choosing the number of such invocations based on the number of available processors). If the value of maxprocs is negative, the behavior is unspecified. Issue History Date ModifiedUsername FieldChange == 2024-02-15 20:53 dwheeler New Issue 2024-02-15 20:53 dwheeler Status New => Under Review 2024-02-15 20:53 dwheeler Assigned To => ajosey 2024-02-15 20:53 dwheeler Name => David A. Wheeler 2024-02-15 20:53 dwheeler Organization => The Linux Foundation 2024-02-15 20:53 dwheeler Section => xargs 2024-02-15 20:53 dwheeler Page Number => 3600-3601 2024-02-15 20:53 dwheeler Line Number => 123252 2024-02-16 10:28 geoffclare Note Added: 0006659 2024-02-16 11:39 kreNote Added: 0006661 2024-02-19 19:58 dwheeler Note Added: 0006667 2024-02-19 21:28 steffenNote Added: 0006668 2024-02-19 22:44 hvdNote Added: 0006669 2024-02-21 00:41 gabravier Note Added: 0006671 2024-03-01 11:48 geoffclare Project 1003.1(2008)/Issue 7 => Issue 8 drafts 2024-04-15 16:04 geoffclare Relationship added related to 0001801 2024-04-15 16:29 geoffclare Note Added: 0006751 ==
[Issue 8 drafts 0001801]: xargs: add -P option
The following issue has been set as RELATED TO issue 0001812. == https://austingroupbugs.net/view.php?id=1801 == Reported By:mohd_akram Assigned To: == Project:Issue 8 drafts Issue ID: 1801 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Resolved Name: Mohamed Akram Organization: User Reference: Section:xargs Page Number:3600-3601 Line Number:123162, 123252 Final Accepted Text:See https://austingroupbugs.net/view.php?id=1801#c6699 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2024-01-25 21:39 UTC Last Modified: 2024-03-25 15:26 UTC == Summary:xargs: add -P option == Relationships ID Summary -- related to 0001811 xargs: add -P option to FUTURE DIRECTIO... related to 0001812 Support xargs -P 0 == Issue History Date ModifiedUsername FieldChange == 2024-01-25 21:39 mohd_akram New Issue 2024-01-25 21:39 mohd_akram Name => Mohamed Akram 2024-01-25 21:39 mohd_akram Section => xargs 2024-01-25 21:39 mohd_akram Page Number => 3600-3601 2024-01-25 21:39 mohd_akram Line Number => 123162, 123252 2024-02-15 16:47 geoffclare Relationship added related to 0001811 2024-02-15 16:52 Don Cragun Note Added: 0006657 2024-02-15 16:53 Don Cragun Status New => Resolved 2024-02-15 16:53 Don Cragun Resolution Open => Accepted As Marked 2024-02-15 16:55 Don Cragun Note Edited: 0006657 2024-02-15 16:55 Don Cragun Tag Attached: issue9 2024-02-15 16:59 Don Cragun Note Edited: 0006657 2024-02-15 17:01 Don Cragun Final Accepted Text => See https://austingroupbugs.net/view.php?id=1801#c6657. 2024-02-16 11:31 kreNote Added: 0006660 2024-02-21 00:20 gabravier Note Added: 0006670 2024-02-21 16:49 gabravier Note Added: 0006672 2024-02-25 06:26 kreNote Added: 0006675 2024-02-25 06:38 kreNote Added: 0006676 2024-02-26 01:11 gabravier Note Added: 0006685 2024-02-26 01:23 gabravier Note Edited: 0006685 2024-02-26 07:30 kreNote Added: 0006686 2024-02-26 10:17 geoffclare Status Resolved => Under Review 2024-02-26 10:17 geoffclare Resolution Accepted As Marked => Reopened 2024-03-01 11:40 geoffclare Note Added: 0006699 2024-03-01 11:42 geoffclare Note Edited: 0006699 2024-03-03 18:44 gabravier Note Added: 0006702 2024-03-03 18:45 gabravier Note Edited: 0006702 2024-03-03 18:46 gabravier Note Edited: 0006702 2024-03-03 18:46 gabravier Note Edited: 0006702 2024-03-03 18:46 gabravier Note Edited: 0006702 2024-03-25 15:26 geoffclare Final Accepted Text See https://austingroupbugs.net/view.php?id=1801#c6657. => See https://austingroupbugs.net/view.php?id=1801#c6699 2024-03-25 15:26 geoffclare Status Under Review => Resolved 2024-03-25 15:26 geoffclare Resolution Reopened => Accepted As Marked 2024-04-15 16:04 geoffclare Relationship added related to 0001812 ==
[Issue 8 drafts 0001812]: Support xargs -P 0
The following issue has been set as RELATED TO issue 0001801. == https://austingroupbugs.net/view.php?id=1812 == Reported By:dwheeler Assigned To:ajosey == Project:Issue 8 drafts Issue ID: 1812 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: David A. Wheeler Organization: The Linux Foundation User Reference: Section:xargs Page Number:3600-3601 Line Number:123252 Final Accepted Text: == Date Submitted: 2024-02-15 20:53 UTC Last Modified: 2024-04-15 16:04 UTC == Summary:Support xargs -P 0 == Relationships ID Summary -- related to 0001801 xargs: add -P option == Issue History Date ModifiedUsername FieldChange == 2024-02-15 20:53 dwheeler New Issue 2024-02-15 20:53 dwheeler Status New => Under Review 2024-02-15 20:53 dwheeler Assigned To => ajosey 2024-02-15 20:53 dwheeler Name => David A. Wheeler 2024-02-15 20:53 dwheeler Organization => The Linux Foundation 2024-02-15 20:53 dwheeler Section => xargs 2024-02-15 20:53 dwheeler Page Number => 3600-3601 2024-02-15 20:53 dwheeler Line Number => 123252 2024-02-16 10:28 geoffclare Note Added: 0006659 2024-02-16 11:39 kreNote Added: 0006661 2024-02-19 19:58 dwheeler Note Added: 0006667 2024-02-19 21:28 steffenNote Added: 0006668 2024-02-19 22:44 hvdNote Added: 0006669 2024-02-21 00:41 gabravier Note Added: 0006671 2024-03-01 11:48 geoffclare Project 1003.1(2008)/Issue 7 => Issue 8 drafts 2024-04-15 16:04 geoffclare Relationship added related to 0001801 ==
[Issue 8 drafts 0001810]: fdopen() can only be used once per file descriptor
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=1810 == Reported By:alanc Assigned To: == Project:Issue 8 drafts Issue ID: 1810 Category: System Interfaces Type: Clarification Requested Severity: Editorial Priority: normal Status: Resolved Name: Alan Coopersmith Organization: Oracle Solaris Engineering User Reference: Section:fdopen() Page Number:917 Line Number:31300-31397 Final Accepted Text:https://austingroupbugs.net/view.php?id=1810#c6750 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2024-02-10 17:41 UTC Last Modified: 2024-04-15 16:00 UTC == Summary:fdopen() can only be used once per file descriptor == Relationships ID Summary -- related to 0001809 close() guidance to use fclose() should... == Issue History Date ModifiedUsername FieldChange == 2024-02-10 17:41 alanc New Issue 2024-02-10 17:41 alanc Name => Alan Coopersmith 2024-02-10 17:41 alanc Organization => Oracle Solaris Engineering 2024-02-10 17:41 alanc Section => fdopen() 2024-02-10 17:41 alanc Page Number => 917 2024-02-10 17:41 alanc Line Number => 31300-31397 2024-02-10 18:57 Don Cragun Relationship added related to 0001809 2024-02-12 19:09 alanc Note Added: 0006652 2024-04-11 11:02 geoffclare Note Added: 0006744 2024-04-11 20:48 alanc Note Added: 0006749 2024-04-15 15:59 geoffclare Note Added: 0006750 2024-04-15 16:00 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1810#c6750 2024-04-15 16:00 geoffclare Status New => Resolved 2024-04-15 16:00 geoffclare Resolution Open => Accepted As Marked ==
[Issue 8 drafts 0001810]: fdopen() can only be used once per file descriptor
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1810 == Reported By:alanc Assigned To: == Project:Issue 8 drafts Issue ID: 1810 Category: System Interfaces Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Alan Coopersmith Organization: Oracle Solaris Engineering User Reference: Section:fdopen() Page Number:917 Line Number:31300-31397 Final Accepted Text: == Date Submitted: 2024-02-10 17:41 UTC Last Modified: 2024-04-15 15:59 UTC == Summary:fdopen() can only be used once per file descriptor == Relationships ID Summary -- related to 0001809 close() guidance to use fclose() should... == -- (0006750) geoffclare (manager) - 2024-04-15 15:59 https://austingroupbugs.net/view.php?id=1810#c6750 -- After page 899 line 30638, add to fclose() APPLICATION USAGE:If the file descriptor associated with the stream has already been closed, fclose() fails with an [EBADF] error (after it deallocates the stream). However, in the event that the same file descriptor number is allocated by some other operation (such as dup(), fopen(), open(), pipe(), socket(), and so forth), before fclose() is called, the fclose() call will close this newly allocated file descriptor instead. Therefore, applications which close the file descriptor before calling fclose() should ensure that they do not perform any file open operations in between closing the file descriptor and calling fclose(). This also applies in the event that two streams have the same associated file descriptor; calling fclose() on the first stream closes the file descriptor associated with both streams, and then calling fclose() on the second stream has the same risk described above. See also xref to P522, L18532 XSH 2.5.1 Interaction of File Descriptors and Standard I/O Streams. After page 918 line 31349, add to fdopen() APPLICATION USAGE:See also the APPLICATION USAGE for fclose(). Issue History Date ModifiedUsername FieldChange == 2024-02-10 17:41 alanc New Issue 2024-02-10 17:41 alanc Name => Alan Coopersmith 2024-02-10 17:41 alanc Organization => Oracle Solaris Engineering 2024-02-10 17:41 alanc Section => fdopen() 2024-02-10 17:41 alanc Page Number => 917 2024-02-10 17:41 alanc Line Number => 31300-31397 2024-02-10 18:57 Don Cragun Relationship added related to 0001809 2024-02-12 19:09 alanc Note Added: 0006652 2024-04-11 11:02 geoffclare Note Added: 0006744 2024-04-11 20:48 alanc Note Added: 0006749 2024-04-15 15:59 geoffclare Note Added: 0006750 ==
[Issue 8 drafts 0001827]: Standardize gzip(1) cli interface instead of adding it to compress(1)
The following issue has been SUBMITTED. == https://www.austingroupbugs.net/view.php?id=1827 == Reported By:nrk Assigned To: == Project:Issue 8 drafts Issue ID: 1827 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: NRK Organization: User Reference: Section:compress(1) utility Page Number:n/a Line Number:n/a Final Accepted Text: == Date Submitted: 2024-04-15 03:23 UTC Last Modified: 2024-04-15 03:23 UTC == Summary:Standardize gzip(1) cli interface instead of adding it to compress(1) Description: As a resolution to https://www.austingroupbugs.net/view.php?id=1041 the gzip/deflate algorithm was added to compress(1) tool. I believe standardizing the gzip(1) interface would've been the correct decision and adding gzip format to compress(1) will create a bunch of practical issues which I'll outline below. Hurdles for script authors -- gzip(1) is ubiquitous and is shipped with almost every distribution. Whereas compress(1) is often not installed by default on many systems. If gzip(1) is standardized, the most existing scripts that are using gzip will automatically become compliant with next POSIX edition. On the other hand adding gzip to compress(1) means such scripts will need to be edited to use compress(1) in order to avoid non-posix dependency. But doing so will result in such scripts no longer working on older systems where compress(1) is either not available or doesn't support gzip format. Standardizing gzip(1) avoids such issues entirely. Confusing cli options - Because gzip and (ancient) compress have different file format and algorithm, many cli options which are applicable to one will not be applicable to the other. The prime example of it is the `-b` flag which has been repurposed to mean different things (max bits or compression level) depending on the algorithm used. This also deviates from *majority* of the compression tool cli interface where `-[0..9]` to indicate compression level has been the de facto standard - leading to unnecessary confusion for the users. Implementation complexity - Currently one can implement the compress(1) utility or the gzip(1) utility as a stand-alone software without having to worry about the other. But if compress(1) also needs to support gzip format then the author now needs to implement both LZW and DEFLATE in order to be compliant. This increases the implementation difficultly - it's also against the unix philosophy of doing one thing. But even more worrying is the passage below: Other implementation-defined algorithms may be supported. If even more format are to be added in the future, then not only will that increase implementation difficultly further, it's also going to create more awkward cli option situation where parameters for a certain algorithm doesn't make sense on the other. Ultimately this will lead to the compress(1) cli either having lots of cli options being confusingly multiplexed or the options will be limited to the subset of parameters which makes sense on most/all algorithms - leading to a tool that does more than one thing, and does them poorly. Desired Action: 1. Revert the changes to compress(1) 2. Standardize a subset of gzip(1) with cli options that's known to be supported by most/all major implementations. == Issue History Date ModifiedUsername FieldChange == 2024-04-15 03:23 nrkNew Issue 2024-04-15 03:23 nrkName => NRK 2024-04-15 03:23 nrkSection => compress(1) utility 2024-04-15 03:23 nrkPage Number => n/a 2024-04-15 03:23 nrkLine Number => n/a ==
[Issue 8 drafts 0001810]: fdopen() can only be used once per file descriptor
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1810 == Reported By:alanc Assigned To: == Project:Issue 8 drafts Issue ID: 1810 Category: System Interfaces Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Alan Coopersmith Organization: Oracle Solaris Engineering User Reference: Section:fdopen() Page Number:917 Line Number:31300-31397 Final Accepted Text: == Date Submitted: 2024-02-10 17:41 UTC Last Modified: 2024-04-11 20:48 UTC == Summary:fdopen() can only be used once per file descriptor == Relationships ID Summary -- related to 0001809 close() guidance to use fclose() should... == -- (0006749) alanc (reporter) - 2024-04-11 20:48 https://austingroupbugs.net/view.php?id=1810#c6749 -- The engineer who originally brought this to my attention also suggested there could be an fdclose() function that closes the stdio stream but not the underlying file descriptor, which could make things safer if someone did actually have a valid use case for using the same fd for multiple streams. (Though while the fdclose() name nicely parallels fdopen() it is a bit confusing of a name for something that explicitly doesn't close the fd - perhaps something more like fddetach() would work better.) Issue History Date ModifiedUsername FieldChange == 2024-02-10 17:41 alanc New Issue 2024-02-10 17:41 alanc Name => Alan Coopersmith 2024-02-10 17:41 alanc Organization => Oracle Solaris Engineering 2024-02-10 17:41 alanc Section => fdopen() 2024-02-10 17:41 alanc Page Number => 917 2024-02-10 17:41 alanc Line Number => 31300-31397 2024-02-10 18:57 Don Cragun Relationship added related to 0001809 2024-02-12 19:09 alanc Note Added: 0006652 2024-04-11 11:02 geoffclare Note Added: 0006744 2024-04-11 20:48 alanc Note Added: 0006749 ==
[Issue 8 drafts 0001809]: close() guidance to use fclose() should also discuss fdopen()
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=1809 == Reported By:alanc Assigned To: == Project:Issue 8 drafts Issue ID: 1809 Category: System Interfaces Type: Clarification Requested Severity: Editorial Priority: normal Status: Resolved Name: Alan Coopersmith Organization: Oracle Solaris Engineering User Reference: Section:close() Page Number:747 Line Number:25797-25799 Final Accepted Text:https://austingroupbugs.net/view.php?id=1809#c6748 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2024-02-10 17:34 UTC Last Modified: 2024-04-11 16:26 UTC == Summary:close() guidance to use fclose() should also discuss fdopen() == Relationships ID Summary -- related to 0001810 fdopen() can only be used once per file... == Issue History Date ModifiedUsername FieldChange == 2024-02-10 17:34 alanc New Issue 2024-02-10 17:34 alanc Name => Alan Coopersmith 2024-02-10 17:34 alanc Organization => Oracle Solaris Engineering 2024-02-10 17:34 alanc Section => close() 2024-02-10 17:34 alanc Page Number => 747 2024-02-10 17:34 alanc Line Number => 25797-25799 2024-02-10 17:42 alanc Note Added: 0006649 2024-02-10 18:53 Don Cragun Project 1003.1(2013)/Issue7+TC1 => Issue 8 drafts 2024-02-10 18:54 Don Cragun Note Added: 0006650 2024-02-10 18:54 Don Cragun version => Draft 4 2024-02-10 18:57 Don Cragun Relationship added related to 0001810 2024-04-11 16:25 geoffclare Note Added: 0006748 2024-04-11 16:26 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1809#c6748 2024-04-11 16:26 geoffclare Status New => Resolved 2024-04-11 16:26 geoffclare Resolution Open => Accepted As Marked ==
[Issue 8 drafts 0001809]: close() guidance to use fclose() should also discuss fdopen()
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1809 == Reported By:alanc Assigned To: == Project:Issue 8 drafts Issue ID: 1809 Category: System Interfaces Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Alan Coopersmith Organization: Oracle Solaris Engineering User Reference: Section:close() Page Number:747 Line Number:25797-25799 Final Accepted Text: == Date Submitted: 2024-02-10 17:34 UTC Last Modified: 2024-04-11 16:25 UTC == Summary:close() guidance to use fclose() should also discuss fdopen() == Relationships ID Summary -- related to 0001810 fdopen() can only be used once per file... == -- (0006748) geoffclare (manager) - 2024-04-11 16:25 https://austingroupbugs.net/view.php?id=1809#c6748 -- Change: An application that had used the stdio routine fopen() to open a file should use the corresponding fclose() routine rather than close(). Once a file is closed, the file descriptor no longer exists, since the integer corresponding to it no longer refers to a file. to: If the file descriptor is associated with a standard I/O stream (for example, if the file descriptor was obtained by calling fileno() on a stream, or if an associated stream was created using fdopen()), the file descriptor should be closed using fclose() on the associated stream (or pclose() if the stream was opened using popen()) instead of calling close() or posix_close() on the file descriptor. Once a file descriptor is closed, the integer corresponding to it no longer refers to a file. However, the same integer can be allocated on a subsequent file open and would then become associated with the stream if the stream has not been closed. If the file descriptor is associated with a directory stream (for example, if the file descriptor was obtained by calling dirfd() on a directory stream, or if a directory stream was created using fdopendir()), the file descriptor should be closed using closedir() on the associated directory stream instead of calling close() or posix_close() on the file descriptor. Issue History Date ModifiedUsername FieldChange == 2024-02-10 17:34 alanc New Issue 2024-02-10 17:34 alanc Name => Alan Coopersmith 2024-02-10 17:34 alanc Organization => Oracle Solaris Engineering 2024-02-10 17:34 alanc Section => close() 2024-02-10 17:34 alanc Page Number => 747 2024-02-10 17:34 alanc Line Number => 25797-25799 2024-02-10 17:42 alanc Note Added: 0006649 2024-02-10 18:53 Don Cragun Project 1003.1(2013)/Issue7+TC1 => Issue 8 drafts 2024-02-10 18:54 Don Cragun Note Added: 0006650 2024-02-10 18:54 Don Cragun version => Draft 4 2024-02-10 18:57 Don Cragun Relationship added related to 0001810 2024-04-11 16:25 geoffclare Note Added: 0006748 ==
[1003.1(2016/18)/Issue7+TC2 0001808]: Add option -a to getconf utility
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=1808 == Reported By:cquike Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1808 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Resolved Name: Enrique Garcia Organization: User Reference: Section:getconf Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1808#c6747 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2024-02-03 01:44 UTC Last Modified: 2024-04-11 15:21 UTC == Summary:Add option -a to getconf utility == Issue History Date ModifiedUsername FieldChange == 2024-02-03 01:44 cquike New Issue 2024-02-03 01:44 cquike Name => Enrique Garcia 2024-02-03 01:44 cquike Section => getconf 2024-02-03 01:44 cquike Page Number => (page or range of pages) 2024-02-03 01:44 cquike Line Number => (Line or range of lines) 2024-02-25 05:48 kreNote Added: 0006674 2024-03-06 10:40 cquike Note Added: 0006705 2024-04-11 15:19 geoffclare Note Added: 0006747 2024-04-11 15:21 geoffclare Note Edited: 0006747 2024-04-11 15:21 geoffclare Interp Status => --- 2024-04-11 15:21 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1808#c6747 2024-04-11 15:21 geoffclare Status New => Resolved 2024-04-11 15:21 geoffclare Resolution Open => Accepted As Marked ==
[1003.1(2016/18)/Issue7+TC2 0001808]: Add option -a to getconf utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1808 == Reported By:cquike Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1808 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Enrique Garcia Organization: User Reference: Section:getconf Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2024-02-03 01:44 UTC Last Modified: 2024-04-11 15:19 UTC == Summary:Add option -a to getconf utility == -- (0006747) geoffclare (manager) - 2024-04-11 15:19 https://austingroupbugs.net/view.php?id=1808#c6747 -- After page 2831 line 93192 section getconf SYNOPSIS, add: getconf -a [-v specification] [pathname] After page 2831 line 93197 section getconf DESCRIPTION, add: If the -a option is specified, the getconf utility shall write to the standard output the names and values of all valid configuration variables; that is, every system_var operand and every path_var operand that the utility accepts, together with the values of the variables specified by those operands. For path_var operands the value written shall be the value of the variable for the path specified by the pathname operand, if present; if no pathname is provided, it is implementation-defined whether the value is for the current working directory (.) or the root directory (/). On page 2831 line 93204 section getconf OPTIONS, change: The following option shall be supported: to: The following options shall be supported: -a Write the names and values of all valid configuration variables. After page 2833 line 93307 section getconf STDOUT, add these new paragraphs: If the -a option is specified, the name of each valid configuration variable and information about the variable shall be written in the following format: "%s: %s\n",, where is the information string that would be written (without the terminating ) for the variable if specified as an operand, as described below. The remainder of this section describes the behavior if the -a option is not specified. On page 2834 line 93327 section getconf EXIT STATUS, change: The specified variable is valid and information about its current state was written successfully. to: The -a option was specified and the names of all valid configuration variables were written successfully together with information about each variable's current state, or the -a option was not specified, the specified variable is valid, and information about its current state was written successfully. On page 2834 line 9 section getconf APPLICATION USAGE, change: None. to: Since the value of a configuration variable obtained from confstr() may include characters, the output when the -a option is specified cannot be assumed to contain one name and value per line. Applications can use the presence of a at the end of the variable name as a means to distinguish names from parts of values that follow a ; however, it is possible (although unlikely) for a multi-line value to match this and it is recommended that applications needing to extract a list of valid variable names should confirm their validity by checking whether getconf accepts them as either a system_var or path_var operand. After page 2835 line 93364 section getconf RATIONALE, add a new paragraph: Historically the GNU implementation of getconf -a did not output a after each variable name, whereas other implementations did. The standard developers decided to require the in order to help applications and users distinguish variable names from parts of values that follow a . In some implementations the use of -v with -a was undocumented but supported; in others it was not supported, but it was felt to be a useful feature that would be simple to provide. Issue History Date ModifiedUsername FieldChange == 2024-02-03 01:44 cquike New Issue
[1003.1(2016/18)/Issue7+TC2 0001817]: lseek(2) - "size of a file" undefined
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1817 == Reported By:kre Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1817 Category: System Interfaces Type: Omission Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XSH 13 lseek Page Number:1292-3 Line Number:43059, 43061-2 43070-2 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-02-25 05:34 UTC Last Modified: 2024-04-11 12:53 UTC == Summary:lseek(2) - "size of a file" undefined == -- (0006746) kre (reporter) - 2024-04-11 12:53 https://austingroupbugs.net/view.php?id=1817#c6746 -- Re https://austingroupbugs.net/view.php?id=1817#c6745 That's fine, but I cannot find a definition for what the "length" of a file is either. When a definition for "size of a file" is added, a definition for "length of a file" should probably be added as well, if they are strictly identical, one can simply refer to the other. Eg: what is the size of a terminal device, or a tape, or a disc ? A FIFO? And for regular files, is the size of the file the number of bytes written, the greatest offset (+1) of any byte written, ... Is it required to be calculated in bytes, or characters, or blocks ?? As I said in the description, what we typically mean for this (at least for regular files) is obvious (I hope) - but the standard cannot (or should not) rely upon "we all know what we mean, you should too". And this still begs the question, of what is the size of a disc, which is where this question arose originally? Is it (like a file) the maximum byte offset (+1) of any byte written to it? While I think most people would agree (approximately, use of [f]truncate() can mangle things) with this for regular files, I suspect that almost no-one measures the size of a disc that way. When considering this, also keep in mind non-writable disc like devices (optical media containing non writable media for example) - is the size of such a disc the maximum capacity it can hold (which is probably what we'd expect for a regular magnetic of ssd type disc) or is it the amount that was recorded upon it (which can never be altered) ? Optical media are seekable devices, so lseek(optical_fd, SEEK_END, 0) is supposed to work, but where should it go? If some-one were to ask what is the size of the mouse I am using, would an appropriate answer be (approx) 12x6x4 (cm) ? Is the actual size of a disc file 3.5 inches? (Or perhaps 2.5 if it is a small one.) Without a definition, how can anyone say that any of those final (absurd) examples is wrong? Issue History Date ModifiedUsername FieldChange == 2024-02-25 05:34 kreNew Issue 2024-02-25 05:34 kreName => Robert Elz 2024-02-25 05:34 kreSection => XSH 13 lseek 2024-02-25 05:34 krePage Number => 1292-3 2024-02-25 05:34 kreLine Number => 43059, 43061-2 43070-2 2024-04-11 11:12 geoffclare Note Added: 0006745 2024-04-11 12:53 kreNote Added: 0006746 ==
[1003.1(2016/18)/Issue7+TC2 0001817]: lseek(2) - "size of a file" undefined
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1817 == Reported By:kre Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1817 Category: System Interfaces Type: Omission Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XSH 13 lseek Page Number:1292-3 Line Number:43059, 43061-2 43070-2 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-02-25 05:34 UTC Last Modified: 2024-04-11 11:12 UTC == Summary:lseek(2) - "size of a file" undefined == -- (0006745) geoffclare (manager) - 2024-04-11 11:12 https://austingroupbugs.net/view.php?id=1817#c6745 -- One reason why some information about file size may seem to be missing is because the synonym "length" is sometimes used instead. For example, on the write() page there is: On a regular file, if the position of the last byte written is greater than or equal to the length of the file, the length of the file shall be set to this position plus one. Issue History Date ModifiedUsername FieldChange == 2024-02-25 05:34 kreNew Issue 2024-02-25 05:34 kreName => Robert Elz 2024-02-25 05:34 kreSection => XSH 13 lseek 2024-02-25 05:34 krePage Number => 1292-3 2024-02-25 05:34 kreLine Number => 43059, 43061-2 43070-2 2024-04-11 11:12 geoffclare Note Added: 0006745 ==
[Issue 8 drafts 0001810]: fdopen() can only be used once per file descriptor
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1810 == Reported By:alanc Assigned To: == Project:Issue 8 drafts Issue ID: 1810 Category: System Interfaces Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Alan Coopersmith Organization: Oracle Solaris Engineering User Reference: Section:fdopen() Page Number:917 Line Number:31300-31397 Final Accepted Text: == Date Submitted: 2024-02-10 17:41 UTC Last Modified: 2024-04-11 11:02 UTC == Summary:fdopen() can only be used once per file descriptor == Relationships ID Summary -- related to 0001809 close() guidance to use fclose() should... == -- (0006744) geoffclare (manager) - 2024-04-11 11:02 https://austingroupbugs.net/view.php?id=1810#c6744 -- Adding some sort of warning about the fclose() issue raised in the bug description is fine. However, I think https://austingroupbugs.net/view.php?id=1810#c6652 goes too far. As long as the rules in XSH 2.5.1 "Interaction of File Descriptors and Standard I/O Streams" are followed, and the fclose() issue is taken into account, it is possible for an application to have two streams with the same underlying file descriptor and suffer no ill effects. (I can't think of a reason why an application would want to do this, but the standard should not warn against it just because its developers lack imagination.) For similar reasons, I think any warning about the fclose() issue should not advise against having two streams with the same underlying file descriptor, but rather advise about the need to take care when closing them. (In particular, the application needs to ensure that no operations that open a file descriptor are performed in between the two fclose() calls, otherwise the second could close the newly opened fd instead of getting an EBADF error.) Issue History Date ModifiedUsername FieldChange == 2024-02-10 17:41 alanc New Issue 2024-02-10 17:41 alanc Name => Alan Coopersmith 2024-02-10 17:41 alanc Organization => Oracle Solaris Engineering 2024-02-10 17:41 alanc Section => fdopen() 2024-02-10 17:41 alanc Page Number => 917 2024-02-10 17:41 alanc Line Number => 31300-31397 2024-02-10 18:57 Don Cragun Relationship added related to 0001809 2024-02-12 19:09 alanc Note Added: 0006652 2024-04-11 11:02 geoffclare Note Added: 0006744 ==
[Issue 8 drafts 0001824]: cp: directories and symlinks
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1824 == Reported By:dag-erling Assigned To: == Project:Issue 8 drafts Issue ID: 1824 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Dag-Erling Smørgrav Organization: User Reference: Section:Utilities Page Number:2741-2748 Line Number:90593-90715, 90876-90880 Final Accepted Text: == Date Submitted: 2024-04-01 15:31 UTC Last Modified: 2024-04-08 08:39 UTC == Summary:cp: directories and symlinks == -- (0006743) geoffclare (manager) - 2024-04-08 08:39 https://austingroupbugs.net/view.php?id=1824#c6743 -- > Line 90628 is within a section about -R. That doesn't imply "its context is traversal of the source". You can use -R without any traversal occurring, e.g.: cp -RL symlink_to_regfile copy_of_regfile cp -RP symlink copy_of_symlink and lines 90623-90625 (for -L) and 90626-90628 (for -P) apply to these cases. > Furthermore, lines 90714-90715, which describe -P in the options section, speak only of source_file or traversal, which we've established is about the source, not the destination. Aha! You've finally identified something I agree is a problem. This text conflicts with line 90628, as it implies (together with the pathname resolution rules) that symlinks are always followed for the destination whereas 90628 says they aren't. The description of -P in OPTIONS was missing from the final POSIX.2b draft and was added by IEEE PASC Interpretation 1003.2 #194. I suspect the working group which processed that interpretation just came up with the wording by comparison to the -H and -L descriptions and missed the significance of the DESCRIPTION text for -P saying "shall not follow any symbolic links" as regards the destination. Note that the rationale for the interpretation says "The standard is clear as the -P option is described in the description section. However, it would be better to have the option described in the Options section as well." (See https://web.archive.org/web/20050116074829/http://www.pasc.org/interps/unofficial/db/p1003.2/pasc-1003.2-194.html). So, it is clear the intention was for the new -P text in OPTIONS to match the existing DESCRIPTION text. Issue History Date ModifiedUsername FieldChange == 2024-04-01 15:31 dag-erling New Issue 2024-04-01 15:31 dag-erling Name => Dag-Erling Smørgrav 2024-04-01 15:31 dag-erling Section => Utilities 2024-04-01 15:31 dag-erling Page Number => 2741-2748 2024-04-01 15:31 dag-erling Line Number => 90593-90715, 90876-90880 2024-04-02 06:19 dannyniu Note Added: 0006731 2024-04-02 06:20 dannyniu Note Added: 0006732 2024-04-02 06:21 dannyniu Note Deleted: 0006732 2024-04-02 06:22 dannyniu Note Edited: 0006731 2024-04-02 15:51 geoffclare Note Added: 0006734 2024-04-04 14:30 geoffclare Note Added: 0006737 2024-04-04 16:01 dag-erling Note Added: 0006739 2024-04-04 16:59 geoffclare Note Added: 0006740 2024-04-04 18:19 geoffclare Note Edited: 0006740 2024-04-05 08:16 geoffclare Note Edited: 0006740 2024-04-05 11:33 dag-erling Note Added: 0006741 2024-04-08 08:39 geoffclare Note Added: 0006743 ==
[Issue 8 drafts 0001826]: du: space used between and , while common implementations use tab
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1826 == Reported By:lanodan Assigned To: == Project:Issue 8 drafts Issue ID: 1826 Category: Shell and Utilities Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Haelwenn Monnier Organization: User Reference: Section:du Page Number:2808 Line Number:93064-93067 Final Accepted Text: == Date Submitted: 2024-04-07 01:48 UTC Last Modified: 2024-04-07 02:07 UTC == Summary:du: space used between and , while common implementations use tab == -- (0006742) philip-guenther (reporter) - 2024-04-07 02:07 https://austingroupbugs.net/view.php?id=1826#c6742 -- The standard doesn't specify a space between and . It says: STDOUT The output from du shall consist of the amount of space allocated to a file and the name of the file, in the following format: "%d %s\n", , But the STDOUT section is _defined_ by XCU 1.4 where it says: The STDOUT section completely describes the standard output of the utility. This section is frequently merely a reference to the following section, OUTPUT FILES, because many utilities treat standard output and output files in the same manner. ... Record formats are described in a notation similar to that used by the C-language function, printf(). See XBD Chapter 5 (on page 121) for a description of this notation. and when you follow that last reference you find: The following characters have the following special meaning in the format string: ’ ’ (An empty character position.) Represents one or more characters. ∆ Represents exactly one character. So the du specification specifies one or more (space and tab) characters between the and Issue History Date ModifiedUsername FieldChange == 2024-04-07 01:48 lanodanNew Issue 2024-04-07 01:48 lanodanName => Haelwenn Monnier 2024-04-07 01:48 lanodanSection => du 2024-04-07 01:48 lanodanPage Number => 2808 2024-04-07 01:48 lanodanLine Number => 93064-93067 2024-04-07 02:07 philip-guentherNote Added: 0006742 ==
[Issue 8 drafts 0001826]: du: space used between and , while common implementations use tab
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1826 == Reported By:lanodan Assigned To: == Project:Issue 8 drafts Issue ID: 1826 Category: Shell and Utilities Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Haelwenn Monnier Organization: User Reference: Section:du Page Number:2808 Line Number:93064-93067 Final Accepted Text: == Date Submitted: 2024-04-07 01:48 UTC Last Modified: 2024-04-07 01:48 UTC == Summary:du: space used between and , while common implementations use tab Description: Ones where a tab is used as separator, version and permalinks as observance point: - BSD 4.1 (literal) https://github.com/dspinellis/unix-history-repo/blob/6e5f0f7526b38c1ab3620133892ecf1fe15a1d2b/usr/src/usr.bin/du/du.c#L158 - NetBSD http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/du/du.c?rev=1.36=text/x-cvsweb-markup_with_tag=MAIN - OpenBSD https://cvsweb.openbsd.org/src/usr.bin/du/du.c?rev=1.33=text/x-cvsweb-markup - FreeBSD https://cgit.freebsd.org/src/tree/usr.bin/du/du.c?id=0b8224d1cc9dc6c9778ba04a75b2c8d47e5d7481#n316 - MacOS https://github.com/apple-oss-distributions/file_cmds/blob/file_cmds-430.100.5/du/du.c#L402 - GNU coreutils 9.4, even with POSIXLY_CORRECT=1 and POSIX_ME_HARDER=1 - BusyBox 1.36.1 - ToyBox https://github.com/landley/toybox/blob/9303bd8ae667ef6385f070aa4937ff8746a2ff59/toys/posix/du.c#L75 illumos being the only one I could find where when compiled for /usr/xpg4/bin/du rather than /usr/bin/du, a space is used: https://github.com/illumos/illumos-gate/blob/1979231e1e29c981e5d1e6cee60f2db46d052b00/usr/src/cmd/du/du.c#L72-L81 A hunch I have is the literal tab degrading into a space on POSIX side of things. Desired Action: Given how widespread tab separation is: Either changing the specified format of du(1), line 93067 on Draft 4.1, from "%d %s\n" to "%d\t%s\n" or clarifying that either space or tab can be used as separator. == Issue History Date ModifiedUsername FieldChange == 2024-04-07 01:48 lanodanNew Issue 2024-04-07 01:48 lanodanName => Haelwenn Monnier 2024-04-07 01:48 lanodanSection => du 2024-04-07 01:48 lanodanPage Number => 2808 2024-04-07 01:48 lanodanLine Number => 93064-93067 ==
[Issue 8 drafts 0001824]: cp: directories and symlinks
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1824 == Reported By:dag-erling Assigned To: == Project:Issue 8 drafts Issue ID: 1824 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Dag-Erling Smørgrav Organization: User Reference: Section:Utilities Page Number:2741-2748 Line Number:90593-90715, 90876-90880 Final Accepted Text: == Date Submitted: 2024-04-01 15:31 UTC Last Modified: 2024-04-04 16:59 UTC == Summary:cp: directories and symlinks == -- (0006740) geoffclare (manager) - 2024-04-04 16:59 https://austingroupbugs.net/view.php?id=1824#c6740 -- What is there before line 90628 that makes you think its context is traversal of the source? I'm not seeing it. Quite the opposite, as line 90613 says "The term source_file refers to the file that is being copied, whether specified as an operand or a file in a file hierarchy rooted in a source_file operand." Lines 90619-90620 say "If none of the options −H, −L, nor −P were specified, it is unspecified which of −H, −L, or −P will be used as a default." It doesn't make any sense to try and think of this in terms of it applying to certain files and not to others. It is simply saying "cp -R a b" can behave the same as "cp -RH a b", "cp -RL a b", or "cp -RP a b". You assert that I claimed "the default behavior should be to follow symbolic links". That is not true. I said that the pathname resolution rules require that symbolic links are followed except when a certain set of conditions is met. For cp, one of those exception conditions is that the -P option is in effect. If a cp implementation has -P as the default when none of -H, -L or -P is specified, then that condition is met by default and symlinks will not be followed by default. Issue History Date ModifiedUsername FieldChange == 2024-04-01 15:31 dag-erling New Issue 2024-04-01 15:31 dag-erling Name => Dag-Erling Smørgrav 2024-04-01 15:31 dag-erling Section => Utilities 2024-04-01 15:31 dag-erling Page Number => 2741-2748 2024-04-01 15:31 dag-erling Line Number => 90593-90715, 90876-90880 2024-04-02 06:19 dannyniu Note Added: 0006731 2024-04-02 06:20 dannyniu Note Added: 0006732 2024-04-02 06:21 dannyniu Note Deleted: 0006732 2024-04-02 06:22 dannyniu Note Edited: 0006731 2024-04-02 15:51 geoffclare Note Added: 0006734 2024-04-04 14:30 geoffclare Note Added: 0006737 2024-04-04 16:01 dag-erling Note Added: 0006739 2024-04-04 16:59 geoffclare Note Added: 0006740 ==
[Issue 8 drafts 0001825]: Does releasing a reader lock carries a "release" memory order semantic?
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1825 == Reported By:dannyniu Assigned To: == Project:Issue 8 drafts Issue ID: 1825 Category: System Interfaces Type: Clarification Requested Severity: Comment Priority: normal Status: New Name: DannyNiu/NJF Organization: User Reference: Section:pthread_rwlock_* Page Number:1787-1804 Line Number:59262-59785 Final Accepted Text: == Date Submitted: 2024-04-02 06:44 UTC Last Modified: 2024-04-04 14:34 UTC == Summary:Does releasing a reader lock carries a "release" memory order semantic? == -- (0006738) dannyniu (reporter) - 2024-04-04 14:34 https://www.austingroupbugs.net/view.php?id=1825#c6738 -- All right then. I'm not objecting to anything here as I've ticked the comment option when I opened this bug. Thanks for the clarification Geoff! Issue History Date ModifiedUsername FieldChange == 2024-04-02 06:44 dannyniu New Issue 2024-04-02 06:44 dannyniu Name => DannyNiu/NJF 2024-04-02 06:44 dannyniu Organization => 2024-04-02 06:44 dannyniu Section => pthread_rwlock_* 2024-04-02 06:44 dannyniu Page Number => 1787-1804 2024-04-02 06:44 dannyniu Line Number => 59262-59785 2024-04-02 15:28 geoffclare Note Added: 0006733 2024-04-03 04:11 dannyniu Note Added: 0006735 2024-04-04 09:09 geoffclare Note Added: 0006736 2024-04-04 14:34 dannyniu Note Added: 0006738 ==
[Issue 8 drafts 0001824]: cp: directories and symlinks
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1824 == Reported By:dag-erling Assigned To: == Project:Issue 8 drafts Issue ID: 1824 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Dag-Erling Smørgrav Organization: User Reference: Section:Utilities Page Number:2741-2748 Line Number:90593-90715, 90876-90880 Final Accepted Text: == Date Submitted: 2024-04-01 15:31 UTC Last Modified: 2024-04-04 14:30 UTC == Summary:cp: directories and symlinks == -- (0006737) geoffclare (manager) - 2024-04-04 14:30 https://austingroupbugs.net/view.php?id=1824#c6737 -- I believe the standard is clear on all of the points raised here. Taking the bullet items after "To summarize" in turn: - The rationale implies that symbolic links are an extension, which I believe to be incorrect.Yes, as per my previous note, the final paragraph of the rationale is out of date. It should be disregarded when interpreting the normative text. - It is unclear whether symbolic links in the destination should be followed, and whether the -L and -P options apply, when inspecting destination paths.XBD 4.16 Pathname Resolution requires that symbolic links are followed except when all of the following are true: 1. This is the last pathname component of the pathname. 2. The pathname has no trailing . 3. The function is required to act on the symbolic link itself, or certain arguments direct that the function act on the symbolic link itself. (Note that "function" here is a reference back to "the function being performed"; it does not mean C language function.) So the only conditions under which cp does not follow a symlink specified as the destination are those where the cp description explicitly says cp acts on the symlink. It says so for -P on line 90628: "shall not follow any symbolic links". I believe all other mentions of acting on the symlink are not related to the destination. (Note that text referring to traversal of the file hierarchy can only be referring to source files, since no traversal is performed for destination files; existence checks are not traversals.) - There is historical precedent for answering these questions with "yes" and "no", respectively. Recent history suggests the wording is vague enough that implementers are confused on the second point.I believe the text in the standard is sufficient to answer the questions. Whether the required behaviour matches what implementations do is another matter. The recent history could be taken as an indication that (at least some) implementors are willing to make changes to conform, once they are made aware of the correct interpretation of the standard. - The description section does not adequately discuss how cp should behave if the source is a directory and the destination exists and is a symbolic link.It needs to be read in combination with XBD 4.16 Pathname Resolution, and noting that -P implies symlinks are not followed for both source and destination. - The description section does not consider the type of the destination at all in the case where the source is a file and the destination exists.Correct, and I don't see any problem with that. If the destination is a directory, the open() call in 3.a.ii will fail and cp will report an error. If -f is specified, an unlink() is attempted in 3.a.iii and will normally also fail, although it does seem to imply that if the implementation supports privileged unlinking of directories then cp will do so when run with appropriate privilege. We should perhaps consider changing the unlink() to remove(). Issue History Date ModifiedUsername FieldChange == 2024-04-01 15:31 dag-erling New Issue 2024-04-01 15:31 dag-erling Name => Dag-Erling Smørgrav 2024-04-01 15:31 dag-erling Section => Utilities 2024-04-01 15:31 dag-erling Page Number =>
[Issue 8 drafts 0001825]: Does releasing a reader lock carries a "release" memory order semantic?
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1825 == Reported By:dannyniu Assigned To: == Project:Issue 8 drafts Issue ID: 1825 Category: System Interfaces Type: Clarification Requested Severity: Comment Priority: normal Status: New Name: DannyNiu/NJF Organization: User Reference: Section:pthread_rwlock_* Page Number:1787-1804 Line Number:59262-59785 Final Accepted Text: == Date Submitted: 2024-04-02 06:44 UTC Last Modified: 2024-04-04 09:09 UTC == Summary:Does releasing a reader lock carries a "release" memory order semantic? == -- (0006736) geoffclare (manager) - 2024-04-04 09:09 https://austingroupbugs.net/view.php?id=1825#c6736 -- Those lines are from 4.15.1 which is derived from C17 and applies to the functions from C17. It's 4.15.2 that covers (carries forward from Issue 7) the memory synchronization requirements for the older POSIX synchronization primitives. Issue History Date ModifiedUsername FieldChange == 2024-04-02 06:44 dannyniu New Issue 2024-04-02 06:44 dannyniu Name => DannyNiu/NJF 2024-04-02 06:44 dannyniu Organization => 2024-04-02 06:44 dannyniu Section => pthread_rwlock_* 2024-04-02 06:44 dannyniu Page Number => 1787-1804 2024-04-02 06:44 dannyniu Line Number => 59262-59785 2024-04-02 15:28 geoffclare Note Added: 0006733 2024-04-03 04:11 dannyniu Note Added: 0006735 2024-04-04 09:09 geoffclare Note Added: 0006736 ==
[Issue 8 drafts 0001825]: Does releasing a reader lock carries a "release" memory order semantic?
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1825 == Reported By:dannyniu Assigned To: == Project:Issue 8 drafts Issue ID: 1825 Category: System Interfaces Type: Clarification Requested Severity: Comment Priority: normal Status: New Name: DannyNiu/NJF Organization: User Reference: Section:pthread_rwlock_* Page Number:1787-1804 Line Number:59262-59785 Final Accepted Text: == Date Submitted: 2024-04-02 06:44 UTC Last Modified: 2024-04-03 04:11 UTC == Summary:Does releasing a reader lock carries a "release" memory order semantic? == -- (0006735) dannyniu (reporter) - 2024-04-03 04:11 https://www.austingroupbugs.net/view.php?id=1825#c6735 -- Ah, my idiocracy. But I still find a bit of problem here. Line 3043-3045: > This standard defines a number of atomic operations (see ) > and operations on mutexes (see ) that are specially > identified as synchronization operations. These operations play a > special role in making assignments in one thread visible to another. We also have the header, as well as several other synchronization primitives. Maybe these should be added? Issue History Date ModifiedUsername FieldChange == 2024-04-02 06:44 dannyniu New Issue 2024-04-02 06:44 dannyniu Name => DannyNiu/NJF 2024-04-02 06:44 dannyniu Organization => 2024-04-02 06:44 dannyniu Section => pthread_rwlock_* 2024-04-02 06:44 dannyniu Page Number => 1787-1804 2024-04-02 06:44 dannyniu Line Number => 59262-59785 2024-04-02 15:28 geoffclare Note Added: 0006733 2024-04-03 04:11 dannyniu Note Added: 0006735 ==
[Issue 8 drafts 0001825]: Does releasing a reader lock carries a "release" memory order semantic?
The following issue has been SUBMITTED. == https://www.austingroupbugs.net/view.php?id=1825 == Reported By:dannyniu Assigned To: == Project:Issue 8 drafts Issue ID: 1825 Category: System Interfaces Type: Clarification Requested Severity: Comment Priority: normal Status: New Name: DannyNiu/NJF Organization: User Reference: Section:pthread_rwlock_* Page Number:1787-1804 Line Number:59262-59785 Final Accepted Text: == Date Submitted: 2024-04-02 06:44 UTC Last Modified: 2024-04-02 06:44 UTC == Summary:Does releasing a reader lock carries a "release" memory order semantic? Description: This arise from my activity elsewhere. For background: https://softwareengineering.stackexchange.com/q/451085/290091 Initially I thought: releasing a reader lock does not issue a release memory order semantic, since the thread holding the reader lock doesn't make modification to the content protected by the reader lock. However later I thought: releasing a reader lock is supposed to carry a release memory order semantic, since the thread may modify other areas of application memory, or issue system calls that modifies system memory. Desired Action: I'd like to confirm my thinking - whether my second thinking is correct. I hope my second thinking is correct and be added to the text of the standard, preferably into normative parts. == Issue History Date ModifiedUsername FieldChange == 2024-04-02 06:44 dannyniu New Issue 2024-04-02 06:44 dannyniu Name => DannyNiu/NJF 2024-04-02 06:44 dannyniu Organization => 2024-04-02 06:44 dannyniu Section => pthread_rwlock_* 2024-04-02 06:44 dannyniu Page Number => 1787-1804 2024-04-02 06:44 dannyniu Line Number => 59262-59785 ==
[Issue 8 drafts 0001824]: cp: directories and symlinks
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1824 == Reported By:dag-erling Assigned To: == Project:Issue 8 drafts Issue ID: 1824 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Dag-Erling Smørgrav Organization: User Reference: Section:Utilities Page Number:2741-2748 Line Number:90593-90715, 90876-90880 Final Accepted Text: == Date Submitted: 2024-04-01 15:31 UTC Last Modified: 2024-04-02 06:20 UTC == Summary:cp: directories and symlinks == -- (0006732) dannyniu (reporter) - 2024-04-02 06:20 https://www.austingroupbugs.net/view.php?id=1824#c6732 -- Here's how I understand the (new) wording of the rationale: 1. Implementations are allowed to copy directories to their own implementation-defined file types, 2. the wording is chosen such that implementations may support symbolic links (pointing to whatever that the implementation supports) as copy destinations for directories. Issue History Date ModifiedUsername FieldChange == 2024-04-01 15:31 dag-erling New Issue 2024-04-01 15:31 dag-erling Name => Dag-Erling Smørgrav 2024-04-01 15:31 dag-erling Section => Utilities 2024-04-01 15:31 dag-erling Page Number => 2741-2748 2024-04-01 15:31 dag-erling Line Number => 90593-90715, 90876-90880 2024-04-02 06:19 dannyniu Note Added: 0006731 2024-04-02 06:20 dannyniu Note Added: 0006732 ==
