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

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.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org