home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / c / 12383 < prev    next >
Encoding:
Internet Message Format  |  1992-08-15  |  3.1 KB
  1. Path: sparky!uunet!olivea!mintaka.lcs.mit.edu!bloom-picayune.mit.edu!news
  2. From: scs@adam.mit.edu (Steve Summit)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Allocate memory to typed in string, How?
  5. Message-ID: <1992Aug15.201359.3601@athena.mit.edu>
  6. Date: 15 Aug 92 20:13:59 GMT
  7. References: <MJN.92Aug9012538@pseudo.uucp> <1992Aug13.184911.376@wyvern.twuug.com>
  8. Sender: news@athena.mit.edu (News system)
  9. Organization: none, at the moment
  10. Lines: 55
  11. Nntp-Posting-Host: adam.mit.edu
  12.  
  13. In article <1992Aug13.184911.376@wyvern.twuug.com>, alpha@wyvern.twuug.com (Joe Wright) writes:
  14. > Attempts to allocate memory, char at a time, to an arbitrary 'string'
  15. > is silly even if it is possible.  If a string is assumed to be a line
  16. > of a text file or arbitrary keyboard input, we can easily declare that
  17. > it must not be longer than (let's say) 256 bytes.
  18.  
  19. I agree that it's easy to "declare that it must not be longer,"
  20. but the ease of stating something is not necessarily correlated
  21. with its wisdom.
  22.  
  23. Attempting to deal with arbitrarily-long input lines, using
  24. dynamic memory allocation or other techniques, is most certainly
  25. not silly.  If you must write a routine which imposes a fixed
  26. limit on input line length, let it be for one of these two
  27. reasons:
  28.  
  29.      1.    "I am too lazy and/or stupid to do any better."
  30.  
  31.      2.    "I have complete control over the input."
  32.  
  33. Operating-system-imposed limits on interactive input line length
  34. are red herrings, for several reasons: they generally do *not*
  35. apply to disk files; they are not the same from system to system,
  36. and they may change between releases of the same system.  (If the
  37. next release of the operating system advertised new, longer
  38. keyboard input buffers, I'd hate to have to tell my customers
  39. that my application couldn't make use of them, because I had
  40. wired in an assumption that the previous, smaller limit held.)
  41.  
  42. Arbitrary, fixed, (small) limits on input line length ought to be
  43. a thing of the past.  It's not all that difficult to write an
  44. input routine which accepts arbitrarily-long lines; indeed, we've
  45. seen several posted recently in the context of this and other
  46. related threads.  The fact that old Unix utilities tended to
  47. (silently, and more-or-usually-less gracefully) impose
  48. 512-character limits should *not* be used as justification to
  49. continue the practice; those limits are one of the more glaring
  50. blights on the ubiquitous "Unix philosophy."
  51.  
  52.                     Steve Summit
  53.                     scs@adam.mit.edu
  54.  
  55. P.S.  Please, don't anyone get too steamed if it seems like I'm
  56.       branding you as "too lazy and/or stupid to do any better."
  57.       I frequently write little throwaway utilities with
  58.       arbitrary limits, because I'm lazy, too.  You can perform a
  59.       cost/benefit analysis which may show that it's not
  60.       worthwhile to accept arbitrarily-large inputs: in a way,
  61.       that's just institutionalized laziness, but if the analysis
  62.       is accurate and well-founded it may well be perfectly
  63.       reasonable and nothing to be ashamed of.  But make very
  64.       very sure that you document the limit(s) well, and deal
  65.       with overflows gracefully (and that you include the costs
  66.       of dealing gracefully, and of putting up with the limits,
  67.       in your analysis).
  68.