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
jos...@codesourcery.com
