[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: Branko Čibej <brane_at_xbc.nu>
Date: 2004-01-18 08:36:12 CET

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

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.