home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / c / 12635 < prev    next >
Encoding:
Text File  |  1992-08-21  |  3.0 KB  |  100 lines
  1. Xref: sparky comp.lang.c:12635 comp.unix.programmer:4402
  2. Path: sparky!uunet!mcsun!ieunet!!bsullivn
  3. From: bsullivn@sc.sni.ie (Bryan O'Sullivan)
  4. Newsgroups: comp.lang.c,comp.unix.programmer
  5. Subject: Re: memory map (mmap)
  6. Message-ID: <159@sc.sni.ie>
  7. Date: 17 Aug 92 10:10:30 GMT
  8. Article-I.D.: sc.159
  9. References: <1992Aug14.130645.26361@cbfsb.cb.att.com>
  10. Reply-To: bryan@sc.sni.ie
  11. Organization: Siemens-Nixdorf Software Development Centre, Dublin
  12. Lines: 81
  13. Followups-To: comp.unix.programmer
  14.  
  15.  
  16. X-Newsreader: Tin 1.1 PL3
  17.  
  18.  
  19. ddewar@cbnewsb.cb.att.com (derek.a.dewar) writes:
  20. :A quick questions about the mmap function in C....
  21.  
  22. Minor semi-pedantic issue: your question should have been directed to
  23. comp.unix.programmer; it's got nothing much to do with the C language in
  24. general, as far as I can see.  Anyway ...
  25.  
  26. :After  mapping the contents of a file into memory using the 
  27. :mmap function, I tried to write something to the mapped segment
  28. :using write(2). I thought this would change the memory copy only,
  29. :but when I use the debugger I find that actaul contents of the file
  30. :have been changed as well as the memory image. My questions is,
  31. :what does "write" actually write to ? The memory image, or the file ?
  32. :(or both ?)
  33.  
  34. Write(2) writes to the file; I'm not sure whether or not changes to the
  35. file in this fashion are reflected in the mapped pages (I think they
  36. are).  You seem to have misinterpreted the use of mmap: it is used to
  37. write to a file without the direct overhead of a write() systems call
  38. for every change you make.  It is _not_ intended to allow you to read in
  39. a file and change its image in memory only.
  40.  
  41. : If it's the file, what function can I use to alter the contents of the
  42. : memory image only, to eliminate any need for disk I/O overhead ?
  43.  
  44. You'll have to roll your own.  Try something like the following:
  45.  
  46. --------
  47.  
  48. #include <sys/types.h>
  49. #include <sys/stat.h>
  50. #include <fcntl.h>
  51.  
  52. struct foo {
  53.     off_t size;
  54.     void *addr;
  55. };
  56.  
  57. struct foo *readall(char *path)
  58. {
  59.     struct stat buf;
  60.     struct foo *bar;
  61.     int fd;
  62.  
  63.     if ((fd = open(path, O_RDONLY)) < 0) {
  64.         perror("open");
  65.         exit(1);
  66.     }
  67.     if (fstat(fd, &buf) < 0) {
  68.         perror("fstat");
  69.         exit(1);
  70.     }
  71.     if ((bar = malloc(sizeof(struct foo)) == NULL) {
  72.         perror("malloc");
  73.         exit(1);
  74.     }
  75.     if ((bar->addr = malloc(bar->size = buf.st_size)) == NULL) {
  76.         perror("malloc");
  77.         exit(1);
  78.     }
  79.     if (read(fd, bar->addr, bar->size) < 0) {
  80.         perror("read");
  81.         exit(1);
  82.     }
  83.     return bar;
  84. }
  85.  
  86. --------
  87.  
  88. The above should read the entire file into a dynamically-allocated block
  89. of memory and return a pointer to a structure describing the allocated
  90. block.  It does no checking to see if you're trying to read a fifo or
  91. special file (in which case buf.st_size is undefined).
  92.  
  93.     -- Bryan
  94.  
  95. -- 
  96. Bryan O'Sullivan                                             +353-1-767551 x225
  97. Siemens-Nixdorf Informationssysteme AG                          bryan@sc.sni.ie
  98. Software Development Centre                    "Theory like mist on eyeglasses.
  99. Dublin                                          Obscure facts." -- Charlie Chan
  100.