On Fri, 11 Apr 2014 22:10:05 -0700, Philip Guenther wrote: > On Sat, 12 Apr 2014, Ralph Siegler wrote: >> > Well, starting with r1.54 [0], stdlib.h never declares getopt(). >> > However, I think the conversation could continue in spite of that. >> > I would expect "motivation" to be aggregated cost in the form: >> > * a significant amount of patched ports; >> > * a significant amount of affected port prospects; or * a significant >> > amount of patched user programs. >> > You happen to mention the last item. Are there other users interested >> > in this facet of source compatibility? >> > >> > Also, are there other possible costs? >> > >> > [0] >> > http://www.openbsd.org/cgi-bin/cvsweb/src/include/stdlib.h.diff? >> r1=1.53;r2=1.54;f=h >> >> You are mistaken, it was just defined in different place/way in same >> file, even 18 years ago it is found in OpenBSD in stdlib.h (as well as >> in unistd.h): > > Gotcha: you don't want to update a program to meet 18+ year old > standards. > Is your beef with OpenBSD? Or is it with POSIX for specifying in 1995 > that getopt() only be declared in unistd.h and not stdlib.h? > > >> It doesn't hurt anything to provide this backward compatibility > > It makes the header more complex and annoying to maintain, just to > support programs that haven't been updated for 18+ years. That's a > negative.
Wrong, the stuff is already in the headers, no maintenance necessary. what would be HARD is to remove all the non-2008.1, and fix the breakages it would cause, then modify and add calls for the missing functionality, again without breaking anything. It would be much fun and entertainment to watch such an endeavor, I'll pop popcorn for that space opera series. > > You may find it interesting to see how long a source tree might work > without changes, but that's not of interest to OpenBSD. It's probably > of *negative* interest of OpenBSD, as adding "#include <unistd.h>" is a > trivial cost to the person compiling said unmaintained program, and such > a program probably hasn't been scrutinized for the various sins of the > past like buffer and string handling, TOCTOU violations, etc. History > is neat to study, but living in it sucks. All BSD have much history in them, even with the fantastic evolution, fixes and improvements. > > > Philip
