From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-5.7 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 3EE0E1F953 for ; Tue, 9 Nov 2021 18:52:23 +0000 (UTC) Received: from localhost ([::1]:51692 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mkWEI-0005KY-22 for normalperson@yhbt.net; Tue, 09 Nov 2021 13:52:22 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60932) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mkWEA-0005KG-4k for bug-gnulib@gnu.org; Tue, 09 Nov 2021 13:52:14 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36984) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mkWE8-0006W9-5W for bug-gnulib@gnu.org; Tue, 09 Nov 2021 13:52:13 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id CC0321600CE; Tue, 9 Nov 2021 10:52:08 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id DATkJKiyYHTv; Tue, 9 Nov 2021 10:52:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0A2D51600D1; Tue, 9 Nov 2021 10:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bzFR90B_omZk; Tue, 9 Nov 2021 10:52:07 -0800 (PST) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id C83DD1600CE; Tue, 9 Nov 2021 10:52:07 -0800 (PST) Message-ID: <92994199-58a4-7074-1a8e-1c0eb6bfaeb0@cs.ucla.edu> Date: Tue, 9 Nov 2021 10:52:07 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US To: Robbie Harwood , Simon Josefsson References: <20211025215543.111906-1-rharwood@redhat.com> <20211025215543.111906-2-rharwood@redhat.com> <87y26eafbr.fsf@latte.josefsson.org> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: [PATCH 01/11] Fix base64 module to work with grub codebase In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-Spam_score_int: -75 X-Spam_score: -7.6 X-Spam_bar: ------- X-Spam_report: (-7.6 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-3.364, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Patrick Steinhardt , bug-gnulib@gnu.org, Daniel Kiper Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On 10/28/21 12:32, Robbie Harwood wrote: > I don't know why Patrick chose to > not use that instead, but a local test seems to work. Is grub2 intended to be portable to compilers that don't support ? If that's the issue, I suggest that grub2 stop worrying that. Surely every compiler of interest to grub2 supports already. And if you really need to support older compilers, the Gnulib stdbool module should suffice. > grub2 shims out config.h for some build targets (e.g., when not building > utilities). Why does it need to do that? Is this because of cross-building, and where is for the utilities platform which is not the same as the target platform? If so, that suggests that you should run two 'configure' instances, one for the utilities and one for the target, and compile the base64 module twice if it's used in both places. > Longer-term, this problem could be avoided by dropping the const > attribute from isbase64(). Since uchar_in_range is a macro, b64 is > const, and to_uchar() doesn't do anything, the compiler should be able > to infer this anyway. (Adding an inline marker to to_uchar() might help > with this.) What do you think? This could hurt performance as the const attribute is for users of base64.h, not for base64.c. A compiler that merely includes base64.h couldn't infer that isbase64 is const and therefore couldn't do common subexpression elimination, unless you use a heavyweight flag like gcc -flto that isn't practical for some applications.