[1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=514 == Reported By:dwheeler Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 514 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: Under Review Name: David A. Wheeler Organization: User Reference: Section:make Page Number:2918 Line Number:95928-95954 Interp Status: --- Final Accepted Text: == Date Submitted: 2011-11-17 00:21 UTC Last Modified: 2020-01-13 04:53 UTC == Summary:Enhance internal macros in make == -- (0004724) Love4Boobies (reporter) - 2020-01-13 04:53 http://austingroupbugs.net/view.php?id=514#c4724 -- I don't think I've misunderstood the note, it's just that you want to use $^ as a replacement for something that it's not supposed to replace. Its use lies elsewhere, where there is nothing in the standard that offers a replacement. Another example would be pattern rules. You cannot use a variable like that in a pattern rule because each target has its own set of prerequisites. Issue History Date ModifiedUsername FieldChange == 2011-11-17 00:21 dwheeler New Issue 2011-11-17 00:21 dwheeler Status New => Under Review 2011-11-17 00:21 dwheeler Assigned To => ajosey 2011-11-17 00:21 dwheeler Name => David A. Wheeler 2011-11-17 00:21 dwheeler Section => make 2011-11-17 00:21 dwheeler Page Number => 2918 2011-11-17 00:21 dwheeler Line Number => 95928-95954 2011-11-17 11:08 joerg Note Added: 0001026 2011-11-17 16:30 Konrad_Schwarz Note Added: 0001030 2012-01-07 00:06 psmith Note Added: 0001088 2012-04-10 16:38 joerg Note Added: 0001193 2019-12-25 10:20 Love4Boobies Note Added: 0004703 2020-01-07 04:33 Love4Boobies Issue Monitored: Love4Boobies 2020-01-07 09:14 Konrad_Schwarz Note Added: 0004709 2020-01-07 14:41 psmith Note Added: 0004711 2020-01-13 04:53 Love4Boobies Note Added: 0004723 2020-01-13 04:53 Love4Boobies Note Added: 0004724 ==
[1003.1(2016)/Issue7+TC2 0001318]: Define close-on-fork flag
The following issue has been SUBMITTED. == http://austingroupbugs.net/view.php?id=1318 == Reported By:nate_karstens Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1318 Category: System Interfaces Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Nate Karstens Organization: Garmin User Reference: Section:fcntl, open, socket Page Number:Unknown Line Number:Unknown Interp Status: --- Final Accepted Text: == Date Submitted: 2020-01-12 10:50 UTC Last Modified: 2020-01-12 10:50 UTC == Summary:Define close-on-fork flag Description: Certain interfaces (like system(), popen(), etc.) are non-atomic in that their implementation first calls a fork() and then an exec(). This creates a race condition in certain scenarios. Please see https://www.mail-archive.com/austin-group-l@opengroup.org/msg05324.html and resulting discussion for a description of one such condition. Issue 1317 already requests enhancements to these interfaces, but this particular issue would also be solvable if there was a close-on-fork flag (similar to close-on-exec, but the file descriptor is closed in the child process after a fork). Desired Action: Add the following to fcntl()/F_DUPFD: The FD_CLOFORK flag associated with the new file descriptor shall be cleared to keep the file open in the child process after a fork. Add the following to fcntl()/F_SETFD If the FD_CLOFORK flag in the third argument is 0, the file descriptor shall remain open in the child process after a fork(). Otherwise, the file descriptor shall be closed in the child process after a fork(). Add the following to fcntl(): F_DUPFD_CLOFORK Like F_DUPFD, but the FD_CLOFORK flag associated with the new file descriptor shall be set. Additional changes to the RETURN VALUE and ERRORS sections may be necessary as well. Add the following to open(): O_CLOFORK If set, the FD_CLOFORK flag for the new file descriptor shall be set. POSIX does not currently specify SOCK_CLOEXEC, but this would be a useful addition. Add the following to socket(): SOCK_CLOEXEC If set, the close-on-exec (FD_CLOEXEC) flag for the new file descriptor shall be set. SOCK_CLOFORK If set, the close-on-fork (FD_CLOFORK) flag for the new file descriptor shall be set. In hindsight, it seems like it would have been preferable to have the default behavior be to close all file descriptors when the process forks, and have flags to override that behavior on an individual basis. Submitter cannot think of a way to do that and maintain backwards-compatibility, short of defining new system calls, but the idea seems like it would be worth considering. == Issue History Date ModifiedUsername FieldChange == 2020-01-12 10:50 nate_karstens New Issue 2020-01-12 10:50 nate_karstens Name => Nate Karstens 2020-01-12 10:50 nate_karstens Organization => Garmin 2020-01-12 10:50 nate_karstens Section => fcntl, open, socket 2020-01-12 10:50 nate_karstens Page Number => Unknown 2020-01-12 10:50 nate_karstens Line Number => Unknown ==
[1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=514 == Reported By:dwheeler Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 514 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: Under Review Name: David A. Wheeler Organization: User Reference: Section:make Page Number:2918 Line Number:95928-95954 Interp Status: --- Final Accepted Text: == Date Submitted: 2011-11-17 00:21 UTC Last Modified: 2020-01-13 04:53 UTC == Summary:Enhance internal macros in make == -- (0004723) Love4Boobies (reporter) - 2020-01-13 04:53 http://austingroupbugs.net/view.php?id=514#c4723 -- I don't think I've misunderstood the note, it's just that you want to use $^ as a replacement for something that it's not supposed to replace. Its use lies elsewhere, where there is nothing in the standard that offers a replacement. Another example would be pattern rules. You cannot use a variable like that in a pattern rule because each target has its own set of prerequisites. Issue History Date ModifiedUsername FieldChange == 2011-11-17 00:21 dwheeler New Issue 2011-11-17 00:21 dwheeler Status New => Under Review 2011-11-17 00:21 dwheeler Assigned To => ajosey 2011-11-17 00:21 dwheeler Name => David A. Wheeler 2011-11-17 00:21 dwheeler Section => make 2011-11-17 00:21 dwheeler Page Number => 2918 2011-11-17 00:21 dwheeler Line Number => 95928-95954 2011-11-17 11:08 joerg Note Added: 0001026 2011-11-17 16:30 Konrad_Schwarz Note Added: 0001030 2012-01-07 00:06 psmith Note Added: 0001088 2012-04-10 16:38 joerg Note Added: 0001193 2019-12-25 10:20 Love4Boobies Note Added: 0004703 2020-01-07 04:33 Love4Boobies Issue Monitored: Love4Boobies 2020-01-07 09:14 Konrad_Schwarz Note Added: 0004709 2020-01-07 14:41 psmith Note Added: 0004711 2020-01-13 04:53 Love4Boobies Note Added: 0004723 ==
Re: system() and pthread_atfork()
I wanted to thank everyone for the discussion and various suggestions. There are two changes that I have created in the Austin Group defect tracker: 1) system(), popen(), etc. should be required to call pthread_atfork() handlers if their implementation is not atomic (see http://austingroupbugs.net/view.php?id=1317). 2) POSIX should specify a SOCK_CLOFORK / FD_CLOFORK socket option (see http://austingroupbugs.net/view.php?id=1318). In addition, it would have been preferable for the default behavior to close all file descriptors on a fork and have flags to override that behavior. I have also been in contact with the author of the original FD_CLOFORK patch for Linux and they are OK with me taking that over and updating for the latest kernel. Cheers, Nate -Original Message- From: Karstens, Nate Sent: Friday, December 20, 2019 4:40 PM To: austin-group-l@opengroup.org Subject: Re: system() and pthread_atfork() Thanks to everyone for the great responses! Below are some notes/discussion on the various replies I've seen: > If it's supposed to behave as if fork() has been called, this implicitly > includes calling atfork handlers when POSIX_C_SOURCE is defined... Regarding glibc, I'm not sure the POSIX_C_SOURCE macro would control that. Here is a reference to the latest definition of system() in the POSIX standard: https://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html The glibc developers had a discussion on this topic here: https://sourceware.org/bugzilla/show_bug.cgi?id=17490 They seemed to go back and forth on this same issue, and one developer suggested communicating the ambiguity with the Austin Group. I'm not sure if this was ever done, but there still appears to be a discrepancy (in system(), popen() -- https://pubs.opengroup.org/onlinepubs/9699919799/functions/popen.html, and maybe others). > Couldn't that be addressed by SO_REUSEADDR? According to https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_10_16, SO_REUSEADDR "indicates that the rules used in validating addresses supplied in a https://pubs.opengroup.org/onlinepubs/9699919799/functions/bind.html should allow reuse of local addresses". Based on this, it doesn't appear to be for the purposes of addressing this issue, and we're not excited about the other side effects as well. > The reason it likely that the implementer of system() and popen() get the > freedom to use a more efficient mechanism. That might be, but it would be good to document the tradeoffs associated with that efficiency. Even better would be to come up with a mechanism to avoid it entirely. If requiring pthread_atfork() handlers to execute is not an option, then maybe a file-descriptor/socket option that marks the socket as closing once the process forks (like SOCK_CLOEXEC / FD_CLOEXEC, but done at fork() instead of exec()). > The vfork() used before also did not call the pthread_atfork() handlers > either. https://pubs.opengroup.org/onlinepubs/009604599/functions/vfork.html comes with a lot of warnings, an explicit recommendation to use fork(), and a note that it may be withdrawn in the future. As such we weren't as worried about it, but maybe we should be... > If you have control over the callers of system() We don't have control over them, which makes this more disconcerting. Cheers, Nate CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
