Bug in -J

Mr. Pib via Digitalmars-d digitalmars-d at puremagic.com
Fri Aug 11 22:42:21 PDT 2017


On Saturday, 12 August 2017 at 03:58:30 UTC, Vladimir Panteleev 
wrote:
> On Saturday, 12 August 2017 at 03:52:25 UTC, Mr. Pib wrote:
>> You are making assumptions about me making assumptions... 
>> please don't make any more assumptions or we will be in an 
>> infinite regression ;/
>
> Sorry, maybe I don't understand the question. Maybe you could 
> explain in broader terms the higher-level goal or problem 
> you're trying to solve, and maybe we can recommend a better way?
>
>> If are aware, it has nothing to do with absolute paths as the 
>> bug should also be exhibited with relative paths. It is a 
>> comparison issue of the strings rather than checking to see if 
>> they represent the same physical location.
>>
>> It would be like saying that \x\y is different from \x\..\x\y. 
>> Dmd does a blind comparison, I bet, rather than what it should 
>> be doing. Obviously \x\y are different strings but they are 
>> not different file locations.
>
> Fairly sure we forbid .. out of security considerations.
>
> I don't think this applies to Windows, but on POSIX, depending 
> on how .. is interpreted, \x\y x/y actually can mean a 
> different file from x/../x/y.
>
> It has taken a lot of consideration and research until we even 
> allowed path separators in import paths. For a very long time, 
> they were completely forbidden, and a long time after that, 
> they were forbidden on Windows (because on Windows things can 
> be more complicated due to the various kinds of reparse points 
> and things such as short filenames).
>
>> If that is not the case, then a better error message should be 
>> given.
>
> Feel free to file a diagnostic enhancement request if you have 
> specific suggestions.

I'm pretty sure that on no OS does the same location mean 
different things?

I am not talking about strange stuff but simple stuff.

I have code that loads a file at runtime and requires the 
absolute path. This is only for debugging purposes. When built in 
release, everything is switched over to use imports and embed the 
files in the binary. The same path is used for other things like 
caching/uniqueID but are never actually read from. You see this 
sort of stuff a lot when you open an executable and see hard 
coded paths but obviously never used for file system purposes.

The files and paths are all the same but import doens't seem to 
think so. Adding baseName solves the problem immediately but that 
is a hack. import should know that the path is the same as the 
one specified by -J. The whole point of -J is to specify the path 
for security purposes, right? So why does it matter if I use 
path\filename or baseName(filename)? Both point to the same 
location and both are consistent with -J, import should 
understand that. It is an obvious oversight. But there is an 
obvious programmatic difference between the two versions. 
Luckily, using baseName does fix the problem so it is not a huge 
deal but it is still a bug/issue with import for being ignorant 
of what it is actually doing.





More information about the Digitalmars-d mailing list