aug@cybvax0.UUCP (Alan Green) (09/11/84)
[ What is a blank line eater? Does it eat the first line? ] Documentation (BSD 4.2 UNIX) for lseek(2) under section 'SYNOPSIS': > pos = lseek(d, offset, whence) > int pos; > int d, offset, whence; Documentation (BSD 4.2 UNIX) for fseek(3S) under section 'SYNOPSIS': > fseek(stream, offset, ptrname) > FILE *stream; > long offset; > > long ftell(stream) > FILE *stream; Does lseek return a long or an int, and is the argument offset a long or an 'int'. (On other machines it returns a long) I realize a long and an int are the same on a VAX (the machine I use): but, lint considers them different. Does any know of a machine where a long and an int are different AND lseek (or fseek) returns an int? Please, reply via Mail Thanks in advance, Alan Green aug!cybvax0!mit-eddie!??? (I don't know my full address, how do I figure it out?)
henry@utzoo.UUCP (Henry Spencer) (09/17/84)
> Does lseek return a long or an int, and is the argument offset a long > or an 'int'. (On other machines it returns a long) This is yet another piece of gratuitous brain-damage brought to you by the morons at Berkeley. The returned value from lseek is of type long on all real UNIX systems. There are a number of places in 4.2 where the code has a wired-in assumption that the machine has 32 bits (not 16, not 64, not anything else either) and that long == int. -- "4.2BSD does everything UNIX does, only differently." Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
donn@utah-cs.UUCP (Donn Seeley) (09/23/84)
From henry@utzoo.UUCP (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 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. 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'. At any rate the manual page chooses not to use this typedef, which is probably a mistake. It is easily corrected if one spends a minute or two looking at the situation (in man2/lseek.2): ------------------------------------------------------------------------ *** /tmp/,RCSt1023012 Sun Sep 23 05:17:09 1984 --- lseek.2 Sun Sep 23 04:56:28 1984 *************** *** 5,11 .SH SYNOPSIS .nf .ft B ! .ta 1.25i 1.6i #define L_SET 0 /* set the seek pointer */ #define L_INCR 1 /* increment the seek pointer */ #define L_XTND 2 /* extend the file size */ --- 5,16 ----- .SH SYNOPSIS .nf .ft B ! #include <sys/types.h> ! #include <sys/file.h> ! .PP ! .nf ! .ft B ! .ta 1.25i 1.6i 1.8i #define L_SET 0 /* set the seek pointer */ #define L_INCR 1 /* increment the seek pointer */ #define L_XTND 2 /* extend the file size */ *************** *** 12,19 .PP .ft B pos = lseek(d, offset, whence) ! int pos; ! int d, offset, whence; .fi .ft R .SH DESCRIPTION --- 17,26 ----- .PP .ft B pos = lseek(d, offset, whence) ! off_t pos; ! int d; ! off_t offset; ! int whence; .fi .ft R .SH DESCRIPTION ------------------------------------------------------------------------ Despite this trivial problem, lseek.2 and the 4.2 manual entries in general are definitely a vast improvement over the earlier Berkeley versions, which usually failed to enumerate the errors which a call could return and sometimes even omitted the return values. Many things which used to be magic cookies in previous versions of the system, such as lseek()'s 'whence', are now clearly parameterized (perhaps influenced by USG Unixes). Efforts at improvement such as this should be commended, not sneered at. Waiting for a return to civility (but not holding my breath), Donn Seeley University of Utah CS Dept donn@utah-cs.arpa 40 46' 6"N 111 50' 34"W (801) 581-5668 decvax!utah-cs!donn
henry@utzoo.UUCP (Henry Spencer) (09/24/84)
A number of people have taken me to task for calling the Berkeley
people "morons". (Probably more than I realize; news feed to Eastern
Canada has been extremely erratic for the last week or two and the
comments I've been getting have been the ones sent by private mail.)
On reflection, they are half-right; a partial apology and clarification
is in order. I have considerable respect for certain specific Berkeley
and ex-Berkeley people, and apologize for hitting them with my blanket
condemnation. Bill Joy and Sam Leffler come to mind; there are others.
This isn't a complete retraction, because changing the return type of
lseek remains an imbecilic act. Specific Berkeley people have plenty
of ability and brains; it's the collective result that reeks. Berkeley
as a whole cannot seem to leave anything alone, even when it works fine
and shouldn't be messed with. I don't deny that they have done many
valuable and useful things; the problem is that they've done many stupid
and harmful things as well, and some of them don't seem to be able to
tell the difference.
Please don't flame at me about the wonders of Berklix until you've fixed
your definition of lseek() to be compatible with UNIX.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryhenry@utzoo.UUCP (Henry Spencer) (09/26/84)
> 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
acheng@uiucdcs.UUCP (09/27/84)
>>This is yet another piece of gratuitous brain-damage brought to you by >>the morons at Berkeley... If the above was intended to be a joke, then said so. If it was what the author considered the Berkeley programmers were, it was a poor judgement. An institute without mega-bucks paid programmers, can provide such a wide spread system, is very amazing. "Ask not what your Unix can do for you;" "Ask what you can do for your Unix!" (Hope JFK don't mind my modification.) acheng%uiuc%csnet-relay ihnp4!uiucdcs!acheng
henry@utzoo.UUCP (Henry Spencer) (09/29/84)
> >>This is yet another piece of gratuitous brain-damage brought to you by > >>the morons at Berkeley... > > If the above was intended to be a joke, then said so. If it was what > the author considered the Berkeley programmers were, it was a poor > judgement. I wish it was a joke. It's not. > An institute without mega-bucks paid programmers, can provide > such a wide spread system, is very amazing. If we bought 4.2BSD from a commercial outfit, with mega-bucks paid programmers, we'd return it with an angry demand for a full refund plus an apology. Some of the bugs in 4.2 are shameful, to put it mildly. The folks here who did most of our 4.1->4.2 conversion work have been heard to say "if we had to do it all over again, we wouldn't". I agree it's amazing that an institute without mega-bucks paid programmers could introduce so many bugs into so much software that used to work. > "Ask not what your Unix can do for you;" > "Ask what you can do for your Unix!" You are in a large rectangular room. There is a 4.2BSD tape lying on the floor. > get Unix I see no Unix here. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
elman@sdamos.UUCP (Jeff Elman) (10/02/84)
>>From: henry@utzoo.UUCP (Henry Spencer) >>Newsgroups: net.unix-wizards >>Subject: Re: Q: lseek returns long or int? (BSD 4 >>This is yet another piece of gratuitous brain-damage brought to you by >>the morons at Berkeley... So tell me, which version of UNIX are you using now? Jeff Elman Phonetics Lab, Dept. of Linguistics, C-008; U.C. San Diego UUCP: ...ucbvax!sdcsvax!sdamos!elman ARPAnet: elman@nprdc.ARPA
henry@utzoo.UUCP (Henry Spencer) (10/03/84)
> >>This is yet another piece of gratuitous brain-damage brought to you by > >>the morons at Berkeley... > >So tell me, which version of UNIX are you using now? Thank you for asking that, you've made my day. I'm using the last true UNIX ever released: V7. Not a Berklix mislabeled "UNIX Version 7", mind you, but a real, honest Bell V7. Since nobody has yet found the cash to buy us something better, utzoo is an 11/44. I'm quite aware that this has its bad points -- 16-bit address spaces are no fun any more -- but it does mean that I can run true UNIX. I don't know what I'd do if they suddenly gave us a VAX... maybe go wail on Research's doorstep until they slip me a V8 tape just to get rid of me... :-)))) -- "7 > 4.2" Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
clyde@ut-ngp.UUCP (Clyde W. Hoover) (10/03/84)
> From: henry@utzoo.UUCP (Henry Spencer) > > If we bought 4.2BSD from a commercial outfit, with mega-bucks paid > programmers, we'd return it with an angry demand for a full refund > plus an apology. Some of the bugs in 4.2 are shameful, to put it > mildly. The folks here who did most of our 4.1->4.2 conversion work > have been heard to say "if we had to do it all over again, we wouldn't". > > I agree it's amazing that an institute without mega-bucks paid programmers > could introduce so many bugs into so much software that used to work. Sorry to hear your 4.2 conversion was so in the weeds. Of all the UNIX conversions and software porting I've done (V6 to PWB, PWB to V7, V7 to 2.8BSD, 2.8BSD to 4.2BSD, 2.8BSD to 2.9BSD), that from 2.8BSD to 4.2BSD was the LEAST painful. Nobody (except for maybe Bill Joy) claims 4.2BSD to be PERFECT. What do you EXPECT from a RESEARCH environment, a polished product? By Grid, you must not have ever dealt with V6 - talk about rough edges! I challange you to essentially REWRITE UNIX and NOT introduce bugs. 4.2 is the first extensive rewrite of UNIX for DEC processors (Bell hasn't really rewritten V7, just glommed on top of it), so I can say I'm suprised. I get tired of people slamming 4.2 - it's not perfect, but I'll take it, bugs and all, over all the other versions floating around. -- Shouter-To-Dead-Parrots @ Univ. of Texas Computation Center; Austin, Texas "Let's show this prehistoric bitch how we do things downtown" clyde@ut-ngp.ARPA, clyde@ut-sally.ARPA ...!ihnp4!ut-ngp!clyde, ...!allegra!ut-ngp!clyde
henry@utzoo.UUCP (Henry Spencer) (10/04/84)
> Nobody (except for maybe Bill Joy) claims 4.2BSD to be PERFECT. I've heard claims that sounded much like this from various Berkeleyphiles. Maybe not perfect, but "it's so much better than everything else". Nonsense. Somewhat better, *maybe*, but hardly Nirvana. > What do you > EXPECT from a RESEARCH environment, a polished product? By Grid, you must > not have ever dealt with V6 - talk about rough edges! An ARPA contract to improve Unix doesn't sound to me like research, it sounds like software production. (Yes, I realize that Berkeley got its fingers burned and has sworn off this sort of thing now.) As for V6... He who never had to use V5 should not complain about V6. I worked with V6 quite a bit, and didn't find it all *that* bad. (Actually, V5 wasn't all that bad either, but V6 was quite definitely an improvement.) > I challange you to > essentially REWRITE UNIX and NOT introduce bugs. 4.2 is the first extensive > rewrite of UNIX for DEC processors ... so I can say I'm suprised. What is not obvious is why Unix *needed* rewriting for Dec processors. Oh, some parts of it, certainly, but most of it worked just fine as it was. My biggest objection to x.yBSD is not the way they've fixed things that needed fixing, but the way they've "fixed" things that *didn't* need it. Of course new work introduces bugs; that's why people with sense keep their hands *off* software that works fine and doesn't need fixing. But not Berkeley... > I get tired of people slamming 4.2 - it's not perfect, but I'll take it, > bugs and all, over all the other versions floating around. I'll take my V7, thanks. At least it didn't dump core all over my root filesystem the first time I booted it. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
brad@bradley.UUCP (10/08/84)
>/**** bradley:net.unix-wizar / utzoo!henry / 6:25 pm Oct 4, 1984 ****/ >> >>This is yet another piece of gratuitous brain-damage brought to you by >> >>the morons at Berkeley... >> >>So tell me, which version of UNIX are you using now? > >Thank you for asking that, you've made my day. I'm using the last true >UNIX ever released: V7. Not a Berklix mislabeled "UNIX Version 7", >mind you, but a real, honest Bell V7. Since nobody has yet found the >cash to buy us something better, utzoo is an 11/44. I'm quite aware that >this has its bad points -- 16-bit address spaces are no fun any more -- >but it does mean that I can run true UNIX. I don't know what I'd do if >they suddenly gave us a VAX... maybe go wail on Research's doorstep until >they slip me a V8 tape just to get rid of me... :-)))) >-- I also ran at one time 'Honest Bell V7', but am now running 2.9BSD, and find that on my 11/44 it runs at least 50% faster, and all my 'Honest Bell V7' programs run plus I have all the stuff from 2.9, like overlays, job control. :-) "2.9 * 50% > 7" Bradley Smith Text Processing/Bradley University {ihnp4,cepu,uiucdcs,noao}!bradley!brad
henry@utzoo.UUCP (Henry Spencer) (10/13/84)
> I also ran at one time 'Honest Bell V7', but am now running 2.9BSD, and find > that on my 11/44 it runs at least 50% faster, and all my 'Honest Bell V7' > programs run plus I have all the stuff from 2.9, like overlays, job control. Yes, 2.9's performance is unquestionably better. What a pity you have to accept all that other trash to get it. But then, nobody's ever seriously worked on performance improvement for Honest Bell V7. Wish someone would... [Watch this space.] -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry