From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jLmJy-000052-Jy for mharc-grub-devel@gnu.org; Tue, 07 Apr 2020 07:23:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51409) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLmJw-0008Vo-3A for grub-devel@gnu.org; Tue, 07 Apr 2020 07:23:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jLmJu-0005US-Vw for grub-devel@gnu.org; Tue, 07 Apr 2020 07:23:07 -0400 Received: from mail-wm1-x343.google.com ([2a00:1450:4864:20::343]:33982) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jLmJu-0005Ty-PS for grub-devel@gnu.org; Tue, 07 Apr 2020 07:23:06 -0400 Received: by mail-wm1-x343.google.com with SMTP id c195so109785wme.1 for ; Tue, 07 Apr 2020 04:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=y0rj5R6MXq6ttEsLvHRQwIUU8rPcEq5Rec/BMgPvP98=; b=Mh8Gn5Pwk6AQKJqNlGJxLUzs6ZvOz7UUFPV1C3BPvjgo92l6OMZhnUAAwWOL6k++8/ IN0AtkGbT/zEFQfq7f6qWTnqI5iDTcDuv868JhZ16j3Ek/UuW6iliG98Py3cUePp8PhS ufK1oMSO9asY/X3CMy5QARONIIxRAXydQnLxrP7FcYqFFOwdMfOBppUXh8xA74ETdc5g BsXWjRe85N0IznahTFso8IZPfpDsb8E3a5DomamLDbj+OMptyrVuBW2v4Q0of/r3VUF8 1svFpqNNasaETTnK6FUGdOO216OgR8wNWVwPt3Q/HXsEsvFqrY0qzQEA+sOwOBe1YPAX R+8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=y0rj5R6MXq6ttEsLvHRQwIUU8rPcEq5Rec/BMgPvP98=; b=VGe+Gpr+lYXM2O5TvWsrPwYwa65O6JBYLBXjNo1bPpZuxvOi/03nqicEPGxNU5LGuk gfa9PV7qF96Zm3tRYAVziWIFtGzuD6VAYP0zkb4dhy2ScxJErBvoCV8pe7yCdmVRsVP6 SroFGUXn2nNa7PBwh5q8JQ5Wxb2i9Q9TXYUBVqeWonIPKufNkWQznhdjtW5mfdDkxLCq NGLRNwBElGg2RVS97BcPSltV9HWQpOFtdpTlsdYuRqz0W1BXx7qDH0pQwDxVdrT5J3// 5tNC4j5I/tK2DbjrzJhDewixwfq6tGeHf+utmYn3gPD6ggynBOTdk+mVXEvc1OcNdt00 QZUQ== X-Gm-Message-State: AGi0PuYuTYE9ofOCPM/NSFFRM9HpPkUFeLB406GXBevPJh4QmTXtR/GN MdP7CVppSghpJH7BiStksL5y7g== X-Google-Smtp-Source: APiQypJ+rjtVy6wxMCnCLcpdG4sgc1h3B9x9JA9OoB4iMWcTExrEskLSB3/bLZsXe1msgFQpugo7KQ== X-Received: by 2002:a7b:cd89:: with SMTP id y9mr1971728wmj.102.1586258585496; Tue, 07 Apr 2020 04:23:05 -0700 (PDT) Received: from vanye ([2001:470:1f09:12f0:b26e:bfff:fea9:f1b8]) by smtp.gmail.com with ESMTPSA id z17sm20499394wru.39.2020.04.07.04.23.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Apr 2020 04:23:05 -0700 (PDT) Date: Tue, 7 Apr 2020 12:23:02 +0100 From: Leif Lindholm To: Daniel Kiper Cc: Javier Martinez Canillas , grub-devel@gnu.org, eschwartz@archlinux.org, floppym@gentoo.org, olaf@aepfle.de, phcoder@gmail.com, pjones@redhat.com Subject: Re: [PATCH v2 2/4] configure: Enforce gnu99 C language standard Message-ID: <20200407112302.GN14075@vanye> References: <20200403124503.12779-1-daniel.kiper@oracle.com> <20200403124503.12779-3-daniel.kiper@oracle.com> <0d9659d3-dc03-9f50-8bd6-c62afe0848b2@redhat.com> <20200407104120.ky53dwbi2b3gvbtb@tomti.i.net-space.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200407104120.ky53dwbi2b3gvbtb@tomti.i.net-space.pl> User-Agent: Mutt/1.10.1 (2018-07-13) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::343 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 11:23:09 -0000 On Tue, Apr 07, 2020 at 12:41:20 +0200, Daniel Kiper wrote: > On Tue, Apr 07, 2020 at 11:38:16AM +0200, Javier Martinez Canillas wrote: > > On 4/3/20 2:45 PM, Daniel Kiper wrote: > > > Commit d5a32255d (misc: Make grub_strtol() "end" pointers have safer > > > const qualifiers) introduced "restrict" keyword into some functions > > > definitions. This keyword was introduced in C99 standard. However, some > > > compilers by default may use C89 or something different. This behavior > > > leads to the breakage during builds when c89 or gnu89 is in force. So, > > > let's enforce gnu99 C language standard for all compilers. This way > > > a bit random build issue will be fixed and the GRUB source will be > > > build consistently regardless of type and version of the compiler. > > > > > > It was decided to use gnu99 C language standard because it fixes the > > > issue mentioned above and also provides some useful extensions which are > > > used here and there in the GRUB source. Potentially we can use gnu11 too. > > > However, this may reduce pool of older compilers which can be used to > > > build the GRUB. So, let's live with gnu99 until we do not discover that > > > we strongly require a feature from newer C standard. > > > > > > Signed-off-by: Daniel Kiper > > > --- > > > v2 - suggestions/fixes: > > > - unconditionally enforce gnu99 C language standard > > > (suggested by Leif Lindholm). > > > --- > > > configure.ac | 4 ++++ > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/configure.ac b/configure.ac > > > index b2576b013..fc74ee800 100644 > > > --- a/configure.ac > > > +++ b/configure.ac > > > @@ -80,6 +80,10 @@ if test "x$TARGET_CFLAGS" = x; then > > > TARGET_CFLAGS=-Os > > > fi > > > > > > > I would add a comment here explaining why gnu99 is enforced. > > I am not convinced that we should repeat here what is said in the commit > message... > > > > +BUILD_CFLAGS="-std=gnu99 $BUILD_CFLAGS" > > > +HOST_CFLAGS="-std=gnu99 $HOST_CFLAGS" > > > +TARGET_CFLAGS="-std=gnu99 $TARGET_CFLAGS" > > > + > > > > Do you want to allow distros to override the -std option or do you want to > > always force to use gnu99? If the latter then I think instead it should be: > > > > BUILD_CFLAGS="$BUILD_CFLAGS -std=gnu99" > > HOST_CFLAGS="$HOST_CFLAGS -std=gnu99" > > TARGET_CFLAGS="$TARGET_CFLAGS -std=gnu99" > > I want to allow everybody to override the defaults. In general I think > that we should not impose any artificial limits. If user wants to shoot in > his/her foot he/she should be allowed to do that... In most cases... If we were to prevent builders from overriding, we would also prevent them from overriding with a *higher* version. I think that would be undesirable. Whereas setting it by default and letting it be overridden means if it breaks the build, it's because the builder has requested options no longer supported by the codebase. / Leif