[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r8343 - trunk/subversion/libsvn_ra_svn

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2004-01-18 15:10:30 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.