I agree. This switch statement clearly was written in the expectation that each
case executed return.
And as I said offline pls confirm that you are confident that all return paths
actually handle that null which may not have been tested in practice before
now. There seemed to be several code paths.
-Phil.
> On Apr 29, 2017, at 5:33 AM, Kevin Rushforth <kevin.rushfo...@oracle.com>
> wrote:
>
> I'm not a "R"eviewer for AWT, but this part of the change looks wrong to me:
>
> case STRRET_CSTR :
> + if (pStrret->cStr != NULL) {
> return JNU_NewStringPlatform(env, reinterpret_cast<const
> char*>(pStrret->cStr));
> + }
> case STRRET_OFFSET :
>
>
> Did you really intended that a NULL pStrret->cStr pointer should fall through
> to the next case (STRRET_OFFSET)? If so, then a comment is in order because
> this seems odd.
>
> -- Kevin
>
>
> Prem Balakrishnan wrote:
>>
>> Hi,
>> Please review fix for JDK 9,
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179014
>> Webrev: http://cr.openjdk.java.net/~pkbalakr/8179014/webrev.00/
>>
>> Issue:
>> JFileChooser with Windows LAF crashes on Windows 10.
>> This issue is reproducible only on Windows 10 (v1703).
>> Creating GodMode directory is the only way we are able to reproduce this
>> issue.
>>
>> Cause:
>> IShellFolder::GetDisplayNameOf() method is used to retrieve the display name
>> of folder/subfolder using the GUID.
>> This method returns NULL for GodMode directory [i.e., folder created with
>> name: GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}].
>> In previous version of windows (tested on v1511) this call returns name
>> “GodMode”.
>> Hence we get crash when processing the return data from the this method.
>>
>> Why only on Windows LAF?
>> Unlike other LAFs in Windows LAF “useSystemExtensionHiding” is set to true.
>> This check avoids the call to IShellFolder::GetDisplayNameOf() method in all
>> other LAF’s.
>> Hence crash is not reported on other LAFs.
>>
>> Fix:
>> Added missing NULL checks in native method.
>> This results in native method returning NULL in this case, which has already
>> been handled on java side, hence no additional change is needed.
>>
>> Regards,
>> Prem
>>
