encode TBase64 bug?
BlitzMax Forums/Brucey's Modules/encode TBase64 bug?| 
 | ||
| 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? | 
| 
 | ||
| Testing [MA==] end of test Seems fine for me, I'm on Max 1.32 (Win32) with Base64 at version 1.00. | 
| 
 | ||
| I just tried it on Mac (Intel 1.33) and Linux (1.32), and both resulted in the text Plash shows above. | 
| 
 | ||
| I'm using Windows Vista 32 bit - BlitzMax 1.33rc5 just rebuilt with the latest MinGW 5.1.4.exe ? | 
| 
 | ||
| Have you tried it under both GCs? I tried it with the threaded and standard GC, with the same output as above. | 
| 
 | ||
| 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? | 
| 
 | ||
| I used MaxIDE. The error is probably caused by the formatting in the BLIde console. | 
| 
 | ||
| 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? | 
| 
 | ||
| Looks like a bug :-) I've updated the code in SVN. Your example now returns only 4 characters from Encode(). | 
| 
 | ||
| Excellent cheers brucey! ;o) | 
| 
 | ||
| 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. |