pharvey at codebydesign.com
Wed Nov 7 22:28:42 GMT 2007
On Tuesday 06 November 2007 14:37:03 Steve Langasek wrote:
> On Tue, Nov 06, 2007 at 09:35:58AM -0800, Peter Harvey wrote:
> > > Ok, I do fall on the side of Steves point about this, it seems IMHO to
> > > be a solution in search of a problem.
> > Ok; if I happen to come across something which seems more significant I
> > will mention it. At the moment I think you guys are right.
> > With this in mind I will not bother to move any further on making the ini
> > lib unicode aware which has the side affect of me dumbing down strings
> > from the Qt GUI code (or odbcinst doing it).
> Sorry, why does this imply that the strings should be dumbed down (which I
> gather means smashing to ASCII), instead of converting between UCS-2 and
Nick can correct me if I am wrong - but I think all of the string processing
in unixODBC is either done assuming an 8bit character (not variable/UTF-8) or
a wide char (ie wchar_t). In either case; by the time we get to the ini lib
(as an example) processing is based upon 8bit character. If we were just
shoving text data around I suppose there would be little problem but in some
cases the text is being interpreted and I would imagine the existing code
would not handle text data safely where characters are outside the limit of a
single 8bit character.
By processing I mean such stuff as the following;
- extracting strings where strings are delimited by ('\0' || ';' || '=') in an
array of characters
- looking for keywords in an array of characters
I suppose UTF-8 could be processed as per 8bit character if, in the case of
more than 8bits being used for a character - that no part of the sequence was
to be a viable ASCII character. I seem to recall something about this in some
doc I read - not sure.
More information about the unixODBC-dev