[M3devel] AND (., 16_ff). Not serious - or so I hope!

[Jay]

>> > 128 limit
>> 
>> I haven't read the code enough yet to verify that but you are probably right
> 
> I was not right :), that call is incremental.

I looked for that aspect too but missed it. :(


>>  > ignoring everything over 16_FF
>> 
>> Probably that is the responsibility/claim of the caller of GetChars.
>> If you want to be correct in the face of non-ASCII, you are probably obligated to call GetWideChars.
>> Perhaps raising an exception would be reasonable to signal the loss of data. Or something.
>> There is HasWideChars for you to check.
> 
> 
>> 
>> There is no encoding implied remember.
>> This isn't UTF8 data.
> 
> 
> It is not, but probably only way to solve this without exception is to make UTF8 "official" 8bit encoding :)
> 

I'm torn on that. We'd have to consider ramifications like Text.Length vs buffer size requirements/expectations.


Is TEXT & its use abstracted enough to have been widened? Should we put it back and introduce WIDETEXT? That is essentially what C and C++ do. They are inconvenient for existing code but simple predictable make sense. Contrast with weird hybrid systems like Perl & Python for which I just can't get through the documentation and understand and predict how they work..


Java is in-between but also simple & predictable -- there being no narrow option other than array of byte, which is reasonable.


 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120626/e6db0ce3/attachment-0002.html>