CMD.EXE considers file deletion commands not able to delete anything as there's nothing to delete as failed. Of course we don't want to bail out of the Makefile because of missing files to delete. Therefore we ignore the return values with '-'. This change limits this workaround to CMD.EXE.
CMD.EXE considers file deletion commands not able to delete anything as there's nothing to delete as failed. Of course we don't want to bail out of the Makefile because of missing files to delete. Therefore we ignore the return values with '-'. This change limits this workaround to CMD.EXE.
The type needs to change (to array); but, the address shouldn't be changed -- it already points to the first element.
Based on a bug analysis by Daniel Serpell.
Uz classifies his own fix as broken:
http://www.cc65.org/mailarchive/2015-01/11721.html
Although the original issue fixed seemed rather significant looking
back now the regression caused by the (broken) fix seems even more
significant :-(
(reverted from commit 55815ea10c)
======================================================================
Equality problem (Ullrich von Bassewitz)
Neil Stockbridge reported a problem with equality comparisons on
cc65.org's mailing list:
http://www.cc65.org/mailarchive/2014-10/11680.html
Uz provided a fix for it:
http://www.cc65.org/mailarchive/2014-10/11683.html
This pull request ask to add the fix to cc65 on github.
In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714058#55 John Dunning writes on 4/May/2015:
"Hi all. I gather that the preference is to license CC65 and
associated technologies under the zlib license. I hereby give my
approval for any software written by me as part of CC65 and associated
technologies under the zlib license."
The above together with the fact that all subsequent work on cc65 was already licensed under the zlib license means that cc65 can now be licensed altogether under the zlib license.
The starting point is the CALL2051:REM <cmdline> approach. It uses the BASIC input buffer at $200. ProDOS stores the name of the loaded program at $280 (which we want for argv[0]) leaving us with 128 char buffer. If we run the program via exec() we don't need the CALL2051 but only the REM token (which is just one char). So have a maximum cmdline length of 126 (plus a terminating zero).
There's no specification for ProDOS BIN file cmdline parameters so exec() just supports the CALL2051:REM <cmdline> approach. In contrast ProDOS SYS files allow for a 'startup filename'. A ProDOS filename is short than 126 chars so having exec() general cut the cmdline after 126 chars seems reasonable. If the SYS file we exec() allows for less we cut the cmdline further.
Our 'loader.system' SYS file however allows for an unusually 126 char long "startup filename" as it is targeted towards cc65 BIN porgrams with their 126 cmdline length.
