>> __accessat (which was added waiting for the final >> POSIX standard) > >Why the "__"-underscores ?
I thought that was clear from the comments? You can't add a function to Solaris which may have the same name as one which is later ratified by POSIX if you're not sure that POSIX will define that function in the exact same manner. >Are you going to switch over the old calls (e.g. |open()| etc.) over to >the new functions and use cwd as |fd| argument ? I believe that that is what happened for most functions; it's also how I did accessat(). However, that switching over is done exclusively in the kernel not it userland (that seems a bit pointless) >> and it is probably best to implement what is missing as private >> functions untile the standard has gravitated toward consensus. >> >> There's some discussion about the 'f' argument. > >Do you mean the |flags| field ? I think I means that there was some discussion about faccessat() vs accessat() and possibly the flags argument. >Erm... IMO this is wrong, e.g. |flags| should contain set of flag _bits_ >and setting unknown bits should return an error. Look, this was a *rough* sketch. Don't nitpick it; that is just a pointless waste of time. >But that's not portable (and it looks more or less like the other >workaround of keeping the current working directory's name around and >concaternate that with the relative path provided as argument (and >that's not really a good idea, for example if a dir looses it's parent >this workaround will no longer work (and may be a problem if the base >path is near |PATH_MAX| (your solution will still work but will still >not be portable)))) ... ;-( Right, but it's portable to a lot of systems. (Keeping a directory's name around, as you rightly point out, has many more drawbacks; the non-portable approach is guaranteed to work on systems that have it) Casper _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
