Re: New ARI warning Wed Aug 12 01:53:55 UTC 2015

Joel Brobecker
2015-08-14T18:06:01Z

> 295a296,301
> > gdb/location.c:39: regression: PTR: Do not use PTR, ISO C 90 implies 'void *'
> gdb/location.c:39:#define EL_TYPE(PTR) (PTR)->type
> > gdb/location.c:47: regression: PTR: Do not use PTR, ISO C 90 implies 'void *'
> gdb/location.c:47:#define EL_LINESPEC(PTR) ((PTR)->u.addr_string)
> > gdb/location.c:48: regression: PTR: Do not use PTR, ISO C 90 implies 'void *'
> gdb/location.c:48:#define EL_PROBE(PTR) ((PTR)->u.addr_string)
> > gdb/location.c:52: regression: PTR: Do not use PTR, ISO C 90 implies 'void *'
> gdb/location.c:52:#define EL_ADDRESS(PTR) (PTR)->u.address
> > gdb/location.c:56: regression: PTR: Do not use PTR, ISO C 90 implies 'void *'
> gdb/location.c:56:#define EL_EXPLICIT(PTR) (&((PTR)->u.explicit))
> > gdb/location.c:62: regression: PTR: Do not use PTR, ISO C 90 implies 'void *'
> gdb/location.c:62:#define EL_STRING(PTR) ((PTR)->as_string)

I'm wondering what other people think of these. On the one hand,
I'm pretty sure the ARI check is too simplistic and N/A for
this code. On the other hand, I'd like to think that our long
term goal/hope is to have a clean ARI report someday.

We could tell the ARI that these are OK by adding explicit ARI:
markers, but it seems to me that it'd be just as simple to change
the name of the parameter for each macro.

Thoughts?

--
Joel