taylor@hplabsz.HPL.HP.COM (Dave Taylor) (08/12/87)
Harry Skelton (guardian@laidback.UUCP) suggested in news.admin the following set of guidelines for posting sources to the network. Since it's so amazingly inane I thought I'd actually spend some time to refute what he suggests. If you don't agree, well... Life is like that some times, I guess. [I've numbered the original points for ease of reference] >1. Simple use of structures or multi-array useage. I don't see what the point of this is - part of the point of having a rich set of data structures available within C is to allow people to create data structures that are appropriate for the task they are attempting to solve - reference the book "Fundamentals of Data Structures" if you'd like more information on why simple structures and/or multi-array usage isn't enough. >2. No externs or unions (if at all possible). As with gotos, externs and unions have their place in complex programming tasks. For one example, try getting the value of "errno" without previously defining it as an "extern int" in your program... Unions might be more reasonable to try to limit, however, since they really are susceptible to different machine architectures. >3. straight use of variables - no pointer playing. Again, what do you mean by 'pointer playing'? There are certain times when you need to be able to hand pointers to pointers to structures or whatever else might be needed. >4. NO TYPEDEFS - some machines will croak on this. (Hi SCO Xenix) Tough luck. Typedefs are part of the standard K&R C as defined in many places (including the K&R `The C Programming Language' book). If some compilers can't handle it, then tough luck. (I'll expand on this topic in a second...) >5. Small moduals - better a few little programs doing something than one > big one. That certainly fits in with the Unix philosophy. I agree. >6. LOTS OF COMMENTS - nuff said. Better yet - lots of *meaningful* comments. I've seen too much code floating around (esp. from AT&T and UCB) that has either no comments, or comments that are just stupid and a waste of space. Neither has any purpose or is helpful... >7. Smart makefiles or config programs - to find out what the user does > not know (see rn) Sounds reasonable - how about a tool for helping people create these funky Makefiles? >8. No BSD or Sys V dependent stuff - must be able to compile 'clean' on > any system. This one is obviously a joke. While it is unfortunate that there is such a difference between BSD and SYSV, there are a number of packages floating around that more-or-less allow you to run the code written for one machine on the other ('cept for job control on SYSV). The problem with this is that the person who writes the original code should be thanked for making it available, not forced into digging up other machines and testing the code on them before releasing it. THAT is the job of some volunteer who finds the program sufficiently interesting that they are willing to put the time in to port it and then post the diffs (or what- ever) to the net... >9. vars must have legable names - no pt.dk.i2.dv - put.disk.in2.drive A fine sentiment, but you have quite a weight of programmers that would disagree in actions -- consider the examples in the book ``Algrithms + Data Structures = Programs'' by Nikolas Wirth - they are neat little programs, but the naming conventions and formatting of the listings is about as bad as in any book I've ever seen. (there are, of course, constraints w.r.t. page space, but still...). The problem is that most programmers learn how to program in environments where identifiers are only 6 or 8 characters significant and so they learn that instead of using variables like "ready_to_update" they use "update" or "u" or "rtu" or something equally cryptic. (of course it should also be pointed out that many lint's, even on machines with "arbitrary length identifiers" still get unhappy if two variables aren't unique in the first 8 or 10 characters...) >10. no memory playing - no mallocs, allocs, callocs or whatever - if it can't be handled by the compiler then don't post it. This one I strongly disagree with. If you look at the Elm System sources you'll find that I include and use my own "palloc" permanent-alloc routine. The reason I do this is because the program is pretty memory intensive and I start up by allocating about 75 strings that are never free'd again. So doing it via my own routine allows me to avoid the major 75-entry traversal for each subsequent call to malloc/free that I make. It is a *noticable* improvement on slower machines. (I suspect that the reason you put this in was because you don't under- stand how malloc works and how a typical large software system uses it) >11. use standard includes - stdio.h curses.h termcap.h ctype.h ect.... Standard based on what? Posix? Xopen? SVID? BSD4.2? This is unfortunately pretty useless as a guideline. >12. include complete documents.... Sounds reasonable, but the majority of people who write these large software systems that are released to the network can't write a clean set of documents if their lives depended on it. There ain't no way around this, and I don't think that crummy documentation is much better than none at all (or a man page, as a minimum)... ---------- In general, the problem with guidelines of this nature is that they ignore some of the fundamental problems rather than addressing them. I see the main problems we're talking about here as a combination of the lack of viable standards already implemented in the Unix community (e.g. POSIX or X/OPEN), the lack of proper education for those people who submit some of the poor programs to the net, and generally a lack of thinking on the part of the people who immediately criticize posted software -- the way I look at it it is just as easy (no - easier) for people to write some neat software and just keep it to themselves, so if they're willing to `expose' themselves to the network community at large then they should be THANKED and other people, instead of whining about "it doesn't work on BSD1.04" should be working on finding someone with the knowledge and interest to do the port... Ah well, that's my nickel. -- Dave Tayeue:
guardian@laidbak.UUCP (Harry Skelton) (08/21/87)
In article <656@hplabsz.HPL.HP.COM> taylor@hplabsz.UUCP (Dave Taylor) writes: >you don't agree, well... > Life is like that some times, I guess. > >I don't see what the point of this is - part of the point of having >a rich set of data structures available within C is to allow people to >create data structures that are appropriate for the task they are attempting >to solve I agree, I do not think that the use of structures, unions, or whatever, should be restricted but rather gracefully use so those who do not under stand what they are downloading can figure out how to handle things. Remember, USENET is for the support of computers and languages both for the 'guru' and for the novice. At least that is the way I feel about it!! >As with gotos, externs and unions have their place in complex programming >tasks. For one example, try getting the value of "errno" without previously >defining it as an "extern int" in your program... >Unions might be more reasonable to try to limit, however, since they really >are susceptible to different machine architectures. The BBS group I talk to are mainly kids or people that are starting with 'C' and the questions I get are mainly with externs, as in "Where is that referenced". They fail to understand that some information can be global. Most look at passing of information via arguments to a function call as global. Sorry to sit and burn but as a programmer I understand the use of various abilities that 'C' offers but I mearly wanted to defend the 'little user' as well. >Again, what do you mean by 'pointer playing'? There are certain times >when you need to be able to hand pointers to pointers to structures or >whatever else might be needed. Pointer playing is to make a shell game of the variables. If you do it too much, you can loose some people in the shuffle. >Tough luck. Typedefs are part of the standard K&R C as defined in >many places ... >If some compilers can't handle it, then tough luck. Then you can post your BSD 'C' program for a Unix 1.2 version 7 user to use then...hmmm?? How about when you have a ancient system and NO upgrades for the OS or the compiler are available? Is this standard? >>5. Small moduals - better a few little programs doing something than one >> big one. > >That certainly fits in with the Unix philosophy. I agree. Thank you.... >>6. LOTS OF COMMENTS - nuff said. > >Better yet - lots of *meaningful* comments. I've seen too much code >floating around (esp. from AT&T and UCB) that has either no comments, >or comments that are just stupid and a waste of space. Neither has >any purpose or is helpful... Sounds like your getting into the hang of things! >>7. Smart makefiles or config programs - to find out what the user does >> not know (see rn) > >Sounds reasonable - how about a tool for helping people create these >funky Makefiles? See comp.unix.source for config! I've got a few ideas on paper too... >>8. No BSD or Sys V dependent stuff - must be able to compile 'clean' on >> any system. > >This one is obviously a joke. While it is unfortunate that there is such >a difference between BSD and SYSV, there are a number of packages floating >around that more-or-less allow you to run the code written for one >machine on the other ('cept for job control on SYSV). The problem with >this is that the person who writes the original code should be thanked >for making it available, not forced into digging up other machines and >testing the code on them before releasing it. THAT is the job of some >volunteer who finds the program sufficiently interesting that they are >willing to put the time in to port it and then post the diffs (or what- >ever) to the net... No it's not a joke. If one is to advertise a program as 'standard 'C'' then let it be portable or portable enough that it only takes a little change to the configuration or whatever in order to make it run. If you want to post BSD or SYS V then note it as such but as is the case, if it is a program with general instructions and calls then it should run pretty fair on both. If someone wants to classify a source as standard, then let it work under both as well as others. May not get a lot of offers but that's what you get when you strip out all of the 'non-compatable' code. >>9. vars must have legable names - no pt.dk.i2.dv - put.disk.in2.drive > >A fine sentiment, but you have quite a weight of programmers that would >disagree in actions True. But what makes greater sense? APL? >>10. no memory playing - no mallocs, allocs, callocs or whatever - if it > can't be handled by the compiler then don't post it. > >This one I strongly disagree with. If you look at the Elm System sources >you'll find that I include and use my own "palloc" permanent-alloc >routine. The reason I do this is because the program is pretty memory >intensive and I start up by allocating about 75 strings that are never >free'd again. So doing it via my own routine allows me to avoid the >major 75-entry traversal for each subsequent call to malloc/free that I make. >It is a *noticable* improvement on slower machines. Nuff said. I guess what I ment is...don't trust the machine. I must applaud your methods. >(I suspect that the reason you put this in was because you don't under- >stand how malloc works and how a typical large software system uses it) Not so! I posted it because I was not catering to the large software system. I have used malloc in several applications but due to the OS I have been burnt by it as well and tend to stray away from the quick and easy. (see: MS-Dos, core dump, confused visual debuggers (dbxtool,sdb)) >>11. use standard includes - stdio.h curses.h termcap.h ctype.h ect.... > >Standard based on what? Posix? Xopen? SVID? BSD4.2? This is unfortunately >pretty useless as a guideline. Why? Is 'stderr' different on all machines? You mean I can't pipe something to 'stdout' on another? ... unlikely ... >>12. include complete documents.... > >Sounds reasonable, but the majority of people who write these large >software systems that are released to the network can't write a clean >set of documents if their lives depended on it. There ain't no way >around this, and I don't think that crummy documentation is much better >than none at all (or a man page, as a minimum)... ...I'm pretty poor at documentation myself but any documentation is better than no documentation. Just ask a user.... >In general, the problem with guidelines of this nature is that they ignore >some of the fundamental problems rather than addressing them. Maybe I'll write you a document and post it? See me in two months. (really!) I sugested ideas. Maybe an outline on the whiteboard will do better next time. >I see the >main problems we're talking about here as a combination of the lack of >viable standards already implemented in the Unix community (e.g. POSIX >or X/OPEN), the lack of proper education for those people who submit some >of the poor programs to the net, and generally a lack of thinking on the >part of the people who immediately criticize posted software -- the >way I look at it it is just as easy (no - easier) for people to write >some neat software and just keep it to themselves, so if they're willing >to `expose' themselves to the network community at large then they should >be THANKED and other people, instead of whining about "it doesn't work on >BSD1.04" should be working on finding someone with the knowledge and >interest to do the port... That is true. But there are those who would like to see some standard that a shared community can work with. I have seen a lot of support for BSD's, Sys V, and others but with the number of home systems and BBS's that are comming up within USENET, a new realm of users now must be supported. If one doesn't like the idea of supporting other 'lesser educated' users, I'm sure that there are a lot of other newsgroups that one can subscribe to or unsubscribe from. <looking up at the great CD drive in the ski> "How about comp.c.standard?" > Ah well, that's my nickel. Ah well, that's my dime. > -- Dave Taylor -- Harry Skelton Harry Skelton - guardian@laidbak.UUCP "...it still beats staying home with the kids all day..."
guy%gorodish@Sun.COM (Guy Harris) (08/22/87)
> I agree, I do not think that the use of structures, unions, or whatever, > should be restricted but rather gracefully use so those who do not under > stand what they are downloading can figure out how to handle things. > Remember, USENET is for the support of computers and languages both for > the 'guru' and for the novice. At least that is the way I feel about it!! If you don't understand what you download, you have to be prepared for it not to work. If some function can be better performed by using an algorithm or data structure that J. Random BBSUser can't understand, that's just too bad. Some of these programs are not *intended* for them; others may be intended for them to *use*, but not to *maintain*. How many writers using a word processor do you think would understand all the details of some code to reformat text on the screen? > The BBS group I talk to are mainly kids or people that are starting with > 'C' and the questions I get are mainly with externs, as in "Where is that > referenced". They fail to understand that some information can be global. > Most look at passing of information via arguments to a function call as > global. Sorry to sit and burn but as a programmer I understand the use of > various abilities that 'C' offers but I mearly wanted to defend the > 'little user' as well. So? These programs aren't posted so that people can use them to learn C; they are posted so that they can be compiled and run. Again, how many computer users would necessarily be able to understand *all* the programs they use? I doubt that there's even any programmer here at Sun who understands *all* of the software here in full detail. > >>11. use standard includes - stdio.h curses.h termcap.h ctype.h ect.... > > > >Standard based on what? Posix? Xopen? SVID? BSD4.2? This is > >unfortunately pretty useless as a guideline. > > Why? Is 'stderr' different on all machines? You mean I can't pipe something > to 'stdout' on another? ... unlikely ... Maybe this is unlikely on UNIX machines, but there may be C implementations that have *none* of the include files listed above! Even ANSI C, while it does require <stdio.h> and <ctype.h>, does not say anything about "curses" or "termcap", and neither does POSIX. > That is true. But there are those who would like to see some standard > that a shared community can work with. I have seen a lot of support for > BSD's, Sys V, and others but with the number of home systems and BBS's that > are comming up within USENET, a new realm of users now must be supported. By saying that this new realm of users "must" be supported, you are either making a moral claim or stating a fact backed up by law or some other form of authority. If the latter, please indicate what this authority is, and be forewarned that a lot of good programs aren't exactly known for their respect for authority.... If the former, I simply reject that claim, and I'm sure a lot of others do as well. There are realms where egalitarianism may be a Good Thing; programming isn't one of them - it tends to be a Bad Thing there (as well as in other technical fields). Naive egalitarianism tends to be an Even Worse Thing. > If one doesn't like the idea of supporting other 'lesser educated' users, > I'm sure that there are a lot of other newsgroups that one can subscribe > to or unsubscribe from. > > <looking up at the great CD drive in the ski> > "How about comp.c.standard?" Fine. If *you* want a newsgroup requiring C code to be written to the lowest common denominator, so that the code in it can be understood by the least sophisticated users and the least sophisticated systems, go ahead and set it up. Don't try and require that an existing community adhere to these arbitrary standards, though; it is not your right to say that that community should move to "other newsgroups". Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
ken@cs.rochester.edu (Ken Yap) (08/22/87)
|8. No BSD or Sys V dependent stuff - must be able to compile 'clean' on | any system. This is a joke, right? I do not have access to 6 different OSes, let alone two dialects of Unix. Most posters, I suspect, like I, wrote the code originally for their own use, then post to the net in the hope that someone will find it useful. If this rule could even be enforced (a joke in itself) we would end up with a trickle of postings of mostly trivial programs. Besides, even if I were to try to make the code portable I would not be able test the code out. But hey, isn't half the fun of getting sources off the net making it run on your machine and then chiding the poster for lack of foresight :-)? Believe me, porting C between Unix dialects is nowhere near as hard as translating language X to language Y, for most X and Y. Ken
gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/22/87)
In article <1113@laidbak.UUCP> guardian@laidbak.UUCP writes: >But there are those who would like to see some standard >that a shared community can work with. We're working hard to establish such standards (ANSI X3.159-198x for C and IEEE 1003.1 for UNIX-like system interface). However, they're not quite ready and won't be widely enough implemented for a couple of years. It is premature to attempt to dictate C source standards for "navie user installed" products. It is absolutely misguided to demand that C programmers hobble themselves by not exploiting many of the language's most useful features, on the grounds that people who don't understand C would not understand the code. Why SHOULD such people be expected to understand the code? There might be some point to that for code that is intended to be tutorial, but that's not what the vast majority of freeware is intended for. There are some things that programmers CAN do now to improve source code portability. For example, I'm working up a list of library routines and headers that are relatively safe to rely on, to guide programmers working on a large local project; I'll post it to comp.lang.c and comp.unix.questions when it's done.
amen@quequeg.UUCP (Bob Amen) (08/24/87)
in article <26297@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) says: > >> The BBS group I talk to are mainly kids or people that are starting with >> 'C' and the questions I get are mainly with externs, as in "Where is that >> referenced". Sorry to sit and burn but as a programmer I understand the use of >> various abilities that 'C' offers but I mearly wanted to defend the >> 'little user' as well. > > So? These programs aren't posted so that people can use them to learn C; they > are posted so that they can be compiled and run. Again, how many computer > users would necessarily be able to understand *all* the programs they use? >... > > By saying that this new realm of users "must" be supported, you are either > making a moral claim or stating a fact backed up by law or some other form of > authority. > ... > >> If one doesn't like the idea of supporting other 'lesser educated' users, >> I'm sure that there are a lot of other newsgroups that one can subscribe >> to or unsubscribe from. > > Fine. If *you* want a newsgroup requiring C code to be written to the lowest > common denominator, so that the code in it can be understood by the least > sophisticated users and the least sophisticated systems, go ahead and set it > up. Don't try and require that an existing community adhere to these arbitrary > standards, though; it is not your right to say that that community should move > to "other newsgroups". As a less sophisticated user than Guy I would like to respond in support of what he says. I am not afraid to look at a program that doesn't compile and try to make it work. In fact I enjoy it and have learned much from doing just that. I've learned alot about C and found new techniques that I otherwise would not have learned. I've also learned alot about how Un*x works and have been able to make many programs work on our system (SYSV with BSD4.2 enhancements) and have (and will continue to) mail the fixes to the original authors so that they can add another machine to the list of "supported" machines. It was my understanding that this is how Usenet is supposed to work. I feel sorry for those that are too timid to tackle a posted program that they might not understand. They will be slow to learn and always behind the times. (I've been programming for about 10 years (in school, mostly and all scientific programming) but have only been using C for a year and a half. I have been administering our systems (2) for two years with no prior sysadmin or Un*x experience...I'm really a neophyte!) I really don't understand why some people are so quick to criticise those that have freely given of their time and expertise by posting things that they have found useful. After all they didn't say that one MUST compile and make their stuff work. They just thought "you" might find it useful too. If "you" don't like it then write the program yourself! Many have put an incredible amount of time and effort into making their programs as portable as possible (given that they are usually working on one flavor of machine) (Dave Taylor is a prime example here!). Those that haven't usually say that "This has been tested on XYZ but may work on ZZX as well. Right on Guy and Dave (from a small corner of the net)! -- Bob Amen (amen@quequeg.UUCP) Chesapeake Bay Institute/Johns Hopkins University (+1 301 338-6329)
daw@houxs.UUCP (D.WOLVERTON) (08/25/87)
In article <26297@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: (> > is Harry Skelton (sp?)) > > The BBS group I talk to are mainly kids or people that are starting with > > 'C' and the questions I get are mainly with externs, as in "Where is that > > referenced". They fail to understand that some information can be global. > > Most look at passing of information via arguments to a function call as > > global. Sorry to sit and burn but as a programmer I understand the use of > > various abilities that 'C' offers but I mearly wanted to defend the > > 'little user' as well. > > So? These programs aren't posted so that people can use them to learn C; they > are posted so that they can be compiled and run. Perhaps one of the best ways to learn "how to use a language" is to read real, honest-to-God code. Not everyone has access to UNIX source. For these people (and the number of them is growing every day), comp.sources may be their primary source for C language coding examples. Which is why I disagree with Harry's position [deleted] that the postings be at the lowest common denominator. Programs which use the more complex features of the language (which is of course relative) provides a body of "literature" for the novice to study. Consider where we would be today if all published books were on the level of "Run, Spot, run." Dave Wolverton AT&T ihuxn!houxs!daw
brian@tlxprs.UUCP (Brian R. Eckert) (08/25/87)
In article <656@hplabsz.HPL.HP.COM> taylor@hplabsz.UUCP (Dave Taylor) writes: >Harry Skelton (guardian@laidback.UUCP) suggested in news.admin the following >set of guidelines for posting sources to the network. Since it's so amazingly >inane I thought I'd actually spend some time to refute what he suggests. If >you don't agree, well... > Life is like that some times, I guess. > I missed the original posting somehow, but have seen a couple of replies to Harry's article. I must say I ABSOLUTELY DON'T AGREE with his (harry) proposed standard; and in addition, I have found things that are outright incorrect. I will just add my two cents, not repeat what everyone else has already said. >>3. straight use of variables - no pointer playing. > >Again, what do you mean by 'pointer playing'? There are certain times >when you need to be able to hand pointers to pointers to structures or >whatever else might be needed. So much for printf, scanf, and friends... I guess we'll all be writing programs that accept limited input and perform limited output (if we get that far). >>4. NO TYPEDEFS - some machines will croak on this. (Hi SCO Xenix) > >Tough luck. Typedefs are part of the standard K&R C as defined in >many places (including the K&R `The C Programming Language' book). >If some compilers can't handle it, then tough luck. (I'll expand on >this topic in a second...) This is wrong. What SCO Xenix do you use? I have dozens of (large) programs that have a number of typedefs in -- I've never had a single complaint from the compiler. >>6. LOTS OF COMMENTS - nuff said. > >Better yet - lots of *meaningful* comments. I've seen too much code > [...] What good are comments on the order of: i++; /* increment i */ I've seen stupidity like this many times. >>7. Smart makefiles or config programs - to find out what the user does >> not know (see rn) > >Sounds reasonable - how about a tool for helping people create these >funky Makefiles? Look at 'Configure.sh' for 'rn'; I've found many useful things there. >>10. no memory playing - no mallocs, allocs, callocs or whatever - if it > can't be handled by the compiler then don't post it. > >This one I strongly disagree with. [...] Who said the compiler can't handle dynamic memory allocation???????? If it's with SCO, don't try to malloc anything bigger than 32K with one call; sbrk (which is the system call that malloc depends on) isn't very cooperative when you try this (this may have been fixed since I last beat my head against a wall over it, but I still don't try it). >>12. include complete documents.... > Don't press your luck. I'm a terrible *USER* manual writer, but I can write useful technical documents for someone to translate into a good user manual (I suppose that's why the programmers here don't write the manuals and only provide technical assitance to the documentation writer(s)). -brian
gwl@rruxa.UUCP (George W. Leach) (08/27/87)
> > I really don't understand why some people are so quick to criticise > those that have freely given of their time and expertise by posting things > that they have found useful. After all they didn't say that one MUST > compile and make their stuff work. They just thought "you" might find it > useful too. If "you" don't like it then write the program yourself! Many > have put an incredible amount of time and effort into making their programs > as portable as possible (given that they are usually working on one flavor > of machine) (Dave Taylor is a prime example here!). Those that haven't > usually say that "This has been tested on XYZ but may work on ZZX as well. > I for one greatly appreciate any effort made by an author of *FREE* software to distribute it. Those who complain really want to be spoon fed everything. Just stop for a minute and consider how long it would take you to write similar software from scratch. Even if you must port it to your environment, you are still way ahead of the game. I suspect that those who complain would never even make the effort to write software from scratch, unless it was for the job or to make $$$$. > Right on Guy and Dave (from a small corner of the net)! ^^^^^^^^^^^^ I think the vast majority of the net would like to join in to thank you guys and everyone else who contributes source. > > -- > Bob Amen (amen@quequeg.UUCP) > Chesapeake Bay Institute/Johns Hopkins University (+1 301 338-6329) George W. Leach Bell Communications Research New Jersey Institute of Technology 444 Hoes Lane 4A-1129 Computer & Information Sciences Dept. Piscataway, New Jersey 08854 Newark, New Jersey 07102 (201) 699-8639 UUCP: ..!bellcore!indra!reggie ARPA: reggie%njit-eies.MAILNET@MIT-MULTICS.ARPA From there to here, from here to there, funny things are everywhere Dr. Seuss "One fish two fish red fish blue fish"
gnu@hoptoad.UUCP (08/28/87)
Harry Skelton (guardian@laidback.UUCP) suggested in news.admin the following > >10. no memory playing - no mallocs, allocs, callocs or whatever - if it > can't be handled by the compiler then don't post it. I agree with Harry. Let's go back to fixed-size buffers for everything. No sense in allocating enough space to handle whatever the world throws at us. If somebody tries to grep a file with a 1000 character line in it, we should clearly core dump. That'll teach the user to keep to 80 columns like Mr. Hollerith said to. -- {dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu gnu@postgres.berkeley.edu My name's in the header where it belongs.
guy%gorodish@Sun.COM (Guy Harris) (08/29/87)
> Well, Harry's idea was none too bright, but yours would set programming > back to the way it was 10 years ago! That was his *whole point*. His suggestion was a *parody* of Skelton's suggestion. Are you of the opinion that Jonathan Swift *really* favored using Irish babies for food? *Sigh* I guess those smiley faces really *are* necessary.... Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com