<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>