From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 732502174A for ; Mon, 1 Apr 2024 17:40:11 +0200 (CEST) Received: (qmail 20009 invoked by uid 550); 1 Apr 2024 15:40:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 19955 invoked from network); 1 Apr 2024 15:40:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1711985998; x=1712590798; darn=lists.openwall.com; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QbFG9YXLEeNvN+W9ZU0QfIbIK9StzDdtleNyFEKFXJo=; b=OJfbrXigsL8VvwJAjrv0afQodTvdi+BgFlJuYqrL+SCnH+iNkxaLhWhU2/rlY9EGLv LDOzCbkd4dvgpruCPmRypTTrq6OR9YmfuwALGBa8OJ523HBVb9/gAOT05uve79KGbxCF UA3GnQGXtGZZaipf6vGryZEV44HzFlEy29KWWCwFmY3fxAbsPSL/buDlPLhnRto/aU7g cWBeYtBIX1rdYZR1hMp106IpY0SKaq5si2GNm/0zw7EDBp1OnLMeOCEfBByRM1F7AjvJ P5wZrX3ERDZAiwrMIWqaAn818A9hp8oKT2MktA9KohqMljlkcuRtVBEDRpZ+EgduaCSQ JFHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711985998; x=1712590798; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QbFG9YXLEeNvN+W9ZU0QfIbIK9StzDdtleNyFEKFXJo=; b=lHdxxH9QCbKXl9ieiGTubEMNk6pdegTOoHpsIohV9cxwJU8wVxYtmxTIUChN8mfvRR 8Yc9EwyaTf0B8qpEHZctVLxX7iXDjwKn9gl4IxcCYELB6OE+h6Jbd8pL8mHLQQxvoTpH NNieIW0JHHxuDFaptsYUuexjuYHcAOJopip84V4BCRxqAY4Us5cOLmeRBFBw0tbOv0Tb nmaCLnwz39j4Qf+U6NSwU3wQ0c/bOr/ks2Dd4Fu6mAHRxmlVQHeKzfHs/+MGgnRI+hhO v030UEi+Kt+w44dMjU9pN9RmVRwQCPPux5xjJvzwtD02+yi4SIumpA81CKrh8dVrhAdq ugmQ== X-Gm-Message-State: AOJu0YyY5o4Vl+ElQp73mP6UjpwG0QmrjH7BpOrF0+gJNUHb3ii9ecLb i0sgKMBKXv4bK9jTuY14WkSEazwoP+gKC2uPt4PiZlDFx04nOja8n0jJ8LS02YAe6hHV2KcLEUs DAPbGiGNTWmaa30dwV+Phqul3/JdKs4I9nUroHHIBiE6DvXgGMKCQ X-Google-Smtp-Source: AGHT+IFzToax0Y/4QWEXJU5XE4VnmKvxFe5cr17P/tmvwJC+vxFtf/LzW00mffyiXopuZISxNGI0CNaMTP2rIaLf3aM= X-Received: by 2002:a05:622a:4b11:b0:432:bfff:91d1 with SMTP id et17-20020a05622a4b1100b00432bfff91d1mr636119qtb.4.1711985997598; Mon, 01 Apr 2024 08:39:57 -0700 (PDT) MIME-Version: 1.0 References: <20240329165047.6bc7a7c9@atlas-11> <20240330020614.GN4163@brightrain.aerifal.cx> In-Reply-To: <20240330020614.GN4163@brightrain.aerifal.cx> From: James Y Knight Date: Mon, 1 Apr 2024 11:39:29 -0400 Message-ID: To: musl@lists.openwall.com Cc: Denis Ovsienko Content-Type: multipart/alternative; boundary="0000000000003fbe4906150acd87" Subject: Re: [musl] musl CMSG_NXTHDR() triggers a -Wsign-compare from Clang --0000000000003fbe4906150acd87 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 29, 2024 at 10:08=E2=80=AFPM Rich Felker wrot= e: > It's not clear to me why clang > (ang gcc?) fail to suppress this as coming from -isystem. Clearly they > now where the macro was expanded from; it's even in the above message. > > Clang and GCC suppress diagnostics in system headers, but as a general rule, do not suppress diagnostics arising from expanding macros which were defined in system headers. There are special cases for some diagnostics, but this is not one of them in Clang. As an example with a different diagnostic, the following triggers -Wincompatible-pointer-types for the definition of "z", but not "y", in both GCC and Clang: // System header "test.h" int yy; float *y =3D &yy; #define FOO float *z =3D &yy; // User file "test.c" #include FOO If there's no path forward on getting compilers not to do this, maybe > we should look into working around the warning this one time? :/ Inserting an explicit cast in the musl macro would seem appropriate here. --0000000000003fbe4906150acd87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Mar 29, 2024= at 10:08=E2=80=AFPM Rich Felker <dal= ias@libc.org> wrote:
It's not clear to me why clang
(ang gcc?) fail to suppre= ss this as coming from -isystem. Clearly they
now where the macro was ex= panded from; it's even in the above message.

= =C2=A0
Clang and GCC suppress diagnostics in system h= eaders, but as a general rule, do not suppress diagnostics arising from exp= anding macros which were defined in system headers. There are special cases= for some diagnostics, but this is not one of them in Clang.

As an example with a different diagnostic, the= following triggers -Wincompatible-pointer-types for the definition of &quo= t;z", but not "y", in both GCC and Clang:

// System header "test.h"
int yy;
float *y =3D &= yy;
#define FOO float *z =3D &yy;

// U= ser file "test.c"
#include <test.h>
FOO=

If there's no path forward on getting compilers not to do this, = maybe
we should look into working around the warning this one time? :/= =C2=A0
=C2=A0
=C2=A0Inserting an explicit = cast in the musl macro would seem appropriate here.
--0000000000003fbe4906150acd87--