From: mjr@TIS.COM (Marcus J. Ranum)
Newsgroups: rec.games.mud.misc
Subject: Re: Note to any fellow DikuMUD coders...
Date: 26 Dec 92 18:01:15 GMT
Reply-To: mjr@TIS.COM
Organization: Trusted Informations Systems, Inc.


Ok, let's try this again... ;)

> Is this from the book of programming according to Mr. Ranum?

	Yes, it is. I'd be the first to admit that I have strong
feelings about the right way to write working, portable, solid
code. I also find that in order to program effectively, a programmer
needs to develop consistent techniques aimed at achieving such
results. After all, if you're programming for money, you owe it
to your employer to give value: high quality, well thought-out,
working software. If you're programming for fun, then you owe
it to yourself (since you're your own employer) not to waste
your time by writing bogus code.

>What makes this "not good programming"?  If you mean it is
>duplication of effort, that is a wasted argument for most code (and
>in particular mud code).

	It's duplication of effort, but it's also a software "time bomb"
in that someday the way a struct sockaddr_in is represented may change
and the code that "works" suddenly and invisibly breaks. If the programmer
uses libraries provided with the system, then making inet_ntoa() work
is the vendor's problem. A similar example is the individuals who still
write code using bitmasks for select() and assuming 64 file descriptors
per process instead of the FD_SET macros and getdtablesize(). That is
"not good programming" in the book of programming according to Mr. Ranum. ;)

	Broken vendor software (who broke inet_ntoa()? AIX?) is a real
problem, and working around it is a pain in the butt. There are two
approaches:
	a) provide alternate functionality  (your own library routine)
	b) provide a patch
	Approach 'a' risks becoming a software time bomb, and approach
'b' risks turning your code into a mass of:

#ifdef	BROKEN_INET_NTOA
#ifdef	SUN
#else
#endif
#else
#endif

	And similar abominations. See the sources for 'mh' for an
example of how software that should be trivial can be obfuscated
beyond usability. These days my thinking aligns with Henry Spencer's
postulate that #ifdef is evil (though I'm not as rabid as he is
about it) and that the best way to do portable software is to
just write stuff and if you need to build it on a system without
inet_ntoa() or a broken inet_ntoa() then you need to either beat
up your vendor and/or get a working version you can link in as a
local patch. If the makefiles for the application are simple and
avoid GNU-ish excesses in complexity, adding "inet_ntoa.c" to
the link should be easy.

> However I did not mean that it is ok to rewrite any library routine,
>only those that are known to be have problems... In particular the
>inet_ntoa() function produces the seg fault on the SunOS machines
>that I have worked on and if it is the case that all SunOS 4.1 has
>this problem it is good enough reason to write your own function.

:checks

	Eeeew, gross. And Sun hasn't fixed this yet? The joke, by
the way, for those who wish to flame me is that the sources for
inet_ntoa basically call sprintf(), or they did the last time I
looked at them. ;) 

> If I write a library routine in a way that I can expect it to
>be portable, this is far better than using one that may be expected
>to be absent or broken.  I didn't suggest they rewrite the entire
>libc, that is your stupid idea.  The people we are talking about writing
>this probably would have no clue as to what to do in the case that
>the library routine they wished to use was "broken". 

	Now who's on his high horse. ;)
	I prefer to assume that anyone who wants to grab sources
off the net is motivated enough to invest a small amount of effort
towards making something work.

	Writing library routines that you "expect" to be portable
doesn't work for applications of any size other than trivial. It
doesn't work for applications that are being written to run
under anything other than BSD UNIX. Supplying an entire libc with
your application is the logical extension of the approach you
are advocating, since at one point or another in 12 years of UNIX
hacking I've seen just about everything that could possibly be
broken, broken. SunOs4.0 had a broken fgets(). Do you include a
working version of fgets() with all your code in case someone
is running SunOS4.0?

	Yes, this stuff is all my opinion, and as such is arguable.
You're welcome to feel that I was out of line in presenting it the
way I did. I suspect if you're still programming in C in another
10 years you'll probably feel just the way I did when you see
someone publicly advocating bad programming practices.

mjr.
Newsgroups: rec.games.mud.misc