Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly

[Xueming Shen]

On 5/3/13 6:48 AM, Alan Bateman wrote:
> On 03/05/2013 00:08, Dan Xu wrote:
>> Hi All,
>>
>> Thanks for all your comments. Based on the previous feedback, I have 
>> moved to the other approach, i.e., to fail file operations if the 
>> invalid NUL characher is found in a file path. As you know, due to 
>> the compatibility issue, we cannot throw an exception immediately in 
>> the File constructors. So the failure is delayed and only shown up 
>> when any file operation is triggered.
>>
>> As for FileInputStream, FileOutputStream, and RandomAccessFile 
>> classes, the FileNotFoundException will be thrown right away since 
>> their spec allow this exception happen in the constructors. Thanks 
>> for your review!
>>
>> webrev: http://cr.openjdk.java.net/~dxu/8003992/webrev.01/
>>
>> -Dan
>>
> This looks much better. I guess a Boolean would have worked as well as 
> adding the PathStatus enum but what you have seems okay.
>
> It would be good to get Sherman's confirmation that we don't need to 
> be concerned about anything else encoding to include NUL.
>
> -Alan.
>
>

The change looks fine. I don't see any encoding issue, though this 
reminds me one
possible use scenario. Do we want to make it path "valid", if the NUL is 
at the end
of the path? This should not been an issue normally though, everything from
the native does not have it. Just wonder if this scenario might work 
before (?), with
no potential vuln risk (?),  we may want to keep it? No, I don't know 
any real code
has the NUL attached to the end, just a wild guess. It's definitely fine 
to wait for
any complain, if there will be, and then react.

-Sherman