|Anonymous | Login | Signup for a new account||2020-01-27 17:40 PST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001197||Inform 6||General||public||2014-02-24 21:35||2015-05-10 17:47|
|Target Version||Fixed in Version|
|Summary||0001197: Changing NUM_ATTR_BYTES produces crashy Glulx code|
|Description||The compiler supports an option $NUM_ATTR_BYTES (in Glulx), which is supposed to allow the user to increase the number of attribute flags. The default value is 7 (for 56 attributes). The value must be an integer of the form 3n+4.|
If I compile Advent.inf with $NUM_ATTR_BYTES=11, the resulting game file crashes. "Memory access out of range (6544DCA5)"
I'm sure I tested this when I was implementing the Glulx compiler, but it obviously hasn't been tested since then. I will have to dig in and figure out what's going haywire.
(This I6 feature is necessary, but not sufficient, for I7 to support more boolean properties efficiently. Currently I7 assumes a fixed limit on I6 attributes, and handles extra boolean properties as I6 properties.)
|Tags||No tags attached.|
I guess I never rigged the code generator to allow for other values! (The attribute-related opcodes allow it, but not parent(), sibling(), child(), print (object), etc.)
I am a silly Zarf.
This will be a big old unit test, won't it. Also (note to self): test with both -S and -~S.
Okay. There's good news and bad news.
The good news is that I have a patch: https://github.com/erkyrath/inform6/commit/996ffb9f8ac406a9624ed5966069f73af3b9740a [^]
And a compiler test: https://github.com/erkyrath/glk-dev/blob/master/unittests/numattrbytes.inf [^]
I have also checked that the compiler's output is byte-identical when NUM_ATTR_BYTES is 7 (checked Advent.inf, glulxercise.inf, and my large Hadean Lands test file.)
The bad news is that I made the same mistake (hardwired "obj-->4") in the Glulx accelerated opcode spec! (See the definition for FUNC_2_CP__Tab.) So increasing NUM_ATTR_BYTES will *still* fail if function acceleration is used, as it is now.
Fixing *that* will require a Glulx spec bump and interpreter update.
However, that's outside the scope of this issue.
|Closing all resolved issues from 2014 and earlier.|
|2014-02-24 21:35||zarf||New Issue|
|2014-02-24 21:35||zarf||Status||new => assigned|
|2014-02-24 21:35||zarf||Assigned To||=> zarf|
|2014-02-27 23:22||zarf||Note Added: 0002519|
|2014-02-28 14:55||zarf||Note Added: 0002520|
|2014-02-28 15:00||zarf||Note Added: 0002521|
|2014-02-28 15:00||zarf||Assigned To||zarf => DavidK|
|2014-03-08 11:36||DavidK||Status||assigned => resolved|
|2014-03-08 11:36||DavidK||Resolution||open => fixed|
|2015-05-10 17:47||jmcgrew||Note Added: 0003678|
|2015-05-10 17:47||jmcgrew||Status||resolved => closed|
|Copyright © 2000 - 2010 MantisBT Group|