This is the mail archive of the gcc-bugs@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]

PR3609 vs. c_strlen


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.


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