From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id D9CCB3857C5E for ; Tue, 9 Mar 2021 23:58:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D9CCB3857C5E Received: by mail-oi1-x236.google.com with SMTP id d20so17029704oiw.10 for ; Tue, 09 Mar 2021 15:58:49 -0800 (PST) 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:content-transfer-encoding; bh=qK8UtdKkC0s3d/QKjl44u613E0tRhx3br+p04vWe8Og=; b=XWhcM4fZRiG+qe5zRwIMSgyItFekoVy82VgeCu8LLVRr0jlQ5abc0nwjOCzDHr/RIL TMuFYB0t1vAgC4z58VsQZQ9mJ4nWeyarQncz9JkTlAXxrU4ydk8y9vrA25c7EkjdizOX 5qoUyGkAwzmzCQ6rX4CU/Q4S7Fewbpj+XSekP+ObgK0GE+0BQPWTw5vpCA63+Npz5SaM SFTcne7ICCArOIvxGDsT2oSAko25o/Rb0nmw3CSURI20aRV0ZIXR2iHFJfAnR1KB+nxs IjnypXDPnbGk4HeZi3HYniR5ZC4KGbLVa4T8K1nbCNK87pJjSTVMnRdq6u0WUspuRaGL mYqA== X-Gm-Message-State: AOAM530YJYO+t64qisEAtMdBfiAc2eaJPmDsXHWOg6Cx1TK7Ke5CkCMh QbnY/Ojf3mbs4+IF7MwjfbVh4pjf5XMP/zof67Y= X-Google-Smtp-Source: ABdhPJzDWiJdASfsX3c+wQNljsetC4oK2652ygRtaMkV+uXcvu6mhoIHT+uEOvHo0ZxnGb3f76jwLJoN28bJ9RmyDxw= X-Received: by 2002:a54:468f:: with SMTP id k15mr500877oic.58.1615334329352; Tue, 09 Mar 2021 15:58:49 -0800 (PST) MIME-Version: 1.0 References: <1569476484.1894162.1615325397167.ref@mail.yahoo.com> <1569476484.1894162.1615325397167@mail.yahoo.com> In-Reply-To: <1569476484.1894162.1615325397167@mail.yahoo.com> From: "H.J. Lu" Date: Tue, 9 Mar 2021 15:58:13 -0800 Message-ID: Subject: Re: SIGSTKSZ is now a run-time variable To: shwaresyst Cc: Eric Blake , Bruno Haible , Carol Bouchard , bug-m4@gnu.org, GNU C Library , austin-group-l@opengroup.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3028.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 23:58:51 -0000 On Tue, Mar 9, 2021 at 1:53 PM shwaresyst via Libc-alpha wrote: > > > Yes, it's not something an application would expect to need to keep incre= asing, just that's the part of I'd move it to. The definition co= uld also be the max required by a processor family, with sysconf() reportin= g a possible lower value for a particular processor stepping. At least that= way the application that doesn't use sysconf() won't be getting SIGSEGV fa= ults. > > Additionally, I believe the definition can be calculated at compile time = as a multiple of ( sizeof(ucontext_t)+sizeof(overhead_struct(s)) ), whateve= r other overhead applies, so I don't see any real need to use sysconf(). Th= is may mean having to munge a by configure, based on config.gue= ss, but that's not the standard's headache. > At compile time, we don't know what the minimum signal stack size is at run-time, especially 10 years from now. --=20 H.J.