On 7 October 2016 at 17:49, David Malcolm <dmalc...@redhat.com> wrote: > On Fri, 2016-10-07 at 10:33 +0530, Prathamesh Kulkarni wrote: >> On 22 September 2016 at 23:15, Joseph Myers <jos...@codesourcery.com> >> 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 6.7.3.1 - "Formal definition of restrict". >> Should we keep the warning in Wall or keep it in Wextra ? >> The attached patch enables it with Wall. >> >> Thanks, >> Prathamesh > > This needs a ChangeLog. > > The changes to diagnostic-core.h and diagnostic.c are OK for trunk, > given a suitable ChangeLog (and could be split into a separate patch if > you like). Thanks, I committed diagnostic.c and diagnostic-core.h changes (with ChangeLog) in r240891.
Thanks, Prathamesh
