2017-06-08 12:11:22 +0100, Geoff Clare: [...] > > OK, but the question remains: "what does it mean?". A "stricter > > requirement" for what? That "." or ".." should not come without > > the other (my interpretation)? Or that they should not be > > treated specially (Mark's interpretation) or that they should be > > returned only once (Robert's interpretation)? > > The condition is poorly worded, but abstracting it helps: > > If condition X is true, one entry shall be returned for dot and > one entry shall be returned for dot-dot; otherwise, they shall not > be returned. > > Thus there are two allowed behaviours. One is to return a single > entry for "." and a single entry for "..". The other is to return > no entry for "." and no entry for "..". > > As far as I can see the only unclear thing is under what circumstances > the two behaviours occur. And since I don't think applications care > one way or the other, we might as well disregard the condition and > treat it as saying that it is unspecified which of the two behaviours > occurs. [...]
OK thanks, unless I'm also misinterpreting what you're saying, we have the same interpretation. And you offer a more correct re-formulation by stressing the "single" part. And going back to my initial: SC> The readdir() spec seems to say that an entry for *both* "." and SC> ".." should be returned if *either* "." or ".." is present in SC> the directory, while "ls -a" should /only/ return the entries SC> present in the directory (with no reference to readdir()). Is SC> that to say that "ls" can't be implemented using "readdir()" SC> (because if a directory contained "." and not "..", that would SC> mean it would print ".." as readdir() would be returning it)? You'd agree there's an inconsistency with "ls -a" which has no similar requirement as readdir() has. -- Stephane
