On 6/28/19 12:47 PM, L A Walsh wrote: > I don't recall reading anything about posix allowing the elimination > of such paths.
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html 4.13: "If a pathname begins with two successive <slash> characters, the first component following the leading <slash> characters may be interpreted in an implementation-defined manner, " Linux has an implementation-defined manner: "// is an alias for /, and therefore may be shortened" Cygwin has an implementation-defined manner: "// is distinct from /, and therefore must be preserved" Note that "may be shortened" is not synonymous with "must be shortened" nor with "must be preserved". So on Linux, preserving "//" is POSIX-compliant, AND shortening "//" to "/" is POSIX-compliant (since both choices comply with the implementation definition). > > If I have an application layer on top of linux that processes those > double slashes, it may or may not work depending on the underlying OS? If your application layer is on top of Linux, then yes, the underlying OS guarantees that your application processing a path beginning with "//" is correct whether it preserves or shortens that path to "/". If you port the source code of an application originally built on Linux to then operate on some other operating system, then the source code is buggy if it shortens the path to "/". But you have to actually check the source code to see if it has that bug - just because 'realpath' in coreutils shortens '//' to '/' on Linux does NOT mean that it is buggy, because the code for realpath has an explicit check (run at configure-time) for whether "//" is distinct from "/" - and on platforms where that check is answered differently than on Linux, the code behaves differently. That is, the coreutils code is self-adapting to the implementation definition of the implementation it is compiled on. > It would useful if bugs were not closed before asking for more > information. They can always be reopened if you provide enough relevant information to show it was closed prematurely. But so far in this case, you have not done so, but merely confirmed my suspicions - you noticed a difference in behavior between Linux and Cygwin, but both behaviors were POSIX-compliant when factoring in the implementation-defined nature of the underlying implementation. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
