home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / rec / games / mud / misc / 1733 < prev    next >
Encoding:
Text File  |  1992-12-26  |  2.3 KB  |  48 lines
  1. Newsgroups: rec.games.mud.misc
  2. Path: sparky!uunet!spool.mu.edu!darwin.sura.net!ra!wintermute.phys.psu.edu!atlantis.psu.edu!handel!stine
  3. From: stine@handel.psu.edu (Jeffrey Stine)
  4. Subject: Re: Note to any fellow DikuMUD coders...
  5. Message-ID: <kwt1H$1cnb@atlantis.psu.edu>
  6. Sender: news@atlantis.psu.edu (Usenet)
  7. Organization: Penn State University
  8. References: <9212241834.AA23599@TIS.COM> <lek1Hah5mb@atlantis.psu.edu> <9212260257.AA22918@TIS.COM>
  9. Date: Sat, 26 Dec 92 06:21:26 GMT
  10. Lines: 36
  11.  
  12. In article <9212260257.AA22918@TIS.COM> mjr@TIS.COM writes:
  13. >stine@handel.psu.edu (Jeffrey Stine) writes:
  14. >
  15. >>I've worked on machines where this call did not work and would produce a
  16. >>seg fault. There is nothing wrong with transforming the address this way
  17. >>provided it is done correctly.
  18. >
  19. >    Sure. You cal also make your code "portable" by including the
  20. >complete source of a libc that you trust to work. If the system libraries
  21. >are broken, that's an implementation detail you should work out with
  22. >the vendor - rewriting library routines in a way that works "provided it
  23. >is done correctly" is not good programming.
  24. >
  25. >mjr.
  26.  
  27.  Is this from the book of programming according to Mr. Ranum?
  28. What makes this "not good programming"?  If you mean it is
  29. duplication of effort, that is a wasted argument for most code (and
  30. in particular mud code).
  31.  However I did not mean that it is ok to rewrite any library routine,
  32. only those that are known to be have problems... In particular the
  33. inet_ntoa() function produces the seg fault on the SunOS machines
  34. that I have worked on and if it is the case that all SunOS 4.1 has
  35. this problem it is good enough reason to write your own function.
  36.  If I write a library routine in a way that I can expect it to
  37. be portable, this is far better than using one that may be expected
  38. to be absent or broken.  I didn't suggest they rewrite the entire
  39. libc, that is your stupid idea.  The people we are talking about writing
  40. this probably would have no clue as to what to do in the case that
  41. the library routine they wished to use was "broken". 
  42.  In conclusion how about getting off your high horse long enough to
  43. realize which group your post is targeting and not refer to something
  44. as vomit without giving specific reasons _why_ it is bad.  I mean
  45. after all not all of us have your _vast_ experience, some of us only
  46. have several years worth of programming these things under our belts.
  47.  
  48.