dup3 syscall - atomic set O_CLOEXEC with dup2

[Kostik Belousov]

On Fri, Jan 20, 2012 at 07:09:43PM -0500, Eitan Adler wrote:
> 2012/1/20 Kostik Belousov <kostikbel at gmail.com>:
> > On Fri, Jan 20, 2012 at 06:25:42PM -0500, Eitan Adler wrote:
> >> I figure this isn't wanted?
> > You silently ignored part of the notes that were provided,
> 
> I fixed the style violations you pointed out and removed
> _SYS_SYSPROTO_H_ and friends.  Which else was there? If I missed
> something I'm sorry.
Manual definition of the struct dup3_args is not needed at all. I
very much doubt that patch can compile since there is now
duplicate definition of the structure.

There is still stray return (0);.

Another reason for the patch to not compile is compat32
syscalls.master changes.

The suggestion of 'it is better to test the presence of O_CLOEXEC
with & instead of comparing with ==, to allow for ease
introduction of future dup3 flags, if any.' is silently ignored.

Probably new: style requires putting opening '{' for the function
body at new line. There shall be no space between '*' and arg name.

New: symbols in the version map shall be ordered alphabetically.

> 
> > and keep
> > complete silence on the primary question about non-standard
> 
> I thought I answered that already but I'll try again: I believe the
> functionality is useful to developers even if it is non-standard. In
> addition if it is standardized at some point in the future it is
> unlikely to have different semantics than the ones implemented.
It very well may have different details that would force us to
draw two versions forever.

> 
> > and fractional nature of the patch.
> 
> How so? I am not including the generated parts in the patch. Should I?
The implementation is partial because dup3() is only part of the
Linux and glibc efforts to allow app authors to handle the race
between obtaining the file descriptor and setting cloexec flag. I
already pointed you to SOCK_CLOEXEC for example. This is ignored
as well.

dup3() alone is almost useless.
> 
> > I see no reason to retype my previous response.
> 
> -- 
> Eitan Adler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20120121/948cc62e/attachment.pgp