On Tue, Jul 19, 2011 at 3:56 PM, Mike Frysinger <[email protected]> wrote: > 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. > Then what's the badness if we use 'e' where it does not need it? If there is no or very little harmless badness, I would say let's force every call site use it. As for the name, we can use a different one. I just borrow the FOPEN_RB from Binutils. Maybe you will like FOPEN_R and FOPEN_W, or FOPEN_READ and FOPEN_WRITE?
>>>>>>> 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. > Ignoring unknown modes is required by the standard. To specify the version accurately I try to avoid adding a comment to explain why we write such code. I would like to add a check for uClibc's version number for its next release when your patch goes in. Jie ------------------------------------------------------------------------------ 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
