ron@celerity.UUCP (03/16/84)
[] Being one of your average searchers-after-truth, I've been ear- nestly perusing the pages of my BSD 4.2 documentation, register- ing some amazement over "how things have changed", and in most cases admiring some of the new bells and whistles and trying to imagine what I will do with them all. This brings me to the sub- ject of this tome and the reason for troubling you all with my chatter. Allowing for the elegance of the new signaling mechanism, what on earth can you do with the alternate signal stack? I have looked at the documentation, examined the listings and while I can understand how they are implemented, I, as yet, haven't been able to understand why I need them. In spite of the well earned reputation for restraint and bashful- ness that the participants in this news group have, I have decid- ed to throw caution to the wind, admit my ignorance and be as- sailed for my cloddish ignorance. Seriously, I'll probably be surprised at the simplicity of the answer, but I am floundering on this one. The documentation to which I have alluded is sections 2 and 3 of the BSD 4.2 UNIX Pro- grammers manual. If there are other documents I have overlooked, or if anyone simply has the answer, I would appreciate a response. Of course, many thanks in advance, Ron McDaniels Celerity Computing Inc. 9692 Summer Evening Drive San Diego, Ca 92126 (619) 566-0416 ucbvax!sdcsvax!celerity!ron
wls@astrovax.UUCP (William L. Sebok) (03/16/84)
> Allowing for the elegance of the new signaling mechanism, what on > earth can you do with the alternate signal stack? I have looked > at the documentation, examined the listings and while I can > understand how they are implemented, I, as yet, haven't been able > to understand why I need them. > Ron McDaniels There is one thing for which I plan to use the signal stack mechanism. One of the conditions one might want to handle within a program is stack overflow. Ordinarily this condition causes a Segmentation violation. However, with a stack invalid because of overflow it is impossible to catch the segmention violation signal. I am including such a signal stack in the BSD 4.2 incarnation of my Forth compiler for the Vax. This compiler wants to catch all (or almost all) signals, returning the appropriate error message, clearing stacks and going back to the main command interpreter. It thus acts as a self-contained programming environment. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,burl,cbosgd,decvax,ihnp4,kpno,princeton,vax135}!astrovax!wls
kvm@basser.SUN (Karlos Mauvtaque) (03/18/84)
I think the answer to the "why" is because there was nothing better to do at the time. This also explains arbitrary changes like those to awk and to _filbuf and so on. This change seems particularly absurd, who in their right mind would use "features" as amazingly unportable as this? I don't even want to gethostname(), as convenient as it may seem. I want my programs to work on lots of UNIX* systems. Or do we think that 4.2 will become a new standard?
kre@mulga.SUN (Robert Elz) (03/18/84)
One answer as to why has already appeared on the net. There are times when such things (exotic as they may seem) really are essential. There were no intentional changes to awk in 4.2 - there was a bug fix that went wrong. Bill Shannon has already posted a fix to that bug. The _filbuf change was a bug fix. I suspect (but haven't investigated) that its the same in system V. My reason for suspecting that, is that in the Kernighan/Pike unix book they use 'read(2)' in their 'tail -f' program (sorry I've forgotten what they called that, I know it most definitely wasn't 'tail -f') - their rationale is that once you've had EOF from stdio, you will continue to get EOF from future reads. That's exactly the way it is in 4.2 - which wasn't available at the time Kernighan/Pike were writing their book. (Maybe its 5.2, or even 5.3 that has this fixed at Bell though) Finally, I don't think that it really needs stating, that no-one should use any of the new low level stuff in 4.2 unless you really need to. Continue doing things the old way, using the library routines. Obviously portability is important. However, its nice to know, that on the odd occasion when the old way simply isn't good enough, that there's a new way, there ready for you to use - you don't have to wait till someone else thinks of it or start hacking yourself. Robert Elz
kvm@basser.SUN (Karlos Mauvtaque) (03/18/84)
I don't agree about the joys of discovering a use for some 4.2 add. If I needed something that only 4.2 has I would have to write it myself so that my program would be portable. It's little consolation for my clients to be told that it would be all right if they had 4.2. I also don't agree that changing undocumented behaviour of a library call is a "bug fix". (Incidently I tried the _filbuf thing on a local Sys V site and things are still untouched, sdb still works without changing your eof character!). Here is an extract from an item of mail that I received following an earlier 4.2 flame (sorry Ed): "4.2bsd may not be a total disaster, but it does a good job of emulating one. Our system guru says he likes the kernel better than system 5's. I wouldn't know -- I'm just a poor, bruised user."