[1003.1(2016/18)/Issue7+TC2 0001546]: BREs: reserve \? \+ and \|
The following issue has been SUBMITTED.
==
https://www.austingroupbugs.net/view.php?id=1546
==
Reported By:calestyo
Assigned To:
==
Project:1003.1(2016/18)/Issue7+TC2
Issue ID: 1546
Category: Base Definitions and Headers
Type: Enhancement Request
Severity: Editorial
Priority: normal
Status: New
Name: Christoph Anton Mitterer
Organization:
User Reference:
Section:9.3 Basic Regular Expressions
Page Number:N/A
Line Number:N/A
Interp Status: ---
Final Accepted Text:
==
Date Submitted: 2022-01-08 03:48 UTC
Last Modified: 2022-01-08 03:48 UTC
==
Summary:BREs: reserve \? \+ and \|
Description:
At least two implementations use \? \+ and \| as special characters, namely
GNU's sed and grep as well as busybox' sed and grep.
Thereby being used by countless of systems.
There \? \+ and \| act for BREs as their unquoted (? + and |) counterparts
of EREs, bringing the same functionality to BREs.
POSXI, as of now
(https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html)
says:
The interpretation of an ordinary character preceded by an unescaped
( '\\' ) is undefined, except for:
- The characters ')', '(', '{', and '}'
- The digits 1 to 9 inclusive (see BREs Matching Multiple Characters)
- A character inside a bracket expression
so a conforming implementation either didn't support \? \+ and \| at all,
or already defined it's own semantics, as e.g. GNU did.
Desired Action:
I would propose, that POSIX doesn't standardise \? \+ and \| ... but
reserve these for that purpose.
I.e. not add the functionality as used by GNU as required for conforming
implementations, but mandating that *if* an implementation chooses to use
\? \+ and \| in some way - it has to be the counterparts of ERE's ? + and |
.
The actual effect of this to the world would be small. Implementation that
don’t already support it, wouldn’t need to add support for it.
But it would prevent that any conforming implementation uses these as
special characters for other purposes.
GNU (and I guess others) support further such uses beyond POSIX, e.g.:
\b \B \< \> \w \W \s \S (GNU's sed and grep)
and:
\` \' (GNU's sed)
I personally would rather tend not to reserve those in POSIX.
POSIX isn't GNU, and the main reason why I propose the reservation of \? \+
and \| is that these are already special in EREs.
But the others from above aren't.
==
Issue History
Date ModifiedUsername FieldChange
==
2022-01-08 03:48 calestyo New Issue
2022-01-08 03:48 calestyo Name => Christoph Anton
Mitterer
2022-01-08 03:48 calestyo Section => 9.3 Basic Regular
Expressions
2022-01-08 03:48 calestyo Page Number => N/A
2022-01-08 03:48 calestyo Line Number => N/A
==
[1003.1(2016/18)/Issue7+TC2 0001545]: sed: standardise or at least reserve -E with sed for use of EREs
The following issue has been SUBMITTED. == https://www.austingroupbugs.net/view.php?id=1545 == Reported By:calestyo Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1545 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: Christoph Anton Mitterer Organization: User Reference: Section:sed utility Page Number:N/A Line Number:NA/ Interp Status: --- Final Accepted Text: == Date Submitted: 2022-01-08 03:22 UTC Last Modified: 2022-01-08 03:22 UTC == Summary:sed: standardise or at least reserve -E with sed for use of EREs Description: As of now: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html doesn’t specify a mode where EREs are used instead of BREs. For some major implementation this is however supported, a quick check revealed at lest GNU, FreeBSD, NetBSD, OpenBSD and busybox. Desired Action: I think POSIX should at least reserve sed's "-E" option (allowing implementations to support ERE's with sed im some way)... or standardise the use of EREs with sed. == Issue History Date ModifiedUsername FieldChange == 2022-01-08 03:22 calestyo New Issue 2022-01-08 03:22 calestyo Name => Christoph Anton Mitterer 2022-01-08 03:22 calestyo Section => sed utility 2022-01-08 03:22 calestyo Page Number => N/A 2022-01-08 03:22 calestyo Line Number => NA/ ==
[1003.1(2016/18)/Issue7+TC2 0001544]: uudecode: standardise or at least reserve - as another special symbol for decoding to stdout
The following issue has been SUBMITTED. == https://www.austingroupbugs.net/view.php?id=1544 == Reported By:calestyo Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1544 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Christoph Anton Mitterer Organization: User Reference: Section:uudecode Page Number:N/A Line Number:N/A Interp Status: --- Final Accepted Text: == Date Submitted: 2022-01-08 03:21 UTC Last Modified: 2022-01-08 03:21 UTC == Summary:uudecode: standardise or at least reserve - as another special symbol for decoding to stdout Description: As of now: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/uudecode.html doesn’t specify "-" as a special symbol for the -o option in order to print the decoded output to stdout, but only the special symbol '/dev/stdout' The rationale even explains: In early drafts, the [ -o outfile] option-argument allowed the use of - to mean standard output. The symbol - has only been used previously in POSIX.1-2017 as a standard input indicator. The standard developers did not wish to overload the meaning of - in this manner. The /dev/stdout concept exists on most modern systems. The /dev/stdout syntax does not refer to a new special file. It is just a magic cookie to specify standard output. Desired Action: The problem with that is that there is no strict guarantee that this file really exists or is available to the process. Imagine a chrooted process where /dev/ and /proc are not bind-mounted or take e.g. Debian's initramfs, where at least as of now, /dev/stdout doesn't exist as a file. IMO, the decision to use a file name as special symbol was rather unfortunate if not short sighted. I've seen at least one implementation which did not support '/dev/stdout' (as a special symbol until recently (busybox, and even now it depends on build configuration so it's not guaranteed to work). This can of course have the effect that output that should go to stdout, goes actually to a file /dev/stdout, if the implementation "forgot" about that speciality of POSIX, and the file doesn't exist as "special file" that also causes output to stdout. The problem is that this could of course cause leakage of sensitive data. At least GNU's uudecode and busybox' unconditionally support "-" as special symbol for -o. It may make sense to reserve "-" as well for that purpose (i.e. that conforming applications must not use it as literal filename) or even directly standardise it as such (i.e. that conforming implementations need to support it)). Of course this may break compatibility if anyone really used it in the sense of a actual filename. Alternatively a new option could be standardised, overriding -o and meaning write to stdout. I think POSIX should at least reserve == Issue History Date ModifiedUsername FieldChange == 2022-01-08 03:21 calestyo New Issue 2022-01-08 03:21 calestyo Name => Christoph Anton Mitterer 2022-01-08 03:21 calestyo Section => uudecode 2022-01-08 03:21 calestyo Page Number => N/A 2022-01-08 03:21 calestyo Line Number => N/A ==
Re: Future of locale, will there be POSIX.utf-8, what will it bring?
C11 tried to add the minimal support for UTF-8, with the u8 string constant prefix, but in a broken manner. C2x provides what can be considered a fix for this, but does it in a mostly unusable way from the aspect of supporting multiple locale languages. That is why you don't see anything about a Unicode enabled locale; the fix enables the C locale to stay unchanged. Because POSIX is adding the header 16 and 32 bit encodings will be supported, separate from wchar_t, via the char16_t and char32_t types. How UCS-2 and UCS-4, as encodings, map to the wide character set used by a platform is left as a quality of implementation issue for the interfaces in that header, so how wchar_t is encoded is considered a non-issue. What's there is adequate to say minimal support for the 3 primary encoding forms has been added, imo. While more aspects of Unicode could be considered in scope of the C standard, I think a lot has been left out so implementations, or standards like POSIX, aren't locked into having to provide things that their end users will rarely, if ever, need. On Fri, Jan 7, 2022 at 1:46 PM, Steffen Nurpmeso wrote: Hello. shwaresyst wrote in <1494661216.220561.1641574109...@mail.yahoo.com>: [i resort a bit] | On Thu, Jan 6, 2022 at 3:40 PM, Steffen Nurpmeso via austin-group-l \ | at The Open Group wrote: Hello! | |I wonder about POSIX.utf-?8, i tried to remember any statement |i had read, and Mantis did not show up results. | |In particular i am interested in whether LC_CTYPE results will |bring true Unicode support or not, the reason i am asking is that |the upcoming version of my work-box GNU LibC-based (2.34) Linux |distribution will provide it like | | localedef -i POSIX -f UTF-8 $PKG/usr/lib/locale/C.UTF-8 2> /dev/null \ ||| true | |and then this thing is detected as an UTF-8 locale, but causes |three test failures of the MUA i maintain because character set |conversion behaves differently. | |My personal opinion was that POSIX.utf8 will bring the complete |range of Unicode characters to at least LC_CTYPE, i wonder about |LC_COLLATE, as language matching is, hm, very language specific. |The rest not (maybe LC_MESSAGES going for UTF-8 though). | |Is that approximately correct? |The first Issue 8 draft is focusing, afaik, on adding the C1x changes \ |and Mantis Issue 8 tagged items. The changes to XBD 6, 7, etc., that \ |will formally add a POSIX UTF8 locale are to be part of the second, \ |maybe third, draft. This is why you don't see them yet. |For maximum compatibility with existing practice the required base \ |repertoire for this will likely be some subset of UCS-2, plus ISO-6429 \ 16-bit characters i do not see in POSIX, going that route would make impossible implementations which use specific bit patterns in wchar_t, which, if i recall correctly from 2014 or when i was looking into the issue, is used by at least the Citrus implementation of the mb* and w* series for at least some asian languages. And more .. but that was not the issue i am concerned about at the moment anyhow, i personally would assume 8-bit aka UTF-8 character strings to be predominant in Unix based systems, they surely are in the predominant ones. (Even though, i have to say, UTF-16 aka 16-bit characters do have their value for the majority of the massively declining number of human languages, and the older i get the more i think using that as a base is a good decision.) |in full, not the complete range. I've hopes this will be significantly \ |more than the minimal repertoire of C2x, but it may not as a matter \ That made me look for and download a 2020 draft of ISO C2X, i did not have a look until now. |of deferral to the C standard. It should be left up to implementations \ |still, in my opinion, how much of the range beyond this base they want \ |to support as extensions, including UTF16 as an encoding. How the LC_* \ |categories will be extended to fully support that base repertoire accord\ |ing to the Unicode requirements hasn't been determined yet either, \ |but this is the nominal goal. And from a glance i do not see anything Unicode-enabled-locale wise. UTF-16 specifically i do not see ... as you will have to convert on input and on output in order to use it in your program, and then you can very well convert to the transparent wchar_t, or use the wide I/O series which gives it to you. Minimizing the tremendous deficiency that many traditional Unix programs have to face because the historic string interfaces do not provide proper functionality to deal with human languages is out of scope is it? At least it seems as if ISO C2X introduces support for UTF-8 as a native string representation ... in practice it seems Unix people use GNU libunicode (which explicitly supports UTF-(32|16|8) i think) as well as ICU (which i think used UTF-16 internally but offered improved UTF-8 interface performance by then), so the ISO standard people were able to
Re: Future of locale, will there be POSIX.utf-8, what will it bring?
Hello. shwaresyst wrote in <1494661216.220561.1641574109...@mail.yahoo.com>: [i resort a bit] | On Thu, Jan 6, 2022 at 3:40 PM, Steffen Nurpmeso via austin-group-l \ | at The Open Group wrote: Hello! | |I wonder about POSIX.utf-?8, i tried to remember any statement |i had read, and Mantis did not show up results. | |In particular i am interested in whether LC_CTYPE results will |bring true Unicode support or not, the reason i am asking is that |the upcoming version of my work-box GNU LibC-based (2.34) Linux |distribution will provide it like | | localedef -i POSIX -f UTF-8 $PKG/usr/lib/locale/C.UTF-8 2> /dev/null \ ||| true | |and then this thing is detected as an UTF-8 locale, but causes |three test failures of the MUA i maintain because character set |conversion behaves differently. | |My personal opinion was that POSIX.utf8 will bring the complete |range of Unicode characters to at least LC_CTYPE, i wonder about |LC_COLLATE, as language matching is, hm, very language specific. |The rest not (maybe LC_MESSAGES going for UTF-8 though). | |Is that approximately correct? |The first Issue 8 draft is focusing, afaik, on adding the C1x changes \ |and Mantis Issue 8 tagged items. The changes to XBD 6, 7, etc., that \ |will formally add a POSIX UTF8 locale are to be part of the second, \ |maybe third, draft. This is why you don't see them yet. |For maximum compatibility with existing practice the required base \ |repertoire for this will likely be some subset of UCS-2, plus ISO-6429 \ 16-bit characters i do not see in POSIX, going that route would make impossible implementations which use specific bit patterns in wchar_t, which, if i recall correctly from 2014 or when i was looking into the issue, is used by at least the Citrus implementation of the mb* and w* series for at least some asian languages. And more .. but that was not the issue i am concerned about at the moment anyhow, i personally would assume 8-bit aka UTF-8 character strings to be predominant in Unix based systems, they surely are in the predominant ones. (Even though, i have to say, UTF-16 aka 16-bit characters do have their value for the majority of the massively declining number of human languages, and the older i get the more i think using that as a base is a good decision.) |in full, not the complete range. I've hopes this will be significantly \ |more than the minimal repertoire of C2x, but it may not as a matter \ That made me look for and download a 2020 draft of ISO C2X, i did not have a look until now. |of deferral to the C standard. It should be left up to implementations \ |still, in my opinion, how much of the range beyond this base they want \ |to support as extensions, including UTF16 as an encoding. How the LC_* \ |categories will be extended to fully support that base repertoire accord\ |ing to the Unicode requirements hasn't been determined yet either, \ |but this is the nominal goal. And from a glance i do not see anything Unicode-enabled-locale wise. UTF-16 specifically i do not see ... as you will have to convert on input and on output in order to use it in your program, and then you can very well convert to the transparent wchar_t, or use the wide I/O series which gives it to you. Minimizing the tremendous deficiency that many traditional Unix programs have to face because the historic string interfaces do not provide proper functionality to deal with human languages is out of scope is it? At least it seems as if ISO C2X introduces support for UTF-8 as a native string representation ... in practice it seems Unix people use GNU libunicode (which explicitly supports UTF-(32|16|8) i think) as well as ICU (which i think used UTF-16 internally but offered improved UTF-8 interface performance by then), so the ISO standard people were able to simply ignore their responsibility and focused on mysterious s..t decisions, and POSIX has to follow ISO C suit for one, and then simply had not the ressources to define an entire Unicode string interface by themselve ... and so practice has created its own Genesis. Thank you. And ciao from Germany, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Future of locale, will there be POSIX.utf-8, what will it bring?
The first Issue 8 draft is focusing, afaik, on adding the C1x changes and Mantis Issue 8 tagged items. The changes to XBD 6, 7, etc., that will formally add a POSIX UTF8 locale are to be part of the second, maybe third, draft. This is why you don't see them yet. For maximum compatibility with existing practice the required base repertoire for this will likely be some subset of UCS-2, plus ISO-6429 in full, not the complete range. I've hopes this will be significantly more than the minimal repertoire of C2x, but it may not as a matter of deferral to the C standard. It should be left up to implementations still, in my opinion, how much of the range beyond this base they want to support as extensions, including UTF16 as an encoding. How the LC_* categories will be extended to fully support that base repertoire according to the Unicode requirements hasn't been determined yet either, but this is the nominal goal. On Thu, Jan 6, 2022 at 3:40 PM, Steffen Nurpmeso via austin-group-l at The Open Group wrote: Hello! I wonder about POSIX.utf-?8, i tried to remember any statement i had read, and Mantis did not show up results. In particular i am interested in whether LC_CTYPE results will bring true Unicode support or not, the reason i am asking is that the upcoming version of my work-box GNU LibC-based (2.34) Linux distribution will provide it like localedef -i POSIX -f UTF-8 $PKG/usr/lib/locale/C.UTF-8 2> /dev/null || true and then this thing is detected as an UTF-8 locale, but causes three test failures of the MUA i maintain because character set conversion behaves differently. My personal opinion was that POSIX.utf8 will bring the complete range of Unicode characters to at least LC_CTYPE, i wonder about LC_COLLATE, as language matching is, hm, very language specific. The rest not (maybe LC_MESSAGES going for UTF-8 though). Is that approximately correct? Thanks and Ciao! from Germany, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Minutes of the 6th January 2022 Teleconference
All
Enclosed are the minutes of yesterday’s teleconference
regards
Andrew
--
Minutes of the 6th January 2022 Teleconference Austin-1188 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 7th January 2022
Attendees:
Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR
Don Cragun, IEEE PASC OR
Mark Ziegast, SHware Systems Dev.
Andrew Josey, The Open Group
Eric Ackermann, HPI, University of Potsdam
Eric Blake, Red Hat, The Open Group OR
Tom Thompson, IEEE
Rob Landley
Geoff Clare, The Open Group
* General news
This was the first call of 2022.
This was a call dedicated to general bugs.
Andrew noted he had fixed an issue with the download bundles which
for some formats had been empty.
* Outstanding actions
None
* Current Business
Bug 1521: here document processing is underspecified Dup of 1036
https://austingroupbugs.net/view.php?id=1521
Bug 1036: Errors/Omissions in specification of here document redirection
Accepted as Marked
https://austingroupbugs.net/view.php?id=1036
This item is tagged for TC3-2008
This resolves this bug and the related bugs 0001043 and 0001521.
On 2018 edition page 2347 line 74748 section 2.3, change:
When an io_here token has been recognized by the grammar (see
[xref to 2.10]), one or more of the subsequent lines immediately
following the next NEWLINE token form the body of one or more
here-documents and shall be parsed according to the rules of
[xref to 2.7.4].
to:
When an io_here token has been recognized by the grammar (see
[xref to 2.10]), one or more of the subsequent lines immediately
following the next NEWLINE token form the body of a here-document
and shall be parsed according to the rules of [xref to 2.7.4].
Any non-NEWLINE tokens (including more io_here tokens) that are
recognized while searching for the next NEWLINE token shall be
saved for processing after the here-document has been parsed.
If a saved token is an io_here token, the corresponding
here-document shall start on the line immediately following the
line containing the trailing delimiter of the previous
here-document. If any saved token includes a character,
the behavior is unspecified.
On 2018 edition page 2348 line 74774 section 2.3, after:
While processing the characters, if instances of expansions or
quoting are found nested within the substitution, the shell
shall recursively process them in the manner specified for the
construct that is found.
append:
For "$(" and '`' only, if instances of io_here tokens are found
nested within the substitution, they shall be parsed according
to the rules of [xref to 2.7.4]; if the terminating ')' or '`'
of the substitution occurs before the NEWLINE token marking the
start of the here-document, the behavior is unspecified.
On 2018 edition page 2362 line 75355 section 2.7.4, change:
The here-document shall be treated as a single word that begins
after the next and continues until there is a line
containing only the delimiter and a , with no
characters in between. Then the next here-document starts, if
there is one.
to:
The here-document shall be treated as a single word that begins
after the next NEWLINE token and continues until there is a
line containing only the delimiter and a , with no
characters in between. Then the next here-document
starts, if there is one. For the purposes of locating this
terminating line, the end of a command_string operand (see [xref
to sh]) shall be treated as a character, and the end
of the commands string in $(commands) and `commands`
may be treated as a . If the end of input is reached
without finding the terminating line, the shell should, but
need not, treat this as a redirection error.
On 2018 edition page 2362 line 75363 section 2.7.4, change:
It is unspecified whether the file descriptor is opened as a
regular file, a special file, or a pipe.
to:
It is unspecified whether the file descriptor is opened as a
regular file or some other type of file.
On 2018 edition page 2362 line 75366 section 2.7.4, change:
If any part of word is quoted, the delimiter shall be formed
by performing quote removal on word, and the here-document lines
shall not be expanded. Otherwise, the delimiter shall be the
word itself.
If no part of word is quoted, all lines of the here-document
shall be expanded for parameter expansion, command substitution,
and arithmetic expansion. In this case, the in the
input behaves ...
to:
If any part of word is quoted, not counting double-quotes outside
a command substitution if the here-document is inside one, the
delimiter shall be formed by performing quote removal on word,
and the here-document lines shall not be expanded. Otherwise:
The delimiter shall be the word itself.
The
[1003.1(2016/18)/Issue7+TC2 0001302]: Alignment with C17
The following issue has been set as RELATED TO issue 0001524. == https://austingroupbugs.net/view.php?id=1302 == Reported By:geoffclare Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1302 Category: Base Definitions and Headers Type: Enhancement Request Severity: Objection Priority: normal Status: Resolved Name: Geoff Clare Organization: The Open Group User Reference: Section:(many) Page Number:(many) Line Number:(many) Interp Status: --- Final Accepted Text:See the attached document C17_alignment_20211019.pdf Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2019-11-19 15:27 UTC Last Modified: 2021-10-21 15:25 UTC == Summary:Alignment with C17 == Relationships ID Summary -- related to 411 adding atomic FD_CLOEXEC support related to 711 Are the stdarg.h macros async-signal-safe? related to 0001163 fscanf omits carriage in the list of wh... related to 0001428 Add definitions of negative... related to 609 It is not clear what threads are consid... related to 0001526 Update fdopen() mode description to mat... related to 0001524 open() flags used by fopen() == Issue History Date ModifiedUsername FieldChange == 2019-11-19 15:27 geoffclare New Issue 2019-11-19 15:27 geoffclare File Added: C17_alignment_20191119.pdf 2019-11-19 15:27 geoffclare Name => Geoff Clare 2019-11-19 15:27 geoffclare Organization => The Open Group 2019-11-19 15:27 geoffclare Section => (many) 2019-11-19 15:27 geoffclare Page Number => (many) 2019-11-19 15:27 geoffclare Line Number => (many) 2019-11-19 15:27 geoffclare Interp Status => --- 2019-11-19 17:04 shware_systems Note Added: 0004663 2019-11-20 09:16 geoffclare Note Added: 0004664 2019-11-20 10:49 denniswNote Added: 0004665 2019-11-20 14:07 geoffclare Note Added: 0004666 2019-11-20 15:41 geoffclare Relationship added related to 411 2019-11-20 15:42 geoffclare Relationship added related to 711 2019-11-20 15:42 geoffclare Relationship added related to 0001163 2020-11-02 11:49 geoffclare File Added: C17_alignment_20201102.pdf 2020-11-02 11:50 geoffclare File Added: C17_alignment_20201102_diffs.pdf 2020-11-02 11:57 geoffclare Note Added: 0005093 2020-11-02 12:01 geoffclare Note Edited: 0005093 2020-11-08 23:42 nick Note Added: 0005108 2020-11-27 14:57 geoffclare Relationship added related to 0001428 2020-12-21 02:36 jscott0Issue Monitored: jscott0 2021-08-13 10:03 geoffclare Note Added: 0005442 2021-08-13 11:10 geoffclare File Added: C17_alignment_20210813.pdf 2021-08-13 11:11 geoffclare File Added: C17_alignment_20210813_diffs.pdf 2021-08-13 11:12 geoffclare Note Added: 0005443 2021-10-15 08:32 geoffclare Relationship added related to 609 2021-10-19 08:55 geoffclare File Added: C17_alignment_20211019.pdf 2021-10-19 08:55 geoffclare File Added: C17_alignment_20211019_diffs.pdf 2021-10-19 09:00 geoffclare Note Added: 0005506 2021-10-19 09:01 geoffclare Note Edited: 0005506 2021-10-19 10:58 geoffclare Relationship added related to 0001526 2021-10-21 15:24 Don Cragun Final Accepted Text => See the attached document
[Issue 8 drafts 0001524]: open() flags used by fopen()
The following issue has been set as RELATED TO issue 0001302. == https://austingroupbugs.net/view.php?id=1524 == Reported By:Don Cragun Assigned To: == Project:Issue 8 drafts Issue ID: 1524 Category: System Interfaces Type: Omission Severity: Objection Priority: normal Status: New Name: Don Cragun Organization: User Reference: Section:fopen() Page Number:881, 882 Line Number:29973-29974, 30005-30013 Final Accepted Text: == Date Submitted: 2021-10-10 18:49 UTC Last Modified: 2022-01-07 10:07 UTC == Summary:open() flags used by fopen() == Relationships ID Summary -- related to 0001302 Alignment with C17 == Issue History Date ModifiedUsername FieldChange == 2021-10-10 18:49 Don Cragun New Issue 2021-10-10 18:49 Don Cragun Name => Don Cragun 2021-10-10 18:49 Don Cragun Section => fopen() 2021-10-10 18:49 Don Cragun Page Number => 881, 882 2021-10-10 18:49 Don Cragun Line Number => 29973-29974, 30005-30013 2021-10-10 18:53 Don Cragun Desired Action Updated 2021-10-10 23:45 kreNote Added: 0005501 2021-10-10 23:51 kreNote Added: 0005502 2021-10-11 03:45 Don Cragun Note Added: 0005503 2021-10-11 09:12 geoffclare Note Added: 0005504 2022-01-07 06:22 Don Cragun Note Added: 0005581 2022-01-07 10:06 geoffclare Note Added: 0005582 2022-01-07 10:07 geoffclare Relationship added related to 0001302 ==
[Issue 8 drafts 0001524]: open() flags used by fopen()
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1524 == Reported By:Don Cragun Assigned To: == Project:Issue 8 drafts Issue ID: 1524 Category: System Interfaces Type: Omission Severity: Objection Priority: normal Status: New Name: Don Cragun Organization: User Reference: Section:fopen() Page Number:881, 882 Line Number:29973-29974, 30005-30013 Final Accepted Text: == Date Submitted: 2021-10-10 18:49 UTC Last Modified: 2022-01-07 10:06 UTC == Summary:open() flags used by fopen() == -- (0005582) geoffclare (manager) - 2022-01-07 10:06 https://austingroupbugs.net/view.php?id=1524#c5582 -- Bug https://austingroupbugs.net/view.php?id=1302 has been resolved since this bug was submitted, so the proposed changes that overlap with 1302 need to be specified in the form "after applying bug 1302 change ..." The first requested change is not needed as it is being made by 1302. Likewise the similar change for 'x' is included in 1302. So the only changes needed are to the table and surrounding text. I suggest: On P882 L30005, after applying bug 1302 change:The file descriptor associated with the opened stream shall be allocated and opened as if by a call to open() using the following flags, with the addition of the O_CLOEXEC flag if mode includes 'e', and the O_EXCL flag if mode includes 'x' and either 'w' or 'a':to:The file descriptor associated with the opened stream shall be allocated and opened as if by a call to open() using the following flags: On P882 L30007, after applying bug 1302 change the third column of the table header from:open() Flagsto:Initial open() Flags After the table on P882 L30007-30013, add the following new paragraphs (all CX shaded):If, and only if, the 'e' mode string character is specified, the O_CLOEXEC flag shall be OR'ed into the initial open() flags specified in the above table. If, and only if, the 'x' mode string character is specified together with either 'w' or 'a', the O_EXCL flag shall be OR'ed into the initial open() flags specified in the above table. When using mode strings specified by this standard, the implementation shall behave as if no other flags had been passed to open(). Issue History Date ModifiedUsername FieldChange == 2021-10-10 18:49 Don Cragun New Issue 2021-10-10 18:49 Don Cragun Name => Don Cragun 2021-10-10 18:49 Don Cragun Section => fopen() 2021-10-10 18:49 Don Cragun Page Number => 881, 882 2021-10-10 18:49 Don Cragun Line Number => 29973-29974, 30005-30013 2021-10-10 18:53 Don Cragun Desired Action Updated 2021-10-10 23:45 kreNote Added: 0005501 2021-10-10 23:51 kreNote Added: 0005502 2021-10-11 03:45 Don Cragun Note Added: 0005503 2021-10-11 09:12 geoffclare Note Added: 0005504 2022-01-07 06:22 Don Cragun Note Added: 0005581 2022-01-07 10:06 geoffclare Note Added: 0005582 ==
