> > Is it safe to assume that all toolchains now know what a > uint32_t is? > > If so, that would be my favourite option. > > I don't know if it would be safe, but I don't see that we use it > anywhere, so this would be new.
OK, then if not uint32_t, perhaps some other unsigned type that is at least 32-bits. Not "unsigned long" I suppose, since that might be 64-bit on some hosts (and therefore bigger than we'd need!) but perhaps just "unsigned"... Can we assume that "unsigned" is at least 32-bit? > > I don't believe that mk_wcwidth.c needs wchar_t at all, nor > should it > > include wchar.h either. > > Currently it's commented out (#if 0), thus we know that it is not > needed. Though I think that is only because Duncan has wrapped mk_wcwidth inside fl_wcwidth which does set a "value" for wchar_t. > But I looked at FL/fl_utf8.h, and there you can see that we > often use "unsigned ucs" etc., and some functions return unsigned > values for unicode characters, e.g.: OK - then "unsigned" is probably what we want? Actually, now I think about it, it is entirely possible I wrote some of the functions in fl_utf8 you are referring to... I have a vague déjà vu about all this now... > Thus, the main challenge would be to stay compatible with FLTK's > internal representation of unicode (not UTF-8) characters. That > dictates "unsigned" (IMHO), unless we want to change that too... Agree. 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
