All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leif Lindholm <leif@nuviainc.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Javier Martinez Canillas <javierm@redhat.com>,
	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
Date: Tue, 7 Apr 2020 12:23:02 +0100	[thread overview]
Message-ID: <20200407112302.GN14075@vanye> (raw)
In-Reply-To: <20200407104120.ky53dwbi2b3gvbtb@tomti.i.net-space.pl>

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 <daniel.kiper@oracle.com>
> > > ---
> > > 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


  reply	other threads:[~2020-04-07 11:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-03 12:44 [PATCH v2 0/4] Various build and doc fixes Daniel Kiper
2020-04-03 12:45 ` [PATCH v2 1/4] configure: Drop unneeded TARGET_CFLAGS expansion Daniel Kiper
2020-04-03 13:36   ` John Paul Adrian Glaubitz
2020-04-07  9:24   ` Javier Martinez Canillas
2020-04-03 12:45 ` [PATCH v2 2/4] configure: Enforce gnu99 C language standard Daniel Kiper
2020-04-07  9:38   ` Javier Martinez Canillas
2020-04-07 10:41     ` Daniel Kiper
2020-04-07 11:23       ` Leif Lindholm [this message]
2020-04-07 11:37       ` Javier Martinez Canillas
2020-04-07 10:52   ` Leif Lindholm
2020-04-03 12:45 ` [PATCH v2 3/4] INSTALL/configure: Update install doc and configure comment Daniel Kiper
2020-04-07  9:43   ` Javier Martinez Canillas
2020-04-07 11:16   ` Leif Lindholm
2020-04-10 12:05     ` Daniel Kiper
2020-04-20 13:04       ` Leif Lindholm
2020-04-21 14:55         ` Daniel Kiper
2020-04-30 11:40           ` Leif Lindholm
2020-04-03 12:45 ` [PATCH v2 4/4] autogen: Replace -iname with -ipath in find command Daniel Kiper
2020-04-07  9:44   ` Javier Martinez Canillas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200407112302.GN14075@vanye \
    --to=leif@nuviainc.com \
    --cc=daniel.kiper@oracle.com \
    --cc=eschwartz@archlinux.org \
    --cc=floppym@gentoo.org \
    --cc=grub-devel@gnu.org \
    --cc=javierm@redhat.com \
    --cc=olaf@aepfle.de \
    --cc=phcoder@gmail.com \
    --cc=pjones@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.