Re: Improve error handling of HMAC computations and SCRAM

From: Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Improve error handling of HMAC computations and SCRAM
Date: 2022-01-11 07:50:50
Message-ID: 066c0624-fbb7-a025-afd6-d54683a96947@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 11.01.2022 07:56, Michael Paquier wrote:
> Thoughts?

A few comments after a quick glance...

+ * Returns a static string providing errors about an error that happened

"errors about an error" looks odd.

+static const char *
+SSLerrmessage(unsigned long ecode)
+{
+ if (ecode == 0)
+ return NULL;
+
+ /*
+ * This may return NULL, but we would fall back to a default error path if
+ * that were the case.
+ */
+ return ERR_reason_error_string(ecode);
+}

We already have SSLerrmessage elsewhere and it's documented to never
return NULL. I find that confusing.

If I have two distinct pg_hmac_ctx's, are their errreason's idependent
from one another or do they really point to the same static buffer?

Regards,

--
Sergey Shinderuk https://postgrespro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-01-11 07:51:19 Re: Windows crash / abort handling
Previous Message Michael Paquier 2022-01-11 07:50:23 Re: pg_dump/restore --no-tableam