Ah, no, that is just the field that is initialized with the Result of gtk3_get_color_for_flags() why I need to initialize it there.
Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 1. Dezember 2016 12:10 > To: 'Prasanta Sadhukhan' <prasanta.sadhuk...@oracle.com>; Phil Race > <philip.r...@oracle.com>; Sergey Bylokhov <sergey.bylok...@oracle.com>; > Vincent Ryan <vincent.x.r...@oracle.com> > Cc: awt-dev@openjdk.java.net; 2d-dev <2d-...@openjdk.java.net>; security- > d...@openjdk.java.net > Subject: RE: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor issues > in awt coding > > Hi Prasanta, > > good point, I added that too. > > Best regards, > Goetz. > > > -----Original Message----- > > From: Prasanta Sadhukhan [mailto:prasanta.sadhuk...@oracle.com] > > Sent: Donnerstag, 1. Dezember 2016 06:05 > > To: Phil Race <philip.r...@oracle.com>; Sergey Bylokhov > > <sergey.bylok...@oracle.com>; Lindenmaier, Goetz > > <goetz.lindenma...@sap.com>; Vincent Ryan <vincent.x.r...@oracle.com> > > Cc: awt-dev@openjdk.java.net; 2d-dev <2d-...@openjdk.java.net>; security- > > d...@openjdk.java.net > > Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor > issues > > in awt coding > > > > Also, in gtk3_interface.c, there is this change for color.alpha > > > > > > 2219 color.alpha = 0; in gtk3_get_color_for_flags() > > but it is used in > > gtk3_get_color_for_state() where it is not initialized > > > > 2268 GdkRGBA color; > > Regards > > Prasanta > > > > On 12/1/2016 1:28 AM, Phil Race wrote: > > > > > > Hi Goetz, > > > > > > > > DataBufferNative.c > > Using uninitialized value lockInfo.rasBase when calling > > DBN_GetPixelPointer. > > > > > > > > 75 lockInfo.resBase = NULL; > > > > Did you actually compile this ? The variable is called "rasBase", not > > "resBase". > > > > And strictly there is no problem since inside DBN_GetPixelPointer > > the code calls ops->Lock which should initialise this. > > A "rasBase" of 0 isn't really any better than a random one .. > > > > Also I don't see why there's a problem here and not in > > the function immediately following since it is the exact same case. > > > > -phil. > > > > On 11/30/2016 10:00 AM, Sergey Bylokhov wrote: > > > > > > cc 2d-dev. > > > > On 30.11.16 18:41, Lindenmaier, Goetz wrote: > > > > > > Hi Vincent, > > > > thanks for the quit review! > > Good catch that I lost the change to p11_mutex.c ... I > > had to change > > it and it fell out of my patches. > > I edited the Last Modified Date, and also updated the > > copyright messages. > > New webrev: > > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt- > > dev/ > > > > Best regards, > > Goetz. > > > > (Am I correct that your openJdk name is Vinnie?) > > > > > > > > -----Original Message----- > > From: Vincent Ryan > > [mailto:vincent.x.r...@oracle.com] > > Sent: Mittwoch, 30. November 2016 14:53 > > To: Lindenmaier, Goetz > > <goetz.lindenma...@sap.com> <mailto:goetz.lindenma...@sap.com> > > Cc: awt-dev@openjdk.java.net <mailto:awt- > > d...@openjdk.java.net> ; security-...@openjdk.java.net <mailto:security- > > d...@openjdk.java.net> > > Subject: Re: RFR(M): 8170525: Fix minor issues > > in awt coding > > > > Hello Goetz, > > > > Please modify the bug summary to reference > > ECC too. > > Your ECC changes look fine but the ‘Last > > Modified Date’ line in the 4 source > > code headers will need to be updated/added. > > > > BTW p11_mutex.c is listed below but appears > > to be missing from the webrev. > > > > Thanks. > > > > > > > > > > On 30 Nov 2016, at 13:12, Lindenmaier, > > Goetz > > <goetz.lindenma...@sap.com > > <mailto:goetz.lindenma...@sap.com> <mailto:goetz.lindenma...@sap.com> > > <mailto:goetz.lindenma...@sap.com> > wrote: > > > > Hi, > > > > I’d like to propose a row of smaller fixes > > where code is noted down a > > bit questionable. > > SAP’s quality process requires that we fix > > these in our internal delivery, > > and I > > Would like to share my fixes with openJdk. > > Some of these fixes are of > > more > > theoretical nature as how I understand the > > code paths never allow the > > problematic situation, but fixing it > > nevertheless assures that nothing is > > overseen if the code changes. Most changes > > are in libawt_xawt, some > > are in libsunec. > > > > I’d appreciate a review: > > > > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ > > > > Changes in detail: > > > > awt_InputMethod.c: > > > > One might overrun the 100 byte fixed-size > > string statusWindow->status > > by copying text->string.multi_byte without > > checking the length. > > > > gtk3_interface.c: > > > > This less-than-zero comparison of an > > unsigned value is never true. > > > > Using uninitialized value color. Field > > color.alpha is uninitialized. > > E.g. used at gtk3_interface.c:2287. > > > > XToolkit.c > > > > Using uninitialized value ret_timeout. > > E.g. in XToolkit.c:6809. > > > > XWindow.c > > > > Argument is incompatible with > > corresponding format string conversion. > > > > splashscreen_sys.c > > > > Overflowed or truncated value (or a value > > computed from an > > overflowed or truncated value) (gdk_scale > 0) > > ? native_scale * > > (double)gdk_scale : native_scale used as return > > value. > > > > ec.c > > > > Using uninitialized value k.dp when calling > > mp_clear. > > > > ecdecode.c > > > > You might overrun the 291 byte fixed-size > > string genenc by copying > > curveParams->geny without checking the > > length. > > Added sanity check before doing the string > > concatenation. > > > > ecl_mult.c > > > > Using uninitialized value kt.flag when > > calling > > *group->point_mul. (The > > function pointer resolves to > > ec_GF2m_pt_mul_mont.) > > > > mpi.c > > > > Using uninitialized value s. Field s.flag is > > uninitialized when calling > > s_mp_exch. > > Using uninitialized value tmp. Field > > tmp.flag > > is uninitialized when > > calling s_mp_exch > > Using uninitialized value t.dp when calling > > mp_clear. > > > > p11_mutex.c > > > > Using uninitialized value *ckpInitArgs. > > Field > > ckpInitArgs->flags is > > uninitialized when calling memcpy. > > > > > > DataBufferNative.c > > > > Using uninitialized value lockInfo.rasBase > > when calling > > BN_GetPixelPointer. > > > > fontpath.c > > > > You might overrun the 512 byte fixed-size > > string fontDirPath by copying > > DirP->name[index] without checking the length. > > > > > > > > > > > > > >
