public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Jason Merrill <jason@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>, gcc@gcc.gnu.org
Subject: Re: C89 question: Do we need to accept -Wint-conversion warnings
Date: Tue, 10 Oct 2023 18:38:23 +0200	[thread overview]
Message-ID: <ZSV9/11+S1kl+wuU@tucnak> (raw)
In-Reply-To: <CADzB+2nAMAzbX_KpyVb7Z0eX_4cJMQmW6cxCXqKL-07ZMbOz7g@mail.gmail.com>

On Tue, Oct 10, 2023 at 12:30:52PM -0400, Jason Merrill via Gcc wrote:
> On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc <gcc@gcc.gnu.org>
> wrote:
> 
> > Are these code fragments valid C89 code?
> >
> >   int i1 = 1;
> >   char *p1 = i;
> >
> >   char c;
> >   char *p2 = &c;
> >   int i2 = p2;
> >
> > Or can we generate errors for them even with -std=gnu89?
> >
> > (It will still be possible to override this with -fpermissive or
> > -Wno-int-conversion.)
> >
> 
> Given that C89 code is unlikely to be actively maintained, I think we
> should be permissive by default in that mode.  People compiling with an old
> -std flag are presumably doing it to keep old code compiling, and it seems
> appropriate to respect that.

Yeah, complete agreement here.

> I'm also (though less strongly) inclined to be permissive in C99 mode, and
> only introduce the new strictness by default for C11/C17 modes.

Especially when the default is -std=gnu17 that can be an option as well.

There might be some code in the wild compiled with -std=gnu99 or -std=c99 just
because it wanted to use C99 features back 15-20 years ago and hasn't been
adjusted since then, but it might be better to adjust that if needed and keep
using those flags only when they are needed because the code isn't C11/C17/C2X
ready.

	Jakub


  reply	other threads:[~2023-10-10 16:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-10 11:29 Florian Weimer
2023-10-10 16:30 ` Jason Merrill
2023-10-10 16:38   ` Jakub Jelinek [this message]
2023-10-10 17:06     ` Florian Weimer
2023-10-10 17:38       ` Joel Sherrill
2023-10-11  7:36   ` David Brown
2023-10-11  8:10     ` Florian Weimer
2023-10-11  8:51       ` David Brown
2023-10-11 10:17         ` Florian Weimer
2023-10-11 11:28           ` David Brown
2023-10-11 11:38             ` Florian Weimer
2023-10-10 16:38 ` Joseph Myers
2023-10-10 17:07   ` Florian Weimer

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=ZSV9/11+S1kl+wuU@tucnak \
    --to=jakub@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jason@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).