
-----------------------------------------------------------------------
 C62101 - Can't compile without DEBUG
-----------------------------------------------------------------------

SUBMITTED BY -> Anson Turner

PROBLEM -> There is an error in the Inform 6.21 compiler's veneer code 
which causes compilation to abort with errors if debugging is not on. 
(Debugging is always on unless Strict mode is disabled with the ~S 
compiler switch.)

WORKAROUND -> To fix this, add the following to the game file after 
including "Parser":

   #ifndef DEBUG;
     Global debug_flag;
   #endif;


-----------------------------------------------------------------------
 C62103 - Plural bit not set on long dictionary words
-----------------------------------------------------------------------

SUBMITTED BY -> Torbjn Anderson

PROBLEM -> If you define a class like so:

   Class Elephant
      with name 'elephant' 'elephants//p'
      has animate;

you would expect Inform to set the plural bit for 'elephants', but it 
doesn't. As far as I can see, the problem is in dictionary_prepare() in 
text.c. Its main loop will terminate before it reaches the // part of 
the word.

WORKAROUND -> Although this really is a bug in the compiler, a quick 
way to address this problem (without patching and recompiling the 
compiler) is to modify the word table directly in the game source:

   'batteries'-->#dict_par1 = 'batteries'->#dict_par1 | 4;

Of course that sort of code can look a little cryptic. It makes for far
more readable source to wrap it in a function:

   [ MakePlural wrd; wrd-->#dict_par1 = wrd->#dict_par1 | 4; ];

So various nine-character words can legibly be made plural in Initialise():

      MakePlural('batteries');
      MakePlural('elephants');
      MakePlural('ostriches');
      MakePlural('creatures');
      MakePlural('gargoyles');
      MakePlural('loopholes');
      MakePlural('limericks');

(Thanks to Jim Fisher)


-----------------------------------------------------------------------
 C62104 - Additive property of NULL fails silently
-----------------------------------------------------------------------

SUBMITTED BY -> Brendan Barnwell

PROBLEM -> Normally, if there is an object Obj with a property prop 
such that Obj.prop==NULL, Obj.prop()==0. Also, if prop is an additive 
property and Obj inherits from Class1, Class2, and Class3 (in that 
order), calling Obj.prop() will result in an additional calls to 
Obj.Class1::prop() if the property routine provided by Obj returns 
false. If Obj.Class1::prop() returns false, Obj.Class2::prop() will be 
called, and Obj.Class3::prop() will be called if THAT returns false.

However, if an intermediate class in the hierarchy defines prop as 
NULL, the property routines of classes higher up the hierarchy will 
never be called. So, if Class2 defines prop as NULL, Obj.Class3::prop()
will NOT be called when it should. However, the return value of the 
Obj.prop() call in this case is still 0.

The result is that any class which defines an additive property as NULL
will break the code -- silently.


-----------------------------------------------------------------------
 C62106 - Indirect call doesn't set "self"
-----------------------------------------------------------------------

SUBMITTED BY -> Brendan Barnwell and L Ross Raszewsk

PROBLEM -> Normally, if your code calls a property routine using 
obj.prop(), then in the obj.prop routine the "self" variable will be 
set to obj. However, if you call the routine indirectly, like this:

   a=obj.prop;
     a();

"self" will not be set correctly (it will retain the value it has in 
the calling routine).

WORKAROUND -> This isn't a bug, because you are not sending a message. 
Notice that the code will crash if prop is not a routine, while a 
message send would either print the string if the value is a string, or
return it if not. The obj.prop(args) format is required for a message 
send. What the code example does is store obj.prop (the address of the 
routine) in a. It then calls the routine at the address stored in a.


-----------------------------------------------------------------------
 C62107 - Nested IFNDEF...IFNOT...ENDIF fails
-----------------------------------------------------------------------

SUBMITTED BY -> Roger Firth

PROBLEM -> If you nest the conditional compilation directives 
IFNDEF...IFNOT...ENDIF in certain configurations, the compiler 
complains "Error: Second 'Ifnot' for the same 'If...' condition". For 
example, the error is reported for the marked IFNOT, although there is 
nothing actually wrong with the code.

   Constant YYY;

   IfNDef XXX;
      IfNDef YYY;
         !
      IfNot;
         IfNDef ZZZ;
            !
         IfNot;
            !
         EndIf;
      EndIf;
   IfNot;      ! This line reported as wrong
      !
   EndIf;

WORKAROUND -> As a workaround, recast the conditions (for example, 
using IFDEF instead of IFNDEF), remove IFNOTs by employing 
complementary IFDEFs and IDNDEFs, or use the bi-platform Glulx compiler 
(without the -G switch), where this bug has been fixed.


-----------------------------------------------------------------------
 C62118 - Nested Includes can crash compiler
-----------------------------------------------------------------------

SUBMITTED BY -> Jim Fisher

PROBLEM -> Essentially, the compiler crashes when Includes are nested 
to a depth greater than three. For example, "source.inf" includes 
"file1.h" which includes "file2.h" which, in turn, includes "file3.h". 
These three nested Include directives work fine. It is only when 
"file3.h" tries to Include another file that the compiler crashes.

WORKAROUND -> A workaround is to increase the value of a #define in 
header.h called MAX_INCLUSION_DEPTH. I'm using the biplatform version 
of Inform, where it's set to 5. Setting it to be a larger number than 
is required should allow deeply nested files to compile.


-----------------------------------------------------------------------
 C62120 - (X in nothing) objectloop fails
-----------------------------------------------------------------------

SUBMITTED BY -> Eric Schmidt

PROBLEM -> Consider this sample routine:

   [ Initialise x;
     location = livingroom;
     objectloop (x in nothing) give x light;
     "What a mess is it here after that party!
      And your relatives arrive in just a few
      hours...";
   ];

(Yes, there are better ways of making it light everywhere. This is just
for example.) The code generates an error message at run time, but 
there is no reason it should. The correct behavior is to give every 
object without a parent light. (Yes, this causes problems if there are 
items out-of-play. Maybe there aren't.)

WORKAROUND -> The compiler is using an optimized version of objectloop 
where the loop follows the eldest child and proceeds through the 
siblings. It is illegal to find the child of nothing, and that is why 
an error occurs. If this is a problem, modify the control expression so
it is not in the "x in y" form, such as objectloop (x && x in nothing).


-----------------------------------------------------------------------
 C62123 - Line numbers in "no such constant" error
-----------------------------------------------------------------------

SUBMITTED BY -> Cedric Knight

PROBLEM -> Suppose the variable "the_time" is mistakenly typed as 
"time" at line 222, and a new verb has been added, defined by TimeSub, 
and called validly as <time>; in line 111. The compilation error is 
shown as at line 111 (111): Error: No such constant as "time".


-----------------------------------------------------------------------
 c62124 - Problem with European quotes
-----------------------------------------------------------------------

SUBMITTED BY -> Roger Firth

PROBLEM -> One of the bugs fixed at the last release of the compiler 
was:

"The character codes for << and >> (Continental European quotation 
marks) were the wrong way around, following a mistake in version 0.2 of
the Z-Machine Standards document. They have therefore been swapped 
over, following the correction made in version 1.0 of that document."

Unfortunately, the fix is wrong, in that the Unicode values @{AB} and 
@{BB} now produce the characters ">>" and "<<", whereas they should 
display "<<" and ">>" respectively.


The problem is associated with the default zscii-to-unicode conversion table. If another table is used (for example, by supplying the directive Zcharacter table '@{AB}' '@{BB}';), then the characters print correctly.

