[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)

[jose.marchesi at oracle dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30444

--- Comment #12 from Jose E. Marchesi <jose.marchesi at oracle dot com> ---
(In reply to Sven from comment #8)
> (In reply to Jose E. Marchesi from comment #7)
> > While implementing this in GNU poke [1] I noticed that the base64 value
> > encoded in ASCII after the // is mutilated, since in order to fit in six
> > characters it is omitting the trailing two padding characters ==.
> 
> Yes, the padding is omitted. But according to section 3.2 of RFC 4648, the
> padding is optional if so desired. Any RFC compliant decoder should work.
> 
> Also see https://en.wikipedia.org/wiki/Base64#Variants_summary_table

Ok, this is worse than I thought :)

Given the section name //AAph7S, the corresponding base64 to decode is
00AAph7S, _not_ AAph7S==.

Found it the hard way while implementing this in BFD.

-- 
You are receiving this mail because:
You are on the CC list for the bug.