On Tue, Jul 19, 2011 at 2:09 PM, Mike Frysinger <[email protected]> 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"?
>>> 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. Regards, 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
