[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-serviceability-dev
Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.
From: David Holmes <david.holmes () oracle ! com>
Date: 2016-12-15 8:28:55
Message-ID: 6c59f87f-3cb9-c20c-4ff8-9beb62b72d90 () oracle ! com
[Download RAW message or body]
Hi Goetz,
On 15/12/2016 4:55 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> I'm sorry for that. Our solaris builds were fine.
> I saw the fix. Thanks Erik for fixing! I thought
> windows was the last platform not to support
> declarations in the code.
Me too! And I'm sure we have declarations all over the place in hotspot.
But this isn't hotspot code ...
> Do you mind sharing what compiler choked on this?
> Maybe we can setup our build accordingly.
Solaris Studio 12u4 is our official compiler for JDK 9.
Seems the problem is caused by the use of -xc99=%none which generates a
warning:
warning: declaration can not follow a statement
which warnings-as-errors seems to turn into:
/scratch/dh198349/jdk9-dev/jdk/src/java.base/unix/native/libjli/java_md_solinux.c",
line 519: error: declaration can not follow a statement
(E_DECLARATION_IN_CODE)
> And, is there a wiki page that describes which
> files are owned by which mailing list, and to which
> repo to push the corresponding changes? I've no
> idea on the jdk side where to post etc.
Not in detail. Different files are owned by different OpenJDK groups -
and each group has its mailing list(s). The main four would be:
http://openjdk.java.net/groups/build
http://openjdk.java.net/groups/core-libs
http://openjdk.java.net/groups/hotspot
http://openjdk.java.net/groups/serviceability
> Opening up jprt will be a great step forward!
Yes indeed!
Thanks,
David
> Best regards,
> Goetz.
>
>
>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes@oracle.com]
>> Sent: Wednesday, December 14, 2016 9:55 PM
>> To: Lindenmaier, Goetz <goetz.lindenmaier@sap.com>;
>> daniel.daugherty@oracle.com; 'Dmitry Samersoff'
>> <dmitry.samersoff@oracle.com>; Java Core Libs <core-libs-
>> dev@openjdk.java.net>; serviceability-dev (serviceability-
>> dev@openjdk.java.net) <serviceability-dev@openjdk.java.net>
>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty
>> coding.
>>
>> Hi Goetz,
>>
>> On 14/12/2016 9:46 PM, Lindenmaier, Goetz wrote:
>>>
>>>> object to the change to k_standard.c for the same reason.
>>> Ok, I remove that too.
>>
>> I had not realized this was to be pushed directly to jdk9/dev. It broke
>> builds on Solaris and so was obviously not tested.
>>
>> David
>>
>>> Best regards,
>>> Goetz.
>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes@oracle.com]
>>>> Sent: Mittwoch, 14. Dezember 2016 12:29
>>>> To: Lindenmaier, Goetz <goetz.lindenmaier@sap.com>;
>>>> daniel.daugherty@oracle.com; 'Dmitry Samersoff'
>>>> <dmitry.samersoff@oracle.com>; Java Core Libs <core-libs-
>>>> dev@openjdk.java.net>; serviceability-dev (serviceability-
>>>> dev@openjdk.java.net) <serviceability-dev@openjdk.java.net>
>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty
>>>> coding.
>>>>
>>>> On 14/12/2016 9:00 PM, Lindenmaier, Goetz wrote:
>>>>> Hi,
>>>>>
>>>>> You're right, I had removed the change to e_asin.c.
>>>>
>>>> You only pointed Joe to that file AFAICS. I would expect he would also
>>>> object to the change to k_standard.c for the same reason.
>>>>
>>>>> New webrev anyways:
>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-
>> corlib_s11y/webrev.05/
>>>>>
>>>>> java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing.
>>>>
>>>> Okay. Thanks.
>>>>
>>>> David
>>>>
>>>>> Best regards,
>>>>> Goetz.
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes@oracle.com]
>>>>>> Sent: Mittwoch, 14. Dezember 2016 11:42
>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier@sap.com>;
>>>>>> daniel.daugherty@oracle.com; 'Dmitry Samersoff'
>>>>>> <dmitry.samersoff@oracle.com>; Java Core Libs <core-libs-
>>>>>> dev@openjdk.java.net>; serviceability-dev (serviceability-
>>>>>> dev@openjdk.java.net) <serviceability-dev@openjdk.java.net>
>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and
>> servicabilty
>>>>>> coding.
>>>>>>
>>>>>> On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> I found "8169317: [s390] Various minor bug fixes and adaptions."
>>>>>>> in jdk9/dev this morning, so I thought it has been promoted based
>>>>>>> on some older change. I waited for that quite a while because tests
>>>>>>> in jdk9/dev kept failing on s390.
>>>>>>> How can I get the information when what was promoted? This always
>>>>>>> is a wild guess for me ... as well as when what will be promoted :)
>>>>>>
>>>>>> Yeah there's no notification in the bug report of when hs pushes up to
>>>>>> dev. The changeset email is the only record of exactly when it happens.
>>>>>>
>>>>>>> Do you think the promotion will happen tonight, or will it take
>>>>>>> another week?
>>>>>>
>>>>>> hs goes through Pre-Integration Testing (PIT) before it is pushed to
>>>>>> dev. There have been delays in getting that started and so a delay in it
>>>>>> finishing and being analyzed. It may still be a couple of days.
>>>>>>
>>>>>>> I removed
>>>>>>> - JLI_StrLen(jrepath) + JLI_StrLen(arch) +
>> JLI_StrLen("/lib//jli:")
>>>> +
>>>>>>> + JLI_StrLen(jrepath) + JLI_StrLen(arch) +
>> JLI_StrLen("/lib/jli:") +
>>>>>>> from
>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-
>> corlib_s11y/webrev.04/
>>>>>>
>>>>>> With that gone that file only has the jvmpath rename - which isn't
>>>>>> fixing anything.
>>>>>>
>>>>>> Joe also asked for the fdlibm changes to dropped.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Best regards,
>>>>>>> Goetz.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes@oracle.com]
>>>>>>>> Sent: Mittwoch, 14. Dezember 2016 11:04
>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier@sap.com>;
>>>>>>>> daniel.daugherty@oracle.com; 'Dmitry Samersoff'
>>>>>>>> <dmitry.samersoff@oracle.com>; Java Core Libs <core-libs-
>>>>>>>> dev@openjdk.java.net>; serviceability-dev (serviceability-
>>>>>>>> dev@openjdk.java.net) <serviceability-dev@openjdk.java.net>
>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and
>> servicabilty
>>>>>>>> coding.
>>>>>>>>
>>>>>>>> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> 8066474 has not been promoted.
>>>>>>>>
>>>>>>>> hs has not been able to push up to dev yet.
>>>>>>>>
>>>>>>>>> I'll remove the strlen // fix for aix from this change and
>>>>>>>>> push it without it. I'd like to get this done.
>>>>>>>>
>>>>>>>> I've lost track of what is now left in this set of changes ??
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Goetz.
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes@oracle.com]
>>>>>>>>>> Sent: Donnerstag, 8. Dezember 2016 23:03
>>>>>>>>>> To: daniel.daugherty@oracle.com; Lindenmaier, Goetz
>>>>>>>>>> <goetz.lindenmaier@sap.com>; 'Dmitry Samersoff'
>>>>>>>>>> <dmitry.samersoff@oracle.com>; Java Core Libs <core-libs-
>>>>>>>>>> dev@openjdk.java.net>; serviceability-dev (serviceability-
>>>>>>>>>> dev@openjdk.java.net) <serviceability-dev@openjdk.java.net>
>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and
>>>> servicabilty
>>>>>>>>>> coding.
>>>>>>>>>>
>>>>>>>>>> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote:
>>>>>>>>>>> On 12/8/16 1:59 PM, David Holmes wrote:
>>>>>>>>>>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks for looking at the change. New webrev:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-
>>>>>> corlib_s11y/webrev.04/
>>>>>>>>>>>>>
>>>>>>>>>>>>>> src/java.base/share/native/libjli/java.c
>>>>>>>>>>>>>> As far as I can see the existing code is working perfectly fine.
>>>>>>>>>>>>> Ah, thanks for the explanation, now I got it! Removed.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output
>> string is
>>>>>>>>>>>>>> expanded with:
>>>>>>>>>>>>>> "%s/lib/%s/jli:"
>>>>>>>>>>>>> I first edited this against jdk9/hs, where the arch is gone since
>>>>>>>>>>>>> 8066474,
>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc
>>>>>>>>>>>>> but the // was not adapted. Then I moved the change to
>> jdk9/dev
>>>>>>>> because
>>>>>>>>>>>>> I thought I have to push it there. And yes, in that coding //
>> would
>>>>>>>>>>>>> be correct.
>>>>>>>>>>>>> So I have to wait until hs is promoted ...
>>>>>>>>>>>>
>>>>>>>>>>>> So just based on the current file, the change proposed - to
>> remove
>>>> one
>>>>>>>>>>>> / - is not correct until the arch directory is removed.
>>>>>>>>>>>
>>>>>>>>>>> That change is already in JDK9-hs:
>>>>>>>>>>>
>>>>>>>>>>> Changeset: c14f9a7b4cab
>>>>>>>>>>> Author: erikj
>>>>>>>>>>> Date: 2016-12-05 17:55 +0100
>>>>>>>>>>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab
>>>>>>>>>>>
>>>>>>>>>>> 8066474: Remove the lib/ directory from Linux and Solaris
>> images
>>>>>>>>>>> Reviewed-by: tbell, ihse
>>>>>>>>>>>
>>>>>>>>>>> along with changesets in the jdk and hotspot repos along with a
>> few
>>>>>>>>>>> closed repos.
>>>>>>>>>>
>>>>>>>>>> Thanks Dan. So we need to see a webrev based on latest hs code -
>>>> where
>>>>>>>>>> removing the extra / would be correct.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>>> Dan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> David
>>>>>>>>>>>> -----
>>>>>>>>>>>>
>>>>>>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary -
>> a
>>>>>>>>>>>>>> comment on
>>>>>>>>>>>>>> the strdup would have sufficed IMO.
>>>>>>>>>>>>> Dmitry asked me to add it. But I think it's ok.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Can I consider this reviewed now? I.e. could I push it once
>> 8066474
>>>> is
>>>>>>>>>>>>> promoted and Joe Darcy agreed?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> Goetz.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes@oracle.com]
>>>>>>>>>>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14
>>>>>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier@sap.com>;
>> 'Dmitry
>>>>>>>>>> Samersoff'
>>>>>>>>>>>>>> <dmitry.samersoff@oracle.com>; Java Core Libs <core-libs-
>>>>>>>>>>>>>> dev@openjdk.java.net>; serviceability-dev (serviceability-
>>>>>>>>>>>>>> dev@openjdk.java.net) <serviceability-dev@openjdk.java.net>
>>>>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and
>>>>>>>>>>>>>> servicabilty
>>>>>>>>>>>>>> coding.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>> Hi Dmitry,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> yes, new_jvmpath is consistent with the other variables.
>>>>>>>>>>>>>>> I also merged the ifs in SDE.c.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> new webrev:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-
>>>>>>>> corlib_s11y/webrev.03/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> src/java.base/share/native/libjli/java.c
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As far as I can see the existing code is working perfectly fine.
>>>>>>>>>>>>>> Given a
>>>>>>>>>>>>>> jvm.cfg with:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -server KNOWN
>>>>>>>>>>>>>> -client IGNORE
>>>>>>>>>>>>>> -myvm KNOWN
>>>>>>>>>>>>>> -oldvm ALIASED_TO -server
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The usage text is:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -server to select the "server" VM
>>>>>>>>>>>>>> -myvm to select the "myvm" VM
>>>>>>>>>>>>>> -oldvm is a synonym for the "server" VM [deprecated]
>>>>>>>>>>>>>> The default VM is server,
>>>>>>>>>>>>>> because you are running on a server-class machine.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> which is exactly what I would expect. Why do you think there
>> is a
>>>>>> bug?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output
>> string is
>>>>>>>>>>>>>> expanded with:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "%s/lib/%s/jli:"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> so it needs to account for the extra "/lib//jli:" characters -
>> and that
>>>>>>>>>>>>>> is exactly what the existing code does:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> + JLI_StrLen("/lib//jli:")
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary -
>> a
>>>>>>>>>>>>>> comment on
>>>>>>>>>>>>>> the strdup would have sufficed IMO.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>> Goetz.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>> From: Dmitry Samersoff
>> [mailto:dmitry.samersoff@oracle.com]
>>>>>>>>>>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM
>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier@sap.com>;
>> Java
>>>> Core
>>>>>>>> Libs
>>>>>>>>>>>>>>>> <core-libs-dev@openjdk.java.net>; serviceability-dev
>>>>>> (serviceability-
>>>>>>>>>>>>>>>> dev@openjdk.java.net) <serviceability-
>> dev@openjdk.java.net>
>>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib
>> and
>>>>>>>>>>>>>>>> servicabilty
>>>>>>>>>>>>>>>> coding.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Goetz,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> SDE.c:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You might combine if at ll. 260 and 263 to one but it's just
>>>>>>>>>>>>>>>> matter of test.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> if (sti == baseStratumIndex || sti < 0) {
>>>>>>>>>>>>>>>> return; /* Java stratum - return unchanged */
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please
>>>>>>>>>>>>>>>>> double-check the new webrev.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> if cnt is <= 0 loop at l.267
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> for (; cnt-- > 0; ++fromEntry) {
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> is never run and we effectively do
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *entryCountPtr = 0;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> at l.283
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So if we you suspect that cnt may become negative or 0:
>>>>>>>>>>>>>>>> (your v.01 changes)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 260 if (sti < 0 && cnt > 0) {
>>>>>>>>>>>>>>>> 261 return;
>>>>>>>>>>>>>>>> 262 }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> it's better to check it early.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But I'm not sure we have to care about negative/zero cnt
>> here.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>>> Hi Dmitry,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> thanks for looking at my change!
>>>>>>>>>>>>>>>>> Updated webrev:
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-
>>>>>>>>>> corlib_s11y/webrev.02
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c
>>>>>>>>>>>>>>>>>> Is this line correct?
>>>>>>>>>>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath);
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It seems pointless. Should I remove it? (The whole file is a
>>>>>>>>>>>>>>>>> horror.)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c
>>>>>>>>>>>>>>>>>> It might be better to return immediately if cnt < 0,
>>>>>>>>>>>>>>>>>> regardless of value of sti.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please
>>>>>>>>>>>>>>>>> double-check the new webrev.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *
>> src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c
>>>>>>>>>>>>>>>>>> It might be better to write
>>>>>>>>>>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0;
>>>>>>>>>>>>>>>>>> and leave one copy of setsockopt() call
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, looks better.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>> Goetz
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This change fixes some minor issues found in our code
>>>> scans.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I hope this correctly addresses corelib and serviceability
>>>> issues.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Please review:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-
>>>>>>>>>>>>>>>> corlib_s11y/webrev.01/
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Goetz.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Changes in detail:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> e_asin.c
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Code scan reports missing {}.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the
>> inexact
>>>>>>>>>>>>>>>>>>> flag of
>>>>>>>>>>>>>>>>>>> the processor.
>>>>>>>>>>>>>>>>>>> It's a way to avoid the C compiler to optimize the code
>>>> away.
>>>>>>>>>>>>>>>>>>> It is
>>>>>>>>>>>>>>>>>>> always true,
>>>>>>>>>>>>>>>>>>> so the parenthesis of the outer else don't matter.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Although this basically just adds the {} I would like to
>> submit
>>>>>>>>>>>>>>>>>>> this to
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> avoid anybody else spends more the 30sec on
>> understanding
>>>>>>>> these
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> if statements.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> k_standard.c
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> exc.retval is returned below and thus should always be
>>>>>>>>>>>>>>>>>>> initialized.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> imageDecompressor.cpp
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Wrong destructor is used. Reported also by David
>> CARLIER
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> java.c
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> java_md_solinux.c
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> "//" in path is useless. Further down a free is missing.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> SDE.c
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Call to stratumTableIndex can return negative value if
>>>>>>>>>>>>>>>>>>> defaultStratumId
>>>>>>>>>>>>>>>>>>> == null.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> socket_md.c
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use
>> is
>>>>>>>>>>>>>>>>>>> hidden in
>>>>>>>>>>>>>>>>>>> the macros.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> unpack.cpp
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> n.slice should not get negative argument for end, which
>> is
>>>>>>>>>>>>>>>>>>> passed from
>>>>>>>>>>>>>>>>>>> dollar1.
>>>>>>>>>>>>>>>>>>> But dollar1 can get negative where it is set to the result
>> of
>>>>>>>>>>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Dmitry Samersoff
>>>>>>>>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia
>>>>>>>>>>>>>>>>>> * I would love to change the world, but they won't give
>> me
>>>> the
>>>>>>>>>>>>>>>>>> sources.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Dmitry Samersoff
>>>>>>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia
>>>>>>>>>>>>>>>> * I would love to change the world, but they won't give me
>> the
>>>>>>>>>>>>>>>> sources.
>>>>>>>>>>>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic