Is this an ASCII conversion bug.

[swhite]

Hi
I am using PB 5.62 64bit on Windows and when I run the following code the result is that Ascii character 149 gets changed to ascii character 63 using the PokeS() or the ASCII(). Have I done something wrong or this indeed a bug?

Code: Select all

lcTxt.s = Chr(149)
Debug Asc(lcTxt)
Debug PeekA(@lcTxt)
*txBuffer=AllocateMemory(10)
PokeS(*txBuffer,lcTxt,1,#PB_Ascii)
Debug Str(PeekA(*txBuffer))
Debug PeekS(*txBuffer,1,#PB_Ascii)

*Buffer = Ascii(Chr(149))
Debug PeekA(*Buffer)
FreeMemory(*txBuffer)
FreeMemory(*Buffer)

[swhite]

Hi
The following code shows that this happens for ASCII values between 128 - 159

Code: Select all

*txBuffer=AllocateMemory(5)
For ln.i=1 To 255
   lcTxt.s = Chr(ln)
   PokeS(*txBuffer,lcTxt,StringByteLength(lcTxt,#PB_Ascii),#PB_Ascii)
   If PeekA(*txBuffer) <> ln
      Debug Str(ln)+" "+Str(PeekA(*txBuffer))
   EndIf
Next
FreeMemory(*txBuffer)

[infratec]

Hi,

that's not a bug. It's a feature

If you open the 'Character-Table' in the Tools menue, then you can see that the 'ASCII'
values for 128 to 159 are not defined.

The not defined values are replaced by a questionmark '?' wich is dezimal 63.

But it's more complicated:
As you can read in the help of Chr() it is working in unicode mode.
And in unicode 0x80 (128) to 0x9F (159) is not defined.
That's the reason why it is not working as you thought.

What's your 'real' intention?

[swhite]

Hi

I have a host authorization service that returns these characters as part of a bitmap so they must be accurate to be interpreted. It currently runs in ASCII mode but I recently updated to Unicode and started seeing problems with the application when ASCII values fell in this range.

It seems to me that the ASCII value is an ASCII value and there is no reason to change it.

Simon

[swhite]

Hi

This issues does not exist in the Linux version so it seems to me it should not be the case in Windows version either.

Simon

[infratec]

If the behaviour in Linux is different to windows, then it's a bug.
The results should be consistant.

Maybe a flag for Chr() is needed to specify the mode (ASCII, UTF8, UNICODE)
The normal codeset in linux is UTF8, so it's possible that the Chr() functions returns other values than '?'

The only workaround which I see is an own DataSection with your needed ASCII values inside.
At least for the values between 128 and 159. Maybe for all values above 127.

Bernd

[wilbert]

If the behaviour in Linux is different to windows, then it's a bug.
The results should be consistant.

Why should the results be consistent ?

Linux probably uses ISO-8859-1 as the default codepage in which case code 0 - 255 are identical to unicode and therefore can be converted.
Windows most likely uses Windows-1252 in which case code 128 - 159 are not identical to unicode so they can not be converted and are substituted by a question mark.