Inform - Support - Patches

About Patches  


DM4 Errata  

Issue L60701

"Zero errors" in library
Submitted by: Andrew Plotkin     Appeared in: Library 6/7 or before     Fixed in: Library 6/8

The Z-machine has several opcodes which deal with objects. For example, @get_parent finds the parent of a given object (the object which contains it.) @get_prop looks up a given (common) property in a given object. There are others.

Each of these opcodes operates on an object reference. In the Z-machine, an object reference is an integer; objects are numbered consecutively starting with 1. The opcode takes the integer and uses it as an index into the object table.

This leaves open the question: what is object zero? In the Z-machine, there is none. It is used as a NULL pointer, a reference meaning "no object". For example, the @get_parent opcode returns zero if it determines that an object is not contained in anything.

Very well; but this leaves open the question, what happens if you give a zero reference to the @get_parent opcode? What is the parent of "no object"? The short answer is: asking that question is a software error. The result is not predictable. If your program does it, your program contains a bug.

A couple of these bugs have crept into the standard Inform library, up until library version 6/7. (They are being fixed in library 6/8.) The most notorious is in the following code. (From Parserm.h, library version 6/7; I don't know how early the bug was introduced.)

  [ HasLightSource i j ad;
    if (i==0) rfalse;
    if (i has light) rtrue;
    if (i has enterable || IsSeeThrough(i)==1)
    {    objectloop (i in i)
            if (HasLightSource(i)==1) rtrue;
    ad = i.&add_to_scope;
    ! ...function continues...

The Inform statement objectloop (i in i) is legal Inform code, but it's not what the library wants to do. It loops i through the contents of what i originally pointed to, leaving i equal to zero at the end of the loop. Then the statement ad = i.&add_to_scope; is an opcode error.

That statement, and the rest of the function, assumes that i remains unchanged after the loop. So the fix is to change those lines to

    {    objectloop (j in i)
            if (HasLightSource(j)==1) rtrue;

If you are an Inform developer, you should make this change in your 6/7 libraries immediately. It also applies to earlier library versions, although I don't know how early. It may go back as far as the Inform 5 libraries (possibly in a different form.) This bug is triggered when the player is in a container or supporter.

Note: Another library 6/7 bug occurs if you type "say to me". I do not have a patch for this one at this time.

Last updated 17 April 2013. This site is no longer supported; information may be out of date.
Maintained as a historical archive by the Interactive Fiction Technology Foundation. Copyright 1993-2018 IFTF, CC-BY-SA unless otherwise noted.
This page was originally managed by Roger Firth.