On Tue, Jul 19, 2011 at 15:34, Jie Zhang wrote: > On Tue, Jul 19, 2011 at 3:07 PM, Mike Frysinger wrote: >> i dont want to force all call sites to use "e" all the time. each >> instance should be reviewed before explicitly adding the "e" flag. > > In what case should we use 'e', in what case should we not use 'e'?
it all revolves around forking. for the most part we will want to use "e", but i dont want to blanket force everyone to it as your proposed changes would have to be undone in order to not use it. >>>>>> rather than __GLIBC__ though, let's use __linux__. >>>>> >>>>> It's a GLIBC thing, not only for Linux. >>>> >>>> O_CLOEXEC is linux-specific. every C library running under Linux >>>> should be picking up "e" support. >>> >>> But 'e', which we are using, is a GLIBC extension. >> >> it started out as a glibc extension, but other C libraries are >> supporting it as well. like uClibc. > > I just took a look at uClibc. Maybe I missed something, but I didn't > see uClibc's fopen support 'e' mode. i thought it was, but if not, i'll push a commit to uClibc to add it :) ignoring that, uClibc itself defines __GLIBC__ already, and the version checks are unnecessary as glibc/uClibc skip unknown modes. -mike ------------------------------------------------------------------------------ Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ _______________________________________________ UrJTAG-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/urjtag-development
