Fatal error when setting $DICT_WORD_SIZE=4 for v3 games due to hardcoded check

Currently, the Inform 6 compiler perfectly handles Z-machine dictionary sizes autonomously behind the scenes. However, if a user attempts to explicitly configure $DICT_WORD_SIZE to a mathematically valid value for a v3 game, the compiler throws a fatal error due to a flawed guardrail and a mix-up between bytes and Z-characters.

The compiler's internal pipeline already handles Z-code dictionary construction flawlessly without needing the $DICT_WORD_SIZE memory setting:

1. In text.c: In dictionary_prepare_z(), the compiler completely ignores the $DICT_WORD_SIZE setting and correctly hardcodes the dictionary text size based on the target version using int dictsize = (version_number==3) ? 6 : 9;. Note that this correctly limits the size to 6 Z-characters for v3 (which packs into 4 bytes).

2. In symbols.c: The compiler safely exposes the correct byte size to the game code by dynamically creating the constant: create_symbol("DICT_WORD_SIZE", ((version_number==3)?4:6), CONSTANT_T);.

Because a v3 dictionary word uses 4 bytes, a user might explicitly pass $DICT_WORD_SIZE=4 on the command line when compiling a v3 game. This is technically accurate.

However, doing so triggers a fatal error: You cannot change DICT_WORD_SIZE in Z-code.

This is triggered by a hardcoded check in inform.c that enforces DICT_WORD_SIZE == 6. The root of this check appears to be a historical unit confusion between bytes and characters. We can see this confusion in the option description inside options.c:

"DICT_WORD_SIZE is the number of characters in a dictionary word. In Z-code this is always 6 (only 4 are used in v3 games)."

This comment conflates Z-characters (6 are used in v3) with bytes (4 are used in v3). Because the developer was thinking "always 6," they locked the memory setting to 6 in inform.c.

Consequently, the compiler throws a fatal error on mathematically valid configurations before it even reaches the dictionary construction logic.

Because the entire Z-code pipeline completely bypasses the command-line $DICT_WORD_SIZE setting to correctly construct the dictionary anyway, throwing a fatal error here is unnecessary. It would be much more user-friendly to downgrade this check to a simple warning (e.g., "Warning: The $DICT_WORD_SIZE setting is ignored in Z-code; dictionary sizes are set automatically"), allowing compilation to proceed normally.

[erkyrath]

I'm afraid this is a place where history trumps intuition.

The DICT_WORD_SIZE constant originally was dictionary bytes, not characters. In fact it wasn't even a defined constant; the compiler handled compiled dictionary words as "uchar w[6]". (Even in v3 games -- the last two bytes were then unused.)

When I added Glulx, it was easiest to make DICT_WORD_SIZE a variable in Glulx (where characters were always bytes) but keep it 6 for Z-code, so as to change existing code as little as possible. When I then added Glulx Unicode, I kept DICT_WORD_SIZE as characters but multiplied it by DICT_CHAR_SIZE (1 or 4) to get bytes, because that still changed no existing code.

This means that, yes, DICT_WORD_SIZE is still bytes in Z-code and not really representative of how v3 works. But this doesn't matter because there is no reason to set that option in Z-code. Changing the setup now (or indeed twenty years ago) would just add chaos for no benefit.

That makes sense from a legacy maintenance perspective - thanks for the historical context. Since we are leaving the strict error check in place, would you approve of a small patch that updates the comment in options.c so future users don't get tripped up?

[erkyrath]

Yes, thanks.