home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / msdos / programm / 9377 < prev    next >
Encoding:
Internet Message Format  |  1992-09-15  |  2.1 KB
  1. Xref: sparky comp.os.msdos.programmer:9377 comp.lang.c:13696
  2. Newsgroups: comp.os.msdos.programmer,comp.lang.c
  3. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!spool.mu.edu!umn.edu!csus.edu!borland.com!alexande
  4. From: alexande@genghis.borland.com (Mark Alexander)
  5. Subject: Re: BC++2.0 lseek problem(ALSO:lseek() question)
  6. Message-ID: <1992Sep15.181611.27033@genghis.borland.com>
  7. Originator: alexande@genghis.borland.com
  8. Sender: news@borland.com (News Admin)
  9. Organization: Borland International
  10. References: <1992Sep12.235241.23213@eng.ufl.edu>
  11. Distribution: usa
  12. Date: Tue, 15 Sep 1992 18:16:11 GMT
  13. Lines: 48
  14.  
  15. In article <1992Sep12.235241.23213@eng.ufl.edu> zzang@stat.ufl.edu (Zhuo Zang) writes:
  16.  
  17. > Hello, the following program using lseek will give different results
  18. > in BC++2.0 than that of in UNIX.  the BC++2.0 will print the last
  19. > character twice.
  20.  
  21. I tried this program with BCC++ for OS/2, BC++ for MS-DOS, and GCC on a
  22. unix box.  All produced the same result.  This assumes that the first line
  23. of the file foo.c is the following:
  24.  
  25. /* use bcc -DMSDOS foo.c to compile in BC++i
  26.  
  27. The program seeks to file offset 3, then reads 20 bytes from the file
  28. into a buffer.  These 20 bytes, which the program prints, should be
  29. the following:
  30.  
  31. use bcc -DMSDOS foo.
  32.  
  33. There are several dangers and harmless mistakes in this program, though.
  34.  
  35. First, the buffer is declared as follows:
  36.  
  37. >char buf[BUFSIZ];
  38.  
  39. The assumption here is that the buffer is greater than 20 bytes long.
  40. If BUFSIZ is <= 20, bad things could happen.  BUFSIZ is usually 512,
  41. but you can't count on it.
  42.  
  43. Secondly, the attempt to zero-terminate the string didn't work; it
  44. just converted '\0' to a (char *), and assigned it to sp:
  45.  
  46. >  sp = '\0';
  47.  
  48. This should have been:
  49.  
  50.    buf[20] = '\0';
  51.  
  52. or
  53.  
  54.    sp[20] = '\0';
  55.  
  56. since sp was set to point to buf[0].
  57.  
  58. However, the program worked without this, because buf[] was declared
  59. as a global variable, and hence was initially zero-filled when the
  60. program was started.  If you had used the buffer again, or had declared
  61. the buffer as a local variable, the program would have failed, because
  62. the buffer would probably not be zero-filled.
  63.