On Tue, Jul 19, 2011 at 4:54 PM, Mike Frysinger <[email protected]> wrote: > 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. > I thought about this. But I'm wondering if we really need those header files. I don't know what system will reject "b" and if they are still in use nowadays. So I think it will be safe to just always append "b" for now until some complains. Actually I suspect it will happen.
>>>>>>>>> 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. > Good point. I work out a new patch. Jie ------------------------------------------------------------------------------ 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ _______________________________________________ UrJTAG-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/urjtag-development
