[ccan] [PATCH] base64: implements rfc4648, the base64 encoding

[Peter Barker]

On Wed, 25 Feb 2015, David Gibson wrote:

>>> I was trying to keep the interface as small as possible.  I couldn't see any
>>> use case for it outside the library.  Having said that, I can see a caller
>>> switching between alphabets and wanting to use the rfc4648 one (rather than
>>> switching between functions to call).
>
> I think that last is a good enough reason to export it.  It also means
> that the rfc4648 specific wrappers can become inlines in the header.

That's done.

> Actually, reading a bit further on, I'd export *just* this, not the
> 1-way alphabet that is exported - you can get to that through the
> encode map field if you need it.

That's also done.

> I think I'd be happy enough with either "alphabet" or "maps".

I've changed it to "maps".

>> advantage/disadvantage (depending on how you look at it) if you
>> accidentally miss some characters.
> I'm not sure, but would an explicit length mean you get a warning if a
> character was accidentally inserted or deleted into the string?  If

pbarker at eccles:~$ gcc -std=c99 test.c -o test
test.c:20:23: warning: initializer-string for array of chars is too long 
[enabled by default]
  const char xyzzy[3] = "abcd";
                        ^

So that's good.  The C standard says anything not set will be initialised 
to 0 - so no warning for short initialisers.

>>>>> +size_t base64_encode(char *dest, const size_t destlen, const char *src, const size_t srclen);
>>>>
>>>> `const size_t foo` parameter is a bit funny-looking.
>>>
>>> Hmmm.  David mentioned the same thing.  I defended it then by pointing out
>
> I'm still uncomfortable with it.  And I think the reason is that it
> exposes in the function signature what's really an internal detail.
> For a simple pass-by-value integer, the caller doesn't care if the
> fuction mangles its copy.  But now, if you change implementation so
> that you do want to change that variable from the original parameter
> value, you need to either change the signature, or do a copy into a
> local.

OK, that's a pretty convincing argument.

I've stripped the consts from the external declarations.  Turns out the 
function definition can *add* the consts without causing compiler 
conniptions.  Everybody wins.

New version will be sent soon.

> David Gibson			| I'll have my music baroque, and my code

Ta,
-- 
Peter Barker                          |   Programmer,Sysadmin,Geek.
pbarker at barker.dropbear.id.au	      |   You need a bigger hammer.
:: It's a hack! Expect underscores! - Nigel Williams