From what I can tell, compiling with either version of gcc seems to result in a compiled executable that will be immediately terminated by the user pressing Ctrl-C - in such a way that this program's own Ctrl-C signal handling is redundant - it never gets a chance to execute.

Before I realised this, I was experimenting with the source code below and trying to find out if pressing Ctrl-C also generates a message that GetMsg() & ReplyMsg() can deal with. But because of gcc's behaviour, I have not been able to learn much.

Does pressing Ctrl-C generate a message? And is there a way to prevent this overbearing termination behaviour of gcc?

(Apologies for this badly formatted source - tabs and spaces aren't welcome on the web...)

/* port1.c - port and message example, run at the smae time as port2.c */
/* From RKM circa 1991-2 */

#include <exec/types.h>
#include <exec/ports.h>
#include <dos/dos.h>
#include <clib/exec_protos.h>
#include <clib/alib_protos.h>
#include <stdio.h>

#ifdef LATTICE
int CXBRK(void) ( return(0); ) /* Disable Lattice CTRL-C handling */
int chkabort(void) (return(0);)
#endif

struct XYMessage
{
struct Message xym_Msg;
WORD xy_X;
WORD xy_Y;
};

void main(int argc, char **argv)
{
struct MsgPort *xyport;
struct XYMessage *xymsg;
ULONG portsig, usersig, signal;
BOOL ABORT = FALSE;

if (xyport = CreatePort("xyport", 0))
{
portsig = 1 << xyport->mp_SigBit; /* Give user a 'break' signal. */
usersig = SIGBREAKF_CTRL_C;

printf("Start port2 in another shell. CTRL-C here when done.\n");
do
{ /* port1 will wait for ever and reply */
signal = Wait(portsig | usersig); /* to messages, until the user breaks. */

/* Since we only have one port that might get messages we */
if (signal & portsig) /* have to reply to, it is not really necessary to test for */
{ /* the portsignal. If there is no message at the port, xymsg */
while(xymsg = (struct XYMessage *)GetMsg(xyport)) /* Simply will be NULL. */
{
printf("port1 received: x = %d y = %d\n", xymsg->xy_X, xymsg->xy_Y);

xymsg->xy_X += 50; /* Since we have not replied yet to the owner of*/
xymsg->xy_Y += 50; /* xymsg, we can change the xymsg data contents */

printf("port1 replying with: x = %d y = %d\n", xymsg->xy_X, xymsg->xy_Y);
ReplyMsg((struct Message *)xymsg);
}
}

if (signal & usersig) /* The user wants to abort. */
{
while(xymsg = (struct XYMessage *)GetMsg(xyport)) /* Make sure port is empty. */
ReplyMsg((struct Message *)xymsg);
ABORT = TRUE;
}
}
while (ABORT == FALSE);

DeletePort(xyport);
}
else printf("Couldn't create 'xyport'\n");
}

[ Edited by ausPPC on 2010/12/14 21:11 ]

It's default system libraries that you link to make an executable that handle these things. Probably in the C run time library.

If you are a newbie C programmer you would be better off avoiding a design that requires Ctrl-C otherwise you'll be stuck on minutiae when you should be writing Hello World.

Are you sure you're compiling your application with the -noixemul switch?

@koan
I'm only using these C examples to try and understand how equivalent PPC assembly programs should behave. Handling Ctrl-C messages (does it generate a message??) is just a stepping stone to something more interesting.

@jacadcaps
Oh no! I forgot about it - I suppose that will make the crucial difference. Also forgot to mention my compile arguments... Thanks for that - I'll go see if I can get the result I wanted...

Much better! Now I'm getting all the extra debug output I wanted... It seems that Ctrl-C does not generate a message... I was having an issue with assuming that it did in an assembly program I was experimenting with earlier...

Hi! You can always use AmigaOS3 compatible functions in MorphOS to play with CTRL+C/D/E/F (source code in PowerD):

Code:

// EOF

ps: sorry for dots instead of spaces/tabs...
bye, MarK.

The problem I was having was failure to use a compiler option that would allow the compiled program to deal with the CtrlC event. Now that I've got a better understanding of this in C and assembler, I can move on to passing messages between programs. This is interesting to me because I have some useful C source that I would like to have compiled and called from my own assembly program, instead, I'm going to try getting the output I want from the C program via message passing.

yes, messages/ports are pretty strong ability of AmigaOS/MorphOS, and allows the communication between different applications in a pretty convenient way. Also take a look at semaphores, they are used for data sharing between different applications.

bye, MarK.