From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F4D3C433F5 for ; Sun, 19 Sep 2021 19:39:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 02F1C60FED for ; Sun, 19 Sep 2021 19:39:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231849AbhISTkq (ORCPT ); Sun, 19 Sep 2021 15:40:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55402 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231848AbhISTkp (ORCPT ); Sun, 19 Sep 2021 15:40:45 -0400 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D0D8C061574 for ; Sun, 19 Sep 2021 12:39:20 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id q11so24832292wrr.9 for ; Sun, 19 Sep 2021 12:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cKigd1YNgIIHoq8UaJnkjEx2bY1teBrkACrlWI5+8jg=; b=XA7LLjXf7F3xnqr/6W1OzrAnJsrXXyWzfDjNDG3jg2otHkWP8oIA9C8wX0FnV+MmXe 2Ursio3mnmnegqTNq+Nj8KcaBUlfBXt7WEQG7Z0a4C1pjCTgrDwAop/xukc69YwBNtns b1dby+GXy09vx7tqeTmgjf/X8xmucb4WIw56uc23knpDNQUZPCM/VFAQowREuURzB+zo 25hidfaQKRX/Mvz2PydAwY7f0Kj53SKxsmJF4LwCJykI80ZZdzxsfnqH+T6dxrlNPfiL uHwTKm8FyjF1scXvo+5TbVVCj2OZbtMw1RvTA8KfMMbEUA/ytANt9agWmPVCAatEjKdi ufzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cKigd1YNgIIHoq8UaJnkjEx2bY1teBrkACrlWI5+8jg=; b=jurEa+3ipG7i10AI2O3YHmNApRi2wu/IyOYRsELy1/JJ9a9D89GHouKZxBJ3l7Tr8I qkPh0XfPCpFmtZMhzu/LoO2GHd2ZS03vqerP+O5YbliOD8Q6kcGv/ZV1GUGlK3wFFCKx xn9A8iOXJIRdi7I84c/HdUCerLMgpvrOhU+07kONXrwlAWS/A516LhakIMLMRqGDXXMo Ntp7VksU3wcPfhRFrU+yB0e4XrlVR+FZzs0a08O2Ns1R2bl14lQVHQbGsAjx8F2sKzuv 3QL7+HNVlR1B2jTFU2f+xqcfp+K0c0qdvSFnB7dmN3hX3KDnI+pcPUxd9PLJ8oG3SNe/ KQvg== X-Gm-Message-State: AOAM530OQTtPjJR9FkJXXvAGARfqt6id7P9apt1MqsWEnUZTDrm2GUX2 rcFUTx+zdUXjgwD1+5h1hNJxP/O18K8= X-Google-Smtp-Source: ABdhPJyjCtJ9/yqZqbFBQAN0foF5LGJHjyAoimvmdcKjeIJ359Jqf8pZAw2qGFiiYna1xP/c0D+W9g== X-Received: by 2002:a5d:6c67:: with SMTP id r7mr8069613wrz.29.1632080358587; Sun, 19 Sep 2021 12:39:18 -0700 (PDT) Received: from [10.168.10.11] ([170.253.36.171]) by smtp.gmail.com with ESMTPSA id q11sm17338403wmc.41.2021.09.19.12.39.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Sep 2021 12:39:18 -0700 (PDT) Subject: Re: [PATCH v2 4/5] alloca.3: remove GCC faffling from NOTES To: =?UTF-8?B?0L3QsNCx?= Cc: linux-man@vger.kernel.org, "Michael Kerrisk (man-pages)" , "G. Branden Robinson" References: <15f837fb-1212-d974-5102-7b8075153761@gmail.com> <20210917204530.3i2ctkt52gyfu7x7@tarta.nabijaczleweli.xyz> From: "Alejandro Colomar (man-pages)" Message-ID: <3cdc683a-b026-0e76-d039-738cb46142c7@gmail.com> Date: Sun, 19 Sep 2021 21:39:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20210917204530.3i2ctkt52gyfu7x7@tarta.nabijaczleweli.xyz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org Hi наб, On 9/17/21 10:45 PM, наб wrote: > On Wed, Sep 15, 2021 at 09:48:14PM +0200, Alejandro Colomar (man-pages) wrote: >> On 9/14/21 2:41 PM, наб wrote: >> [...] >>> +is required, lest a symbol dependency be emitted. >> Sorry that I'm not a native English speaker. I tried to learn what "lest" >> means, but it's difficult to me, and I'm not sure I understand this line. >> Could you maybe please reword it? :) > > I stand by the "lest" version because it gets less noodly, > but rewritten as "in which case a symbol dependency will be emitted > unless is included", see updated scissor-patch below. Hmm, the wording with 'lest' seems more precise, now that I learnt what it means. I applied the first version. I also applied the rest of the patches in this set (v1). Thanks, Alex > > And, well, neither am I, but that's hardly here or there. > > -- >8 -- > Chunks of glibc headers have no place in documenting an interface, > and (__builtin_)alloca() is an intrinsic, not code; those days are, > thankfully, long gone > > Also, clarify standards behaviour (and remove the (outdated!) > list of cc(1) switches) regarding when alloca() is allowed to not be > ODR-usable > > Signed-off-by: Ahelenia Ziemiańska > --- > man3/alloca.3 | 52 +++++++++++++++------------------------------------ > 1 file changed, 15 insertions(+), 37 deletions(-) > > diff --git a/man3/alloca.3 b/man3/alloca.3 > index 20761b079..913cbe56a 100644 > --- a/man3/alloca.3 > +++ b/man3/alloca.3 > @@ -122,46 +122,24 @@ Do not attempt to > .BR free (3) > space allocated by > .BR alloca ()! > -.SS Notes on the GNU version > -Normally, > -.BR gcc (1) > -translates calls to > +.PP > +By necessity, > .BR alloca () > -with inlined code. > -This is not done when either the > -.IR "\-ansi" , > -.IR "\-std=c89" , > -.IR "\-std=c99" , > -or the > -.IR "\-std=c11" > -option is given > -.BR and > -the header > -.I > -is not included. > -Otherwise, (without an \-ansi or \-std=c* option) the glibc version of > -.I > -includes > +is a compiler built-in, also known as > +.BR __builtin_alloca (). > +By default, modern compilers automatically translate all uses of > +.BR alloca () > +into the built-in, but this is forbidden if standards conformance is requested > +.RI ( "\-ansi" , > +.IR "\-std=c*" ), > +in which case a symbol dependency will be emitted unless > .I > -and that contains the lines: > -.PP > -.in +4n > -.EX > -#ifdef __GNUC__ > -#define alloca(size) __builtin_alloca (size) > -#endif > -.EE > -.in > +is included. > .PP > -with messy consequences if one has a private version of this function. > -.PP > -The fact that the code is inlined means that it is impossible > -to take the address of this function, or to change its behavior > -by linking with a different library. > -.PP > -The inlined code often consists of a single instruction adjusting > -the stack pointer, and does not check for stack overflow. > -Thus, there is no NULL error return. > +The fact that > +.BR alloca () > +is a built-in means it is impossible to take its address > +or to change its behavior by linking with a different library. > .SH BUGS > Due to the nature of the stack, it is impossible to check if the allocation > would overflow the space available, and, hence, neither is indicating an error. > -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/