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.
