• Back to Jzip Home
  

Related Links

• Z-Machine Standard 1.0

John's Homepage

history

the z-machine list emails

Me again.

What should GET_PROP_LEN 0 return? My reading of the Standard says that
it's illegal, but I've just caught Shogun (322.89706) doing it.

This arose after I started making Zip 2000 a lot stricter about memory
accesses, which is of course just asking for trouble :)

If, as your first command, you say "STRAIGHTEN THE WHEEL", the following
piece of code gets executed:

 dc94:  GET_PROP_ADDR   L00,#20 -> L0b
 dc98:  GET_PROP_LEN    L0b -> -(SP)
 dc9b:  DIV             (SP)+,#02 -> L0c
 dc9f:  DEC_CHK         L08,#00 [TRUE] RTRUE
 dca3:  LOADW           L07,L08 >> L09
 dca7:  STORE           L06,L09
 dcaa:  JE              L09,"no.word" [TRUE] dc9f
 dcb1:  SCAN_TABLE      L06,L0b,L0c >> -(SP) [TRUE] dc9f
 dcb9:  JE              L06,"closed","shut" [FALSE] dcc6
 dcc1:  TEST_ATTR       L00,#11 [FALSE] dc9f
 dcc6:  JE              L06,"open" [FALSE] RET #FALSE
 dccc:  TEST_ATTR       L00,#11 [TRUE] dc9f
 dcd1:  RFALSE          

where L00 is the object number of the wheel (269, IIRC). The wheel
doesn't have property $20, so GET_PROP_ADDR returns 0. Zip 2000 1.30
then promptly aborts with "Attempt to access memory location &FFFFFFFF,
outside story file".

Logic, and this code, suggests that GET_PROP_LEN 0 should return 0.

Comments?

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/

On Tue, 4 Aug 1998, Kevin Bracey wrote:

> What should GET_PROP_LEN 0 return? My reading of the Standard says that
> it's illegal, but I've just caught Shogun (322.89706) doing it.

Welcome to the wonderful world... As best I can figure, it's illegal, and
Shogun has a bug in it. 

The original ZIP source will behave unpredictably. It will try to read the
byte before the beginning of Z-machine memory, which is a malloced
chunk, so what you get depends on the malloc implementation.

My solution to this mess is to print a warning, *visible to the player*,
and then return zero. By default, such warnings are only printed once per
game session, so they don't interfere *too* much with the playing
experience. There are options to hide such warnings entirely, to show them
every time, and to treat them as fatal errors.

(However, I actually forgot to test for GET_PROP_LEN 0. Oops. I test for
GET_PROP_ADDR 0 and so on, but I missed that case. A note for the TODO
list.)
 
I think it would be a mistake to say that GET_PROP_LEN 0 is legal, and
always returns zero. That would effectively extend the spec and de-qualify
a lot of existing interpreters. I *don't* say that to coddle the
interpreter authors (I think they should *all* test these conditions, and
at the very least behave predictably!) But if it's legal, then more Inform
games will be written which *do* stuff like this. And then players with
older interpreters will encounter more crashes.

If we say it's illegal, and interpreters print warnings so that authors
*know* when they're doing something illegal, then future Inform games will
be more likely to adhere to the spec. (The spec we have now, I mean.)

BTW, I know I've posted this rant before (about GET_PROP_ADDR and so on)
and I'm sure you remember it. I apologize. I think this kind of thing is
important; it's the difference between a reliable software platform and an
unusable one.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

On Tue 04 Aug, Kevin Bracey wrote:
> Me again.
> 
> What should GET_PROP_LEN 0 return? My reading of the Standard says that
> it's illegal, but I've just caught Shogun (322.89706) doing it.

Thereby hangs a tale.  Early releases of Inform relied on
get_prop_len returning 0, because the .# operator, as in,

   x = spell_book.#spell_list;

was supposed to return 0 if the object didn't possess the given
property.  On some versions of Zip and ITF, this does indeed
work.  These days Inform would compile

    obj.#identifier

as:

    1  +0001f     get_prop_addr obj identifier -> TEMP1 
    1  +00023     jz           TEMP1 to L1 if TRUE
    1  +00027     get_prop_len TEMP1 -> TEMP1 
    1  +0002a    .L1

(well, actually it compiles .# to something much more
complicated in Inform 6, but this is the interesting part).
Since get_prop_addr definitely does return 0 if the property
doesn't exist, the above code is protected against this
contigency.  In short, no Inform-compiled game can ever produce
the "bad" case except by the direct result of the author's
folly in using assembly language.

Personally I would prefer the standard to require that

   get_prop_len 0
   
returns 0, since it's not a time-critical operation and why
not be safe rather than sorry.  At the time we made the decision
on this, I'm pretty sure we didn't know about Shogun's behaviour
requiring it.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom