Ctrl-C handling issues

[Minuous]

The following well-known code is supposed to disable SAS/C Ctrl-C handling:

int  CXBRK(void) { return 0; } /* Disable SAS/C Ctrl-C handling */
void chkabort(void) { ; } /* really */

But it does not seem to work, even when using a SCOPTIONS file containing NOCHECKABORT. My program (AmiArcadia 16.02) checks for Ctrl-C in its console window via SetSignal(). Most of the time it catches these, but sometimes it seems SAS/C's break handler catches it instead, and I get a "** User Abort Requested **" requester with option "CONTINUE" and "ABORT", Abort will shut down the program without closing the window etc, Continue lets the program continue and the Ctrl-C is ignored (my break handler doesn't catch it). This code seems to be inserted by SAS/C, as the relevant text string is embedded in the executable.

So, the question is: why isn't SAS/C's break handling turned off, and how can I do this?

Interesting, the OS4 version which is compiled with GCC apparently has a similar issue.

[lsmart]

I am sure I can´t help you, but maybe you find the souliton if you ask yourself some smart questions like:
* Does your program have multiple tasks?
* Is it started from Workbench, or is the break signal sent via CLI?

Seeing the string look identical is nice, but have you patched your code or used a debugger to ensure it is really read from that memory location?

[lsmart]

One more:

* are all your units of compilation (i.e. before linking) share the same definitions of chkabort and CXBRK?

[Minuous]

>Does your program have multiple tasks?

No.

>Is it started from Workbench, or is the break signal sent via CLI?

It can be started from either, but to reproduce the problem I start it from Workbench and then it auto-opens the CLI window on its first printf().

>are all your units of compilation (i.e. before linking) share the same definitions of chkabort and CXBRK?

No, just one definition for the whole program. I will try a separate definition in each module and see if that helps.

[Minuous]

>Does your program have multiple tasks?

No.

>Is it started from Workbench, or is the break signal sent via CLI?

It can be started from either, but to reproduce the problem I start it from Workbench and then it auto-opens the CLI window on its first printf().

>are all your units of compilation (i.e. before linking) share the same definitions of chkabort and CXBRK?

No, just one definition for the whole program. If I try separate definitions in each module the linker complains about multiply defined symbols.

[mongo]

Try:

int CXBRK(void) { return(0); }   /* Disable SAS Lattice CTRL/C handling */
int chkabort(void) { return(0); }/* really */

[x303]

The solution from Mongo should do the trick. Look here: http://cataclysm.cx/random/amiga/reference/Libraries_Manual_guide/node0019.html

[Minuous]

That doesn't work either. chkabort() is defined in sc:include/dos.h as not returning anything, so making the suggested change causes a "conflict with previous declaration" error.

So I edited sc:include/dos.h to indicate that it returns an int. Now it compiles OK again but the resulting program still has the same problem.

[x303]

Hmmm, checked some old code. All voids, no ints. Works over here.

#ifdef SAS_C
int CXBRK(void) { return(0); }
void __regargs __chkabort(void);
void __regargs __chkabort(void) {}
#endif

Edit:
Btw I thought you developed AA with Stormc (looking at the code). Why bother with sas/c
Ran the latest version of it (16.02) and found no problem with CTRL-C. It says 'Quitting.' and exits the program normally.

[ChaosLord]

I would happily check my code to see how I do it but my Amiga HD is knackered

[ChaosLord]

Btw I thought you developed AA with Stormc (looking at the code). Why bother with sas/c

Because he is intelligent enough to know that SASC Rules Them All

[ChaosLord]

I propose that ur prob is caused by: you have some sort of nonstandard Shell or Console device installed.  Or you have some evil hack installed (MCP, etc.) that is causing the problem.

[x303]

If you wanna check out the _cxbrk routine, it's hidden in sc:source :idea:

[lsmart]

>it auto-opens the CLI window on its first printf().

You are using printf? Doesn't this mean you are including and linking some standard C-Library stuff, which might include its own definitions for handling BRK? Are you using your own startup code?

Maybe ChaosLord is right. Try it on a "virgin Workbench". How often does the problem occur? You could write a small program/loop that does nothing but start AA (or better a third small programm that just shows the CTRL-C problem) and then send BRK .

[Minuous]

@x303:

>Btw I thought you developed AA with Stormc (looking at the code). Why bother with sas/c

No, the release builds are built with SAS/C. In theory it is supposed to be compilable with StormC but I have not tried this with any recent version. IIRC I ran into some StormC code generation bugs. Report+ and Handy are built with StormC but the rest of my software is built with SAS/C.

>Ran the latest version of it (16.02) and found no problem with CTRL-C. It says 'Quitting.' and exits the program normally.

The actual scenario to reproduce the behaviour is this: Start AmiArcadia from WB. Switch to Galaxia. Turn on "Log inefficient code". Activate the resulting console window. Press Ctrl-C. About three-quarters of the time it says "Quitting" and quits cleanly, the other quarter of the time it is getting intercepted by SAS/C and the "** User Abort Requested **" comes up.

@Ismart/ChaosLord:

>Are you using your own startup code?

No.

>I propose that ur prob is caused by: you have some sort of nonstandard Shell or Console device installed. Or you have some evil hack installed (MCP, etc.) that is causing the problem.
>Try it on a "virgin Workbench".

OK, disabled everything in WBStartup, also disabled KingCON. Same behaviour occurs.