From amy.lu at oracle.com  Thu Dec  1 09:56:18 2016
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 1 Dec 2016 17:56:18 +0800
Subject: <Sound Dev> JDK 9 RFR of JDK-8170581: Remove
 OpenNonIntegralNumberOfSampleframes.java from ProblemList
Message-ID: <a329c1b6-349a-9e59-1689-686bd2f23909@oracle.com>

javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java

This test was problem listed since the fix JDK-8168881 was only in the 
client forest and not dev.

Now that fix JDK-8168881 is in dev [1], test could be removed from 
ProblemList.txt.

Please review:
bug: https://bugs.openjdk.java.net/browse/JDK-8170581


--- old/test/ProblemList.txt    2016-12-01 17:46:46.000000000 +0800
+++ new/test/ProblemList.txt    2016-12-01 17:46:46.000000000 +0800
@@ -227,8 +227,6 @@

  javax/sound/sampled/Mixers/DisabledAssertionCrash.java 7067310 generic-all

-javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java 
8168881 generic-all
-
  ############################################################################

  # jdk_imageio


Thanks,
Amy

[1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1292ba86a8d4

From joe.darcy at oracle.com  Thu Dec  1 18:13:52 2016
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 1 Dec 2016 10:13:52 -0800
Subject: <Sound Dev> JDK 9 RFR of JDK-8170581: Remove
 OpenNonIntegralNumberOfSampleframes.java from ProblemList
In-Reply-To: <a329c1b6-349a-9e59-1689-686bd2f23909@oracle.com>
References: <a329c1b6-349a-9e59-1689-686bd2f23909@oracle.com>
Message-ID: <78008fe8-b823-fcb0-3b44-b0e0a5bb94f4@oracle.com>

+1

Thanks Amy,

-Joe


On 12/1/2016 1:56 AM, Amy Lu wrote:
> javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java
>
> This test was problem listed since the fix JDK-8168881 was only in the 
> client forest and not dev.
>
> Now that fix JDK-8168881 is in dev [1], test could be removed from 
> ProblemList.txt.
>
> Please review:
> bug: https://bugs.openjdk.java.net/browse/JDK-8170581
>
>
> --- old/test/ProblemList.txt    2016-12-01 17:46:46.000000000 +0800
> +++ new/test/ProblemList.txt    2016-12-01 17:46:46.000000000 +0800
> @@ -227,8 +227,6 @@
>
>  javax/sound/sampled/Mixers/DisabledAssertionCrash.java 7067310 
> generic-all
>
> -javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java 
> 8168881 generic-all
> -
>  ############################################################################ 
>
>
>  # jdk_imageio
>
>
> Thanks,
> Amy
>
> [1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1292ba86a8d4


From javalists at cbfiddle.com  Thu Dec  1 18:47:06 2016
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 1 Dec 2016 10:47:06 -0800
Subject: <Sound Dev> status of AudioSynthesizer in JDK 9
In-Reply-To: <1cd2f932-ccf3-b929-27e9-a8fbdbbbb835@oracle.com>
References: <5035EDE4-DB42-40D3-95DE-7C098D18FFC7@cbfiddle.com>
	<1cd2f932-ccf3-b929-27e9-a8fbdbbbb835@oracle.com>
Message-ID: <4905EFCF-ABDA-420F-A310-1756D30686E4@cbfiddle.com>

The RFE is JDK-8170518.


> On Nov 29, 2016, at 8:19 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> On 15.11.16 23:10, Alan Snyder wrote:
>> What is the plan for the AudioSynthesizer interface in JDK 9?
> 
> This interface will not be opened in the jdk9 because it is to late. I suggest you to create a request in JBS to open this part of functionality.
> As a workaround you can use the Gervill - Software Synthesizer.
> 
>> I use it for two purposes:
>> 
>> One is to configure the synthesizer using the open(SourceDataLine, Map) method.
>> 
>> The other is to generate audio files using the openStream(AudioFormat, Map) method.
> 
> 
> 
> -- 
> Best regards, Sergey.


From goetz.lindenmaier at sap.com  Fri Dec  9 07:57:54 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 9 Dec 2016 07:57:54 +0000
Subject: <Sound Dev> RFR(M): 8170798: Fix minor issues in java2d and sound
	coding.
Message-ID: <d926ae71449b4411a81116eed6fdb31c@DEROTE13DE08.global.corp.sap>

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/8170798-java2d_sound/webrev.01/



Best regards,

  Goetz.



Changes in detail:



hg-ot-font.cc

Looks like assignment instead of compare. Use extra if().


hg-ot_layout-gpos-table.hh

valueFormat is passed to apply(), where it is used as an array with two elements:
line 621: valueFormats[1].get_len();
It was correct as there are actually two fields in the struct that have the
same layout as an array.


ScriptAndLanguageTags.cpp, ThaiShaping.cpp/.h


In ThaiShaping.cpp:307 conState is passed to getNextState() where it is in the end used to index to thaiStateTable.
thaiStateTable has 52 elements. But conState is initialized to 0xFF == 255 in ThaiShaping.cpp:296. This can result in an out-of-bounds access.

OpenTypeLayoutEngine::scriptTags[scriptCodeCount] is accessed with index < scriptCodeCount, but only contains scriptCodeCount-1 elements.

I added a size entry to the enums, and use that for sizing the array and checking the size.


jctrans.c

if cinfo->entropy->encode_mcu resolves to encode_mcu_AC_first() it will access MCU_buffer[0]. (jcphuff.c:487)



cmserr.c

Must check return value of ftell.


cmsgamma.c

Out/out/in are used as arrays in called function.


cmslut.c

Out[] may be used uninitialized.


cmstypes.c

Must check return value of Tell. The negative outcome should not be passed to Seek.


cmsxform.c

Using uninitialized element of array wIn when calling *p->FromInput. (The function pointer resolves to Pack1Byte.)
Using uninitialized element of array fIn when calling *p->FromInputFloat. (The function pointer resolves to PackDoublesFromFloat.)
Using uninitialized element of array fIn when calling *p->FromInputFloat. (The function pointer resolves to PackDoublesFromFloat.)


PLATFORM_API_LinuxOS_ALSA_Ports.c

Using uninitialized element of array controls when calling *creator->newCompoundControl. (The function pointer resolves to PORT_NewCompoundControl.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/sound-dev/attachments/20161209/542f29b4/attachment.html>

From goetz.lindenmaier at sap.com  Tue Dec 13 13:29:07 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 13 Dec 2016 13:29:07 +0000
Subject: <Sound Dev> [ping] RE: RFR(M): 8170798: Fix minor issues in java2d
 and sound coding.
Message-ID: <c9c20025b49949aba01d9d0d363a8d12@DEROTE13DE08.global.corp.sap>

Could someone please have a look at these changes?

Thanks,
  Goetz.

> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Freitag, 9. Dezember 2016 08:58
> To: 2d-dev <2d-dev at openjdk.java.net>; 'sound-dev at openjdk.java.net' <sound-
> dev at openjdk.java.net>
> Subject: RFR(M): 8170798: Fix minor issues in java2d and sound coding.
> 
> 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/8170798-java2d_sound/webrev.01/
> 
> 
> 
> Best regards,
> 
>   Goetz.
> 
> 
> 
> Changes in detail:
> 
> 
> 
> hg-ot-font.cc
> 
> Looks like assignment instead of compare. Use extra if().
> 
> 
> hg-ot_layout-gpos-table.hh
> 
> valueFormat is passed to apply(), where it is used as an array with two
> elements:
> line 621: valueFormats[1].get_len();
> It was correct as there are actually two fields in the struct that have the
> same layout as an array.
> 
> 
> ScriptAndLanguageTags.cpp, ThaiShaping.cpp/.h
> 
> 
> In ThaiShaping.cpp:307 conState is passed to getNextState() where it is in the
> end used to index to thaiStateTable.
> thaiStateTable has 52 elements. But conState is initialized to 0xFF == 255 in
> ThaiShaping.cpp:296. This can result in an out-of-bounds access.
> 
> OpenTypeLayoutEngine::scriptTags[scriptCodeCount] is accessed with index <
> scriptCodeCount, but only contains scriptCodeCount-1 elements.
> 
> I added a size entry to the enums, and use that for sizing the array and checking
> the size.
> 
> 
> jctrans.c
> 
> if cinfo->entropy->encode_mcu resolves to encode_mcu_AC_first() it will
> access MCU_buffer[0]. (jcphuff.c:487)
> 
> 
> 
> cmserr.c
> 
> Must check return value of ftell.
> 
> 
> cmsgamma.c
> 
> Out/out/in are used as arrays in called function.
> 
> 
> cmslut.c
> 
> Out[] may be used uninitialized.
> 
> 
> cmstypes.c
> 
> Must check return value of Tell. The negative outcome should not be passed to
> Seek.
> 
> 
> cmsxform.c
> 
> Using uninitialized element of array wIn when calling *p->FromInput. (The
> function pointer resolves to Pack1Byte.)
> Using uninitialized element of array fIn when calling *p->FromInputFloat. (The
> function pointer resolves to PackDoublesFromFloat.)
> Using uninitialized element of array fIn when calling *p->FromInputFloat. (The
> function pointer resolves to PackDoublesFromFloat.)
> 
> 
> PLATFORM_API_LinuxOS_ALSA_Ports.c
> 
> Using uninitialized element of array controls when calling *creator-
> >newCompoundControl. (The function pointer resolves to
> PORT_NewCompoundControl.)
> 
> 


From philip.race at oracle.com  Tue Dec 13 19:54:56 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 13 Dec 2016 11:54:56 -0800
Subject: <Sound Dev> [OpenJDK 2D-Dev] RFR(M): 8170798: Fix minor issues
 in java2d and sound coding.
In-Reply-To: <d926ae71449b4411a81116eed6fdb31c@DEROTE13DE08.global.corp.sap>
References: <d926ae71449b4411a81116eed6fdb31c@DEROTE13DE08.global.corp.sap>
Message-ID: <38bf7910-554c-81bb-81b5-50fd65146cfe@oracle.com>

Hi Goetz,

Comments in-line but first some general points.

(1) I notice you prepared the webrev against jdk9/dev.
      It should be prepared against jdk9/client - which is where it 
should also be pushed.

(2) However most of these changes are in a 3rd party imported library.
      We don't edit these unless there is a good reason. Instead we 
would report
      them to up-stream and import next time we upgrade.
      So only a subset of these make sense to fix in JDK .. otherwise 
we'll just blow
      them away when we upgrade.

     In particular this means the changes to
     (a) harfbuzz
     (b) littlecms
    which are actively maintained externally and we upgrade periodically.

  Local changes may make sense in
    (c) ICU layout
    (d) libjpeg6b
    since these are at a different stage in their life

Having said that see the comments in-line.

-phil

On 12/08/2016 11:57 PM, 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/8170798-java2d_sound/webrev.01/ 
> <http://cr.openjdk.java.net/%7Egoetz/wr16/8170798-java2d_sound/webrev.01/>
>
> Best regards,
>
>   Goetz.
>
> Changes in detail:
>
> hg-ot-font.cc
>
> Looks like assignment instead of compare. Use extra if().
>
This is a stylistic change. You will need to convince Behdad.
>
>
> hg-ot_layout-gpos-table.hh
>
> valueFormat is passed to apply(), where it is used as an array with 
> two elements:
> line 621: valueFormats[1].get_len();
> It was correct as there are actually two fields in the struct that 
> have the
> same layout as an array.
>


This also needs to go to the harfbuzz mailing list.

>
>
> ScriptAndLanguageTags.cpp, ThaiShaping.cpp/.h
>
>
> In ThaiShaping.cpp:307 conState is passed to getNextState() where it 
> is in the end used to index to thaiStateTable.
> thaiStateTable has 52 elements. But conState is initialized to 0xFF == 
> 255 in ThaiShaping.cpp:296. This can result in an out-of-bounds access.
>

This is not entered unconditionally, so consState should be updated
before we reach there. However the check is harmless so should be fine.

>
> OpenTypeLayoutEngine::scriptTags[scriptCodeCount] is accessed with 
> index < scriptCodeCount, but only contains scriptCodeCount-1 elements.
>
> I added a size entry to the enums, and use that for sizing the array 
> and checking the size.
>
I am fairly sure you didn't include all of these changes in the webrev.
I see only the use for sizing the array
>
>
> jctrans.c
>
> if cinfo->entropy->encode_mcu resolves to encode_mcu_AC_first() it 
> will access MCU_buffer[0]. (jcphuff.c:487)
>
>

It is hard to prove with static analysis but it seems like the block 
above does the initialisation.
So I don't strongly object to this but I also don't see that the case 
for it is proven.

>
> cmserr.c
>
> Must check return value of ftell.
>
>
> cmsgamma.c
>
> Out/out/in are used as arrays in called function.
>
>
> cmslut.c
>
> Out[] may be used uninitialized.
>
>
> cmstypes.c
>
> Must check return value of Tell. The negative outcome should not be 
> passed to Seek.
>
>
> cmsxform.c
>
> Using uninitialized element of array wIn when calling *p->FromInput. 
> (The function pointer resolves to Pack1Byte.)
> Using uninitialized element of array fIn when calling 
> *p->FromInputFloat. (The function pointer resolves to 
> PackDoublesFromFloat.)
> Using uninitialized element of array fIn when calling 
> *p->FromInputFloat. (The function pointer resolves to 
> PackDoublesFromFloat.)
>

All of the above should be proposed to the upstream littlecms list
>
>
>
> PLATFORM_API_LinuxOS_ALSA_Ports.c
>
> Using uninitialized element of array controls when calling 
> *creator->newCompoundControl. (The function pointer resolves to 
> PORT_NewCompoundControl.)
>

So it seems like the elements at indices from controlCount to 10 may not
be initialised but I don't see how this would be a problem since 
PORT_NewCompoundControl
has no hardwired "10" .. it just uses controlCount.
In any case this would seem better addressed by the same kind of memset
after stack allocation that you proposed for the jpeg case.

-phil.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/sound-dev/attachments/20161213/57588c3a/attachment-0001.html>

From goetz.lindenmaier at sap.com  Wed Dec 14 09:45:47 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 14 Dec 2016 09:45:47 +0000
Subject: <Sound Dev> [OpenJDK 2D-Dev] RFR(M): 8170798: Fix minor issues
 in java2d and sound coding.
In-Reply-To: <38bf7910-554c-81bb-81b5-50fd65146cfe@oracle.com>
References: <d926ae71449b4411a81116eed6fdb31c@DEROTE13DE08.global.corp.sap>
	<38bf7910-554c-81bb-81b5-50fd65146cfe@oracle.com>
Message-ID: <2a7e83eee95c49f8b9ccb6c1af87261c@DEROTE13DE08.global.corp.sap>

Hi Phil, 

thanks for looking at my change!
Updated webrev:
http://cr.openjdk.java.net/~goetz/wr16/8170798-java2d_sound/webrev.02/

Best regards,
  Goetz.

> (1) I notice you prepared the webrev against jdk9/dev.
>      It should be prepared against jdk9/client - which is where it should also be
>      pushed.
I'll move to client.

> (2) However most of these changes are in a 3rd party imported library.
>      We don't edit these unless there is a good reason. Instead we would report
>      them to up-stream and import next time we upgrade.
>      So only a subset of these make sense to fix in JDK .. otherwise we'll just blow
>      them away when we upgrade.
> 
>     In particular this means the changes to
>     (a) harfbuzz
>     (b) littlecms
>    which are actively maintained externally and we upgrade periodically.
OK, I removed these changes.  But submitting upstream will probably mean
that I don't get the fixes into jdk9 any more.

>  Local changes may make sense in
>    (c) ICU layout
>    (d) libjpeg6b
>    since these are at a different stage in their life
> 
> Having said that see the comments in-line.
> 
> -phil
> 
> 
> On 12/08/2016 11:57 PM, Lindenmaier, Goetz wrote:
> 
> 	Changes in detail:
>
> 	hb-ot-font.cc 
> 	Looks like assignment instead of compare. Use extra if().
> This is a stylistic change. You will need to convince Behdad.
Yes.  The code scan complains about it, but it was correct.  But I would 
like to get it fixed.  It helps to get these false positives out of the way, as
we have to do these scans over and over again, and maybe other users of
openJdk, too.

> 	hb-ot_layout-gpos-table.hh
> 	valueFormat is passed to apply(), where it is used as an array with two
>          elements:
> 	line 621: valueFormats[1].get_len();
> 	It was correct as there are actually two fields in the struct that have the
> 	same layout as an array.
> This also needs to go to the harfbuzz mailing list.
OK, I'll try to run the scan on the harfbuzz sources and fix stuff there.
But I don't think I'll get any changes I make in harfbuzz into jdk9 at 
this stage. So shouldn't I push it here, anyways?

> 	ScriptAndLanguageTags.cpp, ThaiShaping.cpp/.h
> 	In ThaiShaping.cpp:307 conState is passed to getNextState() where it is
>           in the end used to index to thaiStateTable.
> 	thaiStateTable has 52 elements. But conState is initialized to 0xFF ==
>          255 in ThaiShaping.cpp:296. This can result in an out-of-bounds access.
> This is not entered unconditionally, so consState should be updated
> before we reach there. However the check is harmless so should be fine.
Thanks.

> 	OpenTypeLayoutEngine::scriptTags[scriptCodeCount] is accessed with
>           index < scriptCodeCount, but only contains scriptCodeCount-1 elements.
> 	I added a size entry to the enums, and use that for sizing the array and
>           checking the size.
> I am fairly sure you didn't include all of these changes in the webrev.
> I see only the use for sizing the array.
Sorry, the comment is mixed up.  I added the size entry to the enum for the conState issue.
The array size OpenTypeLayoutEngine::scriptTags[scriptCodeCount] is needed because
OpenTypeLayoutEngine::scriptTags is accessed with an index that runs to scriptCodeCount.
That's the case because it's dual to indicClassTables if I remember correctly.
See OpenTypeLayoutEngine::getScriptTag() that potentially accesses scriptTags[] at
scriptCodeCount-1.

> 	jctrans.
> 	if cinfo->entropy->encode_mcu resolves to encode_mcu_AC_first() it
>           will access MCU_buffer[0]. (jcphuff.c:487)
> It is hard to prove with static analysis but it seems like the block above does the
> initialisation.
> So I don't strongly object to this but I also don't see that the case for it is
> proven.
> 
> 	cmserr.c
> 	Must check return value of ftell.
> 
> 	cmsgamma.c
> 	Out/out/in are used as arrays in called function.
> 
> 	cmslut.c
> 	Out[] may be used uninitialized.
> 
> 	cmstypes.c
> 	Must check return value of Tell. The negative outcome should not be
>           passed to Seek.
> 
> 	cmsxform.c
> 	Using uninitialized element of array wIn when calling *p->FromInput.
>           (The function pointer resolves to Pack1Byte.)
> 	Using uninitialized element of array fIn when calling *p->
>            FromInputFloat. (The function pointer resolves to PackDoublesFromFloat.)
> 	Using uninitialized element of array fIn when calling *p->
>           FromInputFloat. (The function pointer resolves to PackDoublesFromFloat.)
> All of the above should be proposed to the upstream littlecms list.
Ok, I'll try that.  But that leaves the same issue: it will not reach jdk9 anymore?

> 	PLATFORM_API_LinuxOS_ALSA_Ports.c
> 	Using uninitialized element of array controls when calling *creator->
>           newCompoundControl. (The function pointer resolves to
>           PORT_NewCompoundControl.)
> 
> So it seems like the elements at indices from controlCount to 10 may not
> be initialised but I don't see how this would be a problem since
> PORT_NewCompoundControl
> has no hardwired "10" .. it just uses controlCount.
> In any case this would seem better addressed by the same kind of memset
> after stack allocation that you proposed for the jpeg case.
Fixed.  (I thought it's cheaper to initialize only the rest, and more simple
for the C-compiler to remove where useless.)


From sergey.bylokhov at oracle.com  Wed Dec 14 18:28:55 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 14 Dec 2016 21:28:55 +0300
Subject: <Sound Dev> [OpenJDK 2D-Dev] RFR(M): 8170798: Fix minor issues
 in java2d and sound coding.
In-Reply-To: <2a7e83eee95c49f8b9ccb6c1af87261c@DEROTE13DE08.global.corp.sap>
References: <d926ae71449b4411a81116eed6fdb31c@DEROTE13DE08.global.corp.sap>
	<38bf7910-554c-81bb-81b5-50fd65146cfe@oracle.com>
	<2a7e83eee95c49f8b9ccb6c1af87261c@DEROTE13DE08.global.corp.sap>
Message-ID: <FAF72245-5B0C-4839-97DE-FB7E4BE657B3@oracle.com>

Hello.

>> So it seems like the elements at indices from controlCount to 10 may not
>> be initialised but I don't see how this would be a problem since
>> PORT_NewCompoundControl
>> has no hardwired "10" .. it just uses controlCount.
>> In any case this would seem better addressed by the same kind of memset
>> after stack allocation that you proposed for the jpeg case.
> Fixed.  (I thought it's cheaper to initialize only the rest, and more simple
> for the C-compiler to remove where useless.)

It seems that some other implementations of PORT_NewCompoundControl can have the same issue, like in :
PLATFORM_API_BsdOS_ALSA_Ports.c and PLATFORM_API_SolarisOS_Ports.c. Should we apply the same memset there to make them in sync?


From philip.race at oracle.com  Wed Dec 14 18:37:02 2016
From: philip.race at oracle.com (Phil Race)
Date: Wed, 14 Dec 2016 10:37:02 -0800
Subject: <Sound Dev> [OpenJDK 2D-Dev] RFR(M): 8170798: Fix minor issues
 in java2d and sound coding.
In-Reply-To: <2a7e83eee95c49f8b9ccb6c1af87261c@DEROTE13DE08.global.corp.sap>
References: <d926ae71449b4411a81116eed6fdb31c@DEROTE13DE08.global.corp.sap>
	<38bf7910-554c-81bb-81b5-50fd65146cfe@oracle.com>
	<2a7e83eee95c49f8b9ccb6c1af87261c@DEROTE13DE08.global.corp.sap>
Message-ID: <b2401384-d489-c527-72ee-727706969e26@oracle.com>

+1 to the changes you have here.
Comments on the upstream issues in-line.

-phil.

On 12/14/2016 01:45 AM, Lindenmaier, Goetz wrote:
> Hi Phil,
>
> thanks for looking at my change!
> Updated webrev:
> http://cr.openjdk.java.net/~goetz/wr16/8170798-java2d_sound/webrev.02/
>
> Best regards,
>    Goetz.
>
>> (1) I notice you prepared the webrev against jdk9/dev.
>>       It should be prepared against jdk9/client - which is where it should also be
>>       pushed.
> I'll move to client.
>
>> (2) However most of these changes are in a 3rd party imported library.
>>       We don't edit these unless there is a good reason. Instead we would report
>>       them to up-stream and import next time we upgrade.
>>       So only a subset of these make sense to fix in JDK .. otherwise we'll just blow
>>       them away when we upgrade.
>>
>>      In particular this means the changes to
>>      (a) harfbuzz
>>      (b) littlecms
>>     which are actively maintained externally and we upgrade periodically.
> OK, I removed these changes.  But submitting upstream will probably mean
> that I don't get the fixes into jdk9 any more.
>
>>   Local changes may make sense in
>>     (c) ICU layout
>>     (d) libjpeg6b
>>     since these are at a different stage in their life
>>
>> Having said that see the comments in-line.
>>
>> -phil
>>
>>
>> On 12/08/2016 11:57 PM, Lindenmaier, Goetz wrote:
>>
>> 	Changes in detail:
>>
>> 	hb-ot-font.cc
>> 	Looks like assignment instead of compare. Use extra if().
>> This is a stylistic change. You will need to convince Behdad.
> Yes.  The code scan complains about it, but it was correct.  But I would
> like to get it fixed.  It helps to get these false positives out of the way, as
> we have to do these scans over and over again, and maybe other users of
> openJdk, too.
>
>> 	hb-ot_layout-gpos-table.hh
>> 	valueFormat is passed to apply(), where it is used as an array with two
>>           elements:
>> 	line 621: valueFormats[1].get_len();
>> 	It was correct as there are actually two fields in the struct that have the
>> 	same layout as an array.
>> This also needs to go to the harfbuzz mailing list.
> OK, I'll try to run the scan on the harfbuzz sources and fix stuff there.
> But I don't think I'll get any changes I make in harfbuzz into jdk9 at
> this stage. So shouldn't I push it here, anyways?

There is about a 90% chance I will push an updated harfbuzz into JDK9
So your changes will get blown away
But if you get them into upstream soon then I'd pull them in that way.
If upstream says no .. then I would not want to maintain these in JDK.

>
>> 	ScriptAndLanguageTags.cpp, ThaiShaping.cpp/.h
>> 	In ThaiShaping.cpp:307 conState is passed to getNextState() where it is
>>            in the end used to index to thaiStateTable.
>> 	thaiStateTable has 52 elements. But conState is initialized to 0xFF ==
>>           255 in ThaiShaping.cpp:296. This can result in an out-of-bounds access.
>> This is not entered unconditionally, so consState should be updated
>> before we reach there. However the check is harmless so should be fine.
> Thanks.
>
>> 	OpenTypeLayoutEngine::scriptTags[scriptCodeCount] is accessed with
>>            index < scriptCodeCount, but only contains scriptCodeCount-1 elements.
>> 	I added a size entry to the enums, and use that for sizing the array and
>>            checking the size.
>> I am fairly sure you didn't include all of these changes in the webrev.
>> I see only the use for sizing the array.
> Sorry, the comment is mixed up.  I added the size entry to the enum for the conState issue.
> The array size OpenTypeLayoutEngine::scriptTags[scriptCodeCount] is needed because
> OpenTypeLayoutEngine::scriptTags is accessed with an index that runs to scriptCodeCount.
> That's the case because it's dual to indicClassTables if I remember correctly.
> See OpenTypeLayoutEngine::getScriptTag() that potentially accesses scriptTags[] at
> scriptCodeCount-1.

Ok.
>> 	jctrans.
>> 	if cinfo->entropy->encode_mcu resolves to encode_mcu_AC_first() it
>>            will access MCU_buffer[0]. (jcphuff.c:487)
>> It is hard to prove with static analysis but it seems like the block above does the
>> initialisation.
>> So I don't strongly object to this but I also don't see that the case for it is
>> proven.
>>
>> 	cmserr.c
>> 	Must check return value of ftell.
>>
>> 	cmsgamma.c
>> 	Out/out/in are used as arrays in called function.
>>
>> 	cmslut.c
>> 	Out[] may be used uninitialized.
>>
>> 	cmstypes.c
>> 	Must check return value of Tell. The negative outcome should not be
>>            passed to Seek.
>>
>> 	cmsxform.c
>> 	Using uninitialized element of array wIn when calling *p->FromInput.
>>            (The function pointer resolves to Pack1Byte.)
>> 	Using uninitialized element of array fIn when calling *p->
>>             FromInputFloat. (The function pointer resolves to PackDoublesFromFloat.)
>> 	Using uninitialized element of array fIn when calling *p->
>>            FromInputFloat. (The function pointer resolves to PackDoublesFromFloat.)
>> All of the above should be proposed to the upstream littlecms list.
> Ok, I'll try that.  But that leaves the same issue: it will not reach jdk9 anymore?

It still might. Again we like to keep these libraries up-to-date.

>
>> 	PLATFORM_API_LinuxOS_ALSA_Ports.c
>> 	Using uninitialized element of array controls when calling *creator->
>>            newCompoundControl. (The function pointer resolves to
>>            PORT_NewCompoundControl.)
>>
>> So it seems like the elements at indices from controlCount to 10 may not
>> be initialised but I don't see how this would be a problem since
>> PORT_NewCompoundControl
>> has no hardwired "10" .. it just uses controlCount.
>> In any case this would seem better addressed by the same kind of memset
>> after stack allocation that you proposed for the jpeg case.
> Fixed.  (I thought it's cheaper to initialize only the rest, and more simple
> for the C-compiler to remove where useless.)
>


From goetz.lindenmaier at sap.com  Fri Dec 16 10:28:48 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 16 Dec 2016 10:28:48 +0000
Subject: <Sound Dev> [OpenJDK 2D-Dev] RFR(M): 8170798: Fix minor issues
 in java2d and sound coding.
In-Reply-To: <FAF72245-5B0C-4839-97DE-FB7E4BE657B3@oracle.com>
References: <d926ae71449b4411a81116eed6fdb31c@DEROTE13DE08.global.corp.sap>
	<38bf7910-554c-81bb-81b5-50fd65146cfe@oracle.com>
	<2a7e83eee95c49f8b9ccb6c1af87261c@DEROTE13DE08.global.corp.sap>
	<FAF72245-5B0C-4839-97DE-FB7E4BE657B3@oracle.com>
Message-ID: <27d6fe4853074a1595082aae18fed8c3@DEROTE13DE08.global.corp.sap>

Hi Sergey, 

Good catch, I added the memsets to the two other files, too.
Sorrry it took that long, I just wanted to make sure it causes
no upsets on solaris or BSD, I had to fix our build first.

New webrev:
http://cr.openjdk.java.net/~goetz/wr16/8170798-java2d_sound/webrev.03/

This ran through all our testing successfully.  I'll push it Monday
to client if there are no objections.

Best regards,
  Goetz.

> -----Original Message-----
> From: Sergey Bylokhov [mailto:sergey.bylokhov at oracle.com]
> Sent: Mittwoch, 14. Dezember 2016 19:29
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: Phil Race <philip.race at oracle.com>; 2d-dev <2d-dev at openjdk.java.net>;
> sound-dev at openjdk.java.net
> Subject: Re: [OpenJDK 2D-Dev] RFR(M): 8170798: Fix minor issues in java2d and
> sound coding.
> 
> Hello.
> 
> >> So it seems like the elements at indices from controlCount to 10 may not
> >> be initialised but I don't see how this would be a problem since
> >> PORT_NewCompoundControl
> >> has no hardwired "10" .. it just uses controlCount.
> >> In any case this would seem better addressed by the same kind of memset
> >> after stack allocation that you proposed for the jpeg case.
> > Fixed.  (I thought it's cheaper to initialize only the rest, and more simple
> > for the C-compiler to remove where useless.)
> 
> It seems that some other implementations of PORT_NewCompoundControl can
> have the same issue, like in :
> PLATFORM_API_BsdOS_ALSA_Ports.c and PLATFORM_API_SolarisOS_Ports.c.
> Should we apply the same memset there to make them in sync?