This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] fix a couple of bugs in const string folding (PR 86532)


On 07/23/2018 02:05 AM, Jakub Jelinek wrote:
On Sun, Jul 22, 2018 at 04:47:45PM -0600, Martin Sebor wrote:
No, I mean something like:

$ cat y.c
const char a[2][3] = { "1234", "xyz" };
char b[6];

int main ()
{
   __builtin_memcpy(b, a, 4);
   __builtin_memset(b + 4, 'a', 2);
   __builtin_printf("%.6s\n", b);
}
$ gcc y.c
y.c:1:24: warning: initializer-string for array of chars is too long
  const char a[2][3] = { "1234", "xyz" };
                         ^~~~~~
y.c:1:24: note: (near initialization for 'a[0]')
$ ./a.out
1234aa

but expected would be "123xaa".

Hmm.  I assumed this was undefined in C but after double
checking I'm not sure.  If it's in fact valid and the excess
elements are required to be ignored I'll of course fix it in
a subsequent patch.  Let me find out.

If we just warn about the initializer and treat it some way, an optimization
should not change how the initializer is treated.
The memcpy and memset themselves must be valid and they should just copy
whatever is in the initializer without optimizations.

The calls are valid and the initializer doesn't change with or
without optimization.  The concern is that the string_constant
folds this case and returns the whole initializer rather than
taking care to avoid folding it at all, or returning just
the leading portion(*).

Since the code is undefined (and since there is a warning for
it that's enabled by default) it shouldn't matter what happens
in this case.  But if it's thought to be preferable to do either
of the other two (avoid folding or returning what fits, if
the caller asks for a non-nul terminated array) I'm fine making
that change.

It seems to me that the excessive characters should be stripped
by the front-end.  That way the middle-end won't have to worry
about what to do with apparently contradictory data.

Martin

[*] The initial (non-nul terminated) portion of the string
would only be returned to callers that explicitly request it
and are prepared handle it -- it's not on trunk yet but it is
implemented in the followup patch for bug 86552 as a mechanism
to detect uses of non-nul terminated arrays in string functions.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]