On Mon, Jun 18, 2012 at 9:05 PM, Glenn Fowler <[email protected]> wrote:
>> Attached (as "astopen20120612_o_cloexec_patch20120616_001.diff") is a
>> patch which replaces some of the |open()|+|fcntl(...,F_CLOEXEC)|
>> sequences in ast-open.2012-06-12 with |open(...,O_CLOEXEC)| if the
>> |O_CLOEXEC| CPP symbol is available on that platform (I've tested with
>> Solaris 11 and SuSE 12.1).
>
>> IMO the patch is simple&&safe enough for ksh93u+, too.
>
> thanks
No problem... the main idea behind this was to reduce the size of code
a bit and get minor performance improvements (e.g. fewer number of
syscalls).
> dgk and I coordinated on your suggestion
> the iffe-generated <ast_fcntl.h> will do this if O_CLOEXEC is not defined
> #define O_CLOEXEC 0
> just like we did with { O_BINARY O_TEXT }
> this will cut down on #ifdefs
Uhhh... is this wise ? How do you test whether |O_CLOEXEC| is really
supported by a platform or not ? Wouldn't it be "safer" to define
something like |AST_O_CLOEXEC| (see also follow-up email about
|fcntl(...,*CLOEXEC*,...|&co.) instead ? IMO asking because 3rd-party
code may use <stdio.h> from libast... wouldn't it be bitten in some
form by this if it does a #ifdef O_CLOEXEC ... #else ... #endif
without being aware that libast headers already did the |#define
O_CLOEXEC 0| ?
> we also followed gnu's lead and added the 'e' flag to sfopen() for O_CLOEXEC
Thanks...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers
