From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-99237-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 2762 invoked by alias); 14 Jan 2019 20:30:22 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 2726 invoked by uid 89); 14 Jan 2019 20:30:21 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=Hx-spam-relays-external:209.85.222.194, H*RU:209.85.222.194, Hx-languages-length:889, fair
X-HELO: mail-qk1-f194.google.com
Return-Path: <carlos@redhat.com>
Subject: Re: Fwd: What can a signal handler do with SIGSTKSZ?
To: Joseph Myers <joseph@codesourcery.com>
Cc: Florian Weimer <fweimer@redhat.com>, Szabolcs Nagy
 <Szabolcs.Nagy@arm.com>, Zack Weinberg <zackw@panix.com>,
 Christian Brauner <christian@brauner.io>, nd <nd@arm.com>,
 GNU C Library <libc-alpha@sourceware.org>
References: <e4215c6e-e8a4-a9b6-d88f-3c54e262711a@redhat.com>
 <CAKCAbMiCaBst_ofjKkH3Ck1CoOV86wPKv3QSkC89XW_zu=1BLA@mail.gmail.com>
 <CAKCAbMiWEk6UZJZPQb9h6GOJ5tWACMUzgg5dUra0ET4bESMotQ@mail.gmail.com>
 <874lafezhe.fsf@oldenburg2.str.redhat.com>
 <CAKCAbMgRFet-aM4wdhr5i+ezbDKxcNXnhTO6yRASGbznk__oZg@mail.gmail.com>
 <87sgxzdjl4.fsf@oldenburg2.str.redhat.com>
 <CAKCAbMig4Ze7V+WsNOvwERZDzbACZPQ_btc1wR69EXNZCc+J7g@mail.gmail.com>
 <61925098-4669-b478-9baf-644818d26a44@arm.com>
 <87d0ozb4c8.fsf@oldenburg2.str.redhat.com>
 <0a995c61-62d6-7b09-8b5d-1d77b33a242d@redhat.com>
 <alpine.DEB.2.21.1901141814460.5510@digraph.polyomino.org.uk>
From: Carlos O'Donell <carlos@redhat.com>
Openpgp: preference=signencrypt
Message-ID: <c92a0eb9-b588-b8b0-b647-055fe7f887fc@redhat.com>
Date: Mon, 14 Jan 2019 20:30:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.1901141814460.5510@digraph.polyomino.org.uk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SW-Source: 2019-01/txt/msg00307.txt.bz2

On 1/14/19 1:19 PM, Joseph Myers wrote:
> On Mon, 14 Jan 2019, Carlos O'Donell wrote:
> 
>> If *I* were a developer I might expect as Zach pointed out, that I can call
>> every function on the list of callable AS-safe functions, at least once,
>> without recursion, and expect them to operate correctly.
>>
>> A test case for this would therefore be a main, that register a handler
>> that exercises *all* functions in the AS-safe list, and then looks for
>> stack corruption at each execution.
> 
> The POSIX AS-safe list, or the functions that are currently documented as 
> AS-safe in glibc (an observed property, not necessarily a commitment to an 
> API)?  (strtold uses a fair amount of stack, for example, and is listed as 
> AS-safe in glibc.)
 
In the comment above I was only considering the POSIX AS-safe list.

-- 
Cheers,
Carlos.