Austin Group teleconference +1 888 974 9888 PIN 618 156 403
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1// CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:20120311T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:20121104T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:627dec5a87...@opengroup.org DTSTAMP:20220513T052754Z ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org CREATED:20220513T00Z DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel econference +1 888 974 9888 PIN 618 156 403\nDate/Time: 19-May-2022 at 11: 00 America/New_York\nDuration: 1.50 hours\nURL: https://collaboration.open group.org/platform/single_unix_specification/events.php\n\n* All calls are anchored on US time *\n\nTopic: Austin Group teleconference\n ---\nAudio conference information \n---\n\nYou are invit ed to a Zoom meeting.\n\nMeeting ID: 618 156 403\n\nJoin from PC\, Mac\, i OS or Android: https://logitech.zoom.us/j/618156403\n \nor join by phone: \nUS: 888 974 9888\nUK: 800 031 5717\nDE: 800 724 3138\nFR: 805 082 588\n \nOther international numbers available here:\nhttps://zoom.us/u/adlvrb8IL j\n \nMeeting ID: 618 156 403\n\nor join from a H.323/SIP Device:\n Dial: 162.255.37.11 (US West) or 162.255.36.11 (US East)\nMeeting ID: 618 156 403\n\nShare from a PC or MAC: https://zoom.us/share/618156403\n \nOr iPhone one-tap (US Toll): +16699006833\,618156403# or +16465588656\, 618156403#\n\nPassword for zoom call ends with x\n\nAll Austin Group part icipants are most welcome to join the call.\nThe call will last for 90 min utes.\n\n\nAn etherpad is usually up for a meeting\, with a URL using the date format as below:\n\nhttps://posix.rhansen.org/p/202x-mm-dd\n\nLOGIN R EQUIRED to write to the ETHERPAD (Use your gitlab.opengroup.org login.)\n \n \n\nBug reports are available at:\nhttps://www.austingroupbugs.net\n DTSTART;TZID=America/New_York:20220519T11 DURATION:PT1H30M0S LAST-MODIFIED:20220513T012754Z ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org SEQUENCE:0 STATUS:CONFIRMED SUMMARY:Austin Group teleconference +1 888 974 9888 PIN 618 156 403 TRANSP:OPAQUE URL:https://collaboration.opengroup.org/platform/single_unix_specification/ events.php X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-VISIBILITY:40 X-JOINBEFORE:5 X-CATEGORY:Teleconference X-PLATO-SITE:Single UNIX Specification X-PLATO-SITEID:136 END:VEVENT END:VCALENDAR meeting.ics Description: application/ics
Re: POSIX bind_textdomain_codeset(): some invalid codeset arguments
Harald van Dijk wrote in : |On 12/05/2022 18:19, Steffen Nurpmeso via austin-group-l at The Open |Group wrote: |> Bruno Haible wrote in |> <4298913.vrqWZg68TM@omega>: |>|Steffen Nurpmeso wrote: |>|> ... |>|>| [.] "UTF-7"." |>|> |>|> That is overshoot. |>| |>|No. UTF-7 is invalid here because it produces output that is not NUL |>|terminated. See: |>| |>|$ printf 'ab\0' | iconv -t UTF-7 | od -t c |>|000 a b + A A A - |>|007 |>| |>|strlen() on such a return value makes invalid memory accesses. |>|You can convince yourself by running |>|$ OUTPUT_CHARSET=UTF-7 valgrind ls --help |> |> This is then surely bogus? UTF-7 is a normal single byte |> character set and is to be terminated like anything else. Nothing |> in RFC 2152 nor RFC 3501 if you want makes me think something |> else. | |RFC 2152's rules 1 and 3 only allow specifying the listed characters as |their ASCII form. All other characters, including U+, must be |encoded using rule 2. GNU iconv is doing what the RFC specifies here. No really, please. And please do not strip important content, i am neither Chinese nor Russian, and especially not one of the other 7 billion that do not count. (I said surely bogus because i alone see the shiny light of having found give-me-five GNU iconv errors. Or even beyond that.) --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: POSIX bind_textdomain_codeset(): some invalid codeset arguments
On 12/05/2022 18:19, Steffen Nurpmeso via austin-group-l at The Open Group wrote: Bruno Haible wrote in <4298913.vrqWZg68TM@omega>: |Steffen Nurpmeso wrote: |> ... |>| [.] "UTF-7"." |> |> That is overshoot. | |No. UTF-7 is invalid here because it produces output that is not NUL |terminated. See: | |$ printf 'ab\0' | iconv -t UTF-7 | od -t c |000 a b + A A A - |007 | |strlen() on such a return value makes invalid memory accesses. |You can convince yourself by running |$ OUTPUT_CHARSET=UTF-7 valgrind ls --help This is then surely bogus? UTF-7 is a normal single byte character set and is to be terminated like anything else. Nothing in RFC 2152 nor RFC 3501 if you want makes me think something else. RFC 2152's rules 1 and 3 only allow specifying the listed characters as their ASCII form. All other characters, including U+, must be encoded using rule 2. GNU iconv is doing what the RFC specifies here. Cheers, Harald van Dijk
Re: ML reconfigured?
Steffen Nurpmeso wrote in <20220512173651.yl-pn%stef...@sdaoden.eu>: |Steffen Nurpmeso wrote in | <20220512173033.jp_28%stef...@sdaoden.eu>: ||Just wondering, i no longer receive my own messages to the ML? ||I would henceforth save away my sent copy if this is desired? | |So that i got. It thus seems selective values are selectively |applied just as currently desired. (Looking at this, it was likely because i was in Cc:, and i was there because another ML was addressed. Sorry for the noise.) --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: ML reconfigured?
Steffen Nurpmeso wrote in <20220512173033.jp_28%stef...@sdaoden.eu>: |Just wondering, i no longer receive my own messages to the ML? |I would henceforth save away my sent copy if this is desired? So that i got. It thus seems selective values are selectively applied just as currently desired. --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)
ML reconfigured?
Hello. Just wondering, i no longer receive my own messages to the ML? I would henceforth save away my sent copy if this is desired? --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: POSIX bind_textdomain_codeset(): some invalid codeset arguments
Bruno Haible wrote in <4298913.vrqWZg68TM@omega>: |Steffen Nurpmeso wrote: |> ... |>| [.] "UTF-7"." |> |> That is overshoot. | |No. UTF-7 is invalid here because it produces output that is not NUL |terminated. See: | |$ printf 'ab\0' | iconv -t UTF-7 | od -t c |000 a b + A A A - |007 | |strlen() on such a return value makes invalid memory accesses. |You can convince yourself by running |$ OUTPUT_CHARSET=UTF-7 valgrind ls --help This is then surely bogus? UTF-7 is a normal single byte character set and is to be terminated like anything else. Nothing in RFC 2152 nor RFC 3501 if you want makes me think something else. (RFC 5092 "IMAP URL Scheme", which invents the sane-enough- to-think-yourself "UTF-7 -> UTF-16 -> UCS-4 -> UTF-8 -> HEX" conversion scheme, and reverse, even implies the opposite, the example functions both NUL terminate the string.) Except Mark Davis said something like "UTF-7 was a failure" once on the Unicode ML, if i recall correctly, and i surely added "sadly", given the Punycode mess with domain names. But one more ship that sailed. But a pity it is. Why should NUL be treated differently?? No. No, i think it is a bug in GNU iconv that noone stumbled upon because noone is using UTF-7. Heck, how about that, for example: LC_ALL=C printf 'ab\0' | iconv -f iso-8859-1 -t utf-16 | od -t c 000 \0 \0 a \0 b \0 \0 \0 Two leading NULs? LC_ALL=C printf 'ab\0' | iconv -f iso-8859-1 -t ucs-2 | od -t c 000 a \0 b \0 \0 \0 That yes. LC_ALL=C printf 'ab\0' | iconv -f iso-8859-1 -t utf-8 | od -t c 000 a b \0 Yes. LC_ALL=C printf 'ab\0' | iconv -f iso-8859-1 -t utf-7 | od -t c 000 a b + A A A - No. Somehow they all bogus, take SunOS 5.10: LC_ALL=C printf 'ab\0' | iconv -f iso-8859-1 -t utf-16 | od -t 000 376 377 \0 a \0 b \0 \0 Ooh, now it gets scary!! Interestingly OpenBSD 7.1 behaves the same, likely it is an old instance of GNU iconv thus, there it says "GNU libiconv 1.16", here it says "iconv (GNU libc) 2.35". So unless someone convinces me you are arguing based on buggy software. UTF-7 is just another 7-bit single byte character set, and thus. --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)
[1003.1(2013)/Issue7+TC1 0000901]: reserve _POSIX* shell option namespace for future use
The following issue has been CLOSED. == https://austingroupbugs.net/view.php?id=901 == Reported By:rhansen Assigned To: == Project:1003.1(2013)/Issue7+TC1 Issue ID: 901 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Closed Name: Richard Hansen Organization: BBN User Reference: Section:2.14 'set' special built-in Page Number:2382 Line Number:75879-75902 Interp Status: --- Final Accepted Text: Resolution: Rejected Fixed in Version: == Date Submitted: 2014-12-04 18:56 UTC Last Modified: 2022-05-12 16:28 UTC == Summary:reserve _POSIX* shell option namespace for future use == Relationships ID Summary -- related to 854 requirement for additional built-in uti... related to 0001071 Name space reservation should move to XBD related to 935 warn users away from naming functions a... == Issue History Date ModifiedUsername FieldChange == 2014-12-04 18:56 rhansenNew Issue 2014-12-04 18:56 rhansenName => Richard Hansen 2014-12-04 18:56 rhansenOrganization => BBN 2014-12-04 18:56 rhansenSection => 2.14 'set' special built-in 2014-12-04 18:56 rhansenPage Number => 2382 2014-12-04 18:56 rhansenLine Number => 75879-75902 2014-12-04 18:56 rhansenInterp Status => --- 2014-12-04 18:58 rhansenDesired Action Updated 2014-12-11 16:21 nick Relationship added related to 854 2014-12-23 11:45 joerg Note Added: 0002511 2015-04-09 15:17 rhansenRelationship added related to 935 2015-04-09 15:19 rhansenNote Added: 0002612 2015-04-09 15:20 rhansenNote Added: 0002613 2018-01-04 17:13 rhansenNote Deleted: 0002613 2018-01-04 17:23 nick Relationship added related to 0001071 2018-01-05 10:21 geoffclare Note Added: 0003909 2018-05-09 11:51 kreNote Added: 0004024 2018-05-09 11:58 kreNote Added: 0004025 2022-05-12 16:28 geoffclare Status New => Closed 2022-05-12 16:28 geoffclare Resolution Open => Rejected ==
[Online Pubs 0000887]: printf and other functions appear many times in search results
The following issue has been UPDATED. == https://www.austingroupbugs.net/view.php?id=887 == Reported By:safinaskar Assigned To: == Project:Online Pubs Issue ID: 887 Category: Main Index Type: Error Severity: Editorial Priority: normal Status: New Name: Askar Safin Organization: User Reference: URL:http://pubs.opengroup.org/onlinepubs/9699919799 Section:- == Date Submitted: 2014-11-01 11:08 UTC Last Modified: 2022-05-12 16:03 UTC == Summary:printf and other functions appear many times in search results == -- (0005834) agadmin (administrator) - 2022-05-12 16:03 https://www.austingroupbugs.net/view.php?id=887#c5834 -- The index is controlled by a master file with patterns of the form word.idx:@f /functions/vswprintf.html word.idx:@t vswprintf - wide-character formatted output of a stdarg argument list word.idx:=vswprintf - wide-character formatted output of a stdarg argument list We could remove the duplicates from the file, although whether this is a big enough issue to warrant a change right now is debateable. We will review this for a future generation of the html or maintenance work when time permits. Issue History Date ModifiedUsername FieldChange == 2014-11-01 11:08 safinaskar New Issue 2014-11-01 11:08 safinaskar Name => Askar Safin 2014-11-01 11:08 safinaskar URL => http://pubs.opengroup.org/onlinepubs/9699919799 2014-11-01 11:08 safinaskar Section => - 2015-02-24 09:03 agadminNote Added: 0002559 2022-05-12 16:03 agadminNote Added: 0005834 ==
[1003.1(2013)/Issue7+TC1 0001077]: Recommend support for wide-character regcomp and regexec and/or specify multi-byte behavior
The following issue has been CLOSED. == https://austingroupbugs.net/view.php?id=1077 == Reported By:deadpixi Assigned To: == Project:1003.1(2013)/Issue7+TC1 Issue ID: 1077 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: Closed Name: Rob King Organization: User Reference: Section:regcomp Page Number:1783-1789 Line Number:57399-57703 Interp Status: --- Final Accepted Text: Resolution: Rejected Fixed in Version: == Date Submitted: 2016-09-11 17:47 UTC Last Modified: 2022-05-12 15:52 UTC == Summary:Recommend support for wide-character regcomp and regexec and/or specify multi-byte behavior == Issue History Date ModifiedUsername FieldChange == 2016-09-11 17:47 deadpixi New Issue 2016-09-11 17:47 deadpixi Name => Rob King 2016-09-11 17:47 deadpixi Section => regcomp 2016-09-11 17:47 deadpixi Page Number => - 2016-09-11 17:47 deadpixi Line Number => - 2016-09-11 17:53 deadpixi Note Added: 0003376 2016-09-11 17:53 deadpixi Issue Monitored: deadpixi 2016-09-11 21:03 Don Cragun Note Added: 0003377 2016-09-11 21:08 Don Cragun Page Number - => 1783-1789 2016-09-11 21:08 Don Cragun Line Number - => 57399-57703 2016-09-11 21:08 Don Cragun Interp Status => --- 2016-09-11 23:54 deadpixi Note Added: 0003378 2022-05-12 15:51 nick Note Added: 0005833 2022-05-12 15:51 nick Note Edited: 0005833 2022-05-12 15:52 nick Status New => Closed 2022-05-12 15:52 nick Resolution Open => Rejected ==
[1003.1(2013)/Issue7+TC1 0001077]: Recommend support for wide-character regcomp and regexec and/or specify multi-byte behavior
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1077 == Reported By:deadpixi Assigned To: == Project:1003.1(2013)/Issue7+TC1 Issue ID: 1077 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: Rob King Organization: User Reference: Section:regcomp Page Number:1783-1789 Line Number:57399-57703 Interp Status: --- Final Accepted Text: == Date Submitted: 2016-09-11 17:47 UTC Last Modified: 2022-05-12 15:51 UTC == Summary:Recommend support for wide-character regcomp and regexec and/or specify multi-byte behavior == -- (0005833) nick (manager) - 2022-05-12 15:51 https://austingroupbugs.net/view.php?id=1077#c5833 -- T%his issue failed to get a sponsor, and is therefore rejected. If complete wording can be specified and forwarded to a sponsor (IEEE, ISO/IEC JTC 1/SC 22, or The Open Group), it can be reconsidered in the future. Issue History Date ModifiedUsername FieldChange == 2016-09-11 17:47 deadpixi New Issue 2016-09-11 17:47 deadpixi Name => Rob King 2016-09-11 17:47 deadpixi Section => regcomp 2016-09-11 17:47 deadpixi Page Number => - 2016-09-11 17:47 deadpixi Line Number => - 2016-09-11 17:53 deadpixi Note Added: 0003376 2016-09-11 17:53 deadpixi Issue Monitored: deadpixi 2016-09-11 21:03 Don Cragun Note Added: 0003377 2016-09-11 21:08 Don Cragun Page Number - => 1783-1789 2016-09-11 21:08 Don Cragun Line Number - => 57399-57703 2016-09-11 21:08 Don Cragun Interp Status => --- 2016-09-11 23:54 deadpixi Note Added: 0003378 2022-05-12 15:51 nick Note Added: 0005833 ==
[Issue 8 drafts 0001583]: tidy up definition of the term "Special Built-In"
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=1583 == Reported By:calestyo Assigned To: == Project:Issue 8 drafts Issue ID: 1583 Category: Base Definitions and Headers Type: Enhancement Request Severity: Editorial Priority: normal Status: Resolved Name: Christoph Anton Mitterer Organization: User Reference: Section:3.335 Special Built-In Page Number:76 Line Number:2335 Final Accepted Text: Resolution: Accepted Fixed in Version: == Date Submitted: 2022-05-09 01:13 UTC Last Modified: 2022-05-12 15:06 UTC == Summary:tidy up definition of the term "Special Built-In" == Issue History Date ModifiedUsername FieldChange == 2022-05-09 01:13 calestyo New Issue 2022-05-09 01:13 calestyo Name => Christoph Anton Mitterer 2022-05-09 01:13 calestyo Section => 3.335 Special Built-In 2022-05-09 01:13 calestyo Page Number => 76 2022-05-09 01:13 calestyo Line Number => 2335 2022-05-12 15:06 Don Cragun Status New => Resolved 2022-05-12 15:06 Don Cragun Resolution Open => Accepted ==
Re: When can shells remove "known" process IDs from the list?
Robert Elz wrote, on 12 May 2022: > > | > I think they should remain independent. > | Sure, I agree. > > I don't. I cannot think of a single reason why the shell should be > forced to maintain two separate lists of its child processes. The jobs > table needs to have them, so processes in the job can be identified as > they finish. Duplicating that in another table, for no particular reason > I can imagine makes no sense to me. Still, if others want to implement > it that way, I don't object - but the standard has never required that, > and should not, absent some very good reason, be changed to require it now. The standard needs to specify them separately because, as per the mail I just sent in reply to Chet, job numbers identify process groups and therefore cannot identify asynchronous commands started with job control disabled. However, it is an internal implementation detail how that is managed. If you want to have one table with some flag to say whether each entry is a job or a "known process ID that's not a job", that's fine. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: When can shells remove "known" process IDs from the list?
Chet Ramey wrote, on 11 May 2022:
>
> On 5/10/22 12:03 PM, Geoff Clare via austin-group-l at The Open Group wrote:
>
> >> I'd be interested in your reasoning. The standard simply says that jobs
> >> and kill (and wait should be added) work with job %X notation whether
> >> or not job control is enabled.
> >
> > The normative text relating to creation of job numbers/IDs is all
> > conditional on job control being enabled.
>
> Where is that? It's not in the definition of Job ID, it's not in 2.9.3
> Asynchronous Lists, it's not in the `jobs' description, it's not part of
> the definition of Background Job or Foreground Job, it's not in any
> of fg/bg/kill/wait. I feel like I'm missing something obvious here.
You're looking in (some of) the right places, but missing the
significance of what's written there. For example, on the jobs page
it says in STDOUT that the job number written to standard output
is "A number that can be used to identify the process group to the
wait, fg, bg, and kill utilities."
Since it identifies a process *group*, it's not possible for a job
number to identify an asynchronous command that was started with
job control disabled (as it won't be run in its own process group).
This is confirmed by the OPERANDS sections for kill and wait, which
describe the second form for the pid operand as "A job control job ID
(see XBD Section 3.204, on page 66) that identifies a background
process group to be {signaled/waited for}."
Also, you mention "the definition of Job ID", but there is no such
definition. The term that is defined is "Job Control Job ID", which
implies that a "Job ID" is always something connected with job control.
> >> OK. I'm pretty sure everyone already does this for the jobs list. Not sure
> >> whether you want it to include the known IDs list.
> >
> > I think kre intended it apply to the known IDs list as well, and I
> > was agreeing with that.
>
> So for the known IDs list, it's pretty much `wait' and `jobs', right?
The phrase kre used was "when their termination status has been
reported to the user - however that happens". That includes information
written by an interactive shell before it writes a prompt. Although
the standard says this information is about the exit status of
"the background job", it is also, by association, information about
the exit status of a process in the known process IDs list.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
[1003.1(2016/18)/Issue7+TC2 0001584]: strfmon_l should be conditional on [CX]
The following issue has been CLOSED. == https://austingroupbugs.net/view.php?id=1584 == Reported By:bhaible Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1584 Category: System Interfaces Type: Error Severity: Editorial Priority: normal Status: Closed Name: Bruno Haible Organization: GNU User Reference: Section:strfmon_l Page Number:2039 Line Number:65333-65334 Interp Status: --- Final Accepted Text: Resolution: Withdrawn Fixed in Version: == Date Submitted: 2022-05-11 23:57 UTC Last Modified: 2022-05-12 11:09 UTC == Summary:strfmon_l should be conditional on [CX] == Issue History Date ModifiedUsername FieldChange == 2022-05-11 23:57 bhaibleNew Issue 2022-05-11 23:57 bhaibleName => Bruno Haible 2022-05-11 23:57 bhaibleOrganization => GNU 2022-05-11 23:57 bhaibleSection => strfmon_l 2022-05-11 23:57 bhaiblePage Number => 2039 2022-05-11 23:57 bhaibleLine Number => 65333-65334 2022-05-12 09:25 geoffclare Note Added: 0005831 2022-05-12 10:18 bhaibleNote Added: 0005832 2022-05-12 11:09 geoffclare Interp Status => --- 2022-05-12 11:09 geoffclare Status New => Closed 2022-05-12 11:09 geoffclare Resolution Open => Withdrawn ==
[1003.1(2016/18)/Issue7+TC2 0001584]: strfmon_l should be conditional on [CX]
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1584 == Reported By:bhaible Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1584 Category: System Interfaces Type: Error Severity: Editorial Priority: normal Status: New Name: Bruno Haible Organization: GNU User Reference: Section:strfmon_l Page Number:2039 Line Number:65333-65334 Interp Status: --- Final Accepted Text: == Date Submitted: 2022-05-11 23:57 UTC Last Modified: 2022-05-12 10:18 UTC == Summary:strfmon_l should be conditional on [CX] == -- (0005832) bhaible (reporter) - 2022-05-12 10:18 https://austingroupbugs.net/view.php?id=1584#c5832 -- Indeed, the entire and strfmon pages are implicitly wholly [CX] shaded. I withdraw the bug. Issue History Date ModifiedUsername FieldChange == 2022-05-11 23:57 bhaibleNew Issue 2022-05-11 23:57 bhaibleName => Bruno Haible 2022-05-11 23:57 bhaibleOrganization => GNU 2022-05-11 23:57 bhaibleSection => strfmon_l 2022-05-11 23:57 bhaiblePage Number => 2039 2022-05-11 23:57 bhaibleLine Number => 65333-65334 2022-05-12 09:25 geoffclare Note Added: 0005831 2022-05-12 10:18 bhaibleNote Added: 0005832 ==
[1003.1(2016/18)/Issue7+TC2 0001584]: strfmon_l should be conditional on [CX]
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1584 == Reported By:bhaible Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1584 Category: System Interfaces Type: Error Severity: Editorial Priority: normal Status: New Name: Bruno Haible Organization: GNU User Reference: Section:strfmon_l Page Number:2039 Line Number:65333-65334 Interp Status: --- Final Accepted Text: == Date Submitted: 2022-05-11 23:57 UTC Last Modified: 2022-05-12 09:25 UTC == Summary:strfmon_l should be conditional on [CX] == -- (0005831) geoffclare (manager) - 2022-05-12 09:25 https://austingroupbugs.net/view.php?id=1584#c5831 -- The entire strfmon() page specifies things that are not in the C standard, and therefore nothing on that page needs CX shading any more than anything on, say, the getpid() page does. The fact that locale_t is shaded CX on the page is irrelevant. The locale_t definition for strfmon_l() is provided by (where it is not CX shaded). The bug should be processed either as withdrawn (with Bruno's permission) or as rejected. Issue History Date ModifiedUsername FieldChange == 2022-05-11 23:57 bhaibleNew Issue 2022-05-11 23:57 bhaibleName => Bruno Haible 2022-05-11 23:57 bhaibleOrganization => GNU 2022-05-11 23:57 bhaibleSection => strfmon_l 2022-05-11 23:57 bhaiblePage Number => 2039 2022-05-11 23:57 bhaibleLine Number => 65333-65334 2022-05-12 09:25 geoffclare Note Added: 0005831 ==
