Question on glk_stream_open_memory

[eu1 (eu)]

In the Glk Specification, Section 5.6.2:

You can open a stream which reads from or writes into a space in memory. strid_t glk_stream_open_memory(char *buf, glui32 buflen, glui32 fmode, glui32 rock); …
If buf is NULL, or for that matter if buflen is zero, then everything written to the stream is thrown away. This may be useful if you are interested in the character count.
…

However, glk_stream_open_memory(0,0,filemode_Write,0); provokes the error

Zero passed invalidly to Glk function.

whereas glk_stream_open_memory(1,0,filemode_Write,0); does not. Is this a spec violation, or am I misreading things?

[zarf (Andrew Plotkin)]

glk_stream_open_memory(1,0,filemode_Write,0) should be legal. Ditto for glk_stream_open_memory(arr,0,filemode_Write,0) where arr is a valid array address.

glk_stream_open_memory(1,1,filemode_Write,0) is probably legal in itself, but as soon as you write to the stream you may get a segfault, because address 1 is who-knows-where.

[eu1 (eu)]

Right, but what about the case where buf is NULL? Section 5.6.2 seems to suggest that that should be equivalent to buflen=0.

[zarf (Andrew Plotkin)]

Oh, yes. Sorry – I thought I’d answered that. That’s legal too.

[eu1 (eu)]

Thanks. I’ll file a bug report then.

[DavidK (David Kinder)]

I don’t think this is a problem with the Inform 7 IDEs’ Glk libraries. The error message “Zero passed invalidly to Glk function.” comes from the routines in the interpreters to decode the arguments to a Glk call (glkop.c in both Glulxe and Git - they’re using the same code), which suggests to me a problem in the Glulxe interpreter somewhere.

[zarf (Andrew Plotkin)]

Goddammit. I grepped my Glk library source for that message but forgot to look in glkop.c.

Sure enough, I have the “+” notation on glk_stream_open_memory, which means that the dispatch library will reject NULL. I apologize. I will fix that.

[zarf (Andrew Plotkin)]

There’s a further bug in glkop.c for this case (null-optional array parameters). I will have to do more testing to determine if it’s easy to fix, or if ten years of code depend on the legacy behavior.

[zarf (Andrew Plotkin)]

Okay. The change to gi_dispa.c is checked in (see my cheapglk repository). The bug fix to glkop.c is also (glulxe repository). I’ve imported the changes into my other libraries (glkterm and quixe).

Anybody who supports a C-based Glk library or Glulx interpreter should pick up these changes. (Both sides have to be fixed, unfortunately. The library fix uncovered the old interpreter-side bug.)

I added a unit test for this to my memstreamtest.ulx text – see eblong.com/zarf/glulx/ . In that test, type “null grape” and “uninull grape”, and similarly for the the other objects. Those commands should print the length of the description string (in characters) for the noun object. In unfixed interpreters, you’ll see some kind of error.

Since it may take a while for interpreters to absorb these bug fixes, I’ll remind you that

glk_stream_open_memory(array,0,filemode_Write,0);

…is a way to accomplish the same thing, without tripping over the bug. (“The same thing” meaning “measure the length of printed text without printing it to either the screen or memory”.)

[eu1 (eu)]

Thanks for fixing this, zarf.