https://llvm.org/bugs/show_bug.cgi?id=27526
Alexander Cherepanov <chere...@mccme.ru> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
--- Comment #3 from Alexander Cherepanov <chere...@mccme.ru> ---
> --- Comment #1 from David Majnemer <david.majne...@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.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
