home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.12 / text0006.txt < prev    next >
Encoding:
Internet Message Format  |  1989-01-07  |  2.0 KB
  1. Cc: std-unix@sally.utexas.edu
  2. Cc: gwyn@brl.arpa
  3. From: henry@utzoo.uucp
  4.  
  5. > I just ran across the first use of the Posix directory access library
  6. > and was disappointed that it is not source-code compatible...
  7. > 
  8. > For some reason the ***&%^$ standard changed the names of the include
  9. > file and the struct!
  10.  
  11. For an excellent reason:  Berkeley's imbecilic decision to use the same
  12. names in the high-level library as in the implementation within the
  13. kernel causes endless trouble on non-Berkeley systems.
  14.  
  15. > The old #include <sys/dir.h>    is now    #include <dirent.h>
  16.  
  17. This is a godsend for those of us who have a *different* directory structure
  18. in our sys/dir.h, namely that used in the kernel.  User-level libraries
  19. have no business parking their include files in the sys subdirectory!
  20.  
  21. >   "    struct direct            struct dirent
  22.  
  23. And this is a godsend for those of us who want to include *other* kernel
  24. include files in the same program as the directory library.  The kernel
  25. include files are so interrelated that it is impossible to pick up, say,
  26. user.h without also picking up dir.h.  Which means that no program that
  27. uses any of the kernel include files can use the directory library, because
  28. the definitions of "struct direct" clash.  Yes, there are legitimate reasons
  29. for using some of the other include files, at least in non-Berkeley systems.
  30. Arguably these reasons themselves indicate problems that really ought to be
  31. fixed -- but we were talking about compatibility with existing practice!
  32.  
  33. In short, I can assure John that there *are* practical problems with using
  34. the Berkeley naming on non-Berkeley systems.  I have run into them too
  35. often myself to do anything but applaud this "incompatibility"; non-Berklix
  36. systems already find it necessary to engage in incompatible kludges to use
  37. the otherwise-praiseworthy directory library.  I am one of the (doubtless
  38. numerous) people who strongly urged P1003 to fix this bug.
  39.  
  40.                 Henry Spencer @ U of Toronto Zoology
  41.                 {allegra,ihnp4,decvax,pyramid}!utzoo!henry
  42.  
  43. Volume-Number: Volume 12, Number 7
  44.  
  45.