home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 063 < prev    next >
Internet Message Format  |  1990-12-05  |  1KB
  1. From std-unix-request@uunet.uu.net  Mon Aug 27 23:51:26 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA02223; Mon, 27 Aug 90 23:51:26 -0400
  4. Posted-Date: 27 Aug 90 15:11:00 GMT
  5. Received: by cs.utexas.edu (5.64/1.74) 
  6. From: Don_Lewine@dgc.ceo.dg.com
  7. Newsgroups: comp.std.unix
  8. Subject: Meaning of _PC_PATH_MAX
  9. Message-Id: <465@usenix.ORG>
  10. Sender: std-unix@usenix.ORG
  11. X-Submissions: std-unix@uunet.uu.net
  12. Date: 27 Aug 90 15:11:00 GMT
  13. Reply-To: std-unix@uunet.uu.net
  14. To: std-unix@uunet.uu.net
  15.  
  16. From:  Don_Lewine@dgc.ceo.dg.com
  17.  
  18. IEEE Std 1003.1-1988 paragraph 5.7.1.2 note 5 describes the value 
  19. returned by pathconf() when _PC_PATH_MAX is used as an argument as, 
  20. "The maximum length of a relative pathname when the specified 
  21. directory is the working directory."
  22.  
  23. I have tried this on several POSIX.1 systems.  None of them seem to 
  24. enforce the maximum.  In fact they all return a constant (say, 1024) 
  25. even if the path given to pathconf() is already longer than that.
  26.  
  27. Is this conforming behavior?
  28.  
  29. If it is conforming, how should a portable application determine the 
  30. longest pathname a user can specify?  
  31.  
  32. What about _PC_NAME_MAX?  May readdir() return a longer name than the 
  33. value returned by pathconf() for that directory?
  34.  
  35. Volume-Number: Volume 21, Number 63
  36.  
  37.