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

[via llvm-bugs]

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

Alexander Cherepanov <cherepan at mccme.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #3 from Alexander Cherepanov <cherepan at mccme.ru> ---
> --- Comment #1 from David Majnemer <david.majnemer at gmail.com> ---
> GLibc contains the following:

I wouldn't use the glibc manual as a reference, unlike their code the manual is
quite sloppy (I've filed several bugs about it in the past). And their code
works fine in my testcase.

> The behavior of this function is undefined if copying takes place between
> objects that overlap

This is the same language as in C11.

> —for example, if s is also given as an argument to be
> printed under control of the ‘%s’ conversion.

s is not given as an argument in my testcase so this example is not applicable.

> http://www.gnu.org/software/libc/manual/html_mono/libc.html#Formatted-Output-Functions
>
> The Single Unix Specification Version 4 says the same thing:
> If copying takes place between objects that overlap as a result of a call to
> sprintf() or snprintf(), the results are undefined.

This is more or less the same as in C11 but I don't know why you quote all
those manuals. I've already quoted the same from C11. It's in 7.21.6.6p2.

Well, this rule is not violated in my testcase. The copying by %s is done from
s[3..5] (plus s[6] is read but not copied) to s[0..2]. There is no overlap
here.

> Therefore, I do not believe that LLVM's behavior is indicative of a bug.

Have you considered that there effectively is a sequence point between
processing of %s and writing a terminating null char?

-- 
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/51c898e0/attachment.html>