Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
On Fri, 2022-09-09 at 14:13 -0400, Paul Smith via austin-group-l at The Open Group wrote: > Ah OK. I don't have access to the text (as far as I know) so I > wasn't aware that it was defined that way. Sounds good. Oh I see the text in the minutes now. OK with me. Thanks.
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
On Fri, 2022-09-09 at 17:13 +0100, Geoff Clare via austin-group-l at The Open Group wrote: > I assumed when you said "other internal macros" you weren't including > $+ because the addition for $+ is being described by reference to $^ > and so is subject to the same exception for .WAIT. Ah OK. I don't have access to the text (as far as I know) so I wasn't aware that it was defined that way. Sounds good.
Minutes of the 8th September 2022 Teleconference
All Enclosed are the minutes from yesterday’s call regards Andrew - Minutes of the 8th September 2022 TeleconferenceAustin-1253 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 9th September 2022 Attendees: Don Cragun, IEEE PASC OR Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR Geoff Clare, The Open Group Eric Blake, Red Hat, The Open Group OR Andrew Josey, The Open Group Apologies Tom Thompson, IEEE * General news This was a call dedicated to general bugs. * Current Business Bug 1122: POSIX should include gettext() and friends OPEN and https://posix.rhansen.org/p/gettext_draft Also https://austingroupbugs.net/file_download.php?file_id=64&type=bug Geoff's addition to XRAT appendix E and cancellation points lists have been noted to date. A new PDF will be needed, but we will continue to wait for more comments first. AJ and Geoff took an action to start work on preparing a company review draft within The Open Group for new APIs. Bug 1560: clarify wording of command substitution https://austingroupbugs.net/view.php?id=1560 Leave this and related bugs 1561 and 1564 open awaiting reviews/discussion. Bug 1273: glob()'s GLOB_ERR/errfunc and non-directory files OPEN https://austingroupbugs.net/view.php?id=1273 We will leave this open awaiting feedback. Bug 768: add "fd-private" POSIX locks to spec OPEN https://austingroupbugs.net/view.php?id=768 Linux has now had OFD locks for several years, and more code in the wild is starting to use it - so we have existing practice (see note 2508) https://www.gnu.org/software/libc/manual/html_mono/libc.html#Open-File-Description-Locks Starting point of resolution at https://posix.rhansen.org/p/bug768 AI to EricB - take the GNU documentation and turn it into a desired action Bug 739: CX requirements for strftime seem to conflict with ISO C OPEN https://austingroupbugs.net/view.php?id=739 Nick completed his action to liaise with the C committee on this issue. C23 is about to go to ballot, so the way to raise the issue would be as a ballot comment. This could be done either as a UK or US national body comment. Andrew confirmed with the UK C Panel that we can submit comments. Bug 728: Restrictions on signal handlers are both excessive and insufficient OPEN https://austingroupbugs.net/view.php?id=728 The alignment with C17 changes the requirements in this area. There is still no allowance for accessing const objects or string literals, so that is something we could consider adding as an extension to C. Or we could raise the issue with the C committee if we want to stay in sync with the C standard. Suggestion: raise it as a C23 ballot comment. Depending on the answer, we could implement what they plan to do, or diverge (or leave things as they are). AI Nick and Geoff: File ballot comments on C23 (through the US and/or UK national bodies to WG14). Bug 708: Make mblen, mbtowc, and wctomb thread-safe for alignment with C11 OPEN https://austingroupbugs.net/view.php?id=708 This was discussed with WG14: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2148.htm#dr_498 DR 498 (URL above) seems to have an agreed wording change from April 2017, but it has not been applied. Nick asked the WG14 convenor what happened to that DR. It appears the item was discussed but in the end the C committee could not agree an acceptable change, and no alternate proposal was available. We will need to accept the C wording for now. Bug 700: Clarify strtoul's behaviour on strings representing negative numbers OPEN https://austingroupbugs.net/view.php?id=700 AI: Nick and Geoff to work together on a C23 ballot comment (against N3047 7.24.1.7 para 5). Bug 689: Possibly unintended allowance for stdio deadlock OPEN https://austingroupbugs.net/view.php?id=689 Change needs to be coordinated with C23. AI: Nick and Geoff to work together on a C23 ballot comment (against N3047 7.23.3 para 3). Bug 618: require isatty and friends to set errno on failure OPEN https://austingroupbugs.net/view.php?id=618 Action item to EricB: email to various lists to collect results for sample program (see bug 503 comment 1005 for starting point) for current errno behavior on various OS Bug 553: Add new type of shell and shell feature requirement for new shell in posix. Rejected https://austingroupbugs.net/view.php?id=553 No proposal has been received. Therefore this bug is being closed. Bug 514: Enhance internal macros in make Accepted as Marked https://austingroupbugs.net/view.php?id=514 This item is tagged for Issue 8 On D2.1 page 2947 line 98895, after applying bug 1520, change: The $^ macro shall evaluate to the list of prerequisites for the current target. to: The $^ macro shall evaluate to the list of prerequisites for the current target, with any duplicates (except the first) removed. On D2.1 page 2947 after line 98895 add: $+ The $+ macro shall be equivalent to $^, except that dupli
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
Paul Smith wrote, on 09 Sep 2022: > > On Fri, 2022-09-09 at 16:02 +0100, Geoff Clare via austin-group-l at > The Open Group wrote: > > > > $^ > > > > The $^ macro shall evaluate to the list of prerequisites > > > > for the current target, with any duplicates (except > > > > the first) removed. It shall be evaluated for both > > > > target and inference rules. If the list of > > > > prerequisites of the target contain any .WAIT special > > > > targets, the results of expanding $^ are unspecified. > > > > > > Thanks, but what about the other internal macros that may refer to > > > prerequisites? Don't we need to specify the .WAIT behavior for > > > those > > > as well? > > > > No need, because the description of .WAIT being added says "When > > .WAIT appears in a target rule as a prerequisite, it shall not itself > > be treated as a prerequisite". > > Are you saying that the implementations that keep .WAIT (or even change > its name) in $^ have been discovered to NOT keep .WAIT in $+ and so the > $+ macro doesn't need the above special exception saying that the > results are unspecified, and the standard can just affirm that .WAIT is > not present in $+? I assumed when you said "other internal macros" you weren't including $+ because the addition for $+ is being described by reference to $^ and so is subject to the same exception for .WAIT. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
On Fri, 2022-09-09 at 16:02 +0100, Geoff Clare via austin-group-l at The Open Group wrote: > > > $^ > > > The $^ macro shall evaluate to the list of prerequisites > > > for the current target, with any duplicates (except > > > the first) removed. It shall be evaluated for both > > > target and inference rules. If the list of > > > prerequisites of the target contain any .WAIT special > > > targets, the results of expanding $^ are unspecified. > > > > Thanks, but what about the other internal macros that may refer to > > prerequisites? Don't we need to specify the .WAIT behavior for > > those > > as well? > > No need, because the description of .WAIT being added says "When > .WAIT appears in a target rule as a prerequisite, it shall not itself > be treated as a prerequisite". Are you saying that the implementations that keep .WAIT (or even change its name) in $^ have been discovered to NOT keep .WAIT in $+ and so the $+ macro doesn't need the above special exception saying that the results are unspecified, and the standard can just affirm that .WAIT is not present in $+? That seems exceedingly odd to me but ok!
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
Paul Smith wrote, on 09 Sep 2022: > > On Fri, 2022-09-09 at 10:19 +0100, Geoff Clare via austin-group-l at > The Open Group wrote: > > It's intentional. I tried 'all: a b a c' with the GNU, Solaris 11.4 > > and FreeBSD implementations and they all expanded $^ (or $> for > > FreeBSD) to 'a b c'. Are you suggesting that there are circumstances > > where one of these implementations might not preserve the order? > > No, but the GNU make documentation doesn't state this as a requirement. > It says: > > > $^ > > The names of all the prerequisites, with spaces between them. For > > prerequisites which are archive members, only the named member is > > used (see Archives). A target has only one prerequisite on each other > > file it depends on, no matter how many times each file is listed as a > > prerequisite. So if you list a prerequisite more than once for a > > target, the value of $^ contains just one copy of the name. This list > > does not contain any of the order-only prerequisites; for those see > > the ‘$|’ variable, below. > > So if the ordering is required I should update this documentation. Sound like a good idea. There could well be makefiles in existence that rely on the ordering (even if unintentionally). -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
Paul Smith wrote, on 09 Sep 2022: > > On Thu, 2022-09-08 at 17:50 -0400, Lawrence Velázquez via austin-group- > l at The Open Group wrote: > > On Thu, Sep 8, 2022, at 3:29 PM, Paul Smith via austin-group-l at The > > Open Group wrote: > > > I don't have visibility into the current proposed text for the > > > POSIX make definition, but can someone clarify how the .WAIT > > > prerequisites are to be treated when expanding internal macros like > > > $^, $+, $?, and even $< (if, for some weird reason, someone used > > > .WAIT as the first prerequisite)? > > > > > > Is it the case that they are required to ALWAYS be present? Or > > > required to NEVER be present? Or is the value of internal macros > > > not well-defined for prerequisite lists that contain .WAIT? > > > > The latest note on bug 514 begins, "On D2.1 page 2947 line 98895, > > after applying bug 1520, change...". So presumably the intended > > text is a synthesis of the results of 1520 [1] and 514 [2]: > > > > $^ > > The $^ macro shall evaluate to the list of prerequisites > > for the current target, with any duplicates (except > > the first) removed. It shall be evaluated for both > > target and inference rules. If the list of > > prerequisites of the target contain any .WAIT special > > targets, the results of expanding $^ are unspecified. > > > > [example omitted] > > Thanks, but what about the other internal macros that may refer to > prerequisites? Don't we need to specify the .WAIT behavior for those > as well? No need, because the description of .WAIT being added says "When .WAIT appears in a target rule as a prerequisite, it shall not itself be treated as a prerequisite". -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
On Thu, 2022-09-08 at 17:50 -0400, Lawrence Velázquez via austin-group- l at The Open Group wrote: > On Thu, Sep 8, 2022, at 3:29 PM, Paul Smith via austin-group-l at The > Open Group wrote: > > I don't have visibility into the current proposed text for the > > POSIX make definition, but can someone clarify how the .WAIT > > prerequisites are to be treated when expanding internal macros like > > $^, $+, $?, and even $< (if, for some weird reason, someone used > > .WAIT as the first prerequisite)? > > > > Is it the case that they are required to ALWAYS be present? Or > > required to NEVER be present? Or is the value of internal macros > > not well-defined for prerequisite lists that contain .WAIT? > > The latest note on bug 514 begins, "On D2.1 page 2947 line 98895, > after applying bug 1520, change...". So presumably the intended > text is a synthesis of the results of 1520 [1] and 514 [2]: > > $^ > The $^ macro shall evaluate to the list of prerequisites > for the current target, with any duplicates (except > the first) removed. It shall be evaluated for both > target and inference rules. If the list of > prerequisites of the target contain any .WAIT special > targets, the results of expanding $^ are unspecified. > > [example omitted] Thanks, but what about the other internal macros that may refer to prerequisites? Don't we need to specify the .WAIT behavior for those as well? I would imagine, for example, the same rule as above would be in effect for both the "$+" and "$?" internal macros (I guess for "$?" it's sort of implied that .WAIT can never be considered newer than the target, otherwise the target would always be rebuilt--but maybe that should be made explicit, I dunno).
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
On Fri, 2022-09-09 at 10:19 +0100, Geoff Clare via austin-group-l at The Open Group wrote: > It's intentional. I tried 'all: a b a c' with the GNU, Solaris 11.4 > and FreeBSD implementations and they all expanded $^ (or $> for > FreeBSD) to 'a b c'. Are you suggesting that there are circumstances > where one of these implementations might not preserve the order? No, but the GNU make documentation doesn't state this as a requirement. It says: > $^ > The names of all the prerequisites, with spaces between them. For > prerequisites which are archive members, only the named member is > used (see Archives). A target has only one prerequisite on each other > file it depends on, no matter how many times each file is listed as a > prerequisite. So if you list a prerequisite more than once for a > target, the value of $^ contains just one copy of the name. This list > does not contain any of the order-only prerequisites; for those see > the ‘$|’ variable, below. So if the ordering is required I should update this documentation.
Re: XCU, stty, CHANGE HISTORY, Issue 6, para. 1 implies -xcase is still available
наб wrote, on 08 Sep 2022: > > Quoth Issue 8 Draft 2.1, XCU, stty, CHANGE HISTORY, Issue 6: > 108300 The LEGACY items iuclc(−iuclc), xcase, olcuc(−olcuc), > lcase(−lcase), and LCASE(−LCASE) are > 108300 removed. > > Compare SUSv2, Commands and Utilities, stty, OPERANDS, Local Modes: > xcase (−xcase) > Set canonical (unprocessed) upper- or lower-case presentation. This > has the effect of setting (not setting) XCASE in the termios c_lflag > field, as defined in the XBD specification, Chapter 9, General > Terminal Interface. (LEGACY) > (whole paragraph shaded EX). > > XCASE was removed in Issue 6 as well, so, naturally, -xcase makes no > sense, and, indeed, there's no mention of it. > > However, the CHANGE HISTORY would imply that, > if you read it retrochronologically, -xcase never existed, or, > if you read it prochronologically, -xcase was removed in error. I agree this should say xcase(-xcase). Since there has been a change to the stty page since draft 2.1 (for bug 1508) I will fix this as part of the change history updates that go into draft 3. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
Paul Smith wrote, on 08 Sep 2022: > > > https://austingroupbugs.net/view.php?id=514#c5962 > > - > > - > > On D2.1 page 2947 line 98895, after applying bug 1520, > > change:The $^ macro shall evaluate to the list of > > prerequisites for the current target.to:The > > $^ macro shall evaluate to the list of prerequisites for the current > > target, with any duplicates (except the first) removed. > > On D2.1 page 2947 after line 98895 add:$+The > > $+ macro shall be equivalent to $^, except that duplicates shall not > > be removed; all prerequisites shall appear in the order they were > > listed in the makefile > > This was closed before I had a chance to comment on the wording but a > few things: > > First, this text doesn't mention the .WAIT prerequisites that were > added as optional features; do we need to add text for how these are > included (or not) in $^? Or, are they just included like any other > prerequisite? > > Or did .WAIT not get included? I can't remember. This was the subject > of https://austingroupbugs.net/view.php?id=1520 which itself doesn't > mention the removal of duplicate entries, as the above text does. Lawrence answered this part (correctly). > Second, the wording of the $^ implies that when duplicates are seen the > it's always the first instance which is preserved and subsequent > instances are omitted, which means order is preserved. Is that > requirement intentional? It's intentional. I tried 'all: a b a c' with the GNU, Solaris 11.4 and FreeBSD implementations and they all expanded $^ (or $> for FreeBSD) to 'a b c'. Are you suggesting that there are circumstances where one of these implementations might not preserve the order? -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
