Re: Conflicting declarations for b64_encode etc. on Solaris 11.4 Beta - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: Conflicting declarations for b64_encode etc. on Solaris 11.4 Beta
Date
Msg-id 20180214060454.GA4544@paquier.xyz
Whole thread Raw
In response to Re: Conflicting declarations for b64_encode etc. on Solaris 11.4 Beta  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Conflicting declarations for b64_encode etc. on Solaris 11.4 Beta
List pgsql-bugs
On Wed, Jan 24, 2018 at 11:16:11AM +0900, Michael Paquier wrote:
> 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.

Attached is an updated patch which does a bit more consistency work.  I
have renamed the base64 functions with pg_base64_ as prefix in encode.c,
to avoid any conflicts in encode.c.  pgp-armor.c also gets the same
treatment.  There is no real point in renaming the other functions is
not necessary, and hex_encode/hex_decode are publicly available, so
renaming them would cause breakage for any callers of them in plugins.

It is a bit sad that both pgcrypto and encode.c hold copies of base64
functions.  If one looks closely, they use the same logic for
pg_base64_encode, pg_base64_enc_len and pg_base64_dec_len.  Each
pg_b64_decode uses different code paths for error handling, but they
actually have the same conversion logic (see b64_test.c attached which
emulates both, I was too lazy to read and compare b64lookup).  One way
to remove the duplication is to extend the _decode API with a path to
not complain with elog and return a status code, then have encode.c use
a wrapper on top of it, but that may not be worth the complication, and
both code copies are not going to change anyway.  At the end, just the
attached would do the work.

Rainer, could you double-check if this solves your problem with
Solaris 11?  If you expect this OS to be supported, it would be nice if
you could add a buildfarm machine:
https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto
https://buildfarm.postgresql.org/
There are currently two machines running Solaris 10, maintained by Dave
Page: protosciurus and castoroides.  But there is nothing for Solaris
11.

I am adding that to the next commit fest for consideration as well
under my name.  I'll take care of any reviews and/or feedback.  I'll add
as well your name as author if I can find your community account, I hope
you don't mind.
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: response time is very long in PG9.5.5 using psql or jdbc
Next
From: PG Bug reporting form
Date:
Subject: BUG #15064: Deadlock not detected on standby.