Michael Paquier <michael@paquier.xyz> writes:
> On Thu, Jan 06, 2022 at 11:40:04AM -0500, Tom Lane wrote:
>> Also, I wonder if this shouldn't be unified with the SSLerrmessage()
>> support found in be-secure-openssl.c and fe-secure-openssl.c.
> Guess so. HEAD could be poked at for this part. I recall looking at
> that once by that did not seem worth the complications.
Yeah, I suppose there's only a couple lines of code to be saved,
and the complexity of dealing with multiple memory allocation
conventions would outweigh that.
> What do you think?
Hm, you still have cast-away-const in md5_crypt_verify and
plain_crypt_verify. Can we adjust their APIs to make them
return const char * as well (and then their API spec is that
the caller must never free the string, rather than being
vague about it)?
The other thing that bothers me slightly is that it looks like
some code paths could end up passing a NULL string pointer to
ereport or sprintf, since you don't positively guarantee that
an error will return a string there. I suppose this is safe
since 3779ac62d, but I don't really want to start making API
specs depend on it.
regards, tom lane