RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues.

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Mon Mar 2 12:43:08 UTC 2015


Hi Kim,

I agree not to fix this.
I uploaded a new webrev that fixes the remaining issues:
http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.04/

I changed the makefile to only set the flag in gcc 4.8,
changed get_core_path to return -1 and removed the assertions,
and fixed the bracket in graphKit.

Best regards,
  Goetz.

-----Original Message-----
From: Kim Barrett [mailto:kim.barrett at oracle.com] 
Sent: Freitag, 27. Februar 2015 21:34
To: Lindenmaier, Goetz
Cc: hotspot-dev Source Developers
Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues.

On Feb 27, 2015, at 6:59 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> I started to fix the issues you noted, but I'm not sure about this one: 
>> - Result of final jio_snprintf is not checked.

That was one of the issues I recommended not be fixed as part of this changeset, in part to avoid questions like this.

> I think it's on purpose that the result is not checked.  In case of an error
> of the VM, one wants to see as much information as possible. The result 
> of get_core_path is only used for printing, and printing a truncated path 
> still might help to find the core.
> That's also the reason to return strlen and not the result of jio_snprintf.
> 
> Note that jio_snprintf always terminates strings and returns -1 on error.

jio_snprintf also returns -1 for things other than for truncation.  So I disagree with that rationale for not checking the final jio_snprintf result.  But as I said, I would prefer to not delay / derail this change set with this largely unrelated discussion.



More information about the hotspot-dev mailing list