imacarthur wrote: > > On 17 Jan 2009, at 0:16, Alvin wrote: > >> I'm using FLTK 1.3 r6634 and I am seeing a potential off-by-one error >> with >> Fl:event_length(). In past revision of FLTK 1.3.x, Fl::event_length() >> would >> return the number of bytes stored in Fl::event_text() (upon receiving a >> FL_PASTE after a FL_DND_RELEASE event). However, what I am seeing now is >> the Fl::event_length() is returning the number of characters. The >> difference this make is that the null-terminator is not included in the >> count returned by Fl::event_length(). > > Going off at a tangent... > > I should probably know this, but right now I can't remember - what does > Fl::event_length() return for a UTF-8 string? > > If it is indeed literally "characters" rather than "bytes" then Alvin's > approach (which I know is widely used in C-style languages everywhere) > to ensuring the string is NULL-terminated, is not going to work, as many > strings will have far more bytes than characters, in general.
He meant bytes. I would say that 100% of the time when somebody says "number of characters" they mean "number of bytes" (except for UTF-16 where they probably mean "number of 16-bit-words"). People believing that you have to accurately count the number of Unicode code points in a string in order to do any manipulation are one of the biggest impediments to getting Unicode to work. If you see a number that represents an offset or length of a UTF-8 or UTF-16 string, it is ALWAYS the number of bytes/words. If anybody says or insists that it is the "number of characters", they are WRONG!!!! If such mis-informed people are in a position where they may rewrite the code so it starts decoding to Unicode, they must be stopped asap as they are causing more damage than they can possibly imagine. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
