[OpenJDK 2D-Dev] <AWT Dev> RFR(M): 8170525: Fix minor issues in awt coding

[Lindenmaier, Goetz]

Hi Prasanta, 

good point, I added that too.

Best regards,
  Goetz.

> -----Original Message-----
> From: Prasanta Sadhukhan [mailto:prasanta.sadhukhan at oracle.com]
> Sent: Donnerstag, 1. Dezember 2016 06:05
> To: Phil Race <philip.race at oracle.com>; Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Vincent Ryan <vincent.x.ryan at oracle.com>
> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security-
> dev at 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.ryan at oracle.com]
> 				Sent: Mittwoch, 30. November 2016 14:53
> 				To: Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> <mailto:goetz.lindenmaier at sap.com>
> 				Cc: awt-dev at openjdk.java.net <mailto:awt-
> dev at openjdk.java.net> ; security-dev at openjdk.java.net <mailto:security-
> dev at 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.lindenmaier at sap.com
> <mailto:goetz.lindenmaier at sap.com>  <mailto:goetz.lindenmaier at sap.com>
> <mailto:goetz.lindenmaier at 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.
> 
> 
> 
> 
> 
> 
>