[llvm-bugs] [Bug 27526] New: Wrong optimization of sprintf

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=27526

            Bug ID: 27526
           Summary: Wrong optimization of sprintf
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: cherepan at mccme.ru
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

The program:

#include <stdio.h>

int main()
{
  char s[] = "abcdef";
  sprintf(s, "%s", s + 3);
  printf(">%s<\n", s);
}

should print ">def<" but prints "><" when compiled with clang -O. It works fine
when compiled with gcc.

Tested with clang 3.50 and 3.9.0 (trunk 267340) on Debian x86-64.

The reason is that sprintf(..., "%s", ...) is optimized into memcpy(..., ...,
strlen(...) + 1) and glibc's memcpy then presumably copies the string
backwards.
To use memcpy one have to be sure that memory blocks don't overlap. This is
more or less guaranteed for sprintf as its description in C11, 7.21.6.6p2
reads: "If copying takes place between objects that overlap, the behavior is
undefined."

But there is a subtle point here. The 's' conversion specifier doesn't copy the
terminating null from the source string -- C11, 7.21.6.1p8: "Characters from
the array are
written up to (but not including) the terminating null character." IOW copying
non-null chars and writing the terminating null char to the destination array
are two distinct actions. In particular, I don't think C11 requires the
argument for the 's' specifier not to overlap with the (future) terminating
null in the destination array.

Then, C11, 7.21.6p1 reads: "The formatted input/output functions shall behave
as if there is a sequence point after the
actions associated with each specifier." That is, in our example, all non-null
chars have to be fully read and written before the terminating null is written.

To summarize: sprintf(..., "%s", ...) is a two-step process and cannot be
reduced to one memcpy.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160426/1dbc378f/attachment.html>