
-----------------------------------------------------------------------
 C62003 - Zcharacter directive problems
-----------------------------------------------------------------------

SUBMITTED BY -> Torbjrn Andersson 

PROBLEM -> The Zcharacter directive can attempt to write values greater 
than 127 into the alphabet table, which is a two-dimensional array of 
char. If char is signed, this means that when reading the value back you 
will get a negative value. This value is then used as array index when 
writing to other arrays.

The test program I used looked like

  Zcharacter '@`e';   ! E-grave

    [ Main;
          print 36;
	    ];

but the actual result of this is compiler-dependent. In fact, you may 
not see any error at all. In my case, however, it produced a compiler 
error because it had overwritten the table entry that told it that the 
character '6' could be part of a numerical constant.

FIX -> Applied (Thanks to Kevin Bracey)


-----------------------------------------------------------------------
 C62105 - Assembly of @not generates bad code
-----------------------------------------------------------------------

SUBMITTED BY -> David Given

PROBLEM -> The @not opcode has moved from V4 to V5. It was moved from a 
1op to a vop instruction to make room for @call_1n (if I've read the 
zspec correctly). Unfortunately, Inform's assembler only got partly 
updated. (The expression code generator works fine.) So if you're 
compiling for V<=4, this:

   @not local1 -> local2;

works. But in V>=5, Inform complains about a syntax error. The only 
thing Inform will accept is:

   @not local1;
     @not local1 local2;
       etc.

Unfortunately these generate duff code, to such an extent that txd 
locks up.

FIX - Applied (Thanks to Kevin Bracey)


-----------------------------------------------------------------------
 C62108 - @je should accept upto four operands
-----------------------------------------------------------------------

SUBMITTED BY -> Daniel Schepler

PROBLEM -> According to the Z-Machine specification, @je can take 
anywhere from one to four operands (one being useless since it never 
branches). However, the Inform assembler does not accept any more 
operands than two.

FIX - Applied


-----------------------------------------------------------------------
 C62109 - Second operand of @store
-----------------------------------------------------------------------

SUBMITTED BY -> Daniel Schepler

PROLEM -> The @store operation (as well as @inc_chk and @dec_chk, I 
think) is misassembled if the second operand is a variable. The 
following code should illustrate the problem:

   [ Main a b;
       @store a 23;
       @store b a; ! Misassembled to @store b 1
       @print_num b;
       @new_line;
   ];

FIX - Applied


-----------------------------------------------------------------------
 C62112 - Conditional jump assembly is suboptimal
-----------------------------------------------------------------------

SUBMITTED BY -> Kevin Bracey

PROBLEM -> There are number of areas where compilation of branches in 
Inform could be improved. Most of these would involve significant code 
generation modifications, but there is one straightforward error in 
conditional jump assembly.

Conditional jumps can take long or short forms. Short forms can jump up
to 63 bytes, but Inform only uses them for distances of up to 31 bytes.
Fixing this will shave a small amount off of your code size.

FIX -> Applied


-----------------------------------------------------------------------
 C62113 - Malformed dictionary entries if alphabet table is changed
-----------------------------------------------------------------------

SUBMITTED BY -> Kevin  Bracey

PROBLEM -> When inserting words into the dictionary, Inform 
automatically converts them to lower-case. Unfortunately, the way this 
is done assumes that A0 and A1 are the standard lower and upper case 
alphabets. If the alphabet table has been modified in a way that 
changes A0 or A1, dictionary entries will be mangled, as Inform will 
not allow any A1 letters into the dictionary.

The Zcharacter char directive will only modify A2, so the only way to 
provoke the bug is to request a complete replacement alphabet table 
using the Zcharacter string string string form. This would normally be 
done to improve text compression -- many later Inform games such as 
Shogun did this, moving some common upper-case letters into A0 and rare
lower-case letters into A1.

FIX -> Applied


-----------------------------------------------------------------------
 C62114 - Inform-generated V6 and V7 files are limited to 320K
-----------------------------------------------------------------------

SUBMITTED BY -> Kevin Bracey

PROBLEM -> The ofclass and metaclass operators in Inform take a 16-bit 
number, which in some way describes an entity, and have to determine 
what the number represents. The scheme currently used is (HON is the 
highest object number):

    0          represents "nothing"
    1..HON     represent that object
    HON+1..X-1 represent the packed address of a routine
    X..        represent the packed address of a string

For more details see section 8.8 of the Inform Technical Manual.

For this scheme to work, all packed addresses need to be higher than 
the highest object number, and in V6 and V7 the string offset and 
routine offset need to be the same so that the packed addresses of 
strings are higher than the packed addresses of routines.

The first of these is not a significant problem, but by requiring the 
string and routine offsets to be the same, the maximum size of 
Inform-generated V6 and V7 games is limited to 320K.

V6 and V7 allow up to 64K of low memory, 256K of code and 256K of 
strings, with a total size limit of 512K (limited by the file size 
field in the header - otherwise it could be 576K). Inform limits us to 
64K of low memory + 256K of code/strings.

FIX -> Applied


-----------------------------------------------------------------------
 C62115 - @ escapes are incorrectly handled in strings
-----------------------------------------------------------------------

SUBMITTED BY -> Kevin Bracey

PROBLEM -> There are several problems:

   * @@32 outputs a garbled Z-character sequence, rather than a space.
   
   * @@ with any number less than 256 is treated as that character from 
   the source ("ISO") character set, rather than that ZSCII code. 
   Values of 256 or greater are treated as ZSCII codes, and for values 
   less than 128 the error doesn't matter.
   
   * Escape sequences giving non-ASCII characters (eg @@169, @'a or 
   @{E1}) are always output as a 4 Z-character sequence, even if the 
   requested character is in the alphabet table (in which case it 
   should occupy 1 or 2 Z-characters).

In some cases the escape sequence may even output the wrong character 
altogether, if other accented characters are in the alphabet table.

FIX -> Applied


-----------------------------------------------------------------------
 C62116 - Certain abbreviations can crash compiler
-----------------------------------------------------------------------

SUBMITTED BY -> Allen Noe

PROBLEM -> Any Abbreviate directive containing a substring of "<unknown 
attribute>" will cause try_abbreviations_from() in text.c to attempt to
modify a string literal passed down from symbols.c line 305. ISO C99 
states at an attempt to modify a string literal causes "undefined 
behavior".

Modifying string literals was legal under traditional K&R C; however 
modern, standard-compliant compilers (such as GCC) will tell modern 
operating systems (such as Linux) to mark the memory segment containing
these strings as read-only. An attempt to write to a string literal in 
this situation will cause a segmentation violation, also known as a 
"crash".

Note that this bug does not cause a crash in all combinations of 
operating system and compiler.

FIX - Applied


-----------------------------------------------------------------------
 C62117 - Problem using non-ASCII characters in dictionary words
-----------------------------------------------------------------------

SUBMITTED BY -> Fredrick Ramsberg

PROBLEM -> On a platform where char is signed (all except RISC OS, OS/2
and VMS, according to Inform's header file), if you use a non-ASCII 
character in a dictionary word, the dictionary word is corrupted, amd 
the compiler may crash.

The problem can be worked around by using @ escapes instead of literal 
non-ASCII characters in dictionary words.

FIX -> Applied (Thanks to Kevin Bracey)


-----------------------------------------------------------------------
 C62119 - Negative constants in assembly
-----------------------------------------------------------------------

SUBMITED BY -> Daniel Schepler

PROBLEM -> Because of a bug in parsing assembly, it's difficult to 
specify negative constants in assembly operations. For example, if you 
write

   @set_colour 4 (-1);

the compiler will tell you that it found an unexpected expression. 
What's really going on here is that it's misinterpreting 4(-1) as a 
function call. Although you could work around this by using $ffff 
instead of -1, that makes the code less readable.

FIX -> Applied 


-----------------------------------------------------------------------
 C62121 - Expressions with routine/ofclass/or mis-evaluate
-----------------------------------------------------------------------

SUBMITTED BY -> Roger Firth

PROBLEM -> The compiler appears to generate incorrect code for an 
expression combining a routine call and the 'ofclass' and 'or' operators, 
as in the last of the four 'if' statements:

   [ Main; Test(c1); Test(c2); Test(c3); ];

   [ Test o;
       print "Testing ", (name) o, "^";
       if (o ofclass X || o ofclass Y)
          print "1:YES^"; else print "1:NO^";
       if (o ofclass X or Y)
          print "2:YES^"; else print "2:NO^";
       if (parent(o) ofclass X || parent(o) ofclass Y)
          print "3:YES^"; else print "3:NO^";
       if (parent(o) ofclass X or Y)
          print "4:YES^"; else print "4:NO^";
       "";
   ];

   Class X;
   X     p1;
   X  -> c1 "C1";

   Class Y;
   Y     p2;
   Y  -> c2 "C2";

   Class Z;
   Z     p3;
   Z  -> c3 "C3";

The four tests should all give the same results for a given object: YES
for C1 and C2, NO for C3. However, test 4 for C2 erroneously prints NO.

FIX -> Applied (Thanks to Neil Cerutti)


-----------------------------------------------------------------------
 C62125 - Strict check for property array access
-----------------------------------------------------------------------

SUBMITTED BY -> Cedric Knight

PROBLEM -> The Z-machine specification says that it is illegal to use 
@put_prop or @get_prop opcodes when a common property is longer than two 
bytes, and that the result is unspecified. Zip and Frotz follow Infocom
interpreters in corrupting the object table when @put_prop is used, but
other interpreters give a variety of responses to either opcode. 
Authors can, however, unwittingly compile such instructions, for 
example when an additive property is accessed using the '.' operator 
(see L61025 for an example in the library itself).

It might be expected that Strict mode would check for this illegal 
access, but it doesn't.

FIX -> Applied 


