This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
PR3609 vs. c_strlen
- To: gcc-bugs at gcc dot gnu dot org
- Subject: PR3609 vs. c_strlen
- From: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Date: Mon, 6 Aug 2001 21:25:45 +0200
Hi,
regression PR3609 is caused by this hunk of code in builtins.c:c_strlen():
if (offset_node && TREE_CODE (offset_node) != INTEGER_CST)
{
/* If the string has an internal zero byte (e.g., "foo\0bar"), we can't
compute the offset to the following null if we don't know where to
start searching for it. */
int i;
for (i = 0; i < max; i++)
if (ptr[i] == 0)
return 0;
/* We don't know the starting offset, but we do know that the string
has no internal zero bytes. We can assume that the offset falls
within the bounds of the string; otherwise, the programmer deserves
what he gets. Subtract the offset from the length of the string,
and return that. This would perhaps not be valid if we were dealing
with named arrays in addition to literal string constants. */
return size_diffop (size_int (max), offset_node);
}
I think this optimization is only valid for if c_strlen is called from
builtin_strlen, but not if called from builtin_strcpy and friends. I
suggest adding a flag to the c_strlen call to mark if this optimization is
allowed or not.
Other ideas?
Franz.