RE: Why does %#x omit the 0x prefix for a zero value?
Yes, but the same logic (0 being unambiguous in all radices) equally applies to 1. From: shwaresyst Sent: Monday, July 6, 2020 18:35 To: Schwarz, Konrad (CT RDA IOT SES-DE) ; austin-group-l@opengroup.org Subject: RE: Why does %#x omit the 0x prefix for a zero value? The necessity for "0x" is to disambiguate from octal numbers with their leading '0', or decimal for a context allowing leading zeroes, but since a 0 is the same in all radices I suspect the decision was not to require it to keep field width minimal for delimited formats like CSV. As to 2nd, "#.8x" forces a 10 char output for non-zero values, the "0x" followed by the 8 digits for the explicit precision; for zero values and the other format it stays at 8, as the "0x" considered part of the width, I would think. This could be more explicit, but I think matches existing practice for how many spaces get inserted to do a right justify in a field width. On Monday, July 6, 2020 Schwarz, Konrad mailto:konrad.schw...@siemens.com>> wrote: Sorry, this isn’t really a POSIX or a standards question, but does anyone know why this was defined this way? Was it just codification of “historical practice” (i.e., a non-fatal bug)? While we’re at it: when print formatting integers, are there any disadvantages of using a precision specification over a zero flag followed with a field width, i.e., “%#.8x” vs. “%#08x”?
RE: Why does %#x omit the 0x prefix for a zero value?
The necessity for "0x" is to disambiguate from octal numbers with their leading '0', or decimal for a context allowing leading zeroes, but since a 0 is the same in all radices I suspect the decision was not to require it to keep field width minimal for delimited formats like CSV. As to 2nd, "#.8x" forces a 10 char output for non-zero values, the "0x" followed by the 8 digits for the explicit precision; for zero values and the other format it stays at 8, as the "0x" considered part of the width, I would think. This could be more explicit, but I think matches existing practice for how many spaces get inserted to do a right justify in a field width. On Monday, July 6, 2020 Schwarz, Konrad wrote: Sorry, this isn’t really a POSIX or a standards question, but does anyone know why this was defined this way? Was it just codification of “historical practice” (i.e., a non-fatal bug)? While we’re at it: when print formatting integers, are there any disadvantages of using a precision specification over a zero flag followed with a field width, i.e., “%#.8x” vs. “%#08x”?
Why does %#x omit the 0x prefix for a zero value?
Sorry, this isn't really a POSIX or a standards question, but does anyone know why this was defined this way? Was it just codification of "historical practice" (i.e., a non-fatal bug)? While we're at it: when print formatting integers, are there any disadvantages of using a precision specification over a zero flag followed with a field width, i.e., "%#.8x" vs. "%#08x"?
[Issue 8 drafts 0001364]: use of noclobber with files in /tmp
The following issue has been set as RELATED TO issue 0001016. == https://austingroupbugs.net/view.php?id=1364 == Reported By:geoffclare Assigned To: == Project:Issue 8 drafts Issue ID: 1364 Category: Shell and Utilities Type: Clarification Requested Severity: Comment Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section:2.7.2 Redirecting Output Page Number:2287 Line Number:73909 Final Accepted Text: == Date Submitted: 2020-07-06 10:45 UTC Last Modified: 2020-07-06 10:46 UTC == Summary:use of noclobber with files in /tmp == Relationships ID Summary -- related to 0001016 race condition with set -C == Issue History Date ModifiedUsername FieldChange == 2020-07-06 10:45 geoffclare New Issue 2020-07-06 10:45 geoffclare Name => Geoff Clare 2020-07-06 10:45 geoffclare Organization => The Open Group 2020-07-06 10:45 geoffclare Section => 2.7.2 Redirecting Output 2020-07-06 10:45 geoffclare Page Number => 2287 2020-07-06 10:45 geoffclare Line Number => 73909 2020-07-06 10:46 geoffclare Relationship added related to 0001016 ==
[1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C
The following issue has been set as RELATED TO issue 0001364. == https://austingroupbugs.net/view.php?id=1016 == Reported By:izabera Assigned To: == Project:1003.1(2013)/Issue7+TC1 Issue ID: 1016 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Applied Name: Isabella Organization: --- User Reference: --- Section:2.7.2 Page Number: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_02 Line Number:last paragraph Interp Status: Approved Final Accepted Text:https://austingroupbugs.net/view.php?id=1016#c3493 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2015-12-28 13:52 UTC Last Modified: 2020-06-11 11:16 UTC == Summary:race condition with set -C == Relationships ID Summary -- related to 0001364 use of noclobber with files in /tmp == Issue History Date ModifiedUsername FieldChange == 2015-12-28 13:52 izaberaNew Issue 2015-12-28 13:52 izaberaName => Isabella 2015-12-28 13:52 izaberaOrganization => --- 2015-12-28 13:52 izaberaUser Reference=> --- 2015-12-28 13:52 izaberaSection => 2.7.2 2015-12-28 13:52 izaberaPage Number => http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_02 2015-12-28 13:52 izaberaLine Number => last paragraph 2015-12-31 05:58 shware_systems Note Added: 0002990 2015-12-31 12:52 jilles Note Added: 0002991 2015-12-31 14:21 shware_systems Note Added: 0002992 2015-12-31 17:05 nick Interp Status => --- 2015-12-31 17:05 nick Note Added: 0002993 2015-12-31 17:05 nick Description Updated 2016-10-20 16:40 geoffclare Note Added: 0003446 2016-10-31 16:23 geoffclare Note Added: 0003481 2016-10-31 16:28 geoffclare Note Edited: 0003481 2016-10-31 16:33 geoffclare Note Edited: 0003481 2016-11-10 17:33 rhansenNote Added: 0003485 2016-11-10 17:36 rhansenNote Edited: 0003485 2016-11-10 17:37 rhansenNote Edited: 0003485 2016-11-11 15:24 rhansenNote Edited: 0003485 2016-11-11 15:25 rhansenNote Edited: 0003485 2016-11-11 15:27 rhansenNote Edited: 0003485 2016-11-11 15:29 rhansenNote Edited: 0003485 2016-11-11 15:29 rhansenNote Edited: 0003485 2016-11-11 15:30 rhansenNote Edited: 0003485 2016-11-11 21:26 stephane Note Added: 0003486 2016-11-12 13:43 stephane Note Edited: 0003486 2016-11-14 07:01 shware_systems Note Added: 0003487 2016-11-14 09:30 geoffclare Note Added: 0003488 2016-11-14 10:10 stephane Note Added: 0003489 2016-11-14 10:28 stephane Note Added: 0003490 2016-11-14 10:47 geoffclare Note Added: 0003491 2016-11-14 15:55 shware_systems Note Added: 0003492 2016-11-14 16:17 shware_systems Note Edited: 0003492 2016-11-17 16:18 geoffclare Note Added: 0003493 2016-11-17 16:20 geoffclare Interp Status--- => Pending 2016-11-17 16:20 geoffclare Final Accepted Text =>
[Issue 8 drafts 0001363]: out of date wait() RATIONALE regarding core dump indication
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1363 == Reported By:geoffclare Assigned To: == Project:Issue 8 drafts Issue ID: 1363 Category: System Interfaces Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section:wait() Page Number:2154 Line Number:69578 Final Accepted Text: == Date Submitted: 2020-07-03 13:44 UTC Last Modified: 2020-07-03 13:44 UTC == Summary:out of date wait() RATIONALE regarding core dump indication Description: The text:Implementations that support implementation-defined actions, such as the creation of a file containing a core image, on termination of some processes traditionally provide a bit in the status returned by wait() to indicate that such actions have occurred. is out of date because the way to query this using WCOREDUMP() has now been added to the standard. Desired Action: Change:Implementations that support implementation-defined actions, such as the creation of a file containing a core image, on termination of some processes traditionally provide a bit in the status returned by wait() to indicate that such actions have occurred.to:On implementations that support the creation of a file containing a core image on some process terminations, the WCOREDUMP(stat_val) macro indicates whether creation of a core image was attempted. If it returns a non-zero value this does not necessarily mean that the core image was created, only that it was attempted. For example, if the RLIMIT_CORE limit for the process is 0, this prevents creation of the file; WCOREDUMP(stat_val) returning non-zero in this case indicates that the file would have been created if the limit had not been 0. == Issue History Date ModifiedUsername FieldChange == 2020-07-03 13:44 geoffclare New Issue 2020-07-03 13:44 geoffclare Name => Geoff Clare 2020-07-03 13:44 geoffclare Organization => The Open Group 2020-07-03 13:44 geoffclare Section => wait() 2020-07-03 13:44 geoffclare Page Number => 2154 2020-07-03 13:44 geoffclare Line Number => 69578 ==
[Issue 8 drafts 0001364]: use of noclobber with files in /tmp
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1364 == Reported By:geoffclare Assigned To: == Project:Issue 8 drafts Issue ID: 1364 Category: Shell and Utilities Type: Clarification Requested Severity: Comment Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section:2.7.2 Redirecting Output Page Number:2287 Line Number:73909 Final Accepted Text: == Date Submitted: 2020-07-06 10:45 UTC Last Modified: 2020-07-06 10:45 UTC == Summary:use of noclobber with files in /tmp Description: Some time after bug https://austingroupbugs.net/view.php?id=1016 was approved as an interpretation, https://austingroupbugs.net/view.php?id=1016#c3655 was added in which McDutchie observed that the statement "Performing these operations atomically ensures that the creation of lock files and unique (often temporary) files is reliable" is not true if the file is in a public directory such as /tmp, since another user could create a FIFO or device file with the same name. Desired Action: On page 2287 line 73900 section 2.7.2, and page 3587 line 124071 section C.2.7.2, add to the "Notes to Reviewers":If option 2 is adopted in a future draft, note that the change from will need to be reapplied to the option 2 text. where is the URL for this bug. On page 2287 line 73909 section 2.7.2, change:Performing these operations atomically ensures that the creation of lock files and unique (often temporary) files is reliable.to:Performing these operations atomically ensures that the creation of lock files and unique (often temporary) files is reliable, provided the files are created in a private directory (i.e. not in /tmp or similar). On page 3588 line 124127 section C.2.7.2, change:The standard developers consider this to be of less importance than ensuring that the creation of lock files is reliable.to:The standard developers consider this to be of less importance than ensuring that the creation of lock files is reliable (in a private directory). Creation of lock files and unique (often temporary) files with noclobber set is only reliable provided the files are created in a private directory. If a directory such as /tmp is used where other users can create files, then another user could create a FIFO (or a device file, given sufficient privilege) with the same name, causing multiple redirections with noclobber set to open the existing non-regular file instead of one succeeding and the others failing. == Issue History Date ModifiedUsername FieldChange == 2020-07-06 10:45 geoffclare New Issue 2020-07-06 10:45 geoffclare Name => Geoff Clare 2020-07-06 10:45 geoffclare Organization => The Open Group 2020-07-06 10:45 geoffclare Section => 2.7.2 Redirecting Output 2020-07-06 10:45 geoffclare Page Number => 2287 2020-07-06 10:45 geoffclare Line Number => 73909 ==
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
J William Piggott wrote, on 05 Jul 2020: > > > I disagree. The standard defines what each of the conversion > > specifiers is converted to. So the Denmark example demonstrates a > > typical result of a %a conversion, a %d conversion, ..., and a %Z > > conversion for a da_DK locale. > > "what each conversion specifiers is converted to" is implementation > defined. No, it is clearly stated in the standard that %a is converted to the locale's abbreviated weekday name, %d is converted to the day of the month as a decimal number, ..., and %Z is converted to the timezone name. What the abbreviated weekday name is for Denmark in different system's locale definitions is allowed to vary, of course, which is why I used the word "typical" above. > My statement accurately paraphrases those two disjointed requirements. > Your recent suggested addition to the standard states the same language: > | the date > | utility must by default still produce output for that locale that includes > | both the time and the date. > > That is the same as 'locale's appropriate date and time representation' No, they are both required to contain the date and the time, but there is no requirement for them to be represented the same way (and for the POSIX locale they are required not to be represented the same way). > > The standard only requires that by > > default the output includes the date and the time. Using the phrase > > "locale’s appropriate date and time representation" (which is the > > description of the %c format) introduces an unwarranted implication > > that the format used is the same as for the %c conversion. > > It implies that %c *could* be used for the default output. Yes, I have no problem with *could*. > Why are you against adding some clarity to this. I am not against adding clarity. What I am against is your suggestion that the default date utility format be changed to *require* it to be the same as %c. This would force most implementations to change the default date utility format for all of their locales, for no good reason. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
