search

RPGHacker / asar

(Now) official repository of the SNES assembler Asar, originally created by Alcaro
Other
195 stars 42 forks source link

`includeonce` breaks on some equivalent paths #287

Open Underrout opened 11 months ago

Underrout commented 11 months ago

To quote the manual:

The includeonce command places an include guard on the file that is currently being assembled. This prevents it from being assembled again in the same pass.

This is currently not actually true, from what I've seen in 1.81 as well as current versions of 1.9 and 2.0.

While includeonce works fine for something like

incsrc "shared.asm"
incsrc "shared.asm"

it takes very little to break it, something like this is already good enough (in some cases):

incsrc "shared.asm"
incsrc "../shared_code/shared.asm"

The same effect can also be seen when referring to the same file with an absolute and relative path.

As it turns, this problem also seems to appear and disappear depending on the current working directory, so I assume this might also be tied to #253.

Solution: Normalize paths or check them for actual equivalence. Workaround: Use manual include guards: if defined("guard")), etc.

RPGHacker commented 11 months ago

Asar actually does normalize paths for include guards internally. However, I think it might not be reliable when passing the main patch to Asar as a relative path (and maybe there IS some working directory shenanigans going on there). Just for science: Can you reproduce the error when you pass the main patch to Asar as an absolute path?

Anyways, checking paths for true equality unfortunately isn't all that trivial. I'm not sure if we can manage to have a 100% reliable solution.

Underrout commented 11 months ago

However, I think it might not be reliable when passing the main patch to Asar as a relative path (and maybe there IS some working directory shenanigans going on there). Just for science: Can you reproduce the error when you pass the main patch to Asar as an absolute path?

I haven't managed to reproduce it while passing the main patch as an absolute path yet, so that might be the issue. Unfortunate since I do think some tools probably pass relative paths to the asar DLL as well, I've observed the bug in uberasm before.

Anyways, checking paths for true equality unfortunately isn't all that trivial. I'm not sure if we can manage to have a 100% reliable solution.

Idk what C++ version you're bound to but there is fs::equivalent as well as fs::weakl_canonical and fs::canonical.