#3616 Error for sdcc calling sdcpp/etc on WIndows non-C drives with path spaces

[bbbbbr]

Note: I'm filing this bug for partially for information purposes, not sure whether it is worth trying to fix. There is a workaround. There is also a possible solution example linked below.

Affected SDCC versions: possibly all versions back to commit 2546(?)

A couple users have reported a problem with SDCC calling the preprocessor on Windows when the sdcc binaries reside in a folder on non-C drives under a path that has spaces.

Apparent Issue
This appears to be a bug caused by a combination of:

• SDCC using GetShortPathName() to avoid problems calling executables which have spaces in their path name
• https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/src/SDCCsystem.c#l131
• Windows now having the 8.3 short filename support turned OFF by default for non-C drives, causing GetShortPathName() to not return a suitable shortened path name without spaces

Workaround
The workaround is to turn on 8.3 short path names for the desired drive

• Run Windows Command as administrator
  -fsutil.exe 8dot3name query D:
  The volume state is: 1 (8dot3 name creation is disabled). The registry state is: 2 (Per volume setting - the default). Based on the above settings, 8dot3 name creation is disabled on D:
• fsutil 8dot3name set D: 0
  Successfully enabled 8dot3name generation on D:
• fsutil.exe 8dot3name query D:
  The volume state is: 0 (8dot3 name creation is enabled). The registry state is: 2 (Per volume setting - the default). Based on the above settings, 8dot3 name creation is enabled on D:
• Only folders created AFTER the setting has been enabled will get 8.3 filename support, renaming folders does NOT appear to generate 8.3 filename support. However it is possible to manually generate a short path name for an existing folder:
• D:\>fsutil file setshortname "D:\My stuff" "mystuf~1"

Possible solution implementation
GBDK's compiler driver ( lcc) seems to have a possible solution using spawnvp() with a shim version for linux/macos. The original implementation was likely written ~20 years ago and had some improvements about 4 years ago for better quoting support. We haven't heard of any issues so far, but that is hard to say with certainty since cross platform path support can be complicated and users don't always report problems.

https://github.com/gbdk-2020/gbdk-2020/blob/825a20758ac5df0a8651736894c7b3d35d7d33c9/gbdk-support/lcc/lcc.c#L566

https://github.com/gbdk-2020/gbdk-2020/blob/825a20758ac5df0a8651736894c7b3d35d7d33c9/gbdk-support/lcc/lcc.c#L457

Example of issue
These are some summarized versions of the issue, I can paste full details if desired.

Failing:

...
sdcc: Calling preprocessor...
sdcc: sdcpp -nostdinc -Wall (snip)
**THIS LINE**

+ D:\My stuff\gbdk\bin\sdcpp.exe -nostdinc -Wall (snip)
sdcc: Generating code...
'D:\My' is not recognized as an internal or external command,
operable program or batch file.

Working:

...
sdcc: Calling preprocessor...
sdcc: sdcpp -nostdinc -Wall  (snip)
**THIS LINE**

+ C:\MYSTUF~1\gbdk\bin\sdcpp.exe -nostdinc -Wall (snip)
sdcc: Generating code...
ignoring nonexistent directory "C:/My stuff/gbdk/bin/../include/sm83"
(snip)

[Janko Stamenović]

Checking the SDCC source, it is written:

 * I don't like this solution, but unfortunately cmd.exe and command.com
 * don't accept something like this:
 * "program" "argument"
 * Cmd.exe accepts the following:
 * ""program" "argument""
 * but command.com doesn't.
 * The following is accepted by both:
 * program "argument"
 *
 * So the most portable WIN32 solution is to use GetShortPathName()

It seems that it was relevant more than 20 years ago, but now...

The command.com is a 16-bit program and it's not used on any NT-based Windows, only on Windows 95, 98 and ME.

And I've just tested cmd.exe on Windows 2000 and it already accepts the "program" "argument" form (see the attached build) so all the newer versions (in the last two decades) must work the same.

Then the solution could possibly be to completely drop the conversion to 8.3 and just quote the zeroth argument, as I wouldn't expect anybody running a new versions of SDCC on a machine/OS which depends on any command.com or on a cmd.exe from previous century.

[Janko Stamenović]

Uff, checking the implementation more, it seems not only about the cmd.exe per se, but about what _popen from the MS library in Windows is willing to accept, which is... (surprise!) ... more complicated.

[Janko Stamenović]

So, the form ""program 0" "argument 1" "argument 2"" works with _popen.

The 4.4.0 32-bit Windows binary already doesn't run on Windows 2000, this API is "from XP on" (attached)

[Janko Stamenović]

Now: Patch #482

https://sourceforge.net/p/sdcc/patches/482/

[Philipp Klaus Krause]

Please try [r15082] or later to see if this work for you now.

[bbbbbr]

Thanks!

Tested this out and it does appear to resolve the issue for path names with a space and 8.3 short name generation turned off. The recent build with the change does not error out under conditions where the old build does.

For this comparison:
-recent build is 15160

• old build is 14560