#3810 Old Space-in-Path Bug Persists in Windows 64 Bit Version

[Rybec Arethdar]

The latest Windows 64 bit version of SDCC (4.4.0) is still afflicted with this bug originally reported in ~2013: https://forum.pololu.com/t/cant-compile-wixel-sdk/6156

Basically, if SDCC is installed in a path with a space somewhere in it (for example, the default location in Windows, C:\Program Files\SDCC), attempting to compile anything (for example, with the command sdcc SPI.c) will produce an error similar to the following:

C:\Program' is not recognized as an internal or external command, operable program or batch file.

Note that the path has been truncated at the space. Presumably it was attempting to run some utility program and failed to correctly format the path (with quotes or such), splitting the path of the utility into two parts where the second was treated as an argument rather than part of the path.

I did try running this with --verbose, in hopes of identifying the utility it was attempting to call out to, without much luck. The only command shown was a call out to sdcpp, with two -isystem arguments containing correctly quoted paths.

-sdcc: sdcpp.exe -nostdinc -Wall -std=c11 --obj-ext=.rel -D__SDCC_CHAR_UNSIGNED -D__SDCC_MODEL_SMALL -D__SDCC_FLOAT_REENT -D__SDCCCALL=0 -D__SDCC=4_4_0 -D__SDCC_VERSION_MAJOR=4 -D__SDCC_VERSION_MINOR=4 -D__SDCC_VERSION_PATCH=0 -DSDCC=440 -D__SDCC_REVISION=14620 -D__SDCC_mcs51 -D__STDC_NO_COMPLEX__=1 -D__STDC_NO_THREADS__=1 -D__STDC_NO_ATOMICS__=1 -D__STDC_NO_VLA__=1 -D__STDC_ISO_10646__=201409L -D__SIZEOF_FLOAT__=4 -D__SIZEOF_DOUBLE__=4 -D__SDCC_BITINT_MAXWIDTH=64 -isystem "C:\Program Files (x86)\SDCC\bin..\include\mcs51" -isystem "C:\Program Files (x86)\SDCC\bin..\include" -xc "SPI.c"

This bug was evidently fixed shortly after the person who started that thread reported it, but only for the Windows 32 bit version. I've uninstalled the broken 64 bit version (as I did not want to relocate it to a path with no spaces, because I'm trying to write a tutorial, and telling the user they have to install to a special path with no spaces would give them more work and reflect quite badly on SDCC itself), and I installed the 32 bit version. It is working as expected thus far (it threw a different error, but it was expected, as I'm fixing a broken project). (The 32 bit version installs under Program Files (x86), which also has a space, but it works perfectly find for me.)

[Janko Stamenović]

The version 4.4.0 is from January 2024 but the first version with the bug fixed is build 15082 [r15082] from November 2024:

https://sourceforge.net/p/sdcc/code/15082/

which was confirmed to work here:

https://sourceforge.net/p/sdcc/bugs/3616/#eb1e/b6e4

To use or try that fix you'd have to download a recent snapshot from:

https://sourceforge.net/projects/sdcc/files/snapshot_builds/x86_64-w64-mingw32-setup/

[Rybec Arethdar]

Ah, terrible timing on my part then. Thanks for the response. Any timeline on an "official" release containing this fix? If possible, I would prefer not to have to tell the users of my tutorial that they'll have to download a snapshot for the 64 bit version to work right.

I've tested the latest 64 bit snapshot (I figure you deserve it for the inconvenience I've caused), and it's working fine for me.

(Since yesterday, I've fixed a lot of the issues in the project I'm working on, and significant components are compiling without issue. I've not tested anything on hardware yet, as this is a library I'm adapting to a different use case, and I haven't fixed enough of it to get to the part where I can test a finished project using the library.)

[Philipp Klaus Krause]

The release process for 4.5.0 is a bit delayed. I still hope to have it ready sometime in the second half of January.

[Rybec Arethdar]

Alright. Thanks! I'm not sure if I'll publish before then or not (I'm aiming to see if Adafruit will include it in their learning tutorials, since it is for one of their products), but I can leave a note and then remove the reference to the snapshot after 4.5.0 is out. (Or maybe I'll just suggest using the 32 bit one until 4.5.0 is out.)

[Janko Stamenović]

Maybe you haven't tested enough 4.4.0 Win32 version: maybe it isn't actually "working" for any possible directory, but just by default for that one where you installed it.

If you read the that bug report: for the reporter C: disk worked but D: disk didn't as on one Windows kept "short names" feature enabled, on another the feature was (by a modern convention) disabled, and only there SDCC didn't work.

So if I'd write something I would still not claim "4.4.0 works for that" without more testing. I'm however certain that snapshots contain a more modern code now.

[Rybec Arethdar]

I did install the 32 bit version (and now the 64 bit snapshot) on D:. That's where I install most things, but occasionally I forget to change the drive letter. (C: is a fairly small SSD on my system.)

I'll mention in the tutorial that the snapshots are more recent and might be a good solution if people run into issues with the official releases.

[Janko Stamenović]

The feature "create short file names" (on which the older versions, including 4.4.0 depended in cases when they were installed in the path with spaces) is something that could be turned on and off on Windows at any moment (manually, but also programmatically, e.g. after an upgrade) . It could also be that the path to which you installed that 32 bit version already had a short file name created, and that only then the feature was turned off, affecting only the new paths afterwards. That way if you install the next 32-bit program in the "Program Files 86" which already had a PROGRA~1 short file name then that the 32-bit program will work, but if you then install the 64-bit program in the path for which there is no short file name, it fails. The "logic" to induce failure is non intuitive if the way it happens isn't considered: that feature of Windows could be turned on and off. (ref: the https://sourceforge.net/p/sdcc/bugs/3616/ report)

[Rybec Arethdar]

Good point. So yeah, I'll direct people to download the most recent snapshot if 4.4.0 doesn't work for them, until 4.5.0 is released.

[Rybec Arethdar]

A side note, because the snapshots don't have documentation (wish I had known that before uninstalling the previous install), I've attempted to go to https://sdcc.sourceforge.net/doc/ as directed in the snapshot documentation README file. I'm getting a 403 (forbidden) error. It would be awesome if that was fixed, so that I could browse the documentation online... (I don't appear to be forbidden from accessing files within that, but I have to already know the filename...)

[Rybec Arethdar]

Oh, I also can't download the documentation found here: https://sdcc.sourceforge.net/snapshots/docs/sdcc-doc.tar.gz

~~403~~ 404 error there as well.

EDIT: I just double checked, because the Windows zip file gives a 404 error. This one is also a 404 error, not a 403 error.

[Janko Stamenović]

One vote more for https://sdcc.sourceforge.net/doc/ not returning error.

NOTE: As of 2008-10-23 directory index display has been disabled by default. This option may be re-enabled by the project by placing a file with the name ".htaccess" with this line:

Options +Indexes

Btw the current weblink (on https://sdcc.sourceforge.net/ ) to the snapshot docs is:

https://sdcc.sourceforge.net/snap.php#Docs

and currently the most recent there

http://sourceforge.net/projects/sdcc/files/snapshot_builds/sdcc-extra-src/sdcc-extra-src-20241218-15179.tar.bz2/download

and

http://sourceforge.net/projects/sdcc/files/snapshot_builds/docs/sdcc-doc-20241218-15179.zip/download

work.

But a day or two ago the latest binary snapshot for Windows x64 I wanted to suggest you couldn't be downloaded even if it was on that page, and the one from the day before could.

But, on another side, that's why there are a few recent not just the latest one.

[Rybec Arethdar]

Thanks! All of those work for me. Maybe it would be a good idea to change the README.TXT in the doc/ directory to have these instead of the broken ones.

[Philipp Klaus Krause]

Yes, we should update that file before the release.

[Philipp Klaus Krause]

I don't think we currently have .tar.gz documentation snapshots, there's only .zip and .tar.bz2.

[Rybec Arethdar]

Yeah, it looks like the links in the doc/ directory of the snapshots are out of date.

[Philipp Klaus Krause]

I've fixed some links in [r15181]. Any other places that have broken links?

[Rybec Arethdar]

The README.TXT file is different for snapshots. That's where the broken links are that I've come across. It looks different from the README.TXT in that commit.

If it helps, the first line of the file is:

There is no documentation included in the snapshot archives.

[Janko Stamenović]

https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc-build/support/readme-snapshot.txt

[Philipp Klaus Krause]

Fixed in [r15182].