Created attachment 147260 [details] [review]
Use guint32 instead guint16

You should have mentioned that this also causes gcc to emit warnings with -Wall, so it's bad bad bad.

The table is the way it is to make it small. We've worked very hard on making it compact. Would be a shame to throw all that away now to quell a compiler warning.

-1 from me.

but you are right that casting 0x10001af to 0x01af is a bug. Compose-parse.py is supposed to throw away non-bmp keysyms; seems that it doesn't do so reliably. And we need a separate non-BMP table to take these sequences.

Actually the Unicode character in question *is* in the BMP (U+01AF), but the problem is that its corresponding *keysym* is not one of the "traditional" ones that fit in 16 bits, but one of the "generic" ones that are encoded as 0x1000000 + the Unicode codepoint.

Comment on attachment 147260 [details] [review]
Use guint32 instead guint16

As discussed in the meeting, double the size of the table is not a correct solution. See the bottom of the log: http://live.gnome.org/GTK%2B/Meetings?action=AttachFile&do=view&target=20091110.txt

I have fixed the script to reliably throw away >16bit keysyms and regenerated the tables.