C++ condition_variable and timed_mutex with steady_clock and pthreads
C++11's std::condition_variable, std::timed_mutex and std::recursive_timed_mutex support waiting with a timeout specified using an arbitrary clock. It's common to use std::chrono::steady_clock (which corresponds to CLOCK_MONOTONIC) or std::chrono::system_clock (which corresponds to CLOCK_REALTIME) for these waits, and other clocks end up being converted to one of those when performing the wait. Unfortunately, I don't believe that it's possible to implement these on top of the pthread equivalents correctly for std::chrono::steady_clock (i.e. CLOCK_MONOTONIC) since: 1. pthread_mutex_timedlock only supports a time measured against CLOCK_REALTIME. 2. The clock used for pthread_cond_timedwait must be specified when the condition variable is created by pthread_cond_init. The clock to be used for future waits is not known at the point that the std::condition_variable constructor is called. I'm most interested in the std::condition_variable case. since I have code that wants to wait using std::chrono::steady_clock. There are a number of possible workarounds for these. I've described some in a blog post[1] and in defect 0001164[2]. But, my favourite solution is to introduce a variant of pthread_cond_timedwait that takes a an additional clockid_t parameter: int pthread_cond_timedwaitonclock(pthread_cond_t *cond, pthread_mutex_t *mutex, clockid_t clockid, const struct timespec *abstimeout); I've proposed[3] an implementation of this function for glibc (as pthread_cond_timedwaitonclock_np) and it was suggested that I ought to raise it here. (This led me to enter defect 0001164, but since that yielded no response I've finally got round to writing this email too.) The equivalent for mutex would probably be: int pthread_mutex_timedlockonclock(pthread_mutex_t *mutex, clockid_t clockid, const struct timespec *abstimeout); but I've not yet made any attempt to implement it in glibc. Would making the C++ standard library implementable on top of POSIX be considered a good enough reason to add such functions? Are these functions generic enough or perhaps too generic? Android had a pthread_cond_timedwait_monotonic function for a while, but deprecated it when they added support for pthread_condattr_setclock. Thanks. Mike. [1] https://randombitsofuselessinformation.blogspot.com/2018/06/its-about-time-monotonic-time.html [2] http://austingroupbugs.net/view.php?id=1164 [3] http://libc-alpha.sourceware.narkive.com/3ZPZzEOy/rfcv4-add-pthread-cond-timedwaitonclock-np#post1
[1003.1(2016)/Issue7+TC2 0001202]: printf %.Nb with \c in arg (more than N chars into arg) behaviour unclear
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1202 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1202 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XCU 4 -- printf Page Number:3113 Line Number:104118 - 104120, 104123 - 104126 Interp Status: --- Final Accepted Text: == Date Submitted: 2018-08-29 19:26 UTC Last Modified: 2018-08-30 18:42 UTC == Summary:printf %.Nb with \c in arg (more than N chars into arg) behaviour unclear == -- (0004097) kre (reporter) - 2018-08-30 18:42 http://austingroupbugs.net/view.php?id=1202#c4097 -- Re note 409 ... We could continue with the "yes it does", "no it doesn't" debate for ages. That will accomplish nothing. First, I don't have an interpretation - that is the point. The text does not even consider the issue, which is not a surprise, as to emulate Sys V echo, which is the only reason %b exists, using a precision (or field width) makes no sense at all. I agree that if the "\c only works when consumed" was to be the intent, the text would need to be clearer to specify that. But as you need to infer a non-existing "wholly" (which would not be the correct way to fix it, but never mind) to reach the other conclusion, I think we actually agree that the text as it stands is not clear, and needs to be corrected. We can debate what the solution should be (that should happen on the list, not here in notes) but it is plainly obvious that a fix is needed. Issue History Date ModifiedUsername FieldChange == 2018-08-29 19:26 kreNew Issue 2018-08-29 19:26 kreName => Robert Elz 2018-08-29 19:26 kreSection => XCU 4 -- printf 2018-08-29 19:26 krePage Number => 3113 2018-08-29 19:26 kreLine Number => 104118 - 104120, 104123 - 104126 2018-08-30 12:46 joerg Note Added: 0004092 2018-08-30 14:43 shware_systems Note Added: 0004093 2018-08-30 16:28 kreNote Added: 0004095 2018-08-30 18:13 shware_systems Note Added: 0004096 2018-08-30 18:42 kreNote Added: 0004097 ==
[1003.1(2016)/Issue7+TC2 0001202]: printf %.Nb with \c in arg (more than N chars into arg) behaviour unclear
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1202 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1202 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XCU 4 -- printf Page Number:3113 Line Number:104118 - 104120, 104123 - 104126 Interp Status: --- Final Accepted Text: == Date Submitted: 2018-08-29 19:26 UTC Last Modified: 2018-08-30 18:13 UTC == Summary:printf %.Nb with \c in arg (more than N chars into arg) behaviour unclear == -- (0004096) shware_systems (reporter) - 2018-08-30 18:13 http://austingroupbugs.net/view.php?id=1202#c4096 -- Yes, it does say that... Your interpretation would be phrased "bytes from the argument string, as converted, shall be written as if by putc()", or similarly, to require that piecemeal effect, but it says take them from the ~wholly~ converted string, not while converting. It is an indication because the 'wholly' is implied, but I don't see the first interpretation allowed as the intent. The string has to be fully formed before you can take bytes from it, in other words, otherwise it is just a character sequence that may have invalid code points, as bad escapes or according to the charmap of the current locale. Granted, doing it piecemeal is less memory usage intensive, so an implementer might want to read it that first way, but in other parts of the standard it is explicit where this is permitted or required, using phrases like "as if by putc()". Issue History Date ModifiedUsername FieldChange == 2018-08-29 19:26 kreNew Issue 2018-08-29 19:26 kreName => Robert Elz 2018-08-29 19:26 kreSection => XCU 4 -- printf 2018-08-29 19:26 krePage Number => 3113 2018-08-29 19:26 kreLine Number => 104118 - 104120, 104123 - 104126 2018-08-30 12:46 joerg Note Added: 0004092 2018-08-30 14:43 shware_systems Note Added: 0004093 2018-08-30 16:28 kreNote Added: 0004095 2018-08-30 18:13 shware_systems Note Added: 0004096 ==
[1003.1(2016)/Issue7+TC2 0001202]: printf %.Nb with \c in arg (more than N chars into arg) behaviour unclear
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1202 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1202 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XCU 4 -- printf Page Number:3113 Line Number:104118 - 104120, 104123 - 104126 Interp Status: --- Final Accepted Text: == Date Submitted: 2018-08-29 19:26 UTC Last Modified: 2018-08-30 16:28 UTC == Summary:printf %.Nb with \c in arg (more than N chars into arg) behaviour unclear == -- (0004095) kre (reporter) - 2018-08-30 16:28 http://austingroupbugs.net/view.php?id=1202#c4095 -- Re note 4093. There is a reply on the mailing list to most of that, which is not relevant to the current issue. However this part: which indicates the entire argument shall be processed before applying the precision specifier is incorrect, it indicates nothing of the kind, though as the Description of the issue says, it is easy to read it that way. But all it means is that it is converted bytes from the operand string that are written, not that they must be converted before any of the string is processed. Issue History Date ModifiedUsername FieldChange == 2018-08-29 19:26 kreNew Issue 2018-08-29 19:26 kreName => Robert Elz 2018-08-29 19:26 kreSection => XCU 4 -- printf 2018-08-29 19:26 krePage Number => 3113 2018-08-29 19:26 kreLine Number => 104118 - 104120, 104123 - 104126 2018-08-30 12:46 joerg Note Added: 0004092 2018-08-30 14:43 shware_systems Note Added: 0004093 2018-08-30 16:28 kreNote Added: 0004095 ==
[1003.1(2016)/Issue7+TC2 0001130]: Address 0 does not make sense for the c command
The following issue has been UPDATED. == http://austingroupbugs.net/view.php?id=1130 == Reported By:Antonio Diaz Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1130 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: New Name: Antonio Diaz Organization: GNU User Reference: Section:ed Page Number:2682 Line Number:87448-87449 Interp Status: --- Final Accepted Text: == Date Submitted: 2017-03-21 17:07 UTC Last Modified: 2018-08-30 16:24 UTC == Summary:Address 0 does not make sense for the c command == Issue History Date ModifiedUsername FieldChange == 2017-03-21 17:07 Antonio Diaz New Issue 2017-03-21 17:07 Antonio Diaz Name => Antonio Diaz 2017-03-21 17:07 Antonio Diaz Organization => GNU 2017-03-21 17:07 Antonio Diaz Section => ed 2017-03-21 17:07 Antonio Diaz Page Number => 0 2017-03-21 17:07 Antonio Diaz Line Number => 0 2017-03-21 17:10 Antonio Diaz Issue Monitored: Antonio Diaz 2017-03-21 18:26 salty-horseIssue Monitored: salty-horse 2018-08-30 16:24 nick Page Number 0 => 2682 2018-08-30 16:24 nick Line Number 0 => 87448-87449 2018-08-30 16:24 nick Interp Status => --- ==
[1003.1(2016)/Issue7+TC2 0001129]: Incorrect example output of IFS=''; unset var; printf '%s\n' ${var-$*}
The following issue has been RESOLVED.
==
http://austingroupbugs.net/view.php?id=1129
==
Reported By:McDutchie
Assigned To:
==
Project:1003.1(2016)/Issue7+TC2
Issue ID: 1129
Category: Shell and Utilities
Type: Error
Severity: Objection
Priority: normal
Status: Resolved
Name: Martijn Dekker
Organization: modernish
User Reference:
Section:C.2.5
Page Number:3724
Line Number:127689-127690
Interp Status: ---
Final Accepted Text:
Resolution: Accepted
Fixed in Version:
==
Date Submitted: 2017-03-21 14:32 UTC
Last Modified: 2018-08-30 16:22 UTC
==
Summary:Incorrect example output of IFS=''; unset var;
printf '%s\n' ${var-$*}
==
Issue History
Date ModifiedUsername FieldChange
==
2017-03-21 14:32 McDutchie New Issue
2017-03-21 14:32 McDutchie Name => Martijn Dekker
2017-03-21 14:32 McDutchie Organization => modernish
2017-03-21 14:32 McDutchie Section => C.2.5
2017-03-21 14:32 McDutchie Page Number => 3724
2017-03-21 14:32 McDutchie Line Number => 127689-127690
2017-03-21 15:17 geoffclare Note Added: 0003646
2017-03-22 11:50 geoffclare Note View State: public: 3646
2018-08-30 16:21 Don Cragun Interp Status => ---
2018-08-30 16:21 Don Cragun Resolution Open => Accepted
2018-08-30 16:21 Don Cragun Tag Attached: tc3-2008
2018-08-30 16:22 Don Cragun Status New => Resolved
==
[1003.1(2016)/Issue7+TC2 0001129]: Incorrect example output of IFS=''; unset var; printf '%s\n' ${var-$*}
The following issue has been UPDATED.
==
http://austingroupbugs.net/view.php?id=1129
==
Reported By:McDutchie
Assigned To:
==
Project:1003.1(2016)/Issue7+TC2
Issue ID: 1129
Category: Shell and Utilities
Type: Error
Severity: Objection
Priority: normal
Status: New
Name: Martijn Dekker
Organization: modernish
User Reference:
Section:C.2.5
Page Number:3724
Line Number:127689-127690
Interp Status: ---
Final Accepted Text:
==
Date Submitted: 2017-03-21 14:32 UTC
Last Modified: 2018-08-30 16:21 UTC
==
Summary:Incorrect example output of IFS=''; unset var;
printf '%s\n' ${var-$*}
==
Issue History
Date ModifiedUsername FieldChange
==
2017-03-21 14:32 McDutchie New Issue
2017-03-21 14:32 McDutchie Name => Martijn Dekker
2017-03-21 14:32 McDutchie Organization => modernish
2017-03-21 14:32 McDutchie Section => C.2.5
2017-03-21 14:32 McDutchie Page Number => 3724
2017-03-21 14:32 McDutchie Line Number => 127689-127690
2017-03-21 15:17 geoffclare Note Added: 0003646
2017-03-22 11:50 geoffclare Note View State: public: 3646
2018-08-30 16:21 Don Cragun Interp Status => ---
2018-08-30 16:21 Don Cragun Resolution Open => Accepted
==
Re: [1003.1(2016)/Issue7+TC2 0001202]: printf %.Nb with \c in arg (more than N chars into arg) behaviour unclear
Date:Thu, 30 Aug 2018 14:43:09 + From:Austin Group Bug Tracker Message-ID: <95d9731eb02aae845f539112a072b...@austingroupbugs.net> | A NOTE has been added to this issue. Again, replying via e-mail, though this time I will also add a short note to the issue so it remains part of the record... | I think the controlling language here is, at Line 104121: Yes, the defect report noted that language. | which indicates the entire argument shall be processed before applying the | precision specifier, No, it doesn't. It can easly be read that way, but that is not what it says. All that "from the converted string" means is that the output bytes are converted bytes, not the orginag '\' 'n' etc, but a single '\n' Whether the bytes are converted first, or converted as needed, is not specified, and nor should it be, that is implementation detail. Even doing the conversion first (that's what the NetBSD printf does) so ... | and \c taking effect as described for the second option, which is what we do now (as do most other shells, it seems), it kind of just happens naturally, but it need not, and (while I have not coded it yet) I know how to change the code so that even with pre-processing of the string, the \c will only be effective if it (would have been, if it were data) written. What's more, I am leaning towards doing that, as I think the (effect of) the bosh implementation makes much more sense than doing it the way all the rest of us do it. | to leave open the possibility of other sequences being used as | extensions that may convert to one or more final characters subject to the | precision, Sorry, but I have absolutely no idea what the relevance of this is nor whether any of it even makes sense - I do doubt that it is in any way relevant to the question of whether \c should be effective if it is not actually "written" though. | Because of the possibility of embedded characters, this means the | conversion has to be treated as a counted string, not a nul-delimited one, | to satisfy the last sentence quoted; since it does not have an explicit 'or | a NUL character is encountered'. I agree (Joerg said much the same) - but how one makes this work is up to the implementation, specifying that is way out of scope. | As example, a platform might define a \u to expand to the current GMT with | microsecond precision, Yes, it might (NetBSD's printf has a couple of minor extensions in this area, ior example, \nnn works, as well as \0nnn to generate octal, that is a \ followed by a non-zero digit (in the range [1,7]) But what does this have to do with anything related to the issue at all? | On another platform it might output Syntax Error on the | next line, without 'a X' or 'a ' at all. Without the 'X' if there was a syntax error, but the spec requires that even on error, those bytes already generated must be output, so the 'a ' would still be there. Again, this is all immaterial to the issue. kre
[1003.1(2013)/Issue7+TC1 0001123]: Problematic specification of execution environment for word expansions
The following issue has been RESOLVED.
==
http://austingroupbugs.net/view.php?id=1123
==
Reported By:kre
Assigned To:
==
Project:1003.1(2013)/Issue7+TC1
Issue ID: 1123
Category: Shell and Utilities
Type: Clarification Requested
Severity: Objection
Priority: normal
Status: Resolved
Name: Robert Elz
Organization:
User Reference:
Section:2.6
Page Number:2353
Line Number:75006-75007
Interp Status: ---
Final Accepted Text:http://austingroupbugs.net/view.php?id=1123#c4082
Resolution: Accepted As Marked
Fixed in Version:
==
Date Submitted: 2017-03-04 07:56 UTC
Last Modified: 2018-08-30 16:14 UTC
==
Summary:Problematic specification of execution environment
for word expansions
==
Relationships ID Summary
--
related to 0001193 Brace expansion and {var}>file redir...
==
Issue History
Date ModifiedUsername FieldChange
==
2017-03-04 07:56 kreNew Issue
2017-03-04 07:56 kreName => Robert Elz
2017-03-04 07:56 kreSection => 2.6
2017-03-04 07:56 krePage Number => 2353
2017-03-04 07:56 kreLine Number => 75006-75007
2018-08-05 21:45 kreNote Added: 0004070
2018-08-05 21:46 kreNote Added: 0004071
2018-08-05 21:48 kreNote Edited: 0004070
2018-08-05 21:49 kreNote Edited: 0004070
2018-08-05 21:52 kreNote Edited: 0004070
2018-08-06 11:01 geoffclare Note Added: 0004072
2018-08-06 15:06 kreNote Added: 0004073
2018-08-06 15:29 kreNote Edited: 0004070
2018-08-10 09:11 geoffclare Note Added: 0004082
2018-08-10 09:12 geoffclare Relationship added related to 0001193
2018-08-10 11:36 geoffclare Note Edited: 0004082
2018-08-10 11:54 geoffclare Note Edited: 0004082
2018-08-24 09:14 geoffclare Note Edited: 0004082
2018-08-30 16:09 geoffclare Note Edited: 0004082
2018-08-30 16:10 geoffclare Note Edited: 0004082
2018-08-30 16:11 geoffclare Note Edited: 0004082
2018-08-30 16:14 geoffclare Interp Status => ---
2018-08-30 16:14 geoffclare Final Accepted Text =>
http://austingroupbugs.net/view.php?id=1123#c4082
2018-08-30 16:14 geoffclare Status New => Resolved
2018-08-30 16:14 geoffclare Resolution Open => Accepted As
Marked
==
Re: [1003.1(2016)/Issue7+TC2 0001202]: printf %.Nb with \c in arg (more than N chars into arg) behaviour unclear
Date:Thu, 30 Aug 2018 12:46:39 + From:Austin Group Bug Tracker Message-ID: <759af69537ce9ade10f26777c4a01...@www.austingroupbugs.net> | A NOTE has been added to this issue. I am going to reply via e-mail, rather than add more notes to the issue, as nothing here is particularly relevant to the actual resolution... | Some shells convert the %b argument to expand the escape sequences and | later let the resulting string be processed by printf(3). This does not work, Actually, it does, that's what the NetBSD printf does, and null bytes are output just fine. True, the simple no-thought approach to using printf(3) won't work, but it just makes sense to use it to do the heavy lifting. | as a side effect, the \c ending is seen while doing the conversion. Yes, I know why it works the way it works. | If you like to permit coded nul bytes to be inside the string parameter, To %b, and only encoded (as \0 or similar) of course. And as there is nothing in the spec which says those are special in any way, I think it is mandatory that they be handled. | you need to process things completely without help from printf(). No, you don't. But this is just implementation detail, and not important as long as the results are correct. | If you at the same time like to honor %.#b, I think that is mandatory too, despite ksh93's odd special case weird bug | the natural behavior is the behavior from bosh I agree that is reasonable behaviour, I think it might even be the most logical (ie: expected) behaviour, but it is not required by the spec (I'd even consider changing the NetBSD printf so that also does not process the \c unless that byte position is actually output, though I'd do it a completely different way than bosh apparently does, again, just implementation detail.) The issue, which is why I filed the defect report, is that there are theset two wildly different (in behaviour) interpretations of the spec, which contains no hint at all of this variation (neither to specify one way is the correct way, nor to make it unspecified which one will happen if a user does this (which isn't really very likely, as %b is intended to allow printf to emulate SysV echo, and it has no precision args...) That needs to be fixed. kre
[1003.1(2016)/Issue7+TC2 0001108]: LONG_MIN must be <= -2147483648
The following issue has been UPDATED. == http://austingroupbugs.net/view.php?id=1108 == Reported By:nsz Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1108 Category: Base Definitions and Headers Type: Error Severity: Editorial Priority: normal Status: Resolved Name: Szabolcs Nagy Organization: musl libc User Reference: Section:limits.h Page Number: Line Number: Interp Status: --- Final Accepted Text:http://austingroupbugs.net/view.php?id=1108#c4094 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2016-12-09 17:00 UTC Last Modified: 2018-08-30 15:49 UTC == Summary:LONG_MIN must be <= -2147483648 == Relationships ID Summary -- parent of 0001197 Omission from 1108: LONG_MIN must be &l... == Issue History Date ModifiedUsername FieldChange == 2016-12-09 17:00 nszNew Issue 2016-12-09 17:00 nszName => Szabolcs Nagy 2016-12-09 17:00 nszOrganization => musl libc 2016-12-09 17:00 nszSection => limits.h 2016-12-09 18:40 EdSchouten Note Added: 0003512 2016-12-09 22:25 nszNote Added: 0003513 2018-06-07 16:10 geoffclare Note Added: 0004041 2018-06-07 16:11 geoffclare Interp Status => --- 2018-06-07 16:11 geoffclare Final Accepted Text => http://austingroupbugs.net/view.php?id=1108#c4041 2018-06-07 16:11 geoffclare Status New => Resolved 2018-06-07 16:11 geoffclare Resolution Open => Accepted As Marked 2018-06-07 16:11 geoffclare Tag Attached: issue8 2018-07-11 21:10 cmsmithNote Added: 0004050 2018-07-12 08:13 geoffclare Note Added: 0004051 2018-07-12 11:43 shware_systems Note Added: 0004052 2018-07-30 19:02 eblake Note Added: 0004064 2018-07-30 20:29 eblake Relationship added parent of 0001197 2018-08-23 16:32 eblake Resolution Accepted As Marked => Reopened 2018-08-24 08:29 geoffclare Note Added: 0004089 2018-08-24 08:30 geoffclare Note Edited: 0004089 2018-08-24 12:54 kreNote Added: 0004090 2018-08-30 15:27 eblake Note Added: 0004094 2018-08-30 15:40 eblake Note Edited: 0004094 2018-08-30 15:42 eblake Note Edited: 0004094 2018-08-30 15:43 eblake Note Edited: 0004094 2018-08-30 15:44 eblake Note Edited: 0004094 2018-08-30 15:45 eblake Note Edited: 0004094 2018-08-30 15:49 eblake Final Accepted Text http://austingroupbugs.net/view.php?id=1108#c4041 => http://austingroupbugs.net/view.php?id=1108#c4094 2018-08-30 15:49 eblake Resolution Reopened => Accepted As Marked ==
[1003.1(2016)/Issue7+TC2 0001108]: LONG_MIN must be <= -2147483648
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1108
==
Reported By:nsz
Assigned To:
==
Project:1003.1(2016)/Issue7+TC2
Issue ID: 1108
Category: Base Definitions and Headers
Type: Error
Severity: Editorial
Priority: normal
Status: Resolved
Name: Szabolcs Nagy
Organization: musl libc
User Reference:
Section:limits.h
Page Number:
Line Number:
Interp Status: ---
Final Accepted Text:http://austingroupbugs.net/view.php?id=1108#c4041
Resolution: Reopened
Fixed in Version:
==
Date Submitted: 2016-12-09 17:00 UTC
Last Modified: 2018-08-30 15:27 UTC
==
Summary:LONG_MIN must be <= -2147483648
==
Relationships ID Summary
--
parent of 0001197 Omission from 1108: LONG_MIN must be &l...
==
--
(0004094) eblake (manager) - 2018-08-30 15:27
http://austingroupbugs.net/view.php?id=1108#c4094
--
On P280 L9437 replaceMaximum Acceptable Value: −2 147 483
647withMaximum Acceptable Value: −2 147
483 648
At Line 9443 replaceMaximum Acceptable Value: −9 223 372 036
854 775 807withMaximum Acceptable Value: −9
223 372 036 854 775 808
At L9452 replaceMaximum Acceptable Value: −2 147 483
647withMaximum Acceptable Value: −2 147 483
648
At L9467 replaceMaximum Acceptable Value: −32
767withMaximum Acceptable Value: −32
768
After P282 L9539 () add a new paragraph:The maximum
values for SCHAR_MIN, SHRT_MIN, LONG_MIN and LLONG_MIN differ from the C
Standard because POSIX.1 requires two's complement representation for the
corresponding integer types. The maximum value for INT_MIN differs both for
that reason and because POSIX.1 requires that int has a width of at
least 32 bits. See also the RATIONALE section for .
On P282 L9543 () add to the SEE ALSO section.
On P348 L11817 () change:An N-bit signed type has
values in the range -2N-1 or 1-2N-1 to
2N-1-1, while an N-bit unsigned type has values in the range 0
to 2N-1withAn N-bit signed type in
two's complement representation has values in the range -2N-1 to
2N-1-1, while an N-bit unsigned type has values in the range 0
to 2N-1.
While the C standard also permits signed integers in sign-magnitude or
one's complement form, this standard requires an implementation to use
two's complement representation for the standard integer types.
After P349 L11866 add a new paragraph with CX shading:If the
representation of any of the standard types short, int,
long or long long is not the same as one of the above
required types, an intN_t type with that
representation shall be defined along with its uintN_t
counterpart.
On P351-352 L11944-11965 () change all occurrences
of:-1)to:)and add CX
shading to the affected text in parentheses.
On P352 L11979 (), change:-65
535to:-65 536
On P354 L12040 (), replace
(The POSIX standard explicitly requires 8-bit char and
two's-complement arithmetic.)withSince the POSIX.1
standard explicitly requires 8-bit char with two's complement arithmetic,
it is easier for application writers if the same two's complement
guarantees are extended to all of the other standard integer types.
Furthermore, in programming environments with a 32-bit long, some
POSIX.1 interfaces, such as mrand48(), cannot be implemented if
long does not use a two's complement representation.
On P567 L19838 (abs), replaceIn two's-complement
representation, the absolute value of the negative integer with largest
magnitude {INT_MIN} might not be
representable.withSince POSIX.1 requires a two's
complement representation of int, the absolute value of the negative
integer with the largest magnitude {INT_MIN} is not representable, thus
abs(INT_MIN) is undefined.
On P1135 L38361 (imaxabs), replaceThe absolute value of the
most negative number cannot be represented in two's
complement.withSince POSIX.1 requires a two's
complement representation of intmax_t, the absolute value of the
negative integer with the largest magnitude {INTMAX_MIN} is not
representable, thus imaxabs(INTMAX_MIN) is undefined.
On P1232 L41195 (lab
[1003.1(2016)/Issue7+TC2 0001202]: printf %.Nb with \c in arg (more than N chars into arg) behaviour unclear
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1202 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1202 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XCU 4 -- printf Page Number:3113 Line Number:104118 - 104120, 104123 - 104126 Interp Status: --- Final Accepted Text: == Date Submitted: 2018-08-29 19:26 UTC Last Modified: 2018-08-30 14:43 UTC == Summary:printf %.Nb with \c in arg (more than N chars into arg) behaviour unclear == -- (0004093) shware_systems (reporter) - 2018-08-30 14:43 http://austingroupbugs.net/view.php?id=1202#c4093 -- I think the controlling language here is, at Line 104121: "The interpretation of a followed by any other sequence of characters is unspecified. Bytes from the converted string shall be written until the end of the string or the number of bytes indicated by the precision specification is reached. If the precision is omitted, it shall be taken to be infinite, so all bytes up to the end of the converted string shall be written." which indicates the entire argument shall be processed before applying the precision specifier, and \c taking effect as described for the second option, to leave open the possibility of other sequences being used as extensions that may convert to one or more final characters subject to the precision, or treated as a syntax error abort without outputting anything. Because of the possibility of embedded characters, this means the conversion has to be treated as a counted string, not a nul-delimited one, to satisfy the last sentence quoted; since it does not have an explicit 'or a NUL character is encountered'. As example, a platform might define a \u to expand to the current GMT with microsecond precision, which would be at least 8 characters (HH:MM:SS) replacing the \u. On another platform it might output Syntax Error on the next line, without 'a X' or 'a ' at all. Issue History Date ModifiedUsername FieldChange == 2018-08-29 19:26 kreNew Issue 2018-08-29 19:26 kreName => Robert Elz 2018-08-29 19:26 kreSection => XCU 4 -- printf 2018-08-29 19:26 krePage Number => 3113 2018-08-29 19:26 kreLine Number => 104118 - 104120, 104123 - 104126 2018-08-30 12:46 joerg Note Added: 0004092 2018-08-30 14:43 shware_systems Note Added: 0004093 ==
[1003.1(2016)/Issue7+TC2 0001202]: printf %.Nb with \c in arg (more than N chars into arg) behaviour unclear
A NOTE has been added to this issue. == http://www.austingroupbugs.net/view.php?id=1202 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1202 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XCU 4 -- printf Page Number:3113 Line Number:104118 - 104120, 104123 - 104126 Interp Status: --- Final Accepted Text: == Date Submitted: 2018-08-29 19:26 UTC Last Modified: 2018-08-30 12:46 UTC == Summary:printf %.Nb with \c in arg (more than N chars into arg) behaviour unclear == -- (0004092) joerg (reporter) - 2018-08-30 12:46 http://www.austingroupbugs.net/view.php?id=1202#c4092 -- Some shells convert the %b argument to expand the escape sequences and later let the resulting string be processed by printf(3). This does not work, since printf() cannot forward nul characters but as a side effect, the \c ending is seen while doing the conversion. If you like to permit coded nul bytes to be inside the string parameter, you need to process things completely without help from printf(). If you at the same time like to honor %.#b, the natural behavior is the behavior from bosh since the \c is not seen as string processing is aborted because of the %.# modifier. Issue History Date ModifiedUsername FieldChange == 2018-08-29 19:26 kreNew Issue 2018-08-29 19:26 kreName => Robert Elz 2018-08-29 19:26 kreSection => XCU 4 -- printf 2018-08-29 19:26 krePage Number => 3113 2018-08-29 19:26 kreLine Number => 104118 - 104120, 104123 - 104126 2018-08-30 12:46 joerg Note Added: 0004092 ==
Re: New UNIX Certification News - Oracle Corporation
Stephane Chazelas wrote, on 29 Aug 2018: > > 2018-08-28 21:33:17 +0100, Andrew Josey: > [...] > > Oracle Corporation > > > > became the first company to register the following system as conforming to > > the latest UNIX V7 Product Standard. > > > >Oracle Solaris 11.4 Operating System and later > >on SPARC-based and X86 based platforms > > > > For more information about this certification and to see the official list > > of UNIX registered products, please go to the Open Brand Register at > > http://www.opengroup.org/openbrand/register/ > > > > For more information on UNIX V7 certification, see > > http://www.unix.org/unixv7.html > [...] > > Note that the link to the "Conformance Statements database" at > https://www.opengroup.org/openbrand/register/brand3642.htm > seems to be broken. Looks like the UNIX V7 index hasn't been added yet. (Changing the XV1 to XY1 in the URL brings up the UNIX 03 index, so the rest of the URL seems okay.) > > Which edition of that standard has it been tested against? The certification runs were done with versions of the test suites that had been updated to align with SUSv4 TC2, so the answer is 2016 edition (and 2018 edition, as they're technically identical). > Which configuration? (as discussed before, only some "full" > server or workstation deployments have the SUS compliant > software (xpg4/xpg6... packages are optional). The certification doesn't specify a configuration, nor does it need to. The delivered configuration doesn't need to provide a conforming environment by default. The standard just requires that systems document how to set up a conforming environment, which Solaris 11.4 does on the standards(7) man page (which Alan gave a URL for). -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
