der Mouse <mouse@collatz.mcrcim.mcgill.edu> writes:
> 
> >>> 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>...
> > 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.
 [...]
> 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

I was waiting to see if someone else took the same side as myself in this.
I think it comes down to whether NetBSD would rather claim "It's easy to get
software and build it for NetBSD", or "NetBSD is FULLY POSIX complient"

Since I'm from the 'I did Unix before Unix was cool' crowd, standards like
POSIX don't mean so much to me. They're important, but not crucial. In cases
like this I'd prefer to see an install-time option, perhaps something like
-DSTRICT_POSIX which would prune the non-conformant entries from the other
header files.

This makes it easier for me to pitch NetBSD to friends who want a Unix for
home, since I can promote the method which suits them best. It does mean that
there might be two flavors of NetBSD out there, but as long as STRICT_POSIX
headers are always a subset of the non-strict headers, and program built
to work for STRICT will with without it too.

							David Maxwell
							david@web.net

david