public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Tadeus Prastowo <0x66726565@gmail.com>,
	"libc-help@sourceware.org" <libc-help@sourceware.org>
Subject: Re: raise() marked __leaf__ is not C-compliant?
Date: Tue, 27 Oct 2020 15:50:27 -0300	[thread overview]
Message-ID: <25b5791b-5368-7a78-f80d-5ceb2b618d72@linaro.org> (raw)
In-Reply-To: <CAA1YtmtVEcvOOyo+crpNg=p382hyQv47=K3sv1oPgk-AKnN=QA@mail.gmail.com>



On 27/10/2020 13:57, Tadeus Prastowo via Libc-help wrote:
> Hello,
> 
> To quote C18 on the signal() function
> (https://web.archive.org/web/20181230041359/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf),
> Section 7.14.1.1 Paragraph 5:
> 
> If the signal occurs other than as the result of calling the abort or
> raise function, the behavior is undefined if the signal handler refers
> to any object with static or thread storage duration that is not a
> lock-free atomic object other than by assigning a value to an object
> declared as volatile sig_atomic_t
> 
> End quote.
> 
> My understanding is that if my single-threaded program installs a
> signal handler using signal() and the handler is executed as a result
> of calling raise(), then the handler has a defined behavior when the
> handler accesses any object with static storage duration even though
> the object is not qualified using volatile and not of type
> sig_atomic_t.
> 
> If my understanding is incorrect, I would like to have some pointer to
> parts of the C standard that say so.

Unfortunately this is not fully correct, specially if you accessing the 
object outside the signal handler.  As you have noticed in your example, 
compiler can assume the variable 'terminated' won't be modified outside 
the function and apply optimization that avoid read its value from 
memory (most likely GCC will optimize out the '!terminated').

One of the best didactic explanation I have for this is from [1].

[1] https://wiki.sei.cmu.edu/confluence/display/c/SIG31-C.+Do+not+access+shared+objects+in+signal+handlers

  reply	other threads:[~2020-10-27 18:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-27 16:57 Tadeus Prastowo
2020-10-27 18:50 ` Adhemerval Zanella [this message]
2020-10-28  5:47   ` Tadeus Prastowo
2020-10-28  6:13     ` Tadeus Prastowo
2020-10-28  7:33       ` Tadeus Prastowo
2020-10-28 11:53         ` Adhemerval Zanella
2020-10-28 13:19           ` Tadeus Prastowo
2020-10-28 17:34             ` Adhemerval Zanella
2020-10-28 19:23               ` Tadeus Prastowo
2020-10-28 20:17                 ` Adhemerval Zanella
2020-10-29  7:50                   ` Tadeus Prastowo
2020-10-28  8:21 ` Florian Weimer
2020-10-28 12:58   ` Tadeus Prastowo
2020-10-28 17:16     ` Tadeus Prastowo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=25b5791b-5368-7a78-f80d-5ceb2b618d72@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=0x66726565@gmail.com \
    --cc=libc-help@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).