volatile

[Dan Pop]

OK, I'm ready to burn my fingers by possibly typing nonsense:

IIRC, according to ISO/IEC 9899:1999 7.14 and 7.14.1

signal(SIGINT, handler);

has several implementation defined aspects.

Which of them is likely to affect the behaviour of my program?

Dan

 

[Dan Pop]

Dan

I responded to Ravi. I don't recall any text in his message relating
to anything you did.

It doesn't matter. My point was that your claim was wrong: there are
*proper* examples that aren't implementation dependent (to the extent that
the implementation supports the intent of the standard).

Dan

 

[Irrwahn Grausewitz]

Which of them is likely to affect the behaviour of my program?

(<glubb> I /knew/ I shouldn't have done it. ;-)

First off, for other readers convenience, here's your example again:

#include <stdio.h>
#include <signal.h>

sig_atomic_t gotsig = 0;

void handler(int signo)
{
gotsig = signo;
}

int main()
{
signal(SIGINT, handler);
puts("Press the interrupt key to exit.");
while (gotsig == 0) ;
printf ("The program received signal %d.\n", (int)gotsig);
return 0;
}

Now, let's see...

1. 7.14#4
An implementation need not generate any of these [1] signals, except
as a result of explicit calls to the raise function. [...]

2. 7.14.1.1#5
If the signal occurs other than as the result of calling the abort or
raise function, the behavior is undefined if the signal handler
refers to any object with static storage duration other than by
assigning a value to an object declared as volatile sig_atomic_t,
[...] ^^^^^^^^

[1] SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV, SIGTERM


BTW: I'm pretty sure there are implementations not providing for an
"interrupt" key.


I did show your mine, now show me yours.

Regards

 

[Barry Schwarz]

It doesn't matter. My point was that your claim was wrong: there are
*proper* examples that aren't implementation dependent (to the extent that
the implementation supports the intent of the standard).

Yes, but he already rejected several as being insufficient (too
abstract?) for his definition of proper. I guess I should have put
proper in quotes for those who didn't read the quoted part of the post
I was replying to.


<<Remove the del for email>>

 

[Dan Pop]

Which of them is likely to affect the behaviour of my program?

(<glubb> I /knew/ I shouldn't have done it. ;-)

First off, for other readers convenience, here's your example again:

#include <stdio.h>
#include <signal.h>

sig_atomic_t gotsig = 0;

void handler(int signo)
{
gotsig = signo;
}

int main()
{
signal(SIGINT, handler);
puts("Press the interrupt key to exit.");
while (gotsig == 0) ;
printf ("The program received signal %d.\n", (int)gotsig);
return 0;
}

Now, let's see...

1. 7.14#4
An implementation need not generate any of these [1] signals, except
as a result of explicit calls to the raise function. [...]

2. 7.14.1.1#5
If the signal occurs other than as the result of calling the abort or
raise function, the behavior is undefined if the signal handler
refers to any object with static storage duration other than by
assigning a value to an object declared as volatile sig_atomic_t,
[...] ^^^^^^^^

That was my point, wasn't it? To get the *expected* behaviour, you need
volatile.

[1] SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV, SIGTERM


BTW: I'm pretty sure there are implementations not providing for an
"interrupt" key.

According to the standard:

SIGINT receipt of an interactive attention signal

So, just use whatever method the implementation provides for sending an
"interactive attention signal" to the program. The fact that there may
be none, doesn't affect the validy of my example. Not any more than
the validity of the canonical "hello world" program is affected by
the fact that any attempt to send output to stdout may fail.

Dan

 

[Irrwahn Grausewitz]

In <[email protected]> Irrwahn Grausewitz


That was my point, wasn't it? To get the *expected* behaviour, you need
volatile.

Stupid me. I should've re-read your /whole/ post instead of just
grabbing the example code. |-)

So, just use whatever method the implementation provides for sending an
"interactive attention signal" to the program. The fact that there may
be none, doesn't affect the validy of my example. Not any more than
the validity of the canonical "hello world" program is affected by
the fact that any attempt to send output to stdout may fail.

Hm, that's true.

Thanks & Regards

 

[=?ISO-8859-1?Q?Johan_Aur=E9r?=]

Anything preventing SIGINT from being greater than 127?

}

int main()
{
signal(SIGINT, handler);
puts("Press the interrupt key to exit.");
while (gotsig == 0) ;
printf ("The program received signal %d.\n", (int)gotsig);
return 0;
}

Now, let's see...

1. 7.14#4
An implementation need not generate any of these [1] signals, except
as a result of explicit calls to the raise function. [...]

2. 7.14.1.1#5
If the signal occurs other than as the result of calling the abort or
raise function, the behavior is undefined if the signal handler
refers to any object with static storage duration other than by
assigning a value to an object declared as volatile sig_atomic_t,
[...] ^^^^^^^^

That was my point, wasn't it? To get the *expected* behaviour, you need
volatile.

How can you expect *anything* when volatile-qualified objects may be
modified in ways unknown to the implementation?

 

[Dan Pop]

Anything preventing SIGINT from being greater than 127?

So what? No one will be able to tell that the program has displayed the
wrong signal number ;-)

}

int main()
{
signal(SIGINT, handler);
puts("Press the interrupt key to exit.");
while (gotsig == 0) ;
printf ("The program received signal %d.\n", (int)gotsig);
return 0;
}

Now, let's see...

1. 7.14#4
An implementation need not generate any of these [1] signals, except
as a result of explicit calls to the raise function. [...]

2. 7.14.1.1#5
If the signal occurs other than as the result of calling the abort or
raise function, the behavior is undefined if the signal handler
refers to any object with static storage duration other than by
assigning a value to an object declared as volatile sig_atomic_t,
[...] ^^^^^^^^

That was my point, wasn't it? To get the *expected* behaviour, you need
volatile.

How can you expect *anything* when volatile-qualified objects may be
modified in ways unknown to the implementation?

The ways unknown to the implementation are supposed to be known to
the programmer. That's why he can have well defined expectations
from programs using volatile-qualified objects, even if the implementation
itself has no clue about what's going to happen.

Dan