these new iffe probes look good
my first hack at *at() will be to redo ast fts (which is the base for all ast
dir traversal)
based on that the probes/macros may change in order
to make the *at() vs !*at() coding as readable/portable as possible
re _GNU_SOURCE:
its hard enough to coax the latest posix apis out of cc
getting each os implementation to reveal extensions is even more interesting
so most of the *_SOURCE dancing is done in the libast implementation and does
not leak out in *.h
with the exception of { _LARGEFILE64_SOURCE _LARGEFILE_SOURCE }
grabbing the O_PATH value in iffe and using it for O_search will probably be a
necessary evil
re posix compatibility: is linux concerned with that anymore?
On Wed, 18 Jul 2012 10:12:05 +0200 Josh Hurst wrote:
> On Wed, Jul 18, 2012 at 7:22 AM, Roland Mainz <[email protected]>
> wrote:
> > On Mon, Jul 9, 2012 at 9:48 AM, Roland Mainz <[email protected]>
> > wrote:
> > [snip]
> >> - The patch relies on |O_SEARCH| which was added with XPG7. Since
> >> previous XPG versions did not have that test in the shell testsuite we
> >> happily assume that only platforms implementing |O_SEARCH| must be
> >> able to conform to that test (all major Unix versions have |O_SEARCH|
> >> in their current versions since at least two years).
> >>
> >> - The patch could in theory use Linux's |O_PATH| ... but as we
> >> discovered by accident in
> >> https://mailman.research.att.com/pipermail/ast-developers/2012q3/001512.html
> >> |O_PATH| currently does not work in Linux3.0 with |fchdir()|. However
> >> Linus did us a *BIG* favor and pushed ASAP a patch (see
> >> http://marc.info/?l=git-commits-head&m=134170760505086&w=2) and marked
> >> it for inclusion into the 3.x stable branch, e.g. most Linux
> >> distributions running the 3.x kernel series will pick it up quickly
> >> (within less than a couple of months). Once we have a machine with
> >> |O_PATH| fixed we can revisit the issue... but we need a iffe probe
> >> then (the current patch explicitly works without iffe probes).
> >
> > One request:
> > Can we have three new iffe probes for ksh93v-, please:
> > 1. One iffe probe which sets a CPP symbol |O_search| when either...
> > a) ... |O_SEARCH| is defined (Solaris 11 (maybe 10, too), AIX7, etc.)
> > ... or...
> > b) ... |O_PATH| is defined and passes the following test from Olga
> > (please replace s/O_SEARCH/O_PATH/):
> > -- snip --
> Add #define _GNU_SOURCE 1 here.
> > #include <sys/types.h>
> > #include <sys/stat.h>
> > #include <fcntl.h>
> > #include <unistd.h>
> >
> > #include <stdlib.h>
> > #include <stdio.h>
> >
> > int main(int ac, char *av[])
> > {
> > int dirfd, dupdirfd;
> >
> > dirfd=open("/etc", O_SEARCH);
> > if(dirfd<0)
> > {
> > fprintf(stderr, "open() failed.\n");
> > return EXIT_FAILURE;
> > }
> >
> > dupdirfd = fcntl(dirfd, F_DUPFD, 50);
> > if(dirfd<0)
> > {
> > fprintf(stderr, "fcntl() failed.\n");
> > return EXIT_FAILURE;
> > }
> >
> > if(fchdir(dupdirfd)<0)
> > {
> > fprintf(stderr, "fchdir(dupdirfd) failed.\n");
> > return EXIT_FAILURE;
> > }
> >
> > if(fchdir(dirfd)<0)
> > {
> > fprintf(stderr, "fchdir(dirfd) failed.\n");
> > return EXIT_FAILURE;
> > }
> >
> > if(openat(dupdirfd, "profile", O_RDONLY)<0)
> > {
> > fprintf(stderr, "openat(dupdirfd, profile, O_RDONLY)
> > failed.\n");
> > return EXIT_FAILURE;
> > }
> >
> > dirfd=openat(dupdirfd, "krb5", O_SEARCH);
> Replace "krb5" with "X11", Linux has no /etc/krb5 directory.
> > if(dirfd<0)
> > {
> > fprintf(stderr, "openat(dupdirfd, krb5, O_SEARCH)
> > failed.\n");
> > return EXIT_FAILURE;
> > }
> >
> > if(fchdir(dirfd)<0)
> > {
> > fprintf(stderr, "2nd fchdir(dirfd) failed.\n");
> > return EXIT_FAILURE;
> > }
> >
> > puts("SUCCESS.");
> >
> > return EXIT_SUCCESS;
> > }
> > -- snip --
> > Using |O_SEARCH| for |O_search| should be preferred over |O_PATH| if
> > both are available.
> I think a iffe script would be good since the Linux header require
> _GNU_SOURCE to be defined or O_PATH is not defined. IMO the iffe
> script should extract the value for O_PATH (which can differ between
> architectures, i.e. SPARC uses a different bit value than x86-64) and
> make it available as O_search if O_SEARCH is not defined.
> Josh
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers
