[git commit master] CLOEXEC: use open(CLOEXEC) if exist; do not check fcntl(FD_CLOEXEC) failure

Denys Vlasenko vda.linux at googlemail.com
Sun Sep 6 10:07:04 UTC 2009


On Sunday 06 September 2009 08:18, Mike Frysinger wrote:
> On Saturday 05 September 2009 18:05:32 Denys Vlasenko wrote:
> > On Saturday 05 September 2009 23:55, Mike Frysinger wrote:
> > > On Saturday 05 September 2009 17:55:26 Denys Vlasenko wrote:
> > > > >On Saturday 05 September 2009 16:04:36 Denys Vlasenko wrote:
> > > > >> +#ifndef O_CLOEXEC
> > > > >> +# define O_CLOEXEC 0
> > > > >> +#endif
> > > > >
> > > > >it should be defined by the C library headers.  if it isnt, then the
> > > > > port needs updating and the build should fail.  so please drop this
> > > > > cruft.
> > > >
> > > > You probably was thinking about FD_CLOEXEC. :)
> > > >
> > > > Yes, FD_CLOEXEC must exist.
> > > >
> > > > O_CLOEXEC is a new, Linux specific open() flag.
> > > > And currently it is not yet defined, since there are many
> > > > old kernels in the wild which won't understand that.
> > >
> > > no, i'm thinking of O_CLOEXEC.  i know what the flag is for, and it
> > > should be defined in bits/fcntl.h for every port.
> >
> > Currently, it is not defined on any arch:
> 
> then you fix/update the arches instead of ignoring the problem and sprinkling 
> cruft everywhere

Defining O_CLOEXEC does not necessarily make it work.
Kernel should be new enough to understand it.

If the program will be run on an old kernel, open() with O_CLOEXEC
will not work as expected.

In this case, "old kernel" means < 2.6.23. Do you propose
to make it so that uClibc does not work properly for anyone
who is not on kernel >= 2.6.23?
--
vda



More information about the uClibc mailing list