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