On Thu, Sep 18, 2014 at 13:03, Matti Karnaattu wrote: >>No, it just shouldn't be present when a conforming environment is >>requested. I've fixed <unistd.h.> to exclude it when you ask for an >>XSI conforming environment by building with _XOPEN_SOURCE defined. >>(Not sure what about <signal.h> you're referring to there...) > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html > > sigignore, sigset, SIG_POLL etc. > > There is plenty of obsolete stuff that is missing from OpenBSD. I assume > that missing of obsolete stuff is intentional. Can you clarify why > setpgrp should work otherwise?
Lots of obsolete things were never added, so it makes no sense to add them now. Other times, obsolete things should be removed because they clutter up the system and serve as a distraction from the correct interface. In this case, setpgrp as implemented on OpenBSD, with two arguments, is part of its BSD heritage. That doesn't mean it *must* stay, but without some analysis of how much existing software uses the function, it would be premature to remove it. Certainly, as you noticed, several programs in src used it. On the one hand, this is an indication it should be removed. People use it by accident when better, more standardized equivalents are available. On the other hand, a function that is still in use is not so easily deleted. The first question is always, what's less work? Adding obsolete functions is work; removing obsolete functions is work; leaving things alone is less work. The second question is what's the harm or benefit? In this case, setpgrp isn't any worse than setpgid. I think it's better to prefer standard interfaces, but setpgid doesn't offer better functionality, so there's no rush. Now, if you want to delete the function entirely, the best way to start that discussion would be to mail a diff. It will definitely gain more traction if you mention that for example you built everything in ports (takes a few days with a fast amd64 machine) and what the results of that experiment were.
