From nobody Thu Mar 23 08:13:29 2023 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Phylp3687z412j5 for ; Thu, 23 Mar 2023 08:13:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Phyln5YmJz3tcg for ; Thu, 23 Mar 2023 08:13:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="Z12AANk/"; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::52c) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ed1-x52c.google.com with SMTP id ek18so82995267edb.6 for ; Thu, 23 Mar 2023 01:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; t=1679559220; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=A9mB95AeNkhSXvzdyC5VGMKI0fp79nA9a7yBdmjgZOY=; b=Z12AANk/CSf7WYfQK3ZIyOG7XJZ49PiABFitxYMJkgjuZj1heI5TYHquVYl0cR8img AvuTqbrrD6ydfh5giOuJJLMdi8ao6anAbSAogDbThDtP/wvOFF47WSskdbTD8cXRR/L7 PAVALGa9605oL3mTrhx+IZlk1Wi5J25+rKFEhGpyTBZUKY/MtMWDTIGS9u8v5hbrNyvM q6qPxwUuPtlNz/oliT0O7enByjuVEOIS19IbXcL2eLDbhzSROa86rdOtiwEFk/ouTOGZ SWAAv7hmv6Uc+4E3UNruMVOvDJNpc08bK4qqEa7ybIKFqjRijOSM8zTpuo2i8gJLZ46G jwIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679559220; 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=A9mB95AeNkhSXvzdyC5VGMKI0fp79nA9a7yBdmjgZOY=; b=zZBfKwWIvAqn4peNw7iR+YONZZAPKunlpt8JQ9m5shn3qlYY+ZWfE4C5rGEqnAUOEI EpKgfyGAmE5VAfHAyXttVEbpfoTb0zfzpYToIb/wjQkp4EfNgYx4fz1x+JhChr+rJ0Zv zxRwa8NYSS364BfMCw0Jm1Dr1acwZrsQtCPv+c6JXU0hMRPoGlk3eYtg02PzeqJoqURD HzCTM/VWO63xksT/b3HqYMds7TodCUv4aKsD7WC+q89XldgcJypE7v2FmWbGvmadxdV6 rGjCf3QxWsup9vmQ8k823WCmdUbi0Lny9OlxTkNly4sKvTjU46q+KrPiD9S8cjiUlIv2 IwtA== X-Gm-Message-State: AO0yUKVZeYbYFXgRYbOIHNoeA7BTsaGSjZ35ID2/d3CsITfOV6C+U+Qh L2la/dewo11Pay0OJOqvWmOvdolyoGectGBiL6vGjiZW7BNH4K3wjRM= X-Google-Smtp-Source: AK7set+Vw9DV8glRDnwPEQc2saApqlW3HLPmXhZbBT1MpxVc8FXC40hCa0v+AR+2F3dpAZIY2ATkTWc5p09Xm8LYKw4= X-Received: by 2002:a17:907:a706:b0:930:310:abcf with SMTP id vw6-20020a170907a70600b009300310abcfmr5077908ejc.2.1679559220441; Thu, 23 Mar 2023 01:13:40 -0700 (PDT) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 References: <202303220226.32M2QLoe029463@gitrepo.freebsd.org> <010001870d7559c1-09ae94d7-ae1d-4a75-880e-e4f55b4b178e-000000@email.amazonses.com> In-Reply-To: <010001870d7559c1-09ae94d7-ae1d-4a75-880e-e4f55b4b178e-000000@email.amazonses.com> From: Warner Losh Date: Thu, 23 Mar 2023 02:13:29 -0600 Message-ID: Subject: Re: git: ed52baf51bd1 - main - _endian.h: Include sys/ctypes.h for visibility macros To: Colin Percival Cc: Warner Losh , src-committers , "" , dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b6c50e05f78cda61" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52c:from]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; PREVIOUSLY_DELIVERED(0.00)[dev-commits-src-all@freebsd.org]; RCPT_COUNT_FIVE(0.00)[5]; DMARC_NA(0.00)[bsdimp.com]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-Rspamd-Queue-Id: 4Phyln5YmJz3tcg X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --000000000000b6c50e05f78cda61 Content-Type: text/plain; charset="UTF-8" On Thu, Mar 23, 2023, 8:53 AM Colin Percival wrote: > > > On 3/21/23 19:26, Warner Losh wrote: > > [...] > > This had the side effect of sometimes (in the traditional BSD > > compliation environment) > > #if BYTE_ORDER == LITTLE_ENDIAN > > and > > #if BYTE_ORDER == BIG_ENDIAN > > both being true because none of these were defined. This fixes > > that. It also fixes including it after but not before. > > Would it be worth adding > > #if LITTLE_ENDIAN == BIG_ENDIAN > #error Endian defines are broken! > #endif > > just to ensure that any future issues show up quickly? > Not in *endian.h. The problem is that we fail to define them at all, then user programs expect to use them and sometimes they are defined, and other times they are not. Inside of endian.h the above can be true when we're not compiling for __BSD_VISIBLE because in C's reprocessor, undefined values are substituted with zero always... I'd planned on adding a test for it, though, to make sure that we catch this case in testing. But I was planning on that test being: #include int big_endian = BIG_ENDIAN; int little_endian = LITTLE_ENDIAN; int byte_order = BYTE_ORDER which will catch the undefined case since there's no 'substitute 0 for undefined' in an rval. Warner --000000000000b6c50e05f78cda61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 23, 2023, 8:53 AM Colin P= ercival <cperc= iva@tarsnap.com> wrote:


On 3/21/23 19:26, Warner Losh wrote:
>=C2=A0 =C2=A0 =C2=A0 [...]
>=C2=A0 =C2=A0 =C2=A0 This had the side effect of sometimes (in the trad= itional BSD
>=C2=A0 =C2=A0 =C2=A0 compliation environment)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0#if BYTE_ORDER =3D=3D LITTLE_ENDIAN
>=C2=A0 =C2=A0 =C2=A0 and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0#if BYTE_ORDER =3D=3D BIG_ENDIAN
>=C2=A0 =C2=A0 =C2=A0 both being true because none of these were defined= . This fixes
>=C2=A0 =C2=A0 =C2=A0 that. It also fixes including it after <stdio.h= > but not before.

Would it be worth adding

#if LITTLE_ENDIAN =3D=3D BIG_ENDIAN
#error Endian defines are broken!
#endif

just to ensure that any future issues show up quickly?


Not in *endian.h. The problem is that we fail to define them
at all, then user programs expect to use them and sometimes
th= ey are defined, and other times they are not. Inside of endian.h
= the above can be true when we're not compiling for __BSD_VISIBLE
<= div>because in C's reprocessor, undefined values are substituted with
zero always...

I'd planned on adding = a test for it, though, to make sure that we catch
this case i= n testing. But I was planning on that test being:

= #include <endian.h>
int big_endian =3D BIG_ENDIAN;
int little_endian =3D LITTLE_ENDIAN;
int byte_order =3D BYTE_OR= DER

which will catch the undefined case since ther= e's no 'substitute 0
for undefined' in an rval.
=

Warner
--000000000000b6c50e05f78cda61--