RFR: 8229872: (fs) Increase buffer size used with getmntent

[Vladimir Kempik]

Hello

Thanks for comments

updated webrev including all mentioned things.

http://cr.openjdk.java.net/~vkempik/8229872/webrev.08/ <http://cr.openjdk.java.net/~vkempik/8229872/webrev.08/>

Thanks, Vladimir

> 5 сент. 2019 г., в 11:52, Alan Bateman <Alan.Bateman at oracle.com> написал(а):
> 
> On 04/09/2019 16:56, Vladimir Kempik wrote:
>> Hello
>> After thinking about it, I think it’s better to leave getlinelen as is, and just increase maxLineSize by one in getMountEntries.
>> 
>> here is webrev: http://cr.openjdk.java.net/~vkempik/8229872/webrev.07/ <http://cr.openjdk.java.net/~vkempik/8229872/webrev.07/>
> UnixNativeDispatcher.rewind - the comment L413-419 needs cleanup, I think should be one line or just removed.
> 
> UnixNativeDispatcher.getlinelen - the function description is confusing. I think it should be removed or replaced with something simple that explains that it returns the line length (without the NUL terminator) or -1 when at EOF. I see Florian's mail that -1 can be EOF or an error and I agree this needs to be cleaned up.
> 
> LinuxNativeDispatcher.getmntent - the parameter to the native method should be bufLen to match the libc function that it calls. Also I think we should try to keep the formatting/style consistent with the existing code, meaning the NULL checks should be "if (bytes == NULL) {" rather than putting the open brace on a new line.
> 
> LinuxFileSystem.getMountEntries. - maxLineSize++ in the finally block is confusing. I think it would be cleaner to have the following after the finally block:
>   long bufLen = maxLineLen + 1;
> and then call getmntent with bugLen. This will avoid misleading further maintainers into thinking that maxLineLen is the maxium line length.
> At L88 you need a line break to put the statement on the next line (to keep it consistent with the existing code).
> 
> -Alan.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190906/15dbcff6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190906/15dbcff6/signature.asc>