home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / c / 12627 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  1.4 KB
  1. Path: sparky!uunet!usc!sdd.hp.com!elroy.jpl.nasa.gov!ames!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek
  2. From: torek@horse.ee.lbl.gov (Chris Torek)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Help: read() question.
  5. Date: 21 Aug 1992 21:08:18 GMT
  6. Organization: Lawrence Berkeley Laboratory, Berkeley
  7. Lines: 21
  8. Message-ID: <25663@dog.ee.lbl.gov>
  9. References: <1992Aug21.154401.5050@gw.wmich.edu>
  10. Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
  11. NNTP-Posting-Host: 128.3.112.15
  12.  
  13. In article <1992Aug21.154401.5050@gw.wmich.edu> 754clifton@gw.wmich.edu writes:
  14. >Assuming I have a file I have found the exact size (len) of using lseek or
  15. >some other method. Assume also that I have a valid file descriptor ...
  16.  
  17. What is a `file descriptor', and where is `lseek' in the C standard?
  18.  
  19. >    nread = read(fd, buf, len); 
  20.  
  21. You have not shown us your `read' function.  Can we please keep UNIX
  22. and MS-DOS and other system-specific questions to system-specific
  23. groups?
  24.  
  25. To answer the question anyway:  UNIX never promised to read exactly as
  26. many bytes as you ask for.  Most UNIX *implementations* happen to do it
  27. when the underlying file is a `disk file', but that is a side effect of
  28. the implementation, not a design feature.  I cannot speak for other
  29. operating systems.  Since you did not name the OS, the question is in
  30. fact unanswerable.
  31. -- 
  32. In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
  33. Berkeley, CA        Domain:    torek@ee.lbl.gov
  34.