<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Goetz,<br>
<br>
Comments in-line but first some general points.<br>
<br>
(1) I notice you prepared the webrev against jdk9/dev.<br>
It should be prepared against jdk9/client - which is where it
should also be pushed.<br>
<br>
(2) However most of these changes are in a 3rd party imported
library.<br>
We don't edit these unless there is a good reason. Instead we
would report<br>
them to up-stream and import next time we upgrade.<br>
So only a subset of these make sense to fix in JDK .. otherwise
we'll just blow<br>
them away when we upgrade.<br>
<br>
In particular this means the changes to <br>
(a) harfbuzz<br>
(b) littlecms<br>
which are actively maintained externally and we upgrade
periodically.<br>
<br>
Local changes may make sense in<br>
(c) ICU layout<br>
(d) libjpeg6b<br>
since these are at a different stage in their life<br>
<br>
Having said that see the comments in-line.<br>
<br>
-phil<br>
<br>
<div class="moz-cite-prefix">On 12/08/2016 11:57 PM, Lindenmaier,
Goetz wrote:<br>
</div>
<blockquote
cite="mid:d926ae71449b4411a81116eed6fdb31c@DEROTE13DE08.global.corp.sap"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">This change fixes
some minor issues found in our code scans.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">I hope this correctly
addresses corelib and serviceability issues.
<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Please review: <o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><a
moz-do-not-send="true"
href="http://cr.openjdk.java.net/%7Egoetz/wr16/8170798-java2d_sound/webrev.01/"><a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~goetz/wr16/8170798-java2d_sound/webrev.01/">http://cr.openjdk.java.net/~goetz/wr16/8170798-java2d_sound/webrev.01/</a></a><o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Best regards,<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"> Goetz.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Changes in detail:<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span
style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#333333"
lang="EN">hg-ot-font.cc
<br>
<br>
Looks like assignment instead of compare. Use extra if(). <br>
<br>
</span></p>
</div>
</blockquote>
This is a stylistic change. You will need to convince Behdad.<br>
<blockquote
cite="mid:d926ae71449b4411a81116eed6fdb31c@DEROTE13DE08.global.corp.sap"
type="cite">
<div class="WordSection1">
<p class="MsoPlainText"><span
style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#333333"
lang="EN">
<br>
hg-ot_layout-gpos-table.hh <br>
<br>
valueFormat is passed to apply(), where it is used as an
array with two elements:
<br>
line 621: valueFormats[1].get_len(); <br>
It was correct as there are actually two fields in the
struct that have the <br>
same layout as an array. <br>
</span></p>
</div>
</blockquote>
<br>
<br>
This also needs to go to the harfbuzz mailing list.<br>
<br>
<blockquote
cite="mid:d926ae71449b4411a81116eed6fdb31c@DEROTE13DE08.global.corp.sap"
type="cite">
<div class="WordSection1">
<p class="MsoPlainText"><span
style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#333333"
lang="EN">
<br>
<br>
ScriptAndLanguageTags.cpp, ThaiShaping.cpp/.h <br>
<br>
<br>
In ThaiShaping.cpp:307 conState is passed to getNextState()
where it is in the end used to index to thaiStateTable.
<br>
thaiStateTable has 52 elements. But conState is initialized
to 0xFF == 255 in ThaiShaping.cpp:296. This can result in an
out-of-bounds access.
<br>
</span></p>
</div>
</blockquote>
<br>
This is not entered unconditionally, so consState should be updated<br>
before we reach there. However the check is harmless so should be
fine.<br>
<br>
<blockquote
cite="mid:d926ae71449b4411a81116eed6fdb31c@DEROTE13DE08.global.corp.sap"
type="cite">
<div class="WordSection1">
<p class="MsoPlainText"><span
style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#333333"
lang="EN">
<br>
OpenTypeLayoutEngine::scriptTags[scriptCodeCount] is
accessed with index < scriptCodeCount, but only contains
scriptCodeCount-1 elements.
<br>
<br>
I added a size entry to the enums, and use that for sizing
the array and checking the size.
<br>
<br>
</span></p>
</div>
</blockquote>
I am fairly sure you didn't include all of these changes in the
webrev.<br>
I see only the use for sizing the array<br>
<blockquote
cite="mid:d926ae71449b4411a81116eed6fdb31c@DEROTE13DE08.global.corp.sap"
type="cite">
<div class="WordSection1">
<p class="MsoPlainText"><span
style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#333333"
lang="EN">
<br>
jctrans.c <br>
<br>
if cinfo->entropy->encode_mcu resolves to
encode_mcu_AC_first() it will access MCU_buffer[0].
(jcphuff.c:487)
<br>
<br>
<br>
</span></p>
</div>
</blockquote>
<br>
It is hard to prove with static analysis but it seems like the block
above does the initialisation.<br>
So I don't strongly object to this but I also don't see that the
case for it is proven.<br>
<br>
<blockquote
cite="mid:d926ae71449b4411a81116eed6fdb31c@DEROTE13DE08.global.corp.sap"
type="cite">
<div class="WordSection1">
<p class="MsoPlainText"><span
style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#333333"
lang="EN">
<br>
cmserr.c <br>
<br>
Must check return value of ftell. <br>
<br>
<br>
cmsgamma.c <br>
<br>
Out/out/in are used as arrays in called function. <br>
<br>
<br>
cmslut.c <br>
<br>
Out[] may be used uninitialized. <br>
<br>
<br>
cmstypes.c <br>
<br>
Must check return value of Tell. The negative outcome should
not be passed to Seek.
<br>
<br>
<br>
cmsxform.c <br>
<br>
Using uninitialized element of array wIn when calling
*p->FromInput. (The function pointer resolves to
Pack1Byte.)
<br>
Using uninitialized element of array fIn when calling
*p->FromInputFloat. (The function pointer resolves to
PackDoublesFromFloat.)
<br>
Using uninitialized element of array fIn when calling
*p->FromInputFloat. (The function pointer resolves to
PackDoublesFromFloat.)
<br>
</span></p>
</div>
</blockquote>
<br>
All of the above should be proposed to the upstream littlecms list <br>
<blockquote
cite="mid:d926ae71449b4411a81116eed6fdb31c@DEROTE13DE08.global.corp.sap"
type="cite">
<div class="WordSection1">
<p class="MsoPlainText"><span
style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#333333"
lang="EN">
<br>
<br>
PLATFORM_API_LinuxOS_ALSA_Ports.c <br>
<br>
Using uninitialized element of array controls when calling
*creator->newCompoundControl. (The function pointer
resolves to PORT_NewCompoundControl.)
</span><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</blockquote>
<br>
So it seems like the elements at indices from controlCount to 10 may
not<br>
be initialised but I don't see how this would be a problem since
PORT_NewCompoundControl<br>
has no hardwired "10" .. it just uses controlCount.<br>
In any case this would seem better addressed by the same kind of
memset<br>
after stack allocation that you proposed for the jpeg case.<br>
<br>
-phil.<br>
<br>
</body>
</html>