Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ames!lll-tis!ptsfa!ihnp4!laidbak!guardian From: guardian@laidbak.UUCP (Harry Skelton) Newsgroups: comp.sources.d Subject: Re: Standard C Programming - wot a dumb idea. Message-ID: <1113@laidbak.UUCP> Date: Fri, 21-Aug-87 15:58:27 EDT Article-I.D.: laidbak.1113 Posted: Fri Aug 21 15:58:27 1987 Date-Received: Sun, 23-Aug-87 06:18:07 EDT References: <1101@laidbak.UUCP> <656@hplabsz.HPL.HP.COM> Reply-To: guardian@laidbak.UUCP Organization: LAI Chicago Lines: 184 Keywords: standard c flame Summary: differences between rams and lambs 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. "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..."