On Tue, Jul 19, 2011 at 3:07 PM, Mike Frysinger <[email protected]> wrote: > On Tue, Jul 19, 2011 at 14:58, Jie Zhang wrote: >> On Tue, Jul 19, 2011 at 2:09 PM, Mike Frysinger wrote: >>> On Tue, Jul 19, 2011 at 01:00, Jie Zhang wrote: >>>> On Mon, Jul 18, 2011 at 11:34 PM, Mike Frysinger wrote: >>>>> On Monday, July 18, 2011 21:35:15 Jie Zhang wrote: >>>>>> So I came up this patch to solve this issue. You are more familiar with >>>>>> fopen. Do you think this patch is a good idea? >>>>> >>>>> i think i'd rather have it be a define by itself. something like >>>>> FOPEN_CLOEXEC being defined to "e". that way we dont have to create new >>>>> defines for the various append modes as well. >>>> >>>> I don't understand this. If we use a macro for each extension mode, we >>>> surely have to create new defines for each such mode, and we need to >>>> modify each call site of fopen to append the macro. >>> >>> the issue is that i dont want to force every call site to use "e". >>> only when we've looked at it and it makes sense, and the resulting >>> code is clear in what flags it is using. when i look at fopen("foo", >>> FOPEN_RB), i think "ok, it's using rb". it isnt clear that it's also >>> using "e". fopen("foo", "rb" FOPEN_MODE_E) is clear that it's using >>> "rbe". >> >> What do you mean by "looked at it and it makes sense"? > > 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'?
>>>>> 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. 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
