PR35503 - warn for restrict pointer

Prathamesh Kulkarni
Thu Oct 13 20:16:00 GMT 2016

On 7 October 2016 at 10:33, Prathamesh Kulkarni
<> wrote:
> On 22 September 2016 at 23:15, Joseph Myers <> wrote:
>> On Thu, 22 Sep 2016, Prathamesh Kulkarni wrote:
>>> Would that be acceptable ? I am not sure how to make %Z check if the
>>> argument has type vec<int> *
>>> since vec<int> is not really a builtin C type.
>>> Could you suggest me a better solution so that the format checker will check
>>> if arg has type vec<int> * instead of checking if it's just a pointer ?
>>> Also for testing, should I create a testcase in g++.dg since
>>> gcc.dg/format/ tests are C-only ?
>> If it's C++-only then it would need to be in g++.dg.
>> The way we handle GCC-specific types in checking these formats is that the
>> code using these formats has to define typedefs which the format-checking
>> code then looks up.  In most cases it can just look up names like
>> location_t or tree, but for HOST_WIDE_INT it looks up
>> __gcc_host_wide_int__ which the user must have defined as a typedef.
>> Probably that's the way to go in this case: the user must do "typedef
>> vec<int> __gcc_vec_int__;" or similar, and the code looks up
>> __gcc_vec_int__.
> Thanks for the suggestions. To keep it simple, instead of vec<int>,
> I made %Z take two args: int *v, unsigned len, and prints elements in
> v having length == len.
> Is that OK ?
> Bootstrapped+tested on x86_64-unknown-linux-gnu.
> As pointed out earlier in the thread, the patch can give false positives because
> it only checks whether parameters are qualified with restrict, not how
> parameters
> are used inside the function. For instance it warned for example 10
> mentioned in n1570
> under section - "Formal definition of restrict".
> Should we keep the warning in Wall or keep it in Wextra ?
> The attached patch enables it with Wall.
Ping for c, c-family changes:

> Thanks,
> Prathamesh
>> --
>> Joseph S. Myers

More information about the Gcc-patches mailing list