[EMAIL PROTECTED] wrote: > > >> __accessat (which was added waiting for the final > >> POSIX standard) > > > >Why the "__"-underscores ? > > I thought that was clear from the comments?
Erm... sorry... I interpreted the "For now we have:" like "for now we have [in the POSIX draft standard]", not "for now we have [in Solaris]" (I hereby blame the lack of coffee+sleep for this mistake... ;-/ ). > 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. Right... ;-( > >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) Well, depends... it would reduce the number of "active codepaths" between userland and kernel and _maybe_ (just raw guessing) lower the usage in the code case a bit (Ok... I guess the experts will now start to rip this statement into pieces... :-) ) ... or not. I am not sure > >> 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. Do you have any URL for the discussion ? > >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. Sorry... I thought this prototype was part of the standard draft (see above, keyword "coffee"). > >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. Ok... and maybe I shouldn't worry too much since lots of the "older" systems get eliminated from my equation because they lack POSIX thread support... but I fear that some systems still don't have the /proc feature (which generates elephant-sized headaches right now (right after a reliable way to detect whether |fork()| behaves like |forkall()| or |fork1()|, a (portable) way to avoid the need to rely on |SIGCLD| to detect whether a child process terminates (e.g. imagine having two seperate shell instances within one process, both running on seperate threads... fun... ;-( )) etc.). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
