On Mar 18, 2013, at 19:54, Hajimu UMEMOTO <ume at freebsd.org> wrote:
...
> dim> In any case, if you are pulling port headers into your buildworld, the
> dim> effect is not always predictable, as ports are largely independent from
> dim> base. So if you need a customized build of sendmail, would it not be
> dim> better to use the mail/sendmail port instead? There you can easily
> dim> enable all bells and whistles that are not enabled by default in base.
>
> No, it seems to me that this error is not depending on sasl header. I
> suspect clang still has some problem in handling __P.
It is not because of the __P macro specifically, but because of the way
the function parameters are promoted for K&R functions. The
getsasldata() function is first declared as:
static void getsasldata __P((char *, bool, MAILER *, MCI *, ENVELOPE *));
Directly after that, it is defined as a K&R function:
static void
getsasldata(line, firstline, m, mci, e)
char *line;
bool firstline;
MAILER *m;
register MCI *mci;
ENVELOPE *e;
{
...
About 1000 lines below that definition, the address of getsasldata gets
passed to reply(), which is declared as:
extern int reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int));
so it accepts a function pointer parameter which matches the initial
prototype of getsasldata(), but *not* the actual definition!
Now, clang normally warns about the 'firstline' parameter being promoted
from bool to int, as is required for K&R functions:
contrib/sendmail/src/usersmtp.c:618:7: warning: promoted type 'int' of K&R function parameter is not compatible with the parameter type 'bool' declared in a previous prototype [-Wknr-promoted-parameter]
bool firstline;
^
contrib/sendmail/src/usersmtp.c:612:42: note: previous declaration is here
static void getsasldata __P((char *, bool, MAILER *, MCI *, ENVELOPE *));
^
but since we suppress that warning using -Wno-knr-promoted-parameter, we
do not see it during build world. However, this still means the
function type is to be considered incompatible.
This changes only when the definition of getsasldata() is moved further
down in the file, specifically below all the places where it is passed
as a function pointer to reply(). In that case, the compiler does not
know yet the function is defined as K&R, and considers it to be
compatible.
One way to avoid this whole mess would be to stop pretending sendmail is
C99 code, and define the 'bool' type as an int. That would solve all
the K&R promotion problems in one fell swoop. And it requires just a
minor hack in contrib/sendmail/include/sm/gen.h.
Or, alternatively, fix all the function definitions to be actual C99
function definitions, but that would be a lot more work. :-)