Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Mar 2013 23:07:35 +0100
From:      Dimitry Andric <dim@FreeBSD.org>
To:        Hajimu UMEMOTO <ume@freebsd.org>
Cc:        Beat Siegenthaler <beat.siegenthaler@beatsnet.com>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
Subject:   Re: troubles with buildworld/sendmail/sasl/clang
Message-ID:  <5693EC94-324A-42D4-A9AE-68AD1CCA4FC4@FreeBSD.org>
In-Reply-To: <ygeboagfshs.wl%ume@mahoroba.org>
References:  <5146F49B.5080609@beatsnet.com> <C9526976-4075-42C3-98FA-C5FA5E44D7A9@FreeBSD.org> <ygeboagfshs.wl%ume@mahoroba.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 18, 2013, at 19:54, Hajimu UMEMOTO <ume@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.
>=20
> 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. :-)=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5693EC94-324A-42D4-A9AE-68AD1CCA4FC4>