the current plan is to define these in FEATURE/fcntl => <ast_fcntl.h>
O_cloexec == either O_CLOEXEC or 0
O_dupfd_cloexec == either F_DUPFD_CLOEXEC or F_DUPFD
the code would do something like
fd = open( O_cloexec )
if (!O_cloexec) fcntl( fd FD_CLOEXEC )
or
fd = open( O_cloexec )
#if !O_cloexec
fcntl( fd FD_CLOEXEC )
#endif
and
nd = fcntl ( fd F_dupfd_cloexec )
if ( F_dupfd_cloexec == F_DUPFD ) fcntl (nd FD_CLOEXEC )
or
nd = fcntl ( fd F_dupfd_cloexec )
#if F_dupfd_cloexec == F_DUPFD
fcntl (nd FD_CLOEXEC )
#endif
On Mon, 18 Jun 2012 22:15:29 +0200 Roland Mainz wrote:
> On Mon, Jun 18, 2012 at 9:54 PM, Roland Mainz <roland.ma...@nrubsig.org>
> wrote:
> [snip]
> >Wouldn't it be "safer" to define
> > something like |AST_O_CLOEXEC| (see also follow-up email about
> > |fcntl(...,*CLOEXEC*,...|&co.) instead ? IMO asking because 3rd-party
> > code may use <stdio.h> from libast... wouldn't it be bitten in some
> > form by this if it does a #ifdef O_CLOEXEC ... #else ... #endif
> > without being aware that libast headers already did the |#define
> > O_CLOEXEC 0| ?
> Next question is... how should we handle the zillions of
> |dup()|/|dup2()| calls followed by a |fcntl(fd,F_SETFD,FD_CLOEXEC);|?
> 1. Linux provides |dup3(fd, ..., O_CLOEXEC)| for that (I really do not
> like this)
> 2. Solaris 11 ([1]) provies |F_DUPFD_CLOEXEC| and |F_DUP2FD_CLOEXEC|:
> -- snip --
> fcntl(fildes, F_DUPFD_CLOEXEC, 0)
> fcntl(fildes, F_DUP2FD_CLOEXEC, fildes2)
> -- snip --
> My suggestion would be to abstract the Solaris |F_DUPFD_CLOEXEC| and
> |F_DUP2FD_CLOEXEC| into |sh_fcntl()| and add |SH_F_DUPFD_CLOEXEC| and
> |SH_F_DUP2FD_CLOEXEC|. On Solaris it would use |F_DUPFD_CLOEXEC| and
> |F_DUP2FD_CLOEXEC| and on Linux it would use |dup3(...,...,O_CLOEXEC)|
> and the normal |fcntl(fd,F_SETFD,FD_CLOEXEC);| as fall-back.
> Alternatively we should think about having libast (not libshell)
> wrappers around |open()| and |fcntl()| to handle this in libast...
> because libshell is unlikely the only consumer which suffers from the
> |**CLOEXEC**|-madness... ;-/
> [1]=the version on my laptop is too old, e.g. it doesn't have that yet
> ----
> Bye,
> Roland
> --
> __ . . __
> (o.\ \/ /.o) roland.ma...@nrubsig.org
> \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
> /O /==\ O\ TEL +49 641 3992797
> (;O/ \/ \O;)
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
