Re: optimizing out string functions when the string contains a NUL

[Ian Lance Taylor <iant@xxxxxxxxxx>]

ohav chochmah <philomath868@xxxxxxxxx> writes:

> On 6/20/12, Ian Lance Taylor <iant@xxxxxxxxxx> wrote:
>> ohav chochmah <philomath868@xxxxxxxxx> writes:
>>
>>> #define HIDDEN "\0this string starts with a NUL"
>>> ...
>>> AFAICT, the puts and printf are both no-ops, as the C-string stops
>>> before it starts.  yet when doing 'gcc -S tst.c -O2 -march=native' or
>>> even 'gcc -S tst.c -O3 -march=native', GCC generates the following:
>>> ...
>>> in short, the printf was removed but not the puts.  which left me
>>> wondering why?
>>
>> You are describing an optimization in which GCC looks in constant string
>> literals passed to puts and truncates them at \0.  Nobody has
>> implemented that optimization.  It sounds like it would affect very very
>> very few programs, so I'm not sure why anybody would bother to implement
>
> right, but then why is the printf omitted entirely?

Because, unlike the uncommon case of using puts with a string literal
containing '\0', it's very common to use printf in a way that can be
optimized.  In particular, if STRING ends with \n, then printf(STRING)
can be optimized to puts(STRING), which is more efficient.  That kind of
code occurs frequently, so the optimization is worth doing, and it has
been implemented.

>> it.  If anything I think it would be more useful to have a warning.  But
>
> a warning is issued for printf (tst.c:8:5: warning: embedded ‘\0’ in
> format [-Wformat-contains-nul]), but not for puts.

This warning is essentially a side-effect.  Since the printf
optimization requires analyzing the string, it's easy to add this check.
It's not a separate and additional warning, as it would be for puts.

Ian