On Tue, Jul 19, 2011 at 16:16, Jie Zhang wrote: > On Tue, Jul 19, 2011 at 3:56 PM, Mike Frysinger 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.
i like to keep my options open > 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? i'm not stuck on the name. if you got it from binutils, then that's fine ... we can just import the fopen-same.h header from 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. > > 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. i just dont see the point. the string is evaluated at runtime, not compile time, so having a compile check against a specific version but running against a newer means the "e" flag isnt used when it could be. -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
