Branko ÄŒibej <brane@xbc.nu> writes:
> Philip Martin wrote:
>
>>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.
6.7.3/4 talking about type qualifiers
"If the same qualifier appears more than once in the same
specifier-qualifier-list, either directly or via one or more
typedefs, the behaviour is the same as if it appeared once"
That's the bit that xlc gets wrong. I didn't find that the first time
I looked (but then I'm not really a language lawyer, I just play at
the weekend :)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jan 18 15:11:30 2004