Home
Products
Community
Manuals
Contact
Login or Signup

encode TBase64 bug?

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

Arowx(Posted 1+ years ago) #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 1+ years ago) #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 1+ years ago) #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 1+ years ago) #4
I'm using Windows Vista 32 bit - BlitzMax 1.33rc5 just rebuilt with the latest MinGW 5.1.4.exe ?


Plash(Posted 1+ years ago) #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 1+ years ago) #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 1+ years ago) #7
I used MaxIDE. The error is probably caused by the formatting in the BLIde console.


Arowx(Posted 1+ years ago) #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 1+ years ago) #9
Looks like a bug :-)

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


Arowx(Posted 1+ years ago) #10
Excellent cheers brucey! ;o)


ziggy(Posted 1+ years ago) #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.