Problem with array-length parameters defaulting to direction=out

[realh (Tony Houghton)]

I want to use Gio.InputStream.read_all_async() in Typescript, but there’s a problem with the bindings: the count parameter is missing, so there’s no way to tell the function how many bytes to read or allocate in the buffer. On stackoverflow I read that the way this is supposed to work is that gjs automagically handles caller-allocates.

I checked the gir file and noticed that the count parameter is annotated as direction="out"; in the source code it doesn’t have this annotation, so presumably the gir scanner defaults to out for all parameters that are the array-length for an out parameter. This shouldn’t be the case if the array is caller-allocates, so is that a bug in the scanner?

It looks like gjs is affected by this problem:

gjs> Gio.InputStream.prototype.read_all_async;
function read_all_async(io_priority, cancellable, callback) {
	/* wrapper for native symbol g_input_stream_read_all_async(); */
}

The count parameter is missing there as well as from the Typescript bindings that ts-for-gjs generates. I’m amazed that this problem has been undetected for so long!

[zbrown (Zander Brown)]

read_all_async is supposed to read all async so in bindings the buffer is automatically big enough (so the count doesn’t matter), you want read_async for reading only a specific number of bytes

In bindings you probably want read_bytes_async anyway

[realh (Tony Houghton)]

@zbrown

read_all_async is supposed to read all async so in bindings the buffer is automatically big enough (so the count doesn’t matter), you want read_async for reading only a specific number of bytes

The docs say that the read_all functions try to read as many bytes as requested (by count) , not necessarily to the end of the stream. The difference between these and read without all is that the latter may read fewer than the requested count (I’m using sockets, not files, FWIW), so you may have to call it repeatedly, keeping track of how many bytes you’ve read so far.

In bindings you probably want read_bytes_async anyway

That will work, thanks, but it’s a pity there isn’t an _all version.

[StefanSalewski]

@zbrown

read_all_async is supposed to read all async so in bindings the buffer is automatically big enough (so the count doesn’t matter)

I have no idea how that should work – a buffer always large enough? Well yes when we write that binding manually, then we can continuously increase the buffer size when necessary. For automatic binding generation that would be really hard.

Have just compared the Nim bindings. We use the count parameter, it is marked with var keyword, indicating it is an out or inout parameter what may be not fully correct in this case but it does not hurt. I have discovered that the Nim bindings do not test if the buffer is a least count byte large, I have to add that important test soon.

amazed that this problem has been undetected for so long!

I assume that most people using high level languages do use such functions from their own language and not from gio. And GTK has not so many users at all currently unfortunately.