Compiler error in TADS 3 conditions with strings?

Recently I got Thaumistry: In Charm’s Way and the other day I was looking through its folder. There’s a patch file called patch.t with this comment at the very top:

[code]/*

  • WARNING: Due to a TADS bug, string expressions within “if”, “for”, “while”, and “?:” statements
  • can result in nil object reference runtime errors or wrong results. All such comparisons must be
  • performed outside of such statements and their result stored in a local variable.
  • “switch” statements cannot be used. They must be converted to their if-else equivalent.
    */
    [/code]

I’m working on a TADS 3 game and this comment got me worried because my source includes several places where an if() or switch() statement uses strings. Can anyone confirm that this is, indeed, a bug in TADS 3 and what are the exact situations where this would manifest itself?

There are ways around this problem but they’re all very cumbersome and are hard to remember and the comment is vague about exactly what scenarios break.

Realnc should tell, but my guess(!) is this is something related exclusively to a way how Thaumistry patches initially released version at run time to update it to the latest version containing fixes while maintaining binary compatibility to ensure save games are preserved. Normally when you make a change to the source code and build a new version of the game then save game files are no longer valid because save game is in essence a binary dump of objects from the memory and this cannot work with a new binary no mater how small the change is. Thaumistry uses clever trick to patch the game at run time therefore the binary is still the same and patch.t file contains differences (updates to the game to fix things) and is applied using embedded compiler and evaluated at run time. This is really edge case (a hack really) and have rough edges and I believe this comment is related to it.

So for short, whatever you understand what I’m saying or not don’t worry, be happy!

tomasb is correct. The comment in that file only refers to some shortcomings of the DynamicFunc system:

tads.org/t3doc/doc/sysman/dynfunc.htm

tomash and RealNC - thank you for your answer. That’s very reassuring - I really prefer not having to work around this, if it’s not a problem in the plain, non-dynamic-function-from-outside-the-game case.