Status of STREAMS error numbers in
At the ISO C++ committee meeting this week we hope to vote this change into C++23: https://cplusplus.github.io/LWG/issue3869 The current C++ standard (aka C++20) refers to ISO/IEC 9945:2003, but C++23 will use ISO/IEC/IEEE 9945:2009 + Cor 1:2013 and Cor 2:2017 as its normative POSIX reference. But at some point in the future (probably for C++26) we will update that to the new POSIX 202x that is closed to being finished now. C++ imports the contents of from POSIX, instead of just using the bare bones defined by the C standard library (which just has EDOM, EILSEQ and ERANGE). That means that C++ currently includes the ENODATA, ENOSR, ENOSTR and ETIME constants, which are obsolescent in POSIX today. My understanding is that those will not be in the next edition of POSIX. The plan is to deprecate them now in C++23 (equivalent to marking them as obsolescent) so that we can remove them in a future standard after we rebase on a newer POSIX. I would be very grateful to know if my understanding of the removal of those constants from POSIX is incorrect, or if it's likely that they'll be re-added to the draft before publication. Thanks for looking, Jonathan (ISO C++ Library Working Group chair)
[1003.1(2013)/Issue7+TC1 0001050]: Add support for the hyphen character in alias names and shell names
The following issue has been set as RELATED TO issue 0001630. == https://austingroupbugs.net/view.php?id=1050 == Reported By:steffen Assigned To: == Project:1003.1(2013)/Issue7+TC1 Issue ID: 1050 Category: Base Definitions and Headers Type: Enhancement Request Severity: Editorial Priority: normal Status: Applied Name: steffen Organization: User Reference: Section:3. Definitions Page Number:34, 70 Line Number:1168, 2015 Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1050#c5903 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2016-04-30 14:43 UTC Last Modified: 2022-08-05 09:29 UTC == Summary:Add support for the hyphen character in alias names and shell names == Relationships ID Summary -- related to 0001630 Alias names == Issue History Date ModifiedUsername FieldChange == 2016-04-30 14:43 steffenNew Issue 2016-04-30 14:43 steffenName => steffen 2016-04-30 14:43 steffenSection => 3. Definitions 2016-04-30 14:43 steffenPage Number => 34, 70 2016-04-30 14:43 steffenLine Number => 1168, 2015 2016-04-30 14:55 shware_systems Note Added: 0003189 2016-04-30 14:58 shware_systems Note Edited: 0003189 2016-04-30 15:17 shware_systems Note Edited: 0003189 2016-04-30 16:50 kreNote Added: 0003190 2016-04-30 16:51 kreNote Edited: 0003190 2016-05-02 12:53 steffenNote Added: 0003191 2016-05-02 14:58 kreNote Added: 0003192 2016-05-02 18:59 dwheeler Note Added: 0003193 2016-05-02 21:19 kreNote Added: 0003194 2016-05-26 13:52 ormaaj Note Added: 0003232 2016-08-11 23:10 Don Cragun Note Added: 0003346 2016-08-11 23:10 Don Cragun Note Edited: 0003346 2016-08-11 23:11 Don Cragun Note Edited: 0003346 2016-08-11 23:28 kreNote Added: 0003347 2016-08-11 23:39 philip-guentherNote Added: 0003348 2016-08-12 01:05 Don Cragun Note Added: 0003349 2017-04-06 12:46 steffenNote Added: 0003661 2022-07-21 16:29 geoffclare Note Added: 0005903 2022-07-21 16:29 geoffclare Interp Status => --- 2022-07-21 16:29 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1050#c5903 2022-07-21 16:29 geoffclare Status New => Resolved 2022-07-21 16:29 geoffclare Resolution Open => Accepted As Marked 2022-07-21 16:30 geoffclare Tag Attached: issue8 2022-08-05 09:29 geoffclare Status Resolved => Applied 2023-02-09 17:08 nick Relationship added related to 0001630 ==
[Online Pubs 0001630]: Alias names
The following issue has been set as RELATED TO issue 0001050. == https://austingroupbugs.net/view.php?id=1630 == Reported By:mirabilos Assigned To: == Project:Online Pubs Issue ID: 1630 Category: Base Definitions Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: URL:https://austingroupbugs.net/view.php?id=1050 Section:3.10 == Date Submitted: 2023-01-20 21:39 UTC Last Modified: 2023-02-09 17:08 UTC == Summary:Alias names == Relationships ID Summary -- related to 0001050 Add support for the hyphen character in... == Issue History Date ModifiedUsername FieldChange == 2023-01-20 21:39 mirabilos New Issue 2023-01-20 21:39 mirabilos Name => mirabilos 2023-01-20 21:39 mirabilos Organization => mksh 2023-01-20 21:39 mirabilos URL => https://austingroupbugs.net/view.php?id=1050 2023-01-20 21:39 mirabilos Section => 3.10 2023-01-20 22:30 kreNote Added: 0006122 2023-01-20 22:36 kreNote Added: 0006123 2023-01-20 22:38 kreNote Edited: 0006123 2023-02-09 17:08 nick Relationship added related to 0001050 ==
[Online Pubs 0001629]: Shell vs. read(2) errors on the script
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:Online Pubs Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: URL:unsure which applies Section:unsure which applies == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-02-09 16:59 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006145) geoffclare (manager) - 2023-02-09 16:59 https://austingroupbugs.net/view.php?id=1629#c6145 -- The following is a proposed resolution for this bug, but it is not existing practice in almost all shells (they treat a read error like end-of-file) and so we would like feedback from shell authors to indicate whether they are willing to make changes to follow these new requirements. The rationale for requesting this change in behavior is that executing the partial line after getting a read error is really not a good thing for any shell to do. Consider a shell script that contains the command:rm -f -- *.tmpIf the shell successfully reads "rm -f -- *" and then gets an error when it tries to read ".tmp", it will execute "rm -f -- *", resulting in data loss. Please send feedback by March 9, 2023. Add a row (D2.1 p2330) to the table in 2.8.1 Consequences of Shell Errors: Read error when reading commands | shall exit *4 | shall exit *4 | yes and add a new note after the table: 4. If a partial command was read before the read error occurred, that partial command shall not be executed. Add to the exit status section of the sh utility on P3155 after L107008: 1-126A read error was detected while reading commands. Change P3155, L107009-107011 in the exit status section of the sh utility from: 1-125A non-interactive shell detected an error other than command_file not found or executable, including but not limited to syntax, redirection, or variable assignment errors. to: 1-125A non-interactive shell detected an error other than command_file not found, command_file not executable, or a read error while reading commands; including but not limited to syntax, redirection, or variable assignment errors. Issue History Date ModifiedUsername FieldChange == 2023-01-15 17:30 mirabilos New Issue 2023-01-15 17:30 mirabilos Name => mirabilos 2023-01-15 17:30 mirabilos Organization => mksh 2023-01-15 17:30 mirabilos URL => unsure which applies 2023-01-15 17:30 mirabilos Section => unsure which applies 2023-01-20 21:18 chet_ramey Note Added: 0006120 2023-01-30 16:45 nick Relationship added related to 367 2023-02-02 15:51 chet_ramey Note Added: 0006142 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 ==
Re: Minutes of the 6th February 2023 Teleconference
Chet Ramey wrote, on 09 Feb 2023: > > On 2/9/23 4:19 AM, Geoff Clare via austin-group-l at The Open Group wrote: > > > When this was discussed on the call, there was general agreement that > > executing the partial line after getting a read error is really not > > a good thing for shells to be doing. > > OK, that's a reasonable position to take. But is it the role of a standards > body to require that behavior, when shells don't do it today? As I understand it, the plan is (was) to ask the shell authors who participate in this group whether they are willing to change their shells, and if the answers are positive then require the new behaviour in Issue 8, otherwise rethink. Things seemed to have happened in a different order to what was planned as a result of people reading the etherpad notes and jumping to conclusions :-) -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: Minutes of the 6th February 2023 Teleconference
On 2/9/23 4:19 AM, Geoff Clare via austin-group-l at The Open Group wrote: When this was discussed on the call, there was general agreement that executing the partial line after getting a read error is really not a good thing for shells to be doing. OK, that's a reasonable position to take. But is it the role of a standards body to require that behavior, when shells don't do it today? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Minutes of the 6th February 2023 Teleconference
Date:Thu, 9 Feb 2023 09:19:00 + From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: | there was general agreement that executing the partial line | after getting a read error is really not a good thing for | shells to be doing. I'd probably agree that it isn't the ideal approach, but that's irrelevant (or should be) here - it is not what shells do, or have ever done, so is not the standard. This group, just like anyone else, can put the case to shell implementors that the current approach is sub-optimal, and ought be altered. That would be easier on implementors if the standard makes it conforming to treat a read error as an error (resulting in aborting current processing, etc) as well as the current standard behaviour (treat it as EOF). What cannot be done is to require shells to treat read errors as shell errors rather than EOF, that would be legislating, and that is not what should be happening here. There is a clear de-facto standard here, we either write that down as the standard, or allow it or other behaviour considered better as alternatives, and possibly add a future directions for a posdible change in Issue 9 (if shells have altered their behaviour). kre
Re: [1003.1(2016/18)/Issue7+TC2 0001614]: XSH 3/mktime does not specify EINVAL and should
Robert Elz wrote, on 20 Dec 2022: > > Date:Fri, 16 Dec 2022 17:31:03 + > From:"Geoff Clare via austin-group-l at The Open Group" > > > | (Note that I was careful to say > | "system" not "implementation" - Paul Eggert's C defect report said > | that the Arthur Olsen implementation behaved differently in 1994, but > | that is not a "system".) > > Doesn't really matter, that is the implementation used, with modifications, > essentially everywhere these days - but all the systems do tend to modify > it. It is certainly what is in glibc() (modified). And all of those modifications (with the possible exception of NetBSD) included a change to stop it returning -1 for times in a DST transition gap, because that is an undesirable way for mktime() to behave. > But I agree, since we are amending the standard to fit with the existing > implementations, which all seem to comply with what the existing standard > actually requires (almost nothing) those areas where the implementations > disagree need to be left as unspecified or implementation defined. No, the NetBSD behaviour for times in a DST transition breaks application portability and should not be allowed. The C committee agrees, and has decided to update the text in C23 by changing: ... not restricted to the ranges indicated above. 389) On successful completion, the values of the tm_wday and tm_yday components of the structure are set appropriately, and the other components are set to represent the specified calendar time, but with their values forced to the ranges indicated above; the final value of tm_mday is not set until tm_mon and tm_year are determined. to: ... not restricted to the ranges indicated above. If the local time to be used for the conversion is one that includes Daylight Saving Time adjustments, a positive or zero value for tm_isdst causes the mktime function to perform the conversion as if Daylight Saving Time, respectively, is or is not in effect for the specified time. A negative value causes it to attempt to determine whether Daylight Saving Time is in effect for the specified time; if it determines that Daylight Saving Time is in effect it produces the same result as an equivalent call with a positive tm_isdst value, otherwise it produces the same result as an equivalent call with a tm_isdst value of zero. 389) On successful completion, the components of the structure are set to the same values that would be returned by a call to the localtime function with the calculated calendar time as its argument. and changing footnote 389 to read: If the broken-down time specifies a time that is either skipped over or repeated when a transition to or from Daylight Saving Time occurs, it is unspecified whether the mktime function produces the same result as an equivalent call with a positive tm_isdst value or as an equivalent call with a tm_isdst value of zero. (Previously that footnote was where the handling of tm_isdst was explained.) > | Yes, we'll need to say "it is unspecified whether ..." for the cases > | where existing implementations do the adjustment differently. > > Good, then I think we're agreed, for times in the gap, and in the fold > back period (at least when tm_isdst was -1 in the input struct tm) it > will be unspecified whether a time before the gap, or the first occurrence > of a time in the fold back, or a time after the gap, or the second, or > perhaps later occurrence of a fold back time, or in either case, an error, > is returned, as that's what the various implementations (as that word is > used in POSIX - more or less as a synonym for system) do. I said "do the adjustment differently" and I meant precisely that. Returning -1 is not an "adjustment". We should base our wording on the new text of footnote 389 above so that we match what will be in C23. > | Everywhere the mktime() description refers to a struct tm member, it > | is talking about the value that was passed in to mktime(), with the > | exception of the last paragraph where it says the values are set on > | successful completion. > > OK. > > | So the values used in the expression from XBD 4.16 (or 4.17 in D2.1) > | are the values passed in to mktime(), with the exception of tm_yday > | which is calculated from the other members. > > No, what it says is (as quoted above): > > the result > shall be as specified in the expression [...] corrected > for timezone and any seasonal time adjustments, > > The expression is corrected for timezone and seasonal time adjustments, > not the result, which you are assuming. That makes no difference. It is a mathematical expression. The correction can be made to terms within the expression or it can be made as a single addition/subtraction to the result of the expression. In actual code there could be a difference due to the
Re: Minutes of the 6th February 2023 Teleconference
Thorsten Glaser wrote, on 08 Feb 2023: > > Robert Elz via austin-group-l at The Open Group dixit: > > > | The key is that everyone `executes' the partial line after getting EOF, > > | even yash. > > > >This is important, it makes reading from files, and reading from > >strings, work the same way, which avoids the need for everyone to > >supply a terminating \n when supplying the command_string arg to sh -c > >but also for "eval" (and so traps as well) - these strings just have > >commands which end with an "end of string" (no newline at the end > >required). Treating "end of string" and "end of file" the same way > >is the natural thing to do. > > I also believe that this is important. > > However, executing the partial line after getting a read error > can and probably should be treated differently *unless* a read > error is treated as EOF. > > >Read errors being treated differently than EOF would be possible, but > >isn't what has traditionally been done - at most it should be unspecified > >whether this is treated as an error, or the same as EOF. > > Considering that all shells currently treat it as EOF, I would > very much like to have it specified either way: either matching > historical practice (then, implementations don’t have to change > anything) or requiring erroring out (then users can rely on this). > Otherwise, this can wildly differ now that the problem is out and > pressure from users can cause wild changes. When this was discussed on the call, there was general agreement that executing the partial line after getting a read error is really not a good thing for shells to be doing. Consider a shell script that contains the command: rm -f -- *.tmp If the shell successfully reads "rm -f -- *" and then gets an error when it tries to read ".tmp", it will execute "rm -f -- *", resulting in data loss. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
