On Sat, 2021-06-26 at 09:47 +0900, Michael Paquier wrote:
> On Fri, Jun 25, 2021 at 11:40:33PM +0000, Jacob Champion wrote:
> > I can definitely move it (into, say, auth-sasl.c?). I'll probably do
> > that in a second commit, though, since keeping it in place during the
> > refactor makes the review easier IMO.
>
> auth-sasl.c is a name consistent with the existing practice.
>
> > Can do. Does libpq-int-sasl.h work as a filename? This should not be
> > exported to applications.
>
> I would still with the existing naming used by fe-gssapi-common.h, so
> that would be fe-auth-sasl.c and fe-auth-sasl.h, with the header
> remaining internal. Not strongly wedded to this name, of course, that
> just seems consistent.
Done in v3, with a second patch for the code motion.
I added a first pass at API documentation as well. This exposed some
additional front-end TODOs that I added inline, but they should
probably be dealt with independently of the refactor:
- Zero-length client responses are legal in the SASL framework;
currently we use zero as a sentinel for "don't send a response".
- I don't think it's legal for a client to refuse a challenge from the
server without aborting the exchange, so we should probably check to
make sure that client responses are non-NULL in the success case.
--Jacob