[fpc-devel] Unicode support (yet again)

[Hans-Peter Diettrich]

Martin schrieb:
> On 16/09/2011 02:49, Hans-Peter Diettrich wrote:
>> Martin schrieb:
>>> On 15/09/2011 19:52, Hans-Peter Diettrich wrote:
>>>> Graeme Geldenhuys schrieb:
>>>>> On 14/09/2011 19:17, Hans-Peter Diettrich wrote:
>>>>>> How many users will have to deal with chars outside the Unicode BMP?
>>>>>
>>> Any app that loads a text from disk.
>>
>> Again: please answer my question first: How many *users*?
> 
> Are your trying to prove your point by answering questions, that can not 
> be answered ( I don't even know how many users use FPC) ?
> If you need to go that way, that rather proves the weakness of your point.
> 
> My guess more than 90% of all apps deal with some form of user input [1]?
> So the answer is more than 90% of the users/developers/apps.

This also doesn't answer my question :-(

Perhaps I should have stressed *deal with* astral characters. Input and 
output require no explicit code at all, so that the *chance* of 
occurence of such characters is unimportant.

Which real-life code will have to e.g. parse such strings, in a way that 
astral characters can get into the way at all? When strings are split at 
specific locations (whitespace, list or path separators...), these 
places can be determined by Pos or similar functions, regardless of the 
chars in between these delimiters. Likewise upper/lowercase conversions 
can be done with according (Unicode aware) standard functions, working 
on entire strings, not on char level.


> -
> [1]
> Even if the user input does not always contain such data, even if the 
> user input in most cases does not contain such data. The point is the 
> user input can contain such data (even if by accident/unintentional). As 
> for writing an app, if it *can* happen, then the app *must* be able to 
> deal with it.

Please give a reasonable (practical) example, where an application 
*must* deal with (such) chars. (see above)

> So for any application: even a 0.0001% chance that it will happen, means 
> the app must 100% deal with it.

*Not* dealing with string *contents* will reduce that chance to 
definitely zero.

> That is unless you document: "if any of the input contains ..., then 
> your app will [crash|fail| display nonsense]" => because of course if a 
> crash is documented, it isn't a bug, it becomes a feature ;)

Looks like your apps also will toggle bits in Real values, and tend to 
crash with zero-divide later ;-)

SCNR

DoDi