Cc65: Apple ][: CR from keyboard restarts the program with getchar()

[DarwinNE]

Dear all,
I found a strange behavior that I can't explain.

If I compile this file, the program restarts every time I type the return key:
~~~~c

include

int main (void)
{
int c;

printf("Hello world. Type X to exit:\n");
while(c!='X') {
    c=getchar();
    printf("   '%c' -> %d \n",c,c);
}
return 0;

}
~~
Here is the makefile I use to compile and prepare the disk image with Apple Commander:
~~make

I tried with both -t apple2 and -t apple2enh with the same result

cc65_options = -t apple2enh

The complete filename of Apple Commander jar file.

ac-jarfile = ../AppleCommander-macosx-1.6.0.jar

all: test

test:
cl65 $(cc65_options) test.c -o testa
java -jar $(ac-jarfile) -dos140 test.dsk
java -jar $(ac-jarfile) -as test.dsk testa < testa

clean:
rm testa test.dsk
~~~~
I tested it with the Virtual ][ emulator and DOS 3.3.

(I typed return just after G)

Here is the version of Cc65 I am using, running on macOS 10.13.6:
~~
$cl65 --version
cl65 V2.18 - Git 39c0abed
~~
The same issue appears with other standard C functions such as fgets() on stdin.

I am a complete noob with the Apple ][, the problem can come from the emulator or my configuration of Cc65 or Apple Commander, but it is extremely specific. All other things in a large program I am compiling work (using for example CTRL+J instead of return).

I had a look there, and I noticed the 0x0D ascii code has a special treatment:
https://github.com/cc65/cc65/commits/master/libsrc/apple2/read.s
Is that possibly related to the origin of the issue?

Regards,
D.

EDIT: I was reading again the code shown above and I think the printf contains an error as %c expects a character and not an integer. Sorry for this, however, this is not the origin of the issue, as I still obtain a restart if I remove the %c part from the printf.

[oliverschmidt]

You are reading the local variable c without initializing it. With

• that bug fixed
• the latest cc65 revision

I can't reproduce your issue. Please reopen if you come to a different result.

[DarwinNE]

Dear @oliverschmidt, thank you for your reply.
I wanted to write a simple example and I did that too hastily.

I downloaded Cc65 V2.19 (*) and I compiled it.
I tried the following code with the exact same results:
~~~~c

include

int main (void)
{
int c=0;

printf("Hello world. Type X to exit:\n");
while((c=getchar())!='X') {
    printf("   -> %d \n",c);
}
return 0;

}
~~~~
It works for every character, except with CR that restarts the program. I tested the attached disk file with the microM8 emulator, obtaining the same result as in Virtual ][.

test.dsk.zip

Here is a video of the program being loaded in the emulator. I typed CR at second 23.

https://user-images.githubusercontent.com/11355790/102660831-01fc6380-417c-11eb-9c98-38c3a4015495.mov

I would like to reopen the issue, but I can not.

(*) By the way, is it normal that Cc65 V2.19 still reports version V2.18?
~~
$ ./cl65 --version
cl65 V2.18 - N/A
~~

[oliverschmidt]

Please check with https://sourceforge.net/projects/cc65/files/cc65-snapshot-win32.zip telling me

cl65 V2.19 - Git 59c58ac

[oliverschmidt]

By the way, is it normal that Cc65 V2.19 still reports version V2.18?

Unfortunately yes :-(

[DarwinNE]

Please check with https://sourceforge.net/projects/cc65/files/cc65-snapshot-win32.zip telling me

cl65 V2.19 - Git 59c58ac

I'm sorry I can't, I don't have any Windows OS available.

I cloned the current repository (#59c58ac) with Git, I compiled and installed it:

~~
$ cl65 --version
cl65 V2.19 - Git 59c58acb
~~

I get the exact same result.

Is it possible that the executable gets corrupted while using Apple Commander?
EDIT: I tested with Apple Commander 1.4.0 (the "ac" version) and I still get the same result :-(

[oliverschmidt]

Thanks for sharing both the .dsk file and the video. This allowed me to reproduce the issue :-)

It only happens with DOS 3.3 and only if the BASIC interpreter is in a certain state on startup of the cc65 program. In that scenario, printing a CR is interpreted by DOS 3.3 as completing the current command - and the command starting the cc65 program is still "current", so it gets re-executed.

[oliverschmidt]

Fixed with https://github.com/cc65/cc65/commit/0f4cb443b4d34dfceef35c0f9b31abcf69d00c67.

[DarwinNE]

Dear @oliverschmidt
I'm very happy that it could have been useful for you! I just pulled the current version from GitHub and tried it and it works flawlessly!

Thank you very much for your work for the awesome Cc65 and for the fix.

Kind regards,

D.

[oliverschmidt]

Hi D.,

I'm very happy that it could have been useful for you!

Thanks for your cooperation and the very detailed problem description!

Thank you very much for your work for the awesome Cc65 and for the fix.

You're welcome :-)

Regards,
Oliver