[unixODBC-dev] iconv/ICU

Peter Harvey 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
> UTF-8?

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.

--
Peter




More information about the unixODBC-dev mailing list