encode TBase64 bug?

BlitzMax Forums/Brucey's Modules/encode TBase64 bug?

Arowx(Posted 2009) [#1]
Hi Brucey getting an odd result from the TBase64.encode() command...
Import bah.Base64

Print "Testing [" + TBase64.encode("0", 1) + "]"
Print "end of test"
produces
Testing [MA==end of test


It looks like the resulting string is garbled in some way?

Increasing the length value by 2 seems to resolve the problem?


plash(Posted 2009) [#2]
Testing [MA==]
end of test


Seems fine for me, I'm on Max 1.32 (Win32) with Base64 at version 1.00.


Brucey(Posted 2009) [#3]
I just tried it on Mac (Intel 1.33) and Linux (1.32), and both resulted in the text Plash shows above.


Arowx(Posted 2009) [#4]
I'm using Windows Vista 32 bit - BlitzMax 1.33rc5 just rebuilt with the latest MinGW 5.1.4.exe ?


plash(Posted 2009) [#5]
Have you tried it under both GCs? I tried it with the threaded and standard GC, with the same output as above.


Arowx(Posted 2009) [#6]
This is wierd I've been building with Blide and getting this odd result, but when I build using the default IDE it's working fine?

@plash I've checked that both ide's are using the latest version which ide did you use?


plash(Posted 2009) [#7]
I used MaxIDE. The error is probably caused by the formatting in the BLIde console.


Arowx(Posted 2009) [#8]
Yes got it now try this...
Import bah.Base64

Local txt:TStream = WriteStream("test.txt")

txt.WriteString("Testing [" + TBase64.encode("0", 1) + "]")
txt.WriteString("end of test")
txt.close()
Which should produce this
Testing [MA==<NUL>]end of test
Where <NUL> is an empty byte that throws the BLIde console.

So should the Null be there is this just a hiccup or a bug?


Brucey(Posted 2009) [#9]
Looks like a bug :-)

I've updated the code in SVN. Your example now returns only 4 characters from Encode().


Arowx(Posted 2009) [#10]
Excellent cheers brucey! ;o)


ziggy(Posted 2009) [#11]
It was a bug on the internal BLIde formating, as BLIde is understanding the 0 ASCII char as an CString end. Fixed for next BLIde version.