RFR(S): 8207233: Minor improvements of jdk C-coding

[Roger Riggs]

Hi Goetz,

Thanks for the cleanup; looks fine with or without the suggestion below.

src/jdk.crypto.ec/share/native/libsunec/impl/ecl_mult.c: 84, 89
    Since the assignment is done in both branches of the if, it could be 
moved up.

Regards, Roger


On 7/13/2018 6:54 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I ran coverity on the jdk11 jdk sources and want to propose the following fixes. I scanned the linux x86_64 build. Some issues are similar to previous parfait fixes (check for NULL). I also identified some issues I consider real problems.  If you think some are tooo conservative, I'm happy to remove them.
> I posted this to core-libs-dev and awt-dev, if you think this should
> be discussed on other lists please tell me.
>
> http://cr.openjdk.java.net/~goetz/wr18/8207233-covJDK/01/
>
> In detail:
>
> Real issues:
>   ------------
>
>   transport.c
>     Loop overruns the array, it iterates to 8. Only
>     two iterations are intended.
>
>   Unix.c
>     getgroups can return -1. This is handled below,
>     but not here. Return as for other errors.
>
>   Useful code improvements.
>   -------------------------
>
>   zip_util.c
>     pmsg is compared to null above. Thus, don't
>     dereference it unconditionally below.
>     I would assume pmsg is always != NULL, so that the
>     check above could as well be turned into a guarantee.
>     This fix is more safe, though.
>
>   fontpath.c
>     This is a real error, but harmless as the same size is
>     returned.
>
>   pcsc.c
>     If size is 0, mszReaders is not allocated, but accessed
>     below. return if size is 0.
>     Here, too, I would assume that one could turn the if(size)
>     check into a guarantee, but this way it's more safe.
>
>   ecl_muilt.c
>     This block calls point_mul, which requires the kt.flag
>     is initialized.
>
>   unpack.cpp
>     lo is checked for null. If it is null, the dereference
>     below fails.
>     Return if lo == Null similar as above.
>     Alternatively, one could turn the if (lo != null) check into
>     a guarantee.