Tk Source Code

When sizeof(enum) != sizeof(int), unaligned pointer access can happen when using TK_OPTION_STRING_TABLE. This is non-portable. The default behaviour of gcc/clang is to use 'int' as implementation for enum, but the -fshort-enum compiler option can be used to make enum storage more efficient. This cannot be used for Tk, currently.

Problem description: In tkPlace.c, lines 70-72:
<pre>
    Tk_Anchor anchor;	... (Tk_Anchor is an enum)
    BorderMode borderMode; ... (BorderMode is an enum too)
</pre>
If both Tk_Anchor and BorderMode are implemented as shorts, they fit together in an integer and borderMode will not be aligned on a 4-byte border.

Further below:
<pre>
    {TK_OPTION_ANCHOR, "-anchor", NULL, NULL, "nw", -1,
	 Tk_Offset(Content, anchor), ...
    {TK_OPTION_STRING_TABLE, "-bordermode", NULL, NULL, "inside", -1,
	 Tk_Offset(Content, borderMode), ...
</pre>
The `TK_OPTION_STRING_TABLE` option expects a `Tk_Offset` which is 4-byte aligned, as the variable (`borderMode` in this case) should be an integer. It isn't: it's an enum. As soon as the `-bordermode` option is used in the `place`, this will result in non-aligned access: crash!

In total, I found 17 places where this is done wrong. Most of them have an int or a pointer following or preceding the offending variable, so no unaligned access will happen: some padding bytes will be written unintentionally, but that's all. the `-bordermode` is the only example found which really can go wrong.

Proposed solution: Use a new flag TK_OPTION_ENUM_VAR, and check for this flag in TK_OPTION_STRING_TABLE parsing.

The 'revised_text' branch had some additional places where `TK_OPTION_ENUM_VAR` was lacking. Added those now.

Closing

Proposed fix [https://core.tcl-lang.org/tk/timeline?r=bug-eedd795d98|here]