From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10624 Path: news.gmane.org!.POSTED!not-for-mail From: Jan Vorlicek Newsgroups: gmane.linux.lib.musl.general Subject: RE: Using macro CMSG_NXTHDR generates warnings with CLANG Date: Tue, 11 Oct 2016 15:38:38 +0000 Message-ID: References: <20161011150901.GG19318@brightrain.aerifal.cx> <20161011153100.GM28065@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1476200353 31556 195.159.176.226 (11 Oct 2016 15:39:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Oct 2016 15:39:13 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-10637-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 11 17:39:09 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1btz8m-0005X6-UO for gllmg-musl@m.gmane.org; Tue, 11 Oct 2016 17:38:53 +0200 Original-Received: (qmail 32024 invoked by uid 550); 11 Oct 2016 15:38:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 31999 invoked from network); 11 Oct 2016 15:38:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iqVKUXr8J4zkTPxt9lbEJk4eLOnVSpxc1zM5g6ybzGc=; b=nwn81zdLrG4M/w/+s9Yy6P+8e8zuRxA2+nBnsJo42yUAllFxjOP1+xtzi0B3LvWLa8yKIqPuqmhg44IX8KLdOnMWw2OaaGpA/VqIoqRGjD2nBCPvhd9Y1ASOE/FkitsWoScLHHxoHw7h5NfK4gcwPdfxVdQOs9dXD/Nugdn+0hk= Thread-Topic: [musl] Using macro CMSG_NXTHDR generates warnings with CLANG Thread-Index: AdIjQRMXenHgQGEXSke2PXInrhIJgAAkFKyAAADEsoAAADBJIA== In-Reply-To: <20161011153100.GM28065@port70.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=janvorli@microsoft.com; x-originating-ip: [89.177.13.111] x-ms-office365-filtering-correlation-id: ba244ec9-fdf3-4954-687b-08d3f1ecac12 x-microsoft-exchange-diagnostics: 1;HE1PR83MB0060;7:TFF+YKdjiYvcFzpDdqDqs+EZW3jRAotFXY7BiXD2rrDQmec5CR4vcjGk454zNRK+Eq2nnqglLk2DC6AKnL7QGjdFePT04OGC5LxLcNPKmxNSJzxJ4ay6NiDS93dkb7fGKs15S6bh83Fd8liY3DEhaxzJjnyiD6ypTLgWRUHcvlC7pdajwy2ZjKx9ZqUHeyb7TDljgj3dHcGqJ6blJY6TYUlQAj3WGqm1S3vKghFFXf0XCNt0QfOZp3Ulb6kk6pSOTXCc4M2tZijkDfi6NUQANnJ0UAYRd54eFbEslrSntsmerP9EiiKN5uKKpoc1oqyPyxLJdpTIvqzSAObiISXsnd7BvcQzvJLAqB75jDr9eSlms8sLJy0rh6xgnjm//SRw x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR83MB0060; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038);SRVR:HE1PR83MB0060;BCL:0;PCL:0;RULEID:;SRVR:HE1PR83MB0060; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(199003)(51884002)(377424004)(24454002)(504964003)(189002)(377454003)(13464003)(10090500001)(189998001)(2950100002)(33656002)(3846002)(10400500002)(102836003)(81166006)(5660300001)(6116002)(122556002)(9686002)(8990500004)(2501003)(81156014)(6916009)(107886002)(10290500002)(5005710100001)(66066001)(7696004)(76176999)(1730700003)(76576001)(54356999)(68736007)(92566002)(50986999)(5002640100001)(586003)(3660700001)(8676002)(7736002)(19580395003)(11100500001)(19580405001)(3280700002)(2351001)(101416001)(2906002)(4001150100001)(87936001)(110136003)(97736004)(2900100001)(450100001)(105586002)(305945005)(86362001)(106356001)(74316002)(86612001)(8936002)(7846002);DIR:OUT;SFP:1102;SCL:1;SRVR:HE1PR83MB0060;H:HE1PR83MB0058.EURPRD83. prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2016 15:38:38.5060 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR83MB0060 Xref: news.gmane.org gmane.linux.lib.musl.general:10624 Archived-At: My test was a c++ code :-). That's why the struct was not there. Thanks, Jan -----Original Message----- From: Szabolcs Nagy [mailto:nsz@port70.net]=20 Sent: Tuesday, October 11, 2016 5:31 PM To: musl@lists.openwall.com Subject: Re: [musl] Using macro CMSG_NXTHDR generates warnings with CLANG * Rich Felker [2016-10-11 11:09:01 -0400]: > On Mon, Oct 10, 2016 at 10:09:38PM +0000, Jan Vorlicek wrote: > > The testing source is below: > >=20 > > #include > > cmsghdr* GET_CMSG_NXTHDR(msghdr* mhdr, cmsghdr* cmsg); > >=20 this is invalid c code (you cannot leave 'struct' off). > > cmsghdr* GET_CMSG_NXTHDR(msghdr* mhdr, cmsghdr* cmsg) { > > return CMSG_NXTHDR(mhdr, cmsg); > > } > >=20 > > Would it be possible to fix it so that no warnings are generated? We=20 > > are building our application with -Weverything and currently we need=20 > > to disable these two warnings around the CMSG_NXTHDR macro=20 > > invocation. > > Thank you in advance for considering that! >=20 > As these are system headers, the compiler should not be producing any=20 > warnings from them. If it does that's a compiler bug. Are you perhaps=20 > using an odd setup where musl's headers aren't in the default system=20 > include path but instead passed in via -I rather than -isystem? If you=20 > have a minimal test file I could see if the same warnings appear with=20 > clang on Alpine Linux. >=20 fwiw i see the warnings with clang -c -Wcast-align test.c i assume they cannot easily tell if they should warn when a macro defined i= n a system header expanded with user arguments. i think this warning is problematic: it warns about casting char*, but not = about casting void* which has the exact same issue. so if you have apis that uses char* instead of void* for generic pointers (= e.g. for abi compat reasons), then you get loads of false positives (which = is what happens here). it can be worked around by adding a void* cast (but in my opinion that make= s things worse: users will add more casts to get rid of the warning which h= as the opposite effect than what you would want).