Re: Add support for base64url variant

[pierre.techoueyres@free.fr (Pierre Téchoueyres)]

Eli Zaretskii <eliz@gnu.org> writes:

>> ...
>> I would like to have some discussion on how to improve some points :
>> - Is adding parameter to existing functions the way to go or is it 
>> better to add new ones for base64url
>
> I think an optional argument will be fine.

Except here I've added two, and one that doesn't really mean anything if
the second isn't set.  ie. you should not (at least without breaking the
RFC) generate an base64 string without padding.  At first many
parameters seemed to me a good thing : limitted patch and flexibility.
But now I'm no more sure ...


>> - I would like to improve base64-decode* in a way it could detect the 
>> variant but actually don't know how to do that.
>
> Maybe someone else will have an idea.  Is such an algorithmic
> detection described someplace?
>
None I'm aware of.  I was thinking to something like that :
- define two boolean.  One saying you're on crude base64 another saying
  you're on base64url variant. 
- initialize them as false.
- start decoding.
- when finding crude base64  chars (/ or +) set the base64 to true,
- when finding specific url variant chars (- or _) set base64url to true,

try to decode until the end of data.  On parts where padding is checked
do it only if base64 is true.

But this approch could fail on the following cases :
- a mix of chars from both variant without padding (no checks but
  obviously wrong)
- absence of chars from any variant (here I can't decide for the
  necessity of padding).

I would also bring your attention on the part where I dynamically assign
pointers on specialized arrays for encoding (resp. decoding).

ex: line 244 of patch

char const *b64_value_to_char = (url_variant) ? base64url_value_to_char : base64_value_to_char;


Before my change there were static const, so I suppose compiler could
have inlined them or at least stored on some cache.  But now ...
So I'm a little scarried by the possible lost of performance.  If anyone
has some hint on how I could benchmark this (other than by the naive way
which could result in my data where all in cache ...)

Pierre.