> Would it make sense to update the utf-8 code so that we only ever > pass in int32 or uint32 parameters, and not "wchar_t"? We could add > a test on input that converts anything above 24-bits into a specific > undefined character value, which we would need to document of course.
My feeling is that this would probably be a good idea. As for checking that the values are 24-bit clean, then we would perhps do that ONLY if the macro STRICT_RFC3629 was set (see fl_utf.c) but otherwise we'd just let anything go... Sort of... Actually, the STRICT_RFC3629 macro might trigger that already, now I think of it. Nope: in fact the current implementation of fl_utf8decode() will reject any value bigger than 0x0010FFFF whether STRICT_RFC3629 is set or not. SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
