Hey Steven! On Thu, 2015-05-28 at 22:22:06 +0100, Steven Chamberlain wrote: > Guillem Jover wrote: > > In any case here's the patches I've prepared to send upstream. Only > > build tested, though. > > Thanks for this.
Thank you for the review and testing. > Patch 1 would have been a good workaround for Debian sid, if Andreas > had accepted it, but I don't think it should be permanent or go > upstream. I don't like to special-case kfreebsd in code except in > places we really have to, and it's actually wrong for FreeBSD <= 9 > (though they're not a user of util-linux). This allows using the value even if the build system does not know about it, either because we are building on an old system or because the libc is not up-to-date. For FreeBSD <= 9, it should be handled by the run-time checks, so it should fallback to the other codepath. I can reorder the patches so that this makse more sense. In any case I think I'll just send it upstream and let them decide if they want to carry it or not. Or did you mean something else with the comment that it is wrong (I would not expect the value to have been reused for example)? > Patches 2 and 3 look good to go upstream as they benefit other systems > not having fcntl.h or F_DUPFD_CLOEXEC (and older kfreebsd). Sure. > They make patch 1 unnecessary? Well, partially I guess, if the library is being used by threaded applications that fork, then they might end up leaking if the library got built on an old system, but is run on a newer one. > I tested your fallback code and it is working (duplicates the fd and > sets FD_CLOEXEC). Without F_DUPFD_CLOEXEC I get a compiler warning > about unused lowfd, but that doesn't really matter here. Cool, thanks. Sending them upstream now. Regards, Guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
