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

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

[GDB Administrator]

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)

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

[Joel Brobecker]

> 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

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

[Keith Seitz]

On 08/14/2015 11:05 AM, Joel Brobecker wrote:
> 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.

I have it on my plate to address this after BuildBot stops harassing me. :-)

My inclination was to fix gdb_ari.sh to recognize this, but I'm just as
happy to simply rename the parameter to "P". [It's a lot less work, too!]

Keith

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

[Joel Brobecker]

> I have it on my plate to address this after BuildBot stops harassing me. :-)

:-)

> My inclination was to fix gdb_ari.sh to recognize this, but I'm just as
> happy to simply rename the parameter to "P". [It's a lot less work, too!]

I would personally KISS and just rename, but enhancing the gdb_ari.sh
script would of course be a better option (but, to be clear, an option
which I personally think is not worth your time - it would be different
if we had that all the time, but that doesn't appear to be the case).

Thanks!
-- 
Joel

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

[Keith Seitz]

On 08/14/2015 11:32 AM, Joel Brobecker wrote:
>> I have it on my plate to address this after BuildBot stops harassing me. :-)
> 
> :-)
> 
>> My inclination was to fix gdb_ari.sh to recognize this, but I'm just as
>> happy to simply rename the parameter to "P". [It's a lot less work, too!]
> 
> I would personally KISS and just rename, but enhancing the gdb_ari.sh
> script would of course be a better option (but, to be clear, an option
> which I personally think is not worth your time - it would be different
> if we had that all the time, but that doesn't appear to be the case).

I've bought into the KISS idea. It's Friday! :-)

I've pushed this as "obvious." [and remembered the ChangeLog]

Keith