From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 347AB383543F for ; Tue, 9 Mar 2021 15:23:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 347AB383543F Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-17-ts4zsXEyN-m4d73Rfjjn7Q-1; Tue, 09 Mar 2021 10:23:18 -0500 X-MC-Unique: ts4zsXEyN-m4d73Rfjjn7Q-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 776E3881D47; Tue, 9 Mar 2021 15:23:16 +0000 (UTC) Received: from [10.3.112.36] (ovpn-112-36.phx2.redhat.com [10.3.112.36]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D0DFF1037E83; Tue, 9 Mar 2021 15:23:15 +0000 (UTC) Subject: Re: SIGSTKSZ is now a run-time variable To: Bruno Haible , Carol Bouchard , bug-m4@gnu.org, glibc list , "austin-group-l@opengroup.org" References: <1841269.IEpri3ZHvQ@omega> From: Eric Blake Organization: Red Hat, Inc. Message-ID: <6ea9c6e1-40dc-19c9-397d-0d812903bd7e@redhat.com> Date: Tue, 9 Mar 2021 09:23:15 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <1841269.IEpri3ZHvQ@omega> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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 15:23:22 -0000 [adding glibc and Austin group lists] On 3/6/21 12:50 PM, Bruno Haible wrote: > Hi, > > Carol Bouchard wrote in : >> A change that was introduced is the >> #define SIGSTKSZ is no longer a statically defined variable. It's value can >> only be determined at run time. >> >> # define SIGSTKSZ sysconf (_SC_SIGSTKSZ) > > This is invalid. POSIX:2018 [1] defines two lists of macros: > > 1) "The header shall define the following macros which shall > expand to integer constant expressions that need not be usable in > #if preprocessing directives:" > > 2) "The header shall also define the following symbolic constants:" > > SIGSTKSZ is in the second list. This implies that it must expand to a constant > and that it must be usable in #if preprocessing directives. The question becomes whether glibc is in violation of POSIX for having made the change, or whether POSIX needs to be amended to allow SIGSTKSZ to be non-preprocessor-safe and/or non-constant. > > Besides being invalid, it is also not needed. The alternate signal stack > needs to be dimensioned according to the CPU and ABI that is in use. For example, > SPARC processors tend to use much more stack space than x86 per function > invocation. Similarly, 64-bit execution on a bi-arch CPU tends to use more stack > space than 32-bit execution, because return addresses and other pointers are > 64-bit vs. 32-bit large. But once you have fixed the CPU and the ABI, there is > no ambiguity any more. > >> This affects m4 code since the code assumes a statically defined variable which >> can be determined at preprocessor time. > > POSIX guarantees this assumption. > >> Please advise how I can get past this. > > Fix your . https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=6c57d320484988e87e446e2e60ce42816bf51d53 shows where glibc made the change, and I've now seen reports of several projects failing to build when using glibc with this change included. > > Bruno > > [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html > > -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org