[z-machine] Different 1.1 proposal: put_prop and get_prop

[Cedric Knight]

On 06 August 2003 0:41, David Kinder <d.kinder@btinternet.com> wrote:
>> The ZIP behavior matches the Infocom behavior, so IMO it should
>> remain illegal.
>
> I'd agree with this. It doesn't seem quite right to change the
meaning
> of those opcodes from "get and set the property" to "get and set the
> property, or only the first bit of it" just because Inform can
> generate such situations.

But 1.0 does demand that a word operand is dealt with sensibly by
@put_prop when the destination is a single byte, so why not deal with
it sensibly when the destination is *longer* than the source?  And at
the moment @get_prop actually seems to mean 'get the property, except
if it's longer than 2 bytes in which case return its length*256 plus
the first byte of data'.

OK then, how about keeping it illegal, but defining that the
interpreter should display an error and halt, like Zoom (& gnusto) do?
It would at least standardize things in such a way that made bugs
detectable.  I'd regard something which silently corrupts the object
table as a bug.

>
>> Do any story files out there actually try to do this?
>
> I don't think so.

I'm new to this kind of discussion.  If there are no story files
trying to do it, how do we know what the Infocom behaviour would be in
the situation?  By reverse engineering the Infocom interpreters?

There could be story files out there that contain the bug, for
example, because they attempt to change additive property data in
Inform without realising it is represented as an array (see raif).  Or
if an author has tried to modify the single 'name' of an object (as is
perfectly legal), and then added a second name.... It just seems IMHO
that there should be a warning that an author is crossing over into
the Big Undefined, the border of which otherwise might be invisible.

CK