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

[Vladimir Kempik]

Hello

Please review v4 of the patch

http://cr.openjdk.java.net/~vkempik/8229872/webrev.04/

diffs vs v3:
- rewind and getline moved to UnixNativeDispatcher
- some error handling in rewind, but according to manpage&internet, ferror doesn’t set errno, so I can’t get details of error, only the fact if it happened or not.
- bigger comment on getlinelen

Thanks, Vladimir

23 авг. 2019 г., в 18:47, Alan Bateman <Alan.Bateman at oracle.com<mailto:Alan.Bateman at oracle.com>> написал(а):

On 23/08/2019 16:18, Vladimir Kempik wrote:
Hello

I’m not sure about full version of getline.
getline requires malloced buffer and  may update passed in buffer to a new size (via realloc) so it’s not safe to pass anything from java, (even NativeBuffer i think) to it.
two ways to work it around:
1) minimal version of getline, like I did
2) in jni, allocate new, malloced buffer with same size as incoming buffer. pass it to getline. after getline finished, update incoming buffer with proper data (and increase it if needed). will still need malloc/free

Alan, you really sure you want  it to go second path while there is no consumer of full version of getline ?

I think we should introducing ad hoc native methods if possible. The native methods in this area are meant to be simple wrappers of syscall or libc function. There are few exceptions of course but the original intention was to be able to do as much in Java as possible. It should also make it easier to move this code to Project Panama in the future (there is already a version of UnixNativeDispatcher in that project).

You are right that getline is a bit awkward because it is essentially returning both a pointer and a size. If we can't come up with something better then getlinelen might be okay but it needs cleanup and the comment changed to reflect what it does.

-Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190903/09931f49/attachment.html>