Encoding problems due to automatic QByteArray <-> QString casting

[Milian Wolff]

Andreas Pakulat wrote:
> On 22.07.09 16:39:08, Milian Wolff wrote:
>> Milian Wolff wrote:
>>> See also: https://bugs.kde.org/show_bug.cgi?id=183182
>>>
>>> The problem here is that QString has a ctor which converts a QByteArray 
>>> implicitly to a QString. Apparently that fucks up encoding everytime. 
>>> We had to fix that at like four different places, always replacing the  
>>> implicit stuff with QString::fromUtf8(...).
>>>
>>> Now a friend of mine told me that there are:
>>>
>>> -DQT_NO_CAST_FROM_ASCII
>>> -DQT_ASCII_CAST_WARNINGS
>>> -DQT_NO_CAST_TO_ASCII
>>>
>>> Could/should we use those? It would show these kind of errors much earlier.
>> Those are impractical since they (of course) also forbid the ctor for  
>> simple c-char arrays which are used quite a lot (without any harm)
> 
> Pure luck that those don't contain non-ascii characters. We shouldn't
> advertize this implicit conversion by having such places.
> 
>> . of  course we could use QLatinString but I doubt the huge change would
>> justify the small gain. What do you think?
> 
> Is there a way of making them warnings instead of real errors? That would
> at least allow to enable them now and then try to look at the warnings to
> check wether we can maybe easily filter out the real problems from the
> relatively unproblematic c-char array case. Fixing encoding problems
> without these defines is definetly not a nice job, especially since we're
> converting back and forth in a couple of places.

Yes, there is a way to set them to warnings. But with all the other 
cases that would greatly pollute the compile process... I doubt that's 
easier to find possible errors in the make output...

>>> Too bad we can't mark functions/methods explicit :-/
>> We could also supply functions which accept a QByteArray and just calls  
>> the parent function with QString::fromUtf8(input)... That would be  
>> failsafe... But imo a bit ugly to have that for every function...
> 
> Lets not pollute the API with "convenience" functions when the developer
> needing them could've also written proper code. I know I usually also don't
> use QLatin1String, but that should actually be fixed.

If you really want that, then yes - I could add the define for warnings. 
Maybe I even fix some of the warnings...
-- 
Milian Wolff
http://milianw.de