RFR: 8080775: Better argument formatting for assert() and friends

[Lindenmaier, Goetz]

Hi David,

Thanks for doing this good change!

Will you address the format-zero-length issue?  -Wno-format-zero-length is not 
working on gcc 4.3 and 4.1.2.  I'll send a workaround for the older compilers, 
but a real fix would be better.

Addressing the files with PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC.
SAP requires us to fix these, therefore I just started to work on this issue.
I edited a lot of the files already. (jvmtiEnter.xsl was most fun :))
 I'll come up with webrevs next week.
So if you don't mind you can leave this to me.  Can you please point me 
to the bugs that are already open for this?
I also can share my work informally if you want to fix them.

Thanks and best regards,
  Goetz.








-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Lindholm
Sent: Donnerstag, 24. September 2015 10:48
To: Kim Barrett
Cc: hotspot-dev at openjdk.java.net
Subject: Re: RFR: 8080775: Better argument formatting for assert() and friends

Kim,

On 2015-09-23 20:36, Kim Barrett wrote:
> On Sep 23, 2015, at 5:37 AM, David Lindholm <david.lindholm at oracle.com> wrote:
>>> src/share/vm/code/nmethod.cpp
>>> 1712       assert(ic->is_clean(), "nmethod " PTR_FORMAT "not clean %s", from, from->method()->name_and_sig_as_C_string());
>>> ...
>>> 2543     fatal("nmethod at " INTPTR_FORMAT " not in zone", this);
>>> ...
>>> 2551     fatal("findNMethod did not find this nmethod (" INTPTR_FORMAT ")", this);
>>> ...
>>> 2556       tty->print_cr("\t\tin nmethod at " INTPTR_FORMAT " (pcs)", this);
>>>
>>> Pre-existing: Don't we need the p2i() dance for the values associated
>>> with the [INT]PTR_FORMAT directives?  The last isn't touched by your
>>> changes, but happens to be nearby.
>> You are correct, but this file (and many others) silences GCC warnings for format strings with PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC at the top of the file. This should absolutely be fixed in all these files, but fixing all these is a major task, and nothing I want to do in this change.
> Thanks for the explanation.  And I see there are already some relevant
> bug reports, though I didn't see any covering the code directory.

I have assigned these bug reports to me now, and I intend to fix all of 
them regardless of directory.


Thanks,
David

>> I think I'll wait for the rest of your comments before sending out a new webrev.
>>
> Great.  I'll try to finish up soon.
>
>