On Wed, Apr 26, 2017 at 10:26:56PM +0000, Joseph Myers wrote:
> On Wed, 26 Apr 2017, Martin Sebor wrote:
>
> > Testing my solution for bug 77671 (missing -Wformat-overflow
> > sprintf with "%s") caused a regression in the charset/builtin2.c
> > test for bug 25120 (builtin *printf handlers are confused by
> > -fexec-charset). That led me to realize that like -Wformat
> > itself, the whole gimple-ssa-sprintf pass is oblivious to
> > potential differences between the source character set on
> > the host and the execution character set on the target. As
> > a result, when the host and target sets are different, the
> > pass misinterprets ordinary format characters as special
> > (e.g., parts of directives) and vice versa.
> >
> > The attached patch implements a simple solution to this problem
> > by introducing a mapping between the two sets.
>
> target_strtol10 appears to do no checking for overflow, which I'd expect
> would result in nonsensical results for large width values overflowing
> host long (whereas strtol would reliably return LONG_MAX in such cases).
Also, can't there be a way to shortcut all this processing if the
charsets are the same? And is it a good idea if every pass that needs to do
something with the exec charset chars caches its own results of the
langhook?
Jakub
