public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Bernd Edlinger <bernd.edlinger@hotmail.de>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	Richard Biener <rguenther@suse.de>,
	Jakub Jelinek <jakub@redhat.com>, Jeff Law <law@redhat.com>,
	Martin Sebor	<msebor@gmail.com>
Subject: Re: [PATCH] Handle overlength strings in the C FE
Date: Wed, 01 Aug 2018 16:04:00 -0000	[thread overview]
Message-ID: <alpine.DEB.2.20.1808011557190.18075@digraph.polyomino.org.uk> (raw)
In-Reply-To: <AM5PR0701MB26578DF7C6DA998944B41E5BE42D0@AM5PR0701MB2657.eurprd07.prod.outlook.com>

On Wed, 1 Aug 2018, Bernd Edlinger wrote:

> On 07/30/18 17:49, Joseph Myers wrote:
> > On Mon, 30 Jul 2018, Bernd Edlinger wrote:
> > 
> >> Hi,
> >>
> >> this is how I would like to handle the over length strings issue in the C FE.
> >> If the string constant is exactly the right length and ends in one explicit
> >> NUL character, shorten it by one character.
> > 
> > I don't think shortening should be limited to that case.  I think the case
> > where the constant is longer than that (and so gets an unconditional
> > pedwarn) should also have it shortened - any constant that doesn't fit in
> > the object being initialized should be shortened to fit, whether diagnosed
> > or not, we should define GENERIC / GIMPLE to disallow too-large string
> > constants in initializers, and should add an assertion somewhere in the
> > middle-end that no too-large string constants reach it.
> > 
> 
> Okay, there is an update following your suggestion.

It seems odd to me to have two separate bits of code dealing with reducing 
the length, rather than something like

if (too long)
  {
    /* Decide whether to do a pedwarn_init, or a warn_cxx_compat warning,
       or neither.  */
    /* Shorten string, in either case.  */
  }

The memcmp with "\0\0\0\0" is introducing a hidden assumption that any 
sort of character in strings is never more than four bytes.  It also seems 
unnecessary, in that ultimately the over-long string should be shortened 
regardless of whether what's being removed is a zero character or not.

It should not be possible to be over-long and fail tree_fits_uhwi_p 
(TYPE_SIZE_UNIT (type)), simply because STRING_CST lengths are stored in 
host int (even if, ideally, they'd use some other type to allow for 
STRING_CSTs over 2GB in size).  (And I don't think GCC can represent 
target type sizes that don't fit in unsigned HOST_WIDE_INT anyway; the 
only way for a target type size in bytes to fail to be representable in 
unsigned HOST_WIDE_INT should be if the size is not constant.)

-- 
Joseph S. Myers
joseph@codesourcery.com

  reply	other threads:[~2018-08-01 16:04 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-30 11:51 [PATCH] Fix the damage done by my other patch from yesterday to strlenopt-49.c Bernd Edlinger
2018-07-30 13:03 ` Richard Biener
2018-07-30 14:41   ` Bernd Edlinger
2018-07-30 15:52     ` Joseph Myers
2018-07-30 15:57       ` Jakub Jelinek
2018-07-30 16:01         ` Joseph Myers
2018-07-30 16:28           ` Bernd Edlinger
2018-07-30 16:30             ` Jakub Jelinek
2018-07-30 16:08         ` Bernd Edlinger
2018-07-30 17:33     ` Richard Biener
2018-07-31 12:23   ` Bernd Edlinger
2018-07-30 15:22 ` Martin Sebor
2018-07-30 15:49 ` Joseph Myers
2018-08-01 11:20   ` [PATCH] Handle overlength strings in the C FE Bernd Edlinger
2018-08-01 16:04     ` Joseph Myers [this message]
2018-08-01 20:06       ` Bernd Edlinger
2018-08-01 20:28         ` Marek Polacek
2018-08-01 20:43           ` Joseph Myers
2018-08-09 14:07             ` Bernd Edlinger
2018-08-09 22:08               ` Joseph Myers
2018-08-24 19:59               ` [PATCHv2] " Bernd Edlinger
2018-09-13 21:44                 ` Jeff Law
2018-08-01 17:07     ` [PATCH] " Martin Sebor
2018-08-01 17:37       ` Bernd Edlinger
2018-08-01 21:03       ` Eric Gallager
2018-08-01 22:09         ` Joseph Myers

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=alpine.DEB.2.20.1808011557190.18075@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=bernd.edlinger@hotmail.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=law@redhat.com \
    --cc=msebor@gmail.com \
    --cc=rguenther@suse.de \
    /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).