>>[...]
>> On the other hand, I'm feeling much more crotchety this morning, and
>> think maybe we should remove the lseek() prototype from <sys/types.h>
>> to force old/broken software to be updated.
>
>I'm of two minds on this.  (Right, just what everybody wanted: one more
>person's two cents. :-P)
>[...]
>But as an application author, I hate this sort of thing.  Having to
>play "where did this system hide the prototype for foo()" is one of the
>biggest parts of the reason I don't port my stuff to more systems.
>Some systems don't even _have_ <unistd.h>, and the ones that do vary
>widely on what goes in it.
>
>Decreeing that <unistd.h> is the One True Place to get the lseek()
>prototype irritates me; it comes across as saying "we don't care that
>your code used the correct way at the time you wrote it, we will now
>decree, by fiat, that it is broken and needs fixing unless you include
>this new .h file".  It makes me feel as though next month you're liable
>to create <syscalls/lseek.h> and <syscalls/read.h> and such, one per
>syscall, and declare that any code not using them is broken.

I don't think it's _quite_ as bad as that :-)

The main problem was that in the old days, there were no standards, so it was
near impossible to predict where function prototypes ended up on a particular
system.

Nowadays, I get the feeling that the standards are pretty much settling down;
if POSIX says that lseek() should be declared in unistd.h, then I think it's
a safe bet that it will be that way for a long time.  Most of the vendors are
moving in that direction, and newer operating systems seem to have everything
in the right places.  Admittedly, there has been a lot of shuffling around
of header files, but my understanding is that the whole intent has been to
track POSIX, and most of the weird shuffling doesn't require any extra effort
on the programmer's part.  I don't think anyone's saying you should add these
weirdo include files that don't exist anywhere else - they _do_ exist in
most up-to-date operating systems.  Whether or not we want to support code
that was developed on legacy systems (and unfortunately SunOS is fast becoming
a legacy system :-( ) is perhaps the real question.  I see where you're
coming from, but you're going to have to face this issue eventually when you
try porting your code to newer OS's.  At the last place I worked, my boss spent
a couple of days removing tons of "char *malloc()" declarations from our
software package when we did the port to the Alpha.

As for the original question, I'd like to point out a side issue that I have
noticed over time.  There is among certain people a general perception that
the *BSD's are hard to port to.  Now this definately isn't my opinion, but I'm
used to the more common errors (like deleting bogus declarations of sys_error,
adding a #include <unistd.h>, etc etc) whereas new users to *BSD aren't, so
this perception has some basis in fact.

Adding a prototype for truncate() to sys/types.h might make it easier for
newbie users to port some of their favorite software packages, and I think
that would be a good thing.  I also can't see how it would hurt (other than
make the include files slightly less maintainable).

The arguments against this are obvious, and I'm evenly split on this issue.
But it's worth thinking about, at least.

--Ken