intfiction.org

In the Glk Specification, Section 5.6.2:However,provokes the errorwhereasdoes not. Is this a spec violation, or am I misreading things?

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.

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.

Oh, yes. Sorry -- I thought I'd answered that. That's legal too.

Thanks. I'll file a bug report then.

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.

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.

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. :(

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 http://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".)

Thanks for fixing this, zarf.