Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001197Inform 6Generalpublic2014-02-24 21:352015-05-10 17:47
Reporterzarf 
Assigned ToDavidK 
PrioritynormalSeveritymildReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version6.32 
Target VersionFixed in Version 
Summary0001197: Changing NUM_ATTR_BYTES produces crashy Glulx code
DescriptionThe 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.)

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0002519)
zarf (developer)
2014-02-27 23:22

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.
(0002520)
zarf (developer)
2014-02-28 14:55

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.)
(0002521)
zarf (developer)
2014-02-28 15:00

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.
(0003678)
jmcgrew (administrator)
2015-05-10 17:47

Closing all resolved issues from 2014 and earlier.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker