From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <0x66726565@gmail.com> Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) by sourceware.org (Postfix) with ESMTPS id D59D33858012 for ; Wed, 28 Oct 2020 13:20:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D59D33858012 Received: by mail-il1-x135.google.com with SMTP id n5so4622576ile.7 for ; Wed, 28 Oct 2020 06:20:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FZdbxoF42In9Ss6nATt9bwoiglnzpNgHSm6jxHqj4wQ=; b=kC8m2HuJSOySclDnP+5iQdUF/y8dLOATrclWGfNGGKPs+Bm5S4xJJbH0Zn1tFU0VnV m7J2c0zWsrQ1b/2tSqe/kERMbeVEdaYx8WSoqjntBs3i0nU4cO5aSSLgIASqh/BLO/rp 7R7r8SoHDwXPRE+2gWjmW28U2H3uLyp0LpSUWxsR3txqf4AQ4+fvQ36IxuWvo61WfPj1 5GzaEjKQMgZmpIiTgFBy/hJLfaznPL6jHWY5SGD001XUyQQQ9ts6Q0eWnCn/vdvwPQ58 zsvUkmQ3flnk0hg1x56aGvvjqhSADfJbWlK09GQOXGafyEMUfvlnu8040oN9ap65Jva8 vw4w== X-Gm-Message-State: AOAM5327wzJSS1+1TkxebVUaVipu+nDranzJ2VFO8jjvLcHvI7gj6n2H PtPcwWwBY8OTG7ITqzZmHMBVnoxoVNj0mqe65w== X-Google-Smtp-Source: ABdhPJwit7gXyXDj6cXri4RpaPPs8WtABUC0Df39wxm35cnxxPFPhdGbaIAB6P4mlJXpw+9RNr6h6yP2DT0zent1034= X-Received: by 2002:a92:c213:: with SMTP id j19mr5788534ilo.205.1603891204126; Wed, 28 Oct 2020 06:20:04 -0700 (PDT) MIME-Version: 1.0 References: <25b5791b-5368-7a78-f80d-5ceb2b618d72@linaro.org> <518e2a7c-74a3-d5dc-52c3-3fdddd5f7fa4@linaro.org> In-Reply-To: <518e2a7c-74a3-d5dc-52c3-3fdddd5f7fa4@linaro.org> From: Tadeus Prastowo <0x66726565@gmail.com> Date: Wed, 28 Oct 2020 14:19:52 +0100 Message-ID: Subject: Re: raise() marked __leaf__ is not C-compliant? To: Adhemerval Zanella Cc: "libc-help@sourceware.org" , Florian Weimer Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 13:20:07 -0000 On Wed, Oct 28, 2020 at 12:53 PM Adhemerval Zanella wrote: > > On 28/10/2020 04:33, Tadeus Prastowo wrote: > > > > I meant to say: Glibc-2.30 raise() definitely runs a signal handler, > > and the signal handler can be defined in the current compilation unit > > to use static variables. So, unless the C standard says that > > accessing a non-volatile object with static storage duration from > > within a signal handler that is called synchronously using raise() on > > a normal execution path is an undefined behavior, the marking of > > raise() with __leaf__ makes raise() non-compliant with the C standard. > > > >> May I know your opinion, please? > > The sentence "raise() definitely runs a signal handler" is not really > valid in a portable sense. Afaik neither C nor POSIX states which signals > should be delivered synchronously or asynchronously (although some do > only make sense to be delivered synchronously such as SIGSEGV). > > However, Linux does ran some signals synchronously and I agree that using > leaf attribute is incorrect and lead to this kind of problems. My point is > to be fully portable, you need to assume any signal might be delivered > asynchronously (and C standard specifies the volatile sig_atomic_t for > such cases). Thank you for your response. However, C, including C99, C11, and the latest C18 [1], says: "If a signal handler is called, the raise function shall not return until after the signal handler does." And, POSIX [2] says: "If a signal handler is called, the raise() function shall not return until after the signal handler does." So, the sentence "raise() definitely runs a signal handler" is valid in a portable sense as required by the standards, no? [1] Page 195 of https://web.archive.org/web/20181230041359/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf [2] The raise section of Chapter 3 "System Interfaces" of IEEE Standard for Information Technology---POSIX, Volume 2 "System Interfaces", Issue 7. -- Best regards, Tadeus