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,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 9354C23D5D for ; Wed, 24 Apr 2024 11:49:52 +0200 (CEST) Received: (qmail 22016 invoked by uid 550); 24 Apr 2024 09:49:49 -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 21977 invoked from network); 24 Apr 2024 09:49:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713952179; x=1714556979; darn=lists.openwall.com; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=YOXzjaOQwyVr028E7amfhwLH3pfZ11dJ7bZ6JbI1vUQ=; b=LxKkDnwvITcQDPuVKc8Cr2dvpg5gmPcRRYiQUv1Dh2Lk6fgMH9YgvwzN//cEOm/YvH oCWGm4UPlcThwssjaNdbz5rtuZZqGYO1/JvIPCjXXZMUMWomM8PCCSyKWHLOMaztlfgT qspaU3hVqJO39o3hP4SgLamD2m1PUivqoVwx56HoiXIhQggIyDxcEUm7AaHtDSf5UEPZ mSJE0AlGYqNk4xnrQenSlhnzgql3HeQ3R18fQFqtnk9DNDq9FJlHZ0Z9DRFXqenEvsgK II8JTLsMeRCjfbxu5wGttJz3QuZwYGGX4NFufNnRpCHsCVb6L4mZ2Mlj9Be2fwYCMWnU o2Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713952179; x=1714556979; h=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=YOXzjaOQwyVr028E7amfhwLH3pfZ11dJ7bZ6JbI1vUQ=; b=jqbkryeed8KtuQW0oJXWdxTt9ToArWyZTERxbprgaxfcF01NmgaM9v/qbd70Nlyn9i o+QcW/kC7xcaWtV/Yv0GHpBsFTjBeCAKn3rGQUwUHL/G/0zy0QTDL11UWBZww8tvveJm MKpeFQBIMeTsh4sPr7l8/6FWbv7fHnUbPABDMFmWd/vhM0QjflJ/nLb3j3K57Jh1xxVS O+sgskFE1U7d2XsIxrilAl/lfXWo2DrhvBOKb3DvjZ2KVPgzkdvW+Ce0L0o4oC6LFXOt csDPpa45kT4D9QXZqNxB/oRwuhk/sfgpcukcfJgzWmkyM8jE+ZuG/Me/7fzDFPkckLpE adOg== X-Gm-Message-State: AOJu0Yx/8JJ/f+Y+q8/v6x2+V+bXcdipi42U5W+LeBidYkmRrFUtZe2E JYXBzxiZ5NMAbeFLyCDP/L5tAQz4bAmeTepWj/L55T0eab1uk4HZOeX1E8U1TQ2TEwZ4BIHHp82 X17NYWtKkGsBVn62epI2EVmb9s7jBDg== X-Google-Smtp-Source: AGHT+IFI4e0peqf1JJcjhcc+sUBMUrHwSCxbcncY3P8PFPyHK/Cr2viqgHYj41/U7sAD+7KoBg2NnDGAcLdgYdRpSeQ= X-Received: by 2002:a25:2c5:0:b0:dcc:787:e8f9 with SMTP id 188-20020a2502c5000000b00dcc0787e8f9mr1764914ybc.51.1713952178844; Wed, 24 Apr 2024 02:49:38 -0700 (PDT) MIME-Version: 1.0 References: <3KDMGHI91MHTL.24XCHF6E4X1XG@mforney.org> <20240421234809.GK4163@brightrain.aerifal.cx> <1Z2XU7Z5OB2AV.26EJYFLGNXL0W@mforney.org> In-Reply-To: From: Jon Chesterfield Date: Wed, 24 Apr 2024 10:49:27 +0100 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000c83f9c0616d4966b" Subject: Re: [musl] Alignment attribute in headers --000000000000c83f9c0616d4966b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Use in practice and use in documentation don't always align but it seems you're agreeing that requiring GNU macros to use a Linux specific header is invalid. Jon On Wed, 24 Apr 2024, 08:55 Jeffrey Walton, wrote: > > > On Wed, Apr 24, 2024 at 3:40=E2=80=AFAM Jon Chesterfield < > jonathanchesterfield@gmail.com> wrote: > >> Re testing GNUC, >> >> I'm not sure the macro means "targeting Linux", and it seems totally >> legitimate that a C compiler which doesn't implement any GNU extensions >> would not define that macro. Musl is quite a likely choice for a non-gnu >> compiler that wants to compile code to run against the Linux kernel. >> > > __GNUC__, __GNUC_MINOR__ and __GNUC_PATCHLEVEL__ only means the macros ar= e > defined by GNU compilers that use the C preprocessor. See < > https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html>. > > The macros don't mean "targeting Linux". They are also defined on OS X > (Darwin) and Windows. > > Jeff > --000000000000c83f9c0616d4966b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Use in practice and use in documentation don't a= lways align but it seems you're agreeing that requiring GNU macros to u= se a Linux specific header is invalid.

Jon

On Wed, 24 Apr 2024, 08:55 Jeffrey Walton, &l= t;noloader@gmail.com> wrote:

On Wed, Apr 24, 2024 at 3:40=E2=80=AFAM Jon Chesterfield <= jonathanchesterfield@gmail.com> wrote:
Re testing GNUC,

I'm not sure the macro means "t= argeting Linux", and it seems totally legitimate that a C compiler whi= ch doesn't implement any GNU extensions would not define that macro. Mu= sl is quite a likely choice for a non-gnu compiler that wants to compile co= de to run against the Linux kernel.

__GNUC__,=C2=A0__GNUC_MINOR__ and __GNUC_PATCHLEVEL__ only means t= he macros are defined by GNU compilers that use the C preprocessor. See <= ;https://gcc.gnu.org/onlinedocs/cpp/= Common-Predefined-Macros.html>.

The macros = don't mean "targeting Linux". They are also defined on OS X (= Darwin) and Windows.

Jeff
--000000000000c83f9c0616d4966b--