>>> I noticed that our <sys/types.h> header provides a prototype for
>>> lseek().  [Should we add {,f}truncate()?]
>> I'd rather see the prototype moved to <unistd.h>...
> truncate(), ftruncate(), and lseek() have prototypes in <unistd.h>; I
> was asking if we should add truncate() and ftruncate() prototypes to
> <sys/types.h> (lseek is already there) to make it more likely that
> programs using those functions without including <unistd.h> will
> still function correctly.

> 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)

In general, I'm with jtc on this last point: if software is broken, I
prefer to break it _badly_, so that it gets fixed ASAP.

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.

Of course, I know this maze actually comes from trying to track too
many standards at once, and that it really isn't as arbitrary as the
previous paragraph makes it sound.  But as someone who just wants to
write code and make it work, without spending half my life chasing down
standards (and half my money buying copies of them), that's about what
it feels like - I never know when some new standard will suddenly
provoke moving a bunch of stuff around from one include file to
another.  And the best way of finding out, say, what include file
prototypes getdomainname(), is
"find /usr/include -name \*.h -print | xargs mcgrep -H getdomainname".

I've just reread the above and it sounds bitter and cynical, almost
vindictive.  I've decided not to rewrite it, even though I do not
actually feel that strongly about the issue, because I don't think a
rewrite would express those things nearly as well.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu