On Tue, Jan 23, 2018 at 04:45:50PM +0100, Rainer Orth wrote:
> There are already a couple of instances of those functions with a pg_
> prefix, obviously to avoid conflict with differing b64_{encode,decode}
> declarations on other systems, but they don't match exactly:
> e.g. src/include/common/base64.h has
>
> extern int pg_b64_encode(const char *src, int len, char *dst);
> extern int pg_b64_decode(const char *src, int len, char *dst);
Those are new as of v10, being used by the SCRAM implementation with a
more generic API designed for this purpose. The main difference with
what is in encode.c is the whitespace handling to cope with what RFC
5802 requires.
> while the encode.c and pgp-armor.c versions use an unsigned return value
> and len argument.
>
> However, since those two latter versions are static, adding a pg_ prefix
> there, too, worked without conflict, allowed the compilation to finish
> and make check to succeed.
I am not much a fan of using the same function name for both the static
functions in pgcrypto and encode.c, as well as what is in
src/common/. In order to avoid any conflicts, why not just changing at
least the prefix from "b64" to "base64"? That's not completely
problem-proof for the problem either, as php has a base64_encode for
example. So my suggestion would be to change the prefix on all branches
and to append pg_ to all the routines in encode.c for
consistency. Better naming suggestions welcome.
--
Michael