Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > volatile

Reply
Thread Tools

volatile

 
 
Dan Pop
Guest
Posts: n/a
 
      10-15-2003
In <(E-Mail Removed)> Irrwahn Grausewitz <(E-Mail Removed)> writes:

>(E-Mail Removed) (Dan Pop) wrote:
>
>>>>On 12 Oct 2003 22:43:20 GMT, Barry Schwarz
>>>><(E-Mail Removed)> wrote:

><snip>
>>>>>Any proper example would probably be implementation dependent. You
>>>>>haven't told us what system you are using or which other ones you are
>>>>>familiar enough with to understand the example if presented.

><snip>
>>
>>What part of my example was implementation dependent?

>
>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
DESY Zeuthen, RZ group
Email: http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
Dan Pop
Guest
Posts: n/a
 
      10-15-2003
In <bmi8o3$joi$0@216.39.135.211> Barry Schwarz <(E-Mail Removed)> writes:

>On 14 Oct 2003 12:31:29 GMT, (E-Mail Removed) (Dan Pop) wrote:
>
>>In <bmfn99$dio$1@216.39.134.185> Barry Schwarz <(E-Mail Removed)> writes:
>>
>>>On Mon, 13 Oct 2003 13:53:58 +0530, Ravi <(E-Mail Removed)> wrote:
>>>
>>>>On 12 Oct 2003 22:43:20 GMT, Barry Schwarz
>>>><(E-Mail Removed)> wrote:
>>>>
>>>snip
>>>>>Any proper example would probably be implementation dependent. You
>>>>>haven't told us what system you are using or which other ones you are
>>>>>familiar enough with to understand the example if presented.
>>>>
>>>>Linux, Windows or DOS.
>>>>
>>>>TIA.
>>>
>>>Your not welcome. What part of the next paragraph which you
>>>conveniently cut out (which said "And if you did it would be off-topic
>>>here so you are better off asking in a group devoted to your system or
>>>one you understand.") did you not comprehend.

>>
>>What part of my example was implementation dependent?
>>
>>Dan

>
>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
--
Dan Pop
DESY Zeuthen, RZ group
Email: (E-Mail Removed)
 
Reply With Quote
 
 
 
 
Irrwahn Grausewitz
Guest
Posts: n/a
 
      10-15-2003
(E-Mail Removed) (Dan Pop) wrote:

>In <(E-Mail Removed)> Irrwahn Grausewitz <(E-Mail Removed)> writes:
>
>>(E-Mail Removed) (Dan Pop) wrote:
>>>What part of my example was implementation dependent?

>>
>>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?


(<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
--
Irrwahn,
sneaking towards the fire-escape.
--
Irrwahn
((E-Mail Removed))
 
Reply With Quote
 
Barry Schwarz
Guest
Posts: n/a
 
      10-16-2003
On 15 Oct 2003 16:33:21 GMT, (E-Mail Removed) (Dan Pop) wrote:

>In <bmi8o3$joi$0@216.39.135.211> Barry Schwarz <(E-Mail Removed)> writes:
>
>>On 14 Oct 2003 12:31:29 GMT, (E-Mail Removed) (Dan Pop) wrote:
>>
>>>In <bmfn99$dio$1@216.39.134.185> Barry Schwarz <(E-Mail Removed)> writes:
>>>
>>>>On Mon, 13 Oct 2003 13:53:58 +0530, Ravi <(E-Mail Removed)> wrote:
>>>>
>>>>>On 12 Oct 2003 22:43:20 GMT, Barry Schwarz
>>>>><(E-Mail Removed)> wrote:
>>>>>
>>>>snip
>>>>>>Any proper example would probably be implementation dependent. You
>>>>>>haven't told us what system you are using or which other ones you are
>>>>>>familiar enough with to understand the example if presented.
>>>>>
>>>>>Linux, Windows or DOS.
>>>>>
>>>>>TIA.
>>>>
>>>>Your not welcome. What part of the next paragraph which you
>>>>conveniently cut out (which said "And if you did it would be off-topic
>>>>here so you are better off asking in a group devoted to your system or
>>>>one you understand.") did you not comprehend.
>>>
>>>What part of my example was implementation dependent?
>>>
>>>Dan

>>
>>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).
>

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>>
 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      10-16-2003
In <(E-Mail Removed)> Irrwahn Grausewitz <(E-Mail Removed)> writes:

>(E-Mail Removed) (Dan Pop) wrote:
>
>>In <(E-Mail Removed)> Irrwahn Grausewitz <(E-Mail Removed)> writes:
>>
>>>(E-Mail Removed) (Dan Pop) wrote:
>>>>What part of my example was implementation dependent?
>>>
>>>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?

>
>(<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
--
Dan Pop
DESY Zeuthen, RZ group
Email: (E-Mail Removed)
 
Reply With Quote
 
Irrwahn Grausewitz
Guest
Posts: n/a
 
      10-16-2003
(E-Mail Removed) (Dan Pop) wrote:

>In <(E-Mail Removed)> Irrwahn Grausewitz
><(E-Mail Removed)> writes:
>
>> 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.


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
--
Irrwahn
((E-Mail Removed))
 
Reply With Quote
 
=?ISO-8859-1?Q?Johan_Aur=E9r?=
Guest
Posts: n/a
 
      10-17-2003
On Thu, 16 Oct 2003, Dan Pop wrote:

> In <(E-Mail Removed)> Irrwahn Grausewitz <(E-Mail Removed)> writes:
>
> > #include <stdio.h>
> > #include <signal.h>
> >
> > sig_atomic_t gotsig = 0;
> >
> > void handler(int signo)
> > {
> > gotsig = signo;


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?

--
(E-Mail Removed)
 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      10-17-2003
In <(E-Mail Removed) om> =?ISO-8859-1?Q?Johan_Aur=E9r?= <(E-Mail Removed)> writes:

>On Thu, 16 Oct 2003, Dan Pop wrote:
>
>> In <(E-Mail Removed)> Irrwahn Grausewitz <(E-Mail Removed)> writes:
>>
>> > #include <stdio.h>
>> > #include <signal.h>
>> >
>> > sig_atomic_t gotsig = 0;
>> >
>> > void handler(int signo)
>> > {
>> > gotsig = signo;

>
>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
--
Dan Pop
DESY Zeuthen, RZ group
Email: (E-Mail Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ERROR [HY000] [Microsoft][ODBC Microsoft Access Driver]General error Unable to open registry key 'Temporary (volatile) Jet DSN for process 0xffc Thread 0x228 DBC 0x437b94 Jet'. ERROR [IM006] [Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr bazzer ASP .Net 0 03-30-2006 03:16 PM
ERROR [HY000] [Microsoft][ODBC Microsoft Access Driver]General error Unable to open registry key 'Temporary (volatile) Jet DSN for process 0x8fc Thread 0x934 DBC 0x437b94 Jet'. ERROR [IM006] [Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr bazzer ASP .Net 1 03-24-2006 04:20 PM
ERROR [HY000] [Microsoft][ODBC Microsoft Access Driver]General error Unable to open registry key 'Temporary (volatile) Jet DSN for process 0x8fc Thread 0x934 DBC 0x437b94 Jet'. ERROR [IM006] [Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr bazzer ASP .Net 0 03-24-2006 02:22 PM
Use of the Volatile keyword for a pointer to a volatile memory block ben C Programming 5 01-11-2005 05:38 PM
Re: Volatile? Knute Johnson Java 17 07-03-2003 03:31 AM



Advertisments