Philip Martin wrote:
>Travis P <svn@castle.fastmail.fm> writes:
>
>
>
>>If the standard is explicit (if you have a section reference that'd be
>>great, if not I'll just look for it when I can get my hands on a
>>copy), then I'll see if I can't feed this back to the xlc developers
>>for them to fix.
>>
>>
>
>7.14/2 talking about <signal.h> states
>
> "the type defined is sig_atomic_t which is the (possibly
> volatile-qualifed) integer type"
>
>so a volatile qualifer in signal.h is permitted.
>
>7.14.1.1/5 talking about signal handlers
>
> "the behaviour is undefined if the signal handler refers to any
> object with static storage duration other than be assigning to an
> object declared as volatile sig_atomic_t"
>
>Since one cannot know whether signal.h provides a volatile qualifier
>the only way to write portable code is to include the volatile
>qualifier in the declaration in the program. To leave it out and rely
>on the qualifier in signal.h would result in code that is invalid when
>using a different implementation (say the next compiler upgrade).
>
>So my conclusion would be that signal.h is permitted to include a
>volatile qualifier, but if it does it must allow a duplicate qualifier
>from the program.
>
>
I'd say this is a defect in the standard. According to these two
paragraphs, you _cannot_ write portable code that uses signals, and xlc
demonstrates this.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jan 18 08:38:42 2004