RFR(XS) 8170981: Possible access to char array with negative index

Schmidt, Lutz lutz.schmidt at sap.com
Tue Dec 13 10:25:02 UTC 2016


Hi Thomas,

yes we could. But: I tried to keep the fix minimal.

Using outputStream::fill_to() at just one place wouldn’t help much. I would rather remove fixed spacing in all format strings. That converts the fix into a redesign and probably makes it unsuitable for Java9. I do have such a version, though.

Regards,
Lutz


From: Thomas Stüfe <thomas.stuefe at gmail.com<mailto:thomas.stuefe at gmail.com>>
Date: Dienstag, 13. Dezember 2016 um 09:41
To: David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
Cc: Lutz Schmidt <lutz.schmidt at sap.com<mailto:lutz.schmidt at sap.com>>, Rachel Protacio <rachel.protacio at oracle.com<mailto:rachel.protacio at oracle.com>>, "hotspot-runtime-dev at openjdk.java.net<mailto:hotspot-runtime-dev at openjdk.java.net>" <hotspot-runtime-dev at openjdk.java.net<mailto:hotspot-runtime-dev at openjdk.java.net>>
Subject: Re: RFR(XS) 8170981: Possible access to char array with negative index



On Mon, Dec 12, 2016 at 11:19 PM, David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>> wrote:
Hi Lutz,

On 13/12/2016 3:10 AM, Schmidt, Lutz wrote:
Rachel,


thanks a lot for the review. An updated webrev (according to my comments
below) can be found here:
   http://cr.openjdk.java.net/~simonis/webrevs/2016/8170981.v1

I have a few nits with this:

 476     // nSpaces spaces below to adjust the space between the flag value and the

The array is still hardwired to 10 spaces so the comment should still say 10 IMHO - otherwise it sounds like the number of space is dynamically determined.

Please add a trailing comment here:

480     char spaces[] = "          ";  // 10 spaces plus NUL

Style nit:

481     const unsigned int maxFlagLen = 50;
482     const unsigned int nSpaces    = strlen(spaces);

no reason to align the =.

484     st->print("%9s %-*s = ", _type, maxFlagLen-nSpaces, _name);

I'm not quite sure exactly how this code tries to print different length flag names. The above will left-justify and space-pad to at least 40 characters IIUC. If strlen(_name) is < 40 then we later add more padding (up to 10) from the spaces array. Why do we need to do that? Why don't we simply use %-50s in the first place ??


Also, could we not just use outputStream::fill_to() instead of putting those spaces together manually?


Thanks,
David


Regards,
Lutz


On 12.12.16, 17:07, "hotspot-runtime-dev on behalf of Rachel Protacio"
<hotspot-runtime-dev-bounces at openjdk.java.net<mailto:hotspot-runtime-dev-bounces at openjdk.java.net> on behalf of
rachel.protacio at oracle.com<mailto:rachel.protacio at oracle.com>> wrote:

Hi,

I wonder whether it's better to declare

   const char* spaces = "         ";

and then set nSpaces as strlen(spaces), so it's clear that the spaces
string will always be consistent with nSpaces?

Good idea, Rachel! I feel uncomfortable with the ³disconnected²
declarations as well. I had to use a non-constant char array because a
Œ\0¹ is stored into it.

Btw, a ³beautiful² fix would abandon the spaces array altogether and
implement columnar alignment with the help of tty->fill_to(pos). But that
would be a reengineering effort which might not take the Java9 hurdle.


Otherwise, looks good to me.
Rachel

On 12/12/2016 9:45 AM, Schmidt, Lutz wrote:
Hi,

may I please ask for reviews and sponsorship for this small fix in
command
line flag printing?

Bug: https://bugs.openjdk.java.net/browse/JDK-8170981
webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8170981

Thank you!
Lutz






More information about the hotspot-runtime-dev mailing list