On Mon, Jul 18, 2011 at 11:34 PM, Mike Frysinger <[email protected]> wrote: > On Monday, July 18, 2011 21:35:15 Jie Zhang wrote: >> It seems Windows doesn't like 'e' for fopen. > > blah. what is the failure mode exactly ? mingw only provides a stub entry > point which jumps to the real fopen implementation in windows itself, so i > dont have code to look at ... > I didn't check the failure mode. With 'e', fopen failed. Without 'e', fopen succeeded.
>> 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. > rather than __GLIBC__ though, let's use __linux__. It's a GLIBC thing, not only for Linux. 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
