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