Bug in -J

[Vladimir Panteleev via Digitalmars-d]

On Saturday, 12 August 2017 at 05:42:21 UTC, Mr. Pib wrote:
> I'm pretty sure that on no OS does the same location mean 
> different things?

I understand what you mean, but just to clarify on the .. thing:

$ mkdir d d/x d/z
$ ln -s d/z x
$ echo foo > d/z/y
$ echo bar > d/x/y
$ cat x/y
foo
+ cat x/../x/y
bar

> 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.

Sounds like you can also work around it using e.g.

enum appRoot = `C:\Temp\`;
debug
     string data = readText(appRoot ~ "a.dat");
else
     enum data = import("a.dat");

(and build with -JC:\Temp).

That should now also work if a.dat is in a subdirectory relative 
to the -J path.

> 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.

Sounds reasonable, the compiler could check if paths start with a 
-J path.