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".
>> 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.
-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
