Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!princeton!phoenix!macbeth!telesci!tlxprs!brian
From: brian@tlxprs.UUCP (Brian R. Eckert)
Newsgroups: comp.sources.d
Subject: Re: Standard C Programming - wot a dumb idea.
Message-ID: <212@tlxprs.UUCP>
Date: Tue, 25-Aug-87 15:54:41 EDT
Article-I.D.: tlxprs.212
Posted: Tue Aug 25 15:54:41 1987
Date-Received: Fri, 28-Aug-87 00:38:41 EDT
References: <1101@laidbak.UUCP> <656@hplabsz.HPL.HP.COM>
Reply-To: brian@tlxprs.UUCP (Brian R. Eckert)
Organization: Telexpress, Inc.  Willingboro, NJ
Lines: 72

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