[PR c/52952] More precise locations within format strings

Jeff Law law@redhat.com
Wed May 20 16:21:00 GMT 2015


On 05/20/2015 10:08 AM, Manuel López-Ibáñez wrote:
>
>> I don't particularly like file scoped "offset_is_invalid" variable.  It
>> appears that it's only set within check_format_arg, but it's used from a
>> variety of other locations via location_from_offset.  Given the current
>> structure of the code, alternatives would be even uglier.
>
> This comes from the previous version of the patch, but it is not
> necessary anymore, since before using an offset, we try to read the
> string at the location, and if there is no string, the offset is zero.
Ah, well, if it isn't needed, then let's kill it :-)

>
> The variable is set here:
>
> if (TREE_CODE (format_tree) == VAR_DECL
>      && TREE_CODE (TREE_TYPE (format_tree)) == ARRAY_TYPE
>      && (array_init = decl_constant_value (format_tree)) != format_tree
>      && TREE_CODE (array_init) == STRING_CST)
>        {
>      /* Extract the string constant initializer.  Note that this may include
>         a trailing NUL character that is not in the array (e.g.
>         const char a[3] = "foo";).  */
>      array_size = DECL_SIZE_UNIT (format_tree);
>      format_tree = array_init;
>          offset_is_invalid = true;
>        }
>
> to handle this case:
>
> void foo()
> {
>    const char a[] = " %d ";
>    __builtin_printf(a, 0.5);
> }
>
> in such a case, the location we get is the one of the use of 'a', thus
> we cannot get at the actual string " %d " to find an offset. Thus, it
> preserves the current (not ideal) behavior.
>
> OK with offset_is_invalid removed after regtesting?
Yes.

jeff



More information about the Gcc-patches mailing list