From owner-svn-src-all@FreeBSD.ORG Tue Apr 16 11:50:52 2013 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CDECD906; Tue, 16 Apr 2013 11:50:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 76465608; Tue, 16 Apr 2013 11:50:52 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id 98662D41AC8; Tue, 16 Apr 2013 21:28:38 +1000 (EST) Date: Tue, 16 Apr 2013 21:28:36 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Dimitry Andric Subject: Re: svn commit: r246880 - in head: lib/libsm libexec/mail.local libexec/smrsh share/mk usr.bin/vacation usr.sbin/sendmail In-Reply-To: <516D13C5.70900@FreeBSD.org> Message-ID: <20130416205349.W1783@besplex.bde.org> References: <201302162017.r1GKHVdY022667@svn.freebsd.org> <87a9ozayzk.fsf@saturn.laptop> <516D13C5.70900@FreeBSD.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2082392551-1366111716=:1783" X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=HfxM1V48 c=1 sm=1 a=rG3yl5gHAqsA:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=mZmTMruuRn4A:10 a=6I5d2MoRAAAA:8 a=jqniBCV5i6nGcZ7JSMQA:9 a=45ClL6m2LaAA:10 a=7IFj921gttwA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: =?UTF-8?B?zpPOuc+Oz4HOs86/z4IgzprOtc+BzrHOvM6vzrTOsc+C?= , svn-src-head@FreeBSD.org, Gregory Shapiro , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 11:50:53 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2082392551-1366111716=:1783 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 16 Apr 2013, Dimitry Andric wrote: > On 2013-04-16 06:19, =CE=93=CE=B9=CF=8E=CF=81=CE=B3=CE=BF=CF=82 =CE=9A=CE= =B5=CF=81=CE=B1=CE=BC=CE=AF=CE=B4=CE=B1=CF=82 wrote: >> ... >> The warnings that usersmtp.c still triggers when -DSASL is used are: >>=20 >> : cc -O2 -pipe -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src= =20 >> -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. -DNEWDB= =20 >> -DNIS -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 -DSTARTTLS -D_FFR_TL= S_1=20 >> -I/usr/local/include -DSASL=3D20126 -std=3Dgnu99 -Qunused-arguments=20 >> -fstack-protector -Wsystem-headers -Wno-pointer-sign -Wno-empty-body=20 >> -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value=20 >> -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-swit= ch=20 >> -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c=20 >> /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c >> : /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1797:= 50:=20 >> warning: incompatible pointer types passing 'void ()' to parameter of ty= pe=20 >> 'void (*)(char *, bool, MAILER *, struct >> : mailer_con_info *, ENVELOPE *)' [-Wincompatible-pointer-types] >> : smtpresult =3D reply(m, mci, e, TimeOuts.to_auth, getsasldata,= =20 >> NULL, >> : ^~~~~~~~~~~ > > Have you tried the patch I posted here? > > http://lists.freebsd.org/pipermail/freebsd-current/2013-March/040634.html > > If people feel this is the right approach, I am happy to commit it. If > people prefer to just shut up warnings, I am happy with that too. stdbool is certainly incompatible with simple use of __P(()), but why does the error message say that the function type is 'void ()', and why doesn't it say that the prototype doesn't match the function? The function is declared as: @ static void getsasldata __P((char *, bool, MAILER *, MCI *, ENVELOPE *)); This says that the function type is the same as the parameter type. @ static void @ getsasldata(line, firstline, m, mci, e) @ =09char *line; @ =09bool firstline; @ =09MAILER *m; @ =09register MCI *mci; @ =09ENVELOPE *e; @ { This says that the function type is different from what the function's prototype is, at least if the bool is smaller than int or otherwise magic, which it is on at least amd64. clang prints a good error message in the following simplified example: @ #include @=20 @ void foo(bool first); @=20 @ void @ foo(first) @ =09bool first; @ { @ } @ z.c:7:7: warning: promoted type 'int' of K&R function parameter is not co= mpatible with the parameter type 'bool' declared in a previous prototype [-= Wknr-promoted-parameter] @ bool first; @ ^ @ z.c:3:15: note: previous declaration is here @ void foo(bool first); @ ^ @ 1 warning generated. This happens with plain cc -c. gcc of course turns the undefined behaviour from this into a portability problem by accepting the bad code. It takes gcc -pedantic to get a warning= =2E The correct prototype on amd64 is 'void foo(int first);'. This is MD. Unfortunately, the correct way to declare this is unsupported AFAIK. It is 'void foo(__promoteof(bool) first);'. __P(()) is really hard to use, since to use it you first have to modify compilers to support __promoteof(), then use it on the type of all integer args whose type is not int or larger, or do this using MD ifdefs. Extending the example a little gives the answer to my question: @ #include @=20 @ typedef void vb(bool first); @=20 @ vb foo; @ void bar(vb *p); @=20 @ void @ foo(first) @ =09bool first; @ { @ =09bar(foo); @ } @ z.c:10:7: warning: promoted type 'int' of K&R function parameter is not c= ompatible with the parameter type 'bool' declared in a previous prototype [= -Wknr-promoted-parameter] @ bool first; @ ^ @ z.c:5:4: note: previous declaration is here @ vb foo; @ ^ @ z.c:12:6: warning: incompatible pointer types passing 'void ()' to parame= ter of type 'vb *' (aka 'void (*)(bool)') [-Wincompatible-pointer-types] @ bar(foo); @ ^~~ @ z.c:6:14: note: passing argument to parameter 'p' here @ void bar(vb *p); @ ^ @ 2 warnings generated. Apparently clang ignores the mismatched prototype after printing a warning about it, and also throws away the type info that it learns by compiling the K&R function, so it is left with only 'void ()' for the type. Then the warnings for some reason emphasize the secondary warnings from this. The first warning should be an error. It is only a warning for gcc -pedant= ic too. Bruce --0-2082392551-1366111716=:1783--