For diagnosticArgument.cpp, I would prefer adding inline #pragma at only
the sites affected (as suggested by David Holmes), with a comment about
why this is necessary.
But if others decide to go with other solutions, that's fine with me,
too, but please remember to add a comment :-)
Thanks
Hi Yasumasa,
On 10/10/19 21:33, Yasumasa Suenaga wrote:
Hi Serguei,
On 2019/10/11 12:38, serguei.spit...@oracle.com wrote:
Hi Yasumasa,
If this problem is local then I'd prefer variant A as this solution
is local too.
If this problem is observed in other places then variant C would be
Hi Serguei,
On 2019/10/11 12:38, serguei.spit...@oracle.com wrote:
Hi Yasumasa,
If this problem is local then I'd prefer variant A as this solution is local
too.
If this problem is observed in other places then variant C would be better.
This problem might occur in other places in the
Hi Yasumasa,
If this problem is local then I'd prefer variant A as this solution is
local too.
If this problem is observed in other places then variant C would be better.
Thanks,
Serguei
On 10/10/19 18:34, Yasumasa Suenaga wrote:
Hi,
I want to get conclusion of this discussion.
I
Hi David, Serguei, and Alex,
Thank you for reviewing this change and the CSR.
Best regards,
Daniil
On 10/9/19, 5:26 PM, "David Holmes" wrote:
+1 on each
Thanks,
David
On 10/10/2019 9:04 am, Alex Menkov wrote:
> LGTM
> I reviewed CSR as well
>
>
I think Kim has already been clear that he is not a fan of option A:
I'm not a fan of replacing correct and idiomatic uses of strncpy with
strcpy or memcpy. I've suggested in the past that we should turn off
this warning while it is so buggy.
Dan
On 10/10/19 10:02 PM, Yasumasa Suenaga
Thanks Chris!
If others agree with A, I will push webrev.02 .
Yasumasa
On 2019/10/11 10:50, Chris Plummer wrote:
These solutions all have their merits and their warts, but we have to pick
something. I'm ok with with A or C. For B I'd rather you instead used the
#pragma at the warning
These solutions all have their merits and their warts, but we have to
pick something. I'm ok with with A or C. For B I'd rather you instead
used the #pragma at the warning site. If you go with (C), the review
should go out to all of hotspot-dev and build-dev.
Chris
On 10/10/19 6:34 PM,
Hi,
I want to get conclusion of this discussion.
I understand the fix of macroAssembler_x86.hpp is ok, but we have not yet had
conclusion
how we should fix diagnosticArgument.cpp .
I think we can fix diagnosticArgument.cpp as following:
A. Use memcpy()
Hi all,
Please review the fix for
https://bugs.openjdk.java.net/browse/JDK-8224159
webrev:
http://cr.openjdk.java.net/~amenkov/jdk14/jdwp_scopes/webrev/
The change implements IPv6 symbolic scope support in JDWP agent.
Tested
jdk/com/sun/jdi,open/test/hotspot/jtreg/vmTestbase/nsk/jdi
> On Oct 10, 2019, at 4:54 PM, Kim Barrett wrote:
> This is a
> relatively recent warning option (introduced in gcc8, and included in
> -Wall)
Maybe it was added to -Wall in gcc9, since we aren’t seeing these warnings with
gcc8?
> On Oct 10, 2019, at 3:03 AM, David Holmes wrote:
>
> On 10/10/2019 4:50 pm, Chris Plummer wrote:
>> From JBS:
>>
>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14:
>> warning: 'char* strncpy(char*, const char*, size_t)' output truncated
>> before
I thought it was because gcc sees that "len" is always passed in as
strlen(str). It therefore knows without any doubt that you are doing
strncpy() on a nul terminated string, and are copying all but the nul.
However, I missed one case where parse_value() is called and len not
only is not
We have strncpy all over the VM. Why is this the only one that's causing
problems with gcc?
We have one instance in the same file:
void StringArrayArgument::add(const char* str, size_t len) {
if (str != NULL) {
char* ptr = NEW_C_HEAP_ARRAY(char, len+1, mtInternal);
strncpy(ptr, str,
On 10/10/19 1:07 AM, Yasumasa Suenaga wrote:
On 2019/10/10 16:42, David Holmes wrote:
On 10/10/2019 5:25 pm, serguei.spit...@oracle.com wrote:
On 10/9/19 23:39, Chris Plummer wrote:
I think the +1 gets rid of the warning, but it also means there is
no need for the following line that sets
On 10/10/19 12:42 AM, David Holmes wrote:
On 10/10/2019 5:25 pm, serguei.spit...@oracle.com wrote:
On 10/9/19 23:39, Chris Plummer wrote:
I think the +1 gets rid of the warning, but it also means there is
no need for the following line that sets buf[len].
Yes, it was my guess.
Then I agree
(CC:ing serviceability-dev)
On 10/7/19 2:38 PM, Per Liden wrote:
This test is currently disabled for ZGC, but it can easily be enabled by
adjusting the expected log string. ZGC doesn't print "Pause Full", but
it still prints the "(Diagnostic Command)" part.
Also, the test enables gc=debug
I saw the discussion in some OpenJDK mail list #pragma is uncomfortable
because it disables to find implicit bug - but I could not find out them.
It also includes -Wno-* option in GCC.
Yasumasa
On 2019/10/10 17:11, Yasumasa Suenaga wrote:
On 2019/10/10 17:06, serguei.spit...@oracle.com
On 2019/10/10 17:06, serguei.spit...@oracle.com wrote:
On 10/10/19 00:42, David Holmes wrote:
On 10/10/2019 5:25 pm, serguei.spit...@oracle.com wrote:
On 10/9/19 23:39, Chris Plummer wrote:
I think the +1 gets rid of the warning, but it also means there is no need for
the following line that
On 2019/10/10 16:42, David Holmes wrote:
On 10/10/2019 5:25 pm, serguei.spit...@oracle.com wrote:
On 10/9/19 23:39, Chris Plummer wrote:
I think the +1 gets rid of the warning, but it also means there is no need for
the following line that sets buf[len].
Yes, it was my guess.
Then I agree
On 10/10/19 00:42, David Holmes wrote:
On
10/10/2019 5:25 pm, serguei.spit...@oracle.com wrote:
On 10/9/19 23:39, Chris Plummer wrote:
I think the +1 gets rid of the warning,
but it also means there is no need for the following line
On 10/10/2019 5:25 pm, serguei.spit...@oracle.com wrote:
On 10/9/19 23:39, Chris Plummer wrote:
I think the +1 gets rid of the warning, but it also means there is no
need for the following line that sets buf[len].
Yes, it was my guess.
Then I agree this statement must be removed: buf[len] =
On 2019/10/10 16:25, serguei.spit...@oracle.com wrote:
On 10/9/19 23:39, Chris Plummer wrote:
I think the +1 gets rid of the warning, but it also means there is no need for
the following line that sets buf[len].
Yes, it was my guess.
Then I agree this statement must be removed: buf[len] =
On 10/9/19 23:39, Chris Plummer wrote:
I think the +1 gets rid of the warning, but it also means there is no
need for the following line that sets buf[len].
Yes, it was my guess.
Then I agree this statement must be removed: buf[len] = '\0';
Thanks,
Serguei
Chris
On 10/9/19 11:31 PM,
On 10/10/19 12:03 AM, David Holmes wrote:
On 10/10/2019 4:50 pm, Chris Plummer wrote:
On 10/9/19 11:36 PM, David Holmes wrote:
Hi Yasumasa,
On 10/10/2019 3:55 pm, Yasumasa Suenaga wrote:
Hi all,
Please review this change:
JBS: https://bugs.openjdk.java.net/browse/JDK-8232084
webrev:
On 10/10/2019 4:50 pm, Chris Plummer wrote:
On 10/9/19 11:36 PM, David Holmes wrote:
Hi Yasumasa,
On 10/10/2019 3:55 pm, Yasumasa Suenaga wrote:
Hi all,
Please review this change:
JBS: https://bugs.openjdk.java.net/browse/JDK-8232084
webrev:
On 2019/10/10 15:50, Chris Plummer wrote:
On 10/9/19 11:36 PM, David Holmes wrote:
Hi Yasumasa,
On 10/10/2019 3:55 pm, Yasumasa Suenaga wrote:
Hi all,
Please review this change:
JBS: https://bugs.openjdk.java.net/browse/JDK-8232084
webrev:
On 10/9/19 11:36 PM, David Holmes wrote:
Hi Yasumasa,
On 10/10/2019 3:55 pm, Yasumasa Suenaga wrote:
Hi all,
Please review this change:
JBS: https://bugs.openjdk.java.net/browse/JDK-8232084
webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.00/
I tried to build OpenJDK
I think the +1 gets rid of the warning, but it also means there is no
need for the following line that sets buf[len].
Chris
On 10/9/19 11:31 PM, serguei.spit...@oracle.com wrote:
Hi Yasumasa,
The fix in src/hotspot/cpu/x86/macroAssembler_x86.hpp looks Okay.
But I don't understand why you
Hi Yasumasa,
On 10/10/2019 3:55 pm, Yasumasa Suenaga wrote:
Hi all,
Please review this change:
JBS: https://bugs.openjdk.java.net/browse/JDK-8232084
webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.00/
I tried to build OpenJDK on Fedora 30 x64 with GCC 9.2.1, but it was
Hi Yasumasa,
The fix in src/hotspot/cpu/x86/macroAssembler_x86.hpp looks Okay.
But I don't understand why you need this fix in
src/hotspot/share/services/diagnosticArgument.cpp ?:
char* buf = NEW_RESOURCE_ARRAY(char, len + 1);
-
31 matches
Mail list logo
