Q: lseek returns long or int? (BSD 4.2)

[Henry Spencer]

> 	This is yet another piece of gratuitous brain-damage brought to
> 	you by the morons at Berkeley. ...
> 
> This is yet another gratuitous insult from someone who should have
> better things to do.

I do have better things to do, but sometimes I run across a Berkeley
atrocity that angers me beyond bearing.  I realize that speaking out
about it is largely a waste of time, since most Berkeleyphiles are
unreceptive to the suggestion that their beloved x.yBSD could possibly
have flaws, but I keep trying...

> I have no illusions that a lecture on the joys of
> being constructive would be other than wasted breath (or keystrokes),
> so I will merely point out that if there weren't any constructive
> people, we wouldn't have Unix at all.

Most true.  Berkeley (and USG) should try harder to be constructive.
So far their batting average, while not zero, is lower than it should be.

> It IS a bit ironic that this latest flap involves typing, since the
> Berkeley kernel is fairly obsessive in using typedefs to make types
> system-independent.  For instance, the lseek() call has its own
> typedef, 'off_t', for representing the type of a file offset; this is
> surely a greater nod to portability than merely stamping the value as
> 'long'.

Actually, my original note should have said "off_t"; point taken.  This
is not something Berkeley should be given any credit for, by the way,
since "off_t" and its relatives came from Bell Labs.  Berkeley should
be making more use of them than they do; the Berkeley people themselves
have been heard to say, in about so many words, "if your ints aren't 32
bits, forget about running 4.2BSD networking".

> At any rate the manual page chooses not to use this typedef,
> which is probably a mistake.  It is easily corrected...

No "probably" about it, alas.  Furthermore, the original Unix manual
page at least said "long", which is closer to being right than "int".
The change from the semi-portable "long" to the grossly-unportable "int"
is another case of an attitude that others have characterized as "all
the world's a VAX".

> Despite this trivial problem, lseek.2 and the 4.2 manual entries in
> general are definitely a vast improvement over the earlier Berkeley
> versions...

Berkeley is to be commended for adopting the more-detailed presentation
of return values and error conditions, although they didn't invent it.
(Just to be equitable about insulting everyone, I should add that this is
one of the very few USG inventions that is genuinely good and useful.)

> Efforts at improvement such as this should
> be commended, not sneered at.

Note the commendation in the previous paragraph.  The change of lseek's
return value to "int" is still sneer-worthy, regardless.

See also the more recent article from me which contains a semi-apology
for the harsh wording of the original note.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry