| From: Paul Wouters <[email protected]> | On Mon, 30 Oct 2017, D. Hugh Redelmeier wrote: | | > | Thanks for fixing that. I did re-introduce the ifdef for GLOB_ABORTED, | > | not sure why you removed that.
You added it back into lib/libswan/secrets.c. That's the only place I removed it. But GLOB_ABORTED is used in lib/libswan/unbound.c too, and it has never been (conditionally) defined there. So it sure looks pointless. (Unless unbound is optional, and I don't think that it is.) The original definition was introduced by MCR in 6949eb131a. The commit description called this "refactoring" but it does not seem to have been moved from anywhere (it does not appear in a deletion). Perhaps it was just a copy. I'm a bit too lazy to track it down. I may even have written the original original, but I don't know. | > It was claimed to be with compatability with old code. Since glob(3) | > is specified by POSIX, I find it hard to believe that the interface | > has changed recently. Do we support any system that requires this? | | It was only added in 2014: | | commit 3bcc0de0d62a707cf8c7453e5b2124baa82fe66b That commit never mentioned GLOB_ABORTED. The commit message clearly mentions GLOB_BRACE and GLOB_NOMAGIC. Those were not supported by MUSL (but are supported by the Single Unix Specification 2). Perhaps those are now supported by MUSL -- do you know? If so, we could undo that commit. ================ The Single Unix Specification 2, from 1997, derived from POSIX (but free) specifies GLOB_ABORT. <http://pubs.opengroup.org/onlinepubs/7908799/xsh/glob.html> Some BSD manuals say: The historical GLOB_ABEND return constant is no longer supported. Portable applications should use the GLOB_ABORTED constant instead. <https://www.unix.com/man-page/netbsd/3/glob_pattern_p/> We should not support GLOB_ABEND. Unless you can find a system that we intend to support that requires this hack. Why did you think it was useful to add it back? It cannot cure a problem observed in the field since it was incomplete. PS: thanks for reading and checking my code. In this case, it forced me to check things more carefully. _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
