home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / std / c / 3402 < prev    next >
Encoding:
Internet Message Format  |  1993-01-23  |  7.1 KB
  1. Path: sparky!uunet!olivea!sgigate!sgiblab!troi!steve
  2. From: steve@dbaccess.com (Steve Suttles)
  3. Newsgroups: comp.std.c
  4. Subject: Re: C things
  5. Message-ID: <151@mccoy.dbaccess.com>
  6. Date: 22 Jan 93 20:55:00 GMT
  7. References: <107937@bu.edu>
  8. Organization: Cross Access Corp., Santa Clara, CA
  9. Lines: 122
  10. X-Newsreader: Tin 1.1 PL4
  11.  
  12. spacefox@acs.bu.edu (Godfrey Degamo) writes:
  13. : 
  14. : 
  15. : This was posted awhile ago:
  16. : -------------------------------------------------------------------------------
  17. : In article <BzMzqC.n0u@jrd.dec.com> 
  18. : diamond@jit.dec.com (Norman Diamond) writes:
  19. : Remember, a language with gets() and other such niceties is intended for
  20. : hacking, not for security.  The "N" is intended to bring over a known portion
  21. : of the source string, not to protect other stuff near the target.  Now this
  22. : raises the question of why memcpy() was invented, and I don't know the answer.
  23. : 
  24. : On a more serious note, people actually do use gets().  I'd worry about this
  25. : kind of dangerous stuff long before caring about silly things like strncat().
  26. : -------------------------------------------------------------------------------
  27. : 
  28. :      I am  a person who programs in C for recreation.  -much technical jargon 
  29. : is beyond my comprehension.  Perhaps you can answer my two questions.
  30. : 
  31. :      I would like to know why it's "dangerous" to use gets().  I always
  32. : make certain I pass in the name of a char array or some pointer char that
  33. : has been allocated some memory.  It always seems to work for me.
  34.  
  35. The "danger" in get() is common to a large number of routines.  There is an
  36. axiom that is never taught, that one should only use routines that write to
  37. arrays FOR WHICH THE LENGTH OF THE ARRAY IS SPECIFIED.  The problem is that
  38. with gets and strcat and several other routines, you pass the address of a
  39. destination array and it fills it up.  If things are not the way you expect at
  40. the time you write the program (for example, if the user types a line longer
  41. than you expected), you will keep right on going past the end of the array, and
  42. write all over other variables (or worse).  Everyone I know who implicitly
  43. understands this rule learned it the hard way.  Usually more than once.
  44.  
  45. :      What other alternative is there for one to use?  I try to find some
  46. : other way of getting user input other than scanf().  I seem to have problems
  47. : with scanf.  For instance:
  48. : 
  49. :      scanf ("%s", &inputA);
  50. :      scanf ("%s", %inputB);
  51. : 
  52. :      What happens is that inputA gets the user input, then when the computer
  53. : comes to the second line, it reads the CR from the first input as the input
  54. : for inputB.  (I don't remember this: but, I think that I tried a variation
  55. : "%s\r" and it still wouldn't work.)  Anyways, things like this where the
  56. : input of one is "leaked" to the next seem to crop up when I use scanf.
  57. : So, that's why I avoid it.  For numerical input, I use gets() and then
  58. : call a number conversion function.
  59. : 
  60.  
  61. It is also an axiom never to use scanf.  Many programmers use gets or fgets
  62. and then sscanf, many write their own parse routines each time.
  63.  
  64. :      My next question is this:
  65. : 
  66. :      Let's say I have a database program that holds information about people;
  67. : address, telephone number, physical description.  All the data of all the
  68. : people is saved to one file.
  69. :      How do I modify then save the records of one person without loading up
  70. : all the data then saving all the data, which can be very slow when the file
  71. : gets large?
  72. :      I thought of scanning through the file until I get to the record to be
  73. : changed.  And from there, start saving the data, but I'm worried that I will
  74. : overwrite other records if the amount of data is larger then the old data.
  75. :      It's been awhile since I programmed in AppleSoft Basic, but in it, there
  76. : is the concept of Random Access Files and Sequential Files.  In Random 
  77. : Access Files, you can do what I just desribed to you, but each record has to
  78. : be a set size.  Sequential Files could be anysize, but you lose the ability
  79. : to save information without loading all the data into memory.
  80. :      Is there something similar to this in C/Unix or C/MS-DOS?
  81.  
  82. Yup.  Identical.  If you make the records all the same size (obviously, it will
  83. need to be large enough to hold everything you might want to say), then you can
  84. update them without growing.  You can also compute where the beginning of a
  85. record is.  This allows accessing the records in random order, hence the term
  86. Random Access.  If you are only going to access the records sequentially, you
  87. will never need to compute the address of a record.  They can therefore be
  88. varying in size.  They can be updated in place, but if they need to be bigger,
  89. you either have to "move" everything after, or mark that record as deleted and
  90. tack the bigger one on the end.
  91.  
  92. The concept is a universal one.  It is implementation you wanted to ask about.
  93. In C, fseek() and ftell() are the functions you are interested in.  fseek()
  94. will let you know the location of a record in a file, and ftell() will go to a
  95. predetermined address.  It is O/S dependent what the arguments to these
  96. functions, and their return values, should be.  (and on VAX/VMS, you could do
  97. it this way, but RMS has certain advantages too, and should be considered.)
  98.  
  99. :      If you don't have the time to answer my second question, could you
  100. : please point me to some C literature that does?
  101. : 
  102. : Also, if you do respond, I suppose it would be nice to post on this group,
  103. : (if it's not so trivial.)  but I don't read these C programming newsgroups
  104. : often and might forget I posted here!  So, please could you mail your
  105. : answers to me?
  106. : 
  107. Anything to help.  However, if it is not worth your time to read the group
  108. where you posted the question, I find it insulting that you think it is worth
  109. my time to not only read your worthless question but to consider spending my
  110. time to consider it and respond.  If the question is of general interest, and
  111. the answer is as well, then news is the place for it.  If the question is made
  112. public because the answer which is not generally interesting is simply
  113. difficult to find, then email is the place.  However, your statements boil down
  114. to "I have a question which I think everyone wants to know the answer to.
  115. So please answer it publicly.  However, I'm too lazy to get up and read the
  116. bulletin board, so send it by mail, because mail is delivered to my desk."
  117.  
  118. I'm sorry if this seems harsh; I've simply reached my tolerance for this
  119. particular implied insult.  I'm sure you didn't intend it that way, nor did any
  120. of the others.  But I find no moral difference between this scenario and
  121. calling someone up to ask a question, and finishing with "I don't have time to
  122. listen to the answer, so write me a letter.  But I need to know right away".
  123.  
  124. : 
  125. : Thanks for listening, sorry to waste your time, have a good day.
  126. : 
  127. :                                         -G. Degamo,
  128. :                                          spacefox@acs.bu.edu
  129. -- 
  130. Steve Suttles                Internet:  steve@dbaccess.com      Dr. DCL is IN!
  131. CROSS ACCESS Corporation     UUCP: {uunet,sgiblab}!troi!steve  Yo speako TECO!
  132. 2900 Gordon Ave, Suite 100   fax: (408) 735-0328              Talk data to me!
  133. Santa Clara, CA 95051-0718   vox: (408) 735-7545   HA! It's under 4 lines NOW!
  134.