home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / c / 2572 next >
Encoding:
Text File  |  1992-09-07  |  2.6 KB  |  63 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!spool.mu.edu!darwin.sura.net!convex!news.oc.com!utacfd.uta.edu!rwsys!sneaky!gordon
  3. From: gordon@sneaky.lonestar.org (Gordon Burditt)
  4. Subject: Re: Operations on Files
  5. Message-ID: <Bu1tDr.BEK@sneaky.lonestar.org>
  6. Keywords: ANSI C, files
  7. Organization: Gordon Burditt
  8. References: <robertl.4.715452734@county.lmt.mn.org>
  9. Date: Fri, 4 Sep 1992 10:05:22 GMT
  10. Lines: 51
  11.  
  12. >    The ANSI C standard seems to have a rather odd mix of file 
  13. >operations.  Why didn't they add (over K&R) some other useful file 
  14. >operations such as fileexist, getfirst, getnext, etc?  It seems that 
  15. >these could not be much more dependent on the underlying file system than 
  16. >rename or remove.
  17.  
  18. It is not the job of standards committees to invent a lot of new
  19. functions.  There have been many complaints that the committee went
  20. too far with inventing things already.
  21.  
  22. Adding directory-reading interfaces to ANSI C brings up many issues which
  23. ANSI C would be better off trying not to nail down.  
  24.  
  25. A getfirst/getnext interface (which I assume refers to the CP/M
  26. directory-reading calls which later made their way into MSDOS)
  27. is irritating, because of the contortions needed to loop over all
  28. files, treating the first call specially.  One of the really
  29. irritating problems in CP/M, which may have made its way into MSDOS,
  30. is that there was no documented way to get or restore the "next directory 
  31. entry pointer" (except to the beginning), and further, other file 
  32. operations like creating, deleting, or opening files messed up that
  33. hidden variable.
  34.  
  35. But there's a worse problem.  What do the terms "first" and "next" 
  36. mean, given that the program is doing things to the directory during 
  37. a scan?  Even an opendir()/readdir()/closedir() interface has
  38. this problem.
  39.  
  40. What should the following loop do?  Assume you've got a function
  41. called readdirname() which returns the names (strings) of files
  42. in a directory on successive calls, and returns NULL when it
  43. reaches the end.
  44.  
  45.     char    *fn;
  46.  
  47.     opendirname(name);
  48.     while ((fn = readdirname()) != NULL)
  49.         remove(fn);
  50.  
  51. Does this delete ALL the files?  That assumes that the directory stays
  52. in the same order (except for the file being deleted) during a
  53. remove().  Directories that are maintained sorted, use hashing, or
  54. do automatic compaction either make it impossible to implement
  55. readddirname() on top of the existing OS, or end up skipping files.
  56. Some versions of VMS, at least, had some problems with this. 
  57. The issue gets even more confusing if you throw in another process
  58. that repeatedly creates and deletes "x.tmp".  Does this cause the
  59. loop above to skip some entries OTHER THAN "x.tmp"?
  60.  
  61.                     Gordon L. Burditt
  62.                     sneaky.lonestar.org!gordon
  63.