Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > On 10/01/2012 06:51 AM, Michael Haggerty wrote: >> I think I would advocate that the prefix has to match the front of the >> path exactly (including any trailing slashes) and either >> >> strlen(prefix) == 0 >> or the prefix ended with a '/' >> or the prefix and path are identical >> or the character in path following the matching part is a '/' >> >> This would allow the "is path its own prefix" policy to be decided by >> the caller by either including or omitting a trailing slash on the >> prefix argument. > > Thinking about this more, I don't think it will work. As usual, the > special cases around "/" and "//" make things awkward. I think it is > necessary to have a separate argument to specify whether "path is its > own prefix". > > So I am trying to decide how a function path_in_directory() should work, > and would like to get some feedback, especially on the following two points: > > 1. How should "//" be handled? I don't really have experience with the > peculiar paths that start with "//", so I'm not sure how they should be > handled (or even if the handling needs to be platform-dependent). My > working hypothesis is that the inputs should be normalized by the > caller, so if the caller wants "//" to be treated as equivalent to "/" > then the caller should normalize them *before* calling this function. > Conversely, if the caller passes "//" to the function, that implies that > "//" is distinct from "/" and "//" is considered a proper subdirectory > of "/". See the cases marked with "??????" below. I think POSIX essentially says that anything that begins with "//" is up to the platform, but in practice, the only real-life variant we see is "//dosshare/path/from/root". I agree with your "caller should normalize for the semantics it wants to see". If our lazy programming creates paths with duplicated slashes, we should be fixing such codepaths anyway, so assuming that all paths we create ourselves are free of double-slashes _inside_ a path (i.e. when concatenating a subdirectory name to a directory name), the only case we need to worry about is the double-slashes given by the user (either from the command line, environment, or configuration). The path normalizing logic removes double-slashes inside a path, and I think it should do so while keeping the leading slashes, so that we do not lose distinction between "//dosshare/" and "/dosshare/". > 2. Does there need to be any special related to DOS paths? The ceiling computation may need special case for dos. What does the getcwd() give us? Do we learn only the path within the "current drive" and need to prefix C: (or D: or X:) ourselves if we really want to tell C:\bin and D:\bin apart? Assuming that is the case, the ceiling computation would need a helper function that hides the gory details of prefixing getcwd() result with drive letter or whatever needed, and another that normalizes the elements of the environment variables (I presume that if an element in it without the drive prefix should be normalized to add the current drive letter to it so that the normalized getcwd() result can be compared with it). E.g. if the ceiling list is "D:/a/b;/trash/" then getcwd() returning "/a" alone does not make it outside the ceiling due to "D:/a/b"---our current drive must be "D" for that pattern to kick in. The unqualified /trash would apply to any drive. Does that make sense? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html