the 5.42 docs for Base64Decoder uses #PB_Ascii|#PB_String_NoZero, but it would also be good if it mentioned somewhere that the buffer needs to be Ascii, if indeed that's still the case! btw I think from the new 5.50 on you can use Ascii() instead of PokeS(etc,#PB_Ascii)
[edit] oops, i meant binary data not ascii string!
Last edited by Keya on Wed Jun 22, 2016 8:15 pm, edited 1 time in total.
Fred wrote:You should use MemoryStringLength() instead of MemorySize(), as ascii strings needs to be zero terminated.
Since Base64 don't want the terminating character, I always use AllocateMemory(StringByteLength(..., #PB_Ascii)) which is without terminating character and PokeS(... #PB_String_NoZero)
PureBasic 5.73 | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Old bugs good, new bugs bad! Updates are evil: might fix old bugs and introduce no new ones.
Im just wondering about a situation where for example i read a full .EML file with its base64-encoded attachments into an AllocateMemory(Lof(hFile)) buffer, and then use wilberts FindData module to quickly locate the position of each attachment in the buffer. If Base64Decoder expects a string I would need to make a str=PeekS copy from the buffer? wouldnt be good with large attachments (slower + duplicated memory), especially with base64 sizes being +33% ?
Keya wrote:Im just wondering about a situation where for example i read a full .EML file with its base64-encoded attachments into an AllocateMemory(Lof(hFile)) buffer, and then use wilberts FindData module to quickly locate the position of each attachment in the buffer. If Base64Decoder expects a string I would need to make a str=PeekS copy from the buffer? wouldnt be good with large attachments (slower + duplicated memory), especially with base64 sizes being +33% ?
If you need to decode big attachments, you could build you own high speed decoder. The Base64 specification is not that complicated.
For small attachments, the impact on memory and speed probably isn't that big.