[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-nio-dev
Subject:    Re: RFR: 8229872: (fs) Increase buffer size used with getmntent
From:       Alan Bateman <Alan.Bateman () oracle ! com>
Date:       2019-08-23 15:47:17
Message-ID: bd3896eb-2112-0dc5-8278-287123f7c274 () oracle ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]