From owner-freebsd-hackers@freebsd.org Sun Jan 10 13:25:27 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 725A34CC3B0; Sun, 10 Jan 2021 13:25:27 +0000 (UTC) (envelope-from thj@freebsd.org) Received: from wforward4-smtp.messagingengine.com (wforward4-smtp.messagingengine.com [64.147.123.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DDHdg0MC6z4dM0; Sun, 10 Jan 2021 13:25:26 +0000 (UTC) (envelope-from thj@freebsd.org) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailforward.west.internal (Postfix) with ESMTP id E944D275A; Sun, 10 Jan 2021 08:25:21 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Sun, 10 Jan 2021 08:25:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=jMhseTttd5MeuRr6+xt+KnRmXRGcr nTR+6VgjUow0ew=; b=lnpHaXx+aBrjm9fXFnK4sP5blRk3mQ4BMgHByxCIxP7Vl D2rjq9ehpxAOp3A1L+O1Ob5yzHFj5uCU4B/Hgm/ffb6Zc5fSq77879BW1Z6G7gjZ 3QBfHCox6XcJBC4lzEwhcdjtBHROhmqkJOXs8TmaWbB+kZTXu//E6NekTkBfx/mS EROrQAbtNw5bsiichOHDNDUJFlQvMFJiUzB+39ctDE0muVQoWSgD2Gws1qHMH9Ke LomXcMoWnyzzo6n6vi8BzhQ8Iw8kwx34bwwqWXzmQouiV+VxtijUBwX/aIELOvPK 6Nyggtn2ZwCfyeCUrhJ/QQPcpxRYvxDuRO5JnXJEQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegledgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttd dtvdenucfhrhhomhepvfhomhculfhonhgvshcuoehthhhjsehfrhgvvggsshgurdhorhhg qeenucggtffrrghtthgvrhhnpeffgeduheffudelkefhiefhffefhfdtvdehvefhueegve eghfehgfdttddtudekleenucffohhmrghinhepfhhrvggvsghsugdrohhrghdprgguvhgv nhhtuhhrihhsthdrmhgvnecukfhppedufeejrdehtddrudejrdduvdenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhjsehfrhgvvggsshgu rdhorhhg X-ME-Proxy: Received: from tom-desk.erg.abdn.ac.uk (tom-desk.erg.abdn.ac.uk [137.50.17.12]) by mail.messagingengine.com (Postfix) with ESMTPA id BB18524005C; Sun, 10 Jan 2021 08:25:20 -0500 (EST) Date: Sun, 10 Jan 2021 13:25:19 +0000 From: Tom Jones To: freebsd-hackers@freebsd.org Cc: freebsd-advocacy@freebsd.org Subject: FreeBSD Bugathon January 16th 2000UTC Message-ID: <20210110132452.GA37700@tom-desk.erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4DDHdg0MC6z4dM0 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2021 13:25:27 -0000 Hello Hackers, On the 16th January 2021 from 2000 UTC for about 4 hours we will be running a coordinated virtual Bugathon. FreeBSD has a Problem Report (PR) database[1] where users and developers are encouraged to file issues and regressions they find in both the base system and ports tree. A Bugathon is a focused session where we try to triage, process, fix and close as many reports as we can from the PR database. We held two successful Bugathons in 2020 and we hope to continue this pattern into 2021. This Bugathon we are going to try and focus on issues related to the branching of 13 on the 22nd of January. Previously we used google meet through out the day to have a live voice channel and it proved to be a really helpful resource to get immediate answers to questions. This Bugathon we are going to do live coordination using the FreeBSD Discord server[2] to coordinate work, triage and discuss PRs and patches. If Discord is too scary there will also be people in the #freebsd-bugs irc channel freenode. I look forward to joining you to squash bugs and commit fixes to improve FreeBSD. - Tom [1]: https://bugs.freebsd.org [2]: https://wiki.freebsd.org/Discord Some other links: https://wiki.freebsd.org/OfficeHours https://wiki.freebsd.org/MarkLinimon/BugbustingOfficeHours https://wiki.freebsd.org/Bugathons https://wiki.freebsd.org/MarkLinimon/KitchenerNotes https://wiki.freebsd.org/BugBusting https://adventurist.me/posts/00301 From owner-freebsd-hackers@freebsd.org Mon Jan 11 10:01:42 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7FC444D2D6D for ; Mon, 11 Jan 2021 10:01:42 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DDq452jRJz3F5w for ; Mon, 11 Jan 2021 10:01:41 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 10BA1Vlg085455 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 11 Jan 2021 11:01:32 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1610359292; bh=wIGkH0UW4teDe+XP7xC9m0ydFTht/qIK1rK0zy5SVTg=; h=Date:From:To:Subject; b=UYdKdD3pm5Nf5YT2AtJS685+2ZaQuJojbORxeCGdLlBZdc+KayB19mh+DaRxTEdc9 bueHGnvxrTjGRG78CaN6rFz6uuiEHPbgkZf4xVJbHzspcVrpt6SWu8TDYHtY5QuEVx /2e7M2s+2CliAdhQDG6Zm6EDeF83nGJH/y9stmCo= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 10BA1V8M043355 for ; Mon, 11 Jan 2021 11:01:31 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 10BA1VPs043352 for ; Mon, 11 Jan 2021 11:01:31 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Mon, 11 Jan 2021 11:01:31 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: RTL8188EU Wifi adapter - what i am missing Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4DDq452jRJz3F5w X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=UYdKdD3p; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[194.1.144.90:from]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[194.1.144.90:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[puchar.net:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[puchar.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2021 10:01:42 -0000 FreeBSD 12.2-STABLE in kernel config: device wlan # 802.11 support options IEEE80211_DEBUG # enable debug msgs options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's options IEEE80211_SUPPORT_MESH # enable 802.11s draft support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device uether device rtwn device rtwn_usb device rtwnfw device firmware in dmesg: rtwn0: on usbus4 rtwn0: MAC/BB RTL8188EU, RF 6052 1T1R ifconfig wlan0 create wlandev rtwn0 then wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf results in: Successfully initialized wpa_supplicant ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Invalid argument ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Invalid argument wlan0: Trying to associate with 00:21:29:8a:26:af (SSID='linksysd' freq=2432 MHz) Failed to add supported operating classes IE wlan0: Authentication with 00:21:29:8a:26:af timed out. wlan0: CTRL-EVENT-DISCONNECTED bssid=00:21:29:8a:26:af reason=3 locally_generated=1 wlan0: Trying to associate with 00:21:29:8a:26:af (SSID='linksysd' freq=2432 MHz) Failed to add supported operating classes IE wlan0: Authentication with 00:21:29:8a:26:af timed out. wlan0: CTRL-EVENT-DISCONNECTED bssid=00:21:29:8a:26:af reason=3 locally_generated=1 wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="linksysd" auth_failures=1 duration=10 reason=CONN_FAILED wlan0: CTRL-EVENT-SSID-REENABLED id=0 ssid="linksysd" wlan0: Trying to associate with 00:21:29:8a:26:af (SSID='linksysd' freq=2432 MHz) Failed to add supported operating classes IE wlan0: CTRL-EVENT-DISCONNECTED bssid=00:21:29:8a:26:af reason=3 locally_generated=1 wlan0: CTRL-EVENT-TERMINATING wpa_supplicant.conf contains: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel eapol_version=1 ap_scan=1 fast_reauth=1 network={ scan_ssid=1 ssid="linksysd" psk="passwordhere" } thank you for help From owner-freebsd-hackers@freebsd.org Thu Jan 14 11:25:34 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 465174DDF68 for ; Thu, 14 Jan 2021 11:25:34 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DGhnV0lnyz3hkb for ; Thu, 14 Jan 2021 11:25:34 +0000 (UTC) (envelope-from thierry@pompo.net) Received: by mailman.nyi.freebsd.org (Postfix) id 19E464DE31F; Thu, 14 Jan 2021 11:25:34 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 19AB34DE057 for ; Thu, 14 Jan 2021 11:25:34 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from edna.lautre.net (edna.lautre.net [80.67.160.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "lautre.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DGhnT1LJjz3htb for ; Thu, 14 Jan 2021 11:25:32 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from graf.pompo.net (graf.pompo.net [78.225.128.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by edna.lautre.net (Postfix) with ESMTPSA id 08A8B11C55E for ; Thu, 14 Jan 2021 12:25:24 +0100 (CET) Received: by graf.pompo.net (Postfix, from userid 1001) id EE8C8A2CCD7; Thu, 14 Jan 2021 12:25:23 +0100 (CET) Date: Thu, 14 Jan 2021 12:25:23 +0100 From: Thierry Thomas To: FreeBSD Hackerz Subject: Some fun with -O2 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 12.2-STABLE amd64 Organization: Kabbale Eros X-Face: (hRbQnK~Pt7$ct`!fupO(`y_WL4^-Iwn4@ly-.,[4xC4xc; y=\ipKMNm<1J>lv@PP~7Z<.tKjAnXLs: X-PGP: 0xF1C516B3C8359753 X-Rspamd-Queue-Id: 4DGhnT1LJjz3htb X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of thierry@pompo.net designates 80.67.160.88 as permitted sender) smtp.mailfrom=thierry@pompo.net X-Spamd-Result: default: False [-0.67 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.67)[-0.673]; FORGED_SENDER(0.30)[thierry@freebsd.org,thierry@pompo.net]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[80.67.160.88:from]; ASN(0.00)[asn:20766, ipnet:80.67.160.0/19, country:FR]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[thierry@freebsd.org,thierry@pompo.net]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[thierry]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[80.67.160.88:from:127.0.2.255]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 11:25:34 -0000 Let´s check a small C program, check_mktime.c, fetchable from . $CC -o check_mktime -O2 check_mktime.c ./check_mktime It is OK with clang90. It loops forever with gcc9, gcc10, clang10 and clang11, but OK without -O2. It is part of the configure script of ports/math/oleo, and I guess that the same part could be found in other configure scripts. Note a similar program is part of glibc: see . Regards. -- Th. Thomas. From owner-freebsd-hackers@freebsd.org Thu Jan 14 11:44:48 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CB1C24DEF50 for ; Thu, 14 Jan 2021 11:44:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DGjCh2v4Hz3jrR for ; Thu, 14 Jan 2021 11:44:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 633664DF083; Thu, 14 Jan 2021 11:44:48 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6300D4DEF9F for ; Thu, 14 Jan 2021 11:44:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DGjCg41wTz3jYt; Thu, 14 Jan 2021 11:44:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 10EBiYhc095215 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 Jan 2021 13:44:37 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 10EBiYhc095215 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 10EBiYBY095214; Thu, 14 Jan 2021 13:44:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Jan 2021 13:44:34 +0200 From: Konstantin Belousov To: Thierry Thomas Cc: FreeBSD Hackerz Subject: Re: Some fun with -O2 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4DGjCg41wTz3jYt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 11:44:48 -0000 On Thu, Jan 14, 2021 at 12:25:23PM +0100, Thierry Thomas wrote: > Let´s check a small C program, check_mktime.c, fetchable from > . > > $CC -o check_mktime -O2 check_mktime.c > ./check_mktime > > It is OK with clang90. > It loops forever with gcc9, gcc10, clang10 and clang11, > but OK without -O2. > > It is part of the configure script of ports/math/oleo, and I guess that > the same part could be found in other configure scripts. > > Note a similar program is part of glibc: see > . There is no fun with this stuff. The time_t type is signed, then the loop for (time_t_max = 1; 0 < time_t_max; time_t_max *= 2) continue; intent is to get signed overflow, which is UB. Modern compilers prefer to shoot into your foot instead of following common sense. Workaround is to add -fwrapv compiler switch. From owner-freebsd-hackers@freebsd.org Thu Jan 14 12:05:05 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4ED864DFF49 for ; Thu, 14 Jan 2021 12:05:05 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DGjg51hQ9z3lC4 for ; Thu, 14 Jan 2021 12:05:05 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id 3830B4DFE78; Thu, 14 Jan 2021 12:05:05 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 37F3E4DFF48 for ; Thu, 14 Jan 2021 12:05:05 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DGjg5143Yz3lH8; Thu, 14 Jan 2021 12:05:05 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id F2E0B1AE1; Thu, 14 Jan 2021 12:05:04 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::5cfc:8384:2375:c6d] (unknown [IPv6:2001:470:7a58:0:5cfc:8384:2375:c6d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 2A3A933F47; Thu, 14 Jan 2021 13:05:02 +0100 (CET) From: Dimitry Andric Message-Id: <5E0B4EA1-0F24-41C2-AEDD-F9D127B5D290@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_33B68D4C-1DE7-44C6-B1EE-8E2F5E6AF82E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Subject: Re: Some fun with -O2 Date: Thu, 14 Jan 2021 13:04:54 +0100 In-Reply-To: Cc: FreeBSD Hackerz To: Thierry Thomas References: X-Mailer: Apple Mail (2.3445.104.17) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 12:05:05 -0000 --Apple-Mail=_33B68D4C-1DE7-44C6-B1EE-8E2F5E6AF82E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 14 Jan 2021, at 12:25, Thierry Thomas wrote: >=20 > Let=C2=B4s check a small C program, check_mktime.c, fetchable from > . >=20 > $CC -o check_mktime -O2 check_mktime.c > ./check_mktime $ gcc -fsanitize=3Dundefined check_mktime.c -o check_mktime <...lots of warnings snipped...> $ ./check_mktime check_mktime.c:109:51: runtime error: signed integer overflow: = 4611686018427387904 * 2 cannot be represented in type 'long int' check_mktime.c:111:13: runtime error: signed integer overflow: = -9223372036854775808 - 1 cannot be represented in type 'long int' check_mktime.c:123:28: runtime error: signed integer overflow: = 1073741824 * 2 cannot be represented in type 'int' check_mktime.c:125:7: runtime error: signed integer overflow: = -2147483648 - 1 cannot be represented in type 'int' This program indeed relies on -fwrapv. -Dimitry --Apple-Mail=_33B68D4C-1DE7-44C6-B1EE-8E2F5E6AF82E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYAAzZgAKCRCwXqMKLiCW o+p8AJ0RXoS2gDkHTWNSbxjyeye4WQa/8ACgmCobasaFEDND9qQodSFJkiYpg8M= =Jr7y -----END PGP SIGNATURE----- --Apple-Mail=_33B68D4C-1DE7-44C6-B1EE-8E2F5E6AF82E-- From owner-freebsd-hackers@freebsd.org Thu Jan 14 12:17:51 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4E80B4E0480 for ; Thu, 14 Jan 2021 12:17:51 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from erza.lautre.net (erza.lautre.net [80.67.160.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "lautre.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DGjxp2PL9z3lgt for ; Thu, 14 Jan 2021 12:17:50 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from graf.pompo.net (graf.pompo.net [78.225.128.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by erza.lautre.net (Postfix) with ESMTPSA id 5846FFA38F for ; Thu, 14 Jan 2021 13:17:48 +0100 (CET) Received: by graf.pompo.net (Postfix, from userid 1001) id 5B588A2CE35; Thu, 14 Jan 2021 13:17:47 +0100 (CET) Date: Thu, 14 Jan 2021 13:17:47 +0100 From: Thierry Thomas To: freebsd-hackers@freebsd.org Subject: Re: Some fun with -O2 Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 12.2-STABLE amd64 Organization: Kabbale Eros X-Face: (hRbQnK~Pt7$ct`!fupO(`y_WL4^-Iwn4@ly-.,[4xC4xc; y=\ipKMNm<1J>lv@PP~7Z<.t KjAnXLs: X-PGP: 0xF1C516B3C8359753 X-Rspamd-Queue-Id: 4DGjxp2PL9z3lgt X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of thierry@pompo.net designates 80.67.160.89 as permitted sender) smtp.mailfrom=thierry@pompo.net X-Spamd-Result: default: False [-0.92 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-0.92)[-0.915]; FORGED_SENDER(0.30)[thierry@freebsd.org,thierry@pompo.net]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[80.67.160.89:from]; ASN(0.00)[asn:20766, ipnet:80.67.160.0/19, country:FR]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[thierry@freebsd.org,thierry@pompo.net]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[thierry]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[80.67.160.89:from:127.0.2.255]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 12:17:51 -0000 Le jeu. 14 janv. 21 ŕ 12:44:34 +0100, Konstantin Belousov écrivait : > There is no fun with this stuff. > > The time_t type is signed, then the loop > for (time_t_max = 1; 0 < time_t_max; time_t_max *= 2) > continue; > intent is to get signed overflow, which is UB. Modern compilers prefer to > shoot into your foot instead of following common sense. > > Workaround is to add -fwrapv compiler switch. Indeed, but the fun part is the different behaviour with / without -O2. -- Th. Thomas. From owner-freebsd-hackers@freebsd.org Thu Jan 14 14:22:45 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E6A914E4261 for ; Thu, 14 Jan 2021 14:22:45 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DGmjw6K5sz3wY4 for ; Thu, 14 Jan 2021 14:22:44 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f42.google.com with SMTP id q2so9790925iow.13 for ; Thu, 14 Jan 2021 06:22:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=9oYkbYtryv/xlKdE0u/ihr7KkfXYC5M6zndSs3r/Bys=; b=X1R47S4agMwnQYy60R6MhXhXV8sNAT07JubdOktWyhrtdPva1ZTWjVf1FfI9dtxJph Qw6YZTl12mrgh1sDfNsX7ChetT3ubZk+1eAkvVhkKMAMbW4VFUOM/ia8AIDeJPbt1jul nNALCPu4F3k8antU3CH5ASRoE00kEg2yGhJz+10MKxszocv3CTUaBMti7WASm0xMUt1z T7Rx3uuLD0dj9Bra9hTrmziffI2Bj8x7zHJqbMnITuXqF26/fxUhy+WVpRd+FO4+bOSj vG3tgM+IMHMjxu1CB1b/DuG3Hf74xMt4ZmzdyUJUDEx0znYtiCLYd6K/lQ8+Z9fYyD1m Xzvw== X-Gm-Message-State: AOAM533sTwlqN8KDmnbclLXEbrPr9KiKXBRhEeEwRRuovyIolbguA5Oi xPsBFJ7s+zWDOCx1ngN+CJEnPlR2glw5bjZe7Sos1Gpb8oGRng== X-Google-Smtp-Source: ABdhPJwOZpFZU0RaZzX7uLjS9xlWPAxIXi0YITe4+XUP9aWww/7vo7hql8PCe0cSlLY8nSNKZRJB0DagvLVIFCkjPu4= X-Received: by 2002:a05:6638:164c:: with SMTP id a12mr6518705jat.128.1610634163212; Thu, 14 Jan 2021 06:22:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Thu, 14 Jan 2021 09:22:30 -0500 Message-ID: Subject: Re: Some fun with -O2 To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4DGmjw6K5sz3wY4 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.42 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [1.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_DN_ALL(0.00)[]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.166.42:from]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[209.85.166.42:from:127.0.2.255]; NEURAL_SPAM_SHORT(1.00)[0.996]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.42:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.42:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 14:22:46 -0000 On Thu, 14 Jan 2021 at 07:17, Thierry Thomas wrote: > > > Workaround is to add -fwrapv compiler switch. > > Indeed, but the fun part is the different behaviour with / without -O2. Perhaps fun, but not surprising; this is a consequence of some optimization. Can we fix this in autoconf and then have math/oleo regenerate configure? From owner-freebsd-hackers@freebsd.org Thu Jan 14 17:44:51 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 10F884E917A for ; Thu, 14 Jan 2021 17:44:51 +0000 (UTC) (envelope-from "") Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DGsC62T3Mz4hCM for ; Thu, 14 Jan 2021 17:44:50 +0000 (UTC) (envelope-from "") Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id D438F160062 for ; Thu, 14 Jan 2021 18:44:47 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4DGsC317Fsz9rxD for ; Thu, 14 Jan 2021 18:44:47 +0100 (CET) From: Walter von Entferndt To: freebsd-hackers@freebsd.org Subject: Implicit assuptions (was: Re: Some fun with -O2) Date: Thu, 14 Jan 2021 18:44:19 +0100 Message-ID: <12075361.5MqMfjp4zD@t450s.local.lan> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-Rspamd-Queue-Id: 4DGsC62T3Mz4hCM X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=posteo.net (policy=none); spf=none (mx1.freebsd.org: domain of mout01.posteo.de has no SPF policy when checking 185.67.36.141) smtp.helo=mout01.posteo.de X-Spamd-Result: default: False [0.31 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_MED(-0.20)[185.67.36.141:from]; MIME_BASE64_TEXT(0.10)[]; NEURAL_HAM_SHORT(-0.59)[-0.591]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8495, ipnet:185.67.36.0/23, country:DE]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; DMARC_POLICY_SOFTFAIL(0.10)[posteo.net : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 17:44:51 -0000 QXQgRG9ubmVyc3RhZywgMTQuIEphbnVhciAyMDIxLCAxMzowMDowMCBDRVQsIEtvbnN0YW50aW4g QmVsb3Vzb3Ygd3JvdGU6Cj4gVGhlIHRpbWVfdCB0eXBlIGlzIHNpZ25lZCwgdGhlbiB0aGUgbG9v cAo+ICAgZm9yICh0aW1lX3RfbWF4ID0gMTsgMCA8IHRpbWVfdF9tYXg7IHRpbWVfdF9tYXggKj0g MikKPiAgICAgICAgY29udGludWU7Cj4gCj4gaW50ZW50IGlzIHRvIGdldCBzaWduZWQgb3ZlcmZs b3csIHdoaWNoIGlzIFVCLiAgTW9kZXJuIGNvbXBpbGVycyBwcmVmZXIgdG8KPiBzaG9vdCBpbnRv IHlvdXIgZm9vdCBpbnN0ZWFkIG9mIGZvbGxvd2luZyBjb21tb24gc2Vuc2UuCj4gClRoZSBuZXh0 IGxpbmUgaW4gdGhlIHByb2dyYW0gaXM6IHRpbWVfdF9tYXgtLTsKClRoZSBwcm9ibGVtIGhlcmUg aXMgb25lIG9mIHRoZSBtb3N0IGNvbW1vbiBpbiBwcm9ncmFtbWluZzogdG8gcmVseSBvbiBhbiAv CmltcGxpY2l0IGFzc3VtcHRpb24vIChlLmcuIGhvdyB0aGUgY29tcGlsZXIgKG9yIHRoZSBDUFUs Li4uKSBoYW5kbGVzIHNvbWUgCmV4cHJlc3Npb24pLiAgT2J2aW91c2x5LCB0aGUgYWJvdmUgbG9v cCBjb25kaXRpb24gKDAgPCB0aW1lX3RfbWF4KSBpcyAKKG1hdGhlbWF0aWNhbGx5KSBhbHdheXMg dHJ1ZSBhbmQgdGh1cyBjYW4gYmUgb3B0aW1pemVkIHJpZ2h0IGF3YXkgdG8gYW4gCmluZmluaXRl IGxvb3AuICBJc24ndCB0aGF0IGNvbW1vbiBzZW5zZSwgdG9vPyBIb3cgc2hvdWxkIHRoZSBjb21w aWxlciAob3IgdGhlIApDUFUpIGtub3cgdGhhdCB0aGlzIHdhcyAvbm90LyBpbnRlbmRlZD8KCj4g V29ya2Fyb3VuZCBpcyB0byBhZGQgLWZ3cmFwdiBjb21waWxlciBzd2l0Y2guAAo+CkFuZCB0aGUg Y29ycmVjdCBzb2x1dGlvbiBpczogRG8gbm90IHJlbHkgb24gaW1wbGljaXQgYXNzdW1wdGlvbnMu ICBJbnN0ZWFkLCAKd3JpdGUgZG93biAvZXhwbGljaXRlbHkvIHdoYXQgeW91IGludGVuZCB0byBk byBvciBnZXQgYXMgcmVzdWx0LiAgSWYgdGhhdCdzIApub3QgcG9zc2libGUgKG9yIHRvbyBjb21w bGljYXRlZCksIGF0IGxlYXN0IGFkZCBhIGNvbW1lbnQgZXhwbGFpbmluZyB5b3VyIAppbnRlbnRp b24uCgpTaW5jZSB0aGUgYmVoYXZpb3VyIG9uIHNpZ25lZCBvdmVyZmxvdyBpcyB1bmRlZmluZWQg aW4gQywgdGhlIGFib3ZlIHN0YXRlbWVudCAKbXVzdCBiZSByZXdyaXR0ZW4gY29tcGxldGVseS4g IEZvciB0aGUgY2FzZSBhYm92ZSwgaXQncyBvYnZpb3VzIChhbHNvIGZyb20gdGhlIApuYW1lIG9m IHRoZSB2YXJpYWJsZSkgdGhhdCB0aGUgYXV0aG9yIHdhbnRzIHRvIGhhdmUgdGltZV90X21heCAg PSB0aGUgbGFyZ2VzdCAKcG9zc2libGUgcG9zaXRpdmUgbnVtYmVyIG9mIHR5cGUgdGltZV90IChh bGwgYml0cyAxIGV4Y2VwdCB0aGUgc2lnbiBiaXQpLiAgT0ssIAp0aGVuIHdyaXRlIHRoYXQgaW5z dGVhZDoKClthZGQJI2luY2x1ZGUgPHN0ZGxpYi5oPl0KYWRkCSNpbmNsdWRlIDxsaW1pdHMuaD4K Y2hhbmdlCXN0YXRpYyB0aW1lX3QgdGltZV90X21heDsKdG8Jc3RhdGljIGNvbnN0IHRpbWVfdCB0 aW1lX3RfbWF4ID0gTE9OR19NQVg7CltiZWNhdXNlIHRpbWVfdCBlcXVhbHMgbG9uZyBpbnRdCmRl bAlmb3IgKHRpbWVfdF9tYXggPSAxOyAwIDwgdGltZV90X21heDsgdGltZV90X21heCAqPSAyKQpk ZWwJCWNvbnRpbnVlOwpkZWwJdGltZV90X21heC0tOwoKWW91IG1heSBhbHNvCmFkZAkjaW5jbHVk ZSA8c3RkaW8uaD4KYWRkCXByaW50ZiAoInRpbWVfdF9tYXggPSAlbGRcbiIsIHRpbWVfdF9tYXgp OwoKaW4gbWFpbigpIHRvIHZlcmlmeSB0aGF0J3MgZ2l2aW5nIHlvdSB3aGF0IHlvdSB3YW50Lgot LSAKPXxvKQkiU3RlbGwnIERpciB2b3IgZXMgZ2VodCB1bmQga2VpbmVyIGtyaWVndCdzIGhpbi4i IChXb2xmZ2FuZyBOZXVzcyk= From owner-freebsd-hackers@freebsd.org Thu Jan 14 19:00:36 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 64AD24EACF9 for ; Thu, 14 Jan 2021 19:00:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DGttW2wJwz4mSZ for ; Thu, 14 Jan 2021 19:00:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1610650833; bh=CQttohcWIzVBKoNGQt497TrhnQ8PSn9lzrET/UIeBmi=; h=Subject:From:Date:To:From:Subject:Reply-To; b=aPMmDXEj/H45dNtrLLl1DOsl0z4pZhXvSDqBtl1wlBLmOJDhwFxDQ2HTOFI6YAoK0YukLyB6M0pX+kRuA7ZIATJ+rSHd7Ck6o4Bjc+b8tbNNvLCsPMeU8YkRQsFPXgTirJ+PPUmCa5vfqrLTCbQezRubOhBTQwpVJMkk2g3bWON+Lb0FnrvVsm3AA9KUoEtM4ADh26ziQNNCiPckW+90dsJ1JhT8Ov4fZXWRHh6VboLpfuXimnRVmMsn553UWvyWr4X6U+1Xu5TOjPJBVBHwugxqjcrPD69Vba/EITMM19WPuk+WNlvS545PQeJrIVOltHL6YUeQ+MfvnjKo6AufGw== X-YMail-OSG: u4bkWUoVM1k3wQJ36Cvxame2ofF5jxGgABTlpkn.361sL4R17gBWTmoeiTP9u8z _Cz.xY6aQStYbYhluAi8CmFc6pdyoQHuaSEt4GkTNMbacWMJbOI_2E4Rbv5y.0TVGT8ducN3zm0c QYxLBJdzYFT09YJyq8tJEOdY4yQkkX4WnKf_ASA6H2zMgj7Zo2xumnZBu9Iw7lFxYLwC659UPqxz 6O5ryXVFrZHob74d5iCOa9Lvx2NsTK0mS_KPuo95DL1ZTT65rwLy1yWUdiu68Of06n6ACS0LSbfB C3urRWrD78sBSdHSd6H3LaYynxZE2dX35BYdXcCODZLZYeLSBz52Jzxt936sJ2OaYAMNkx204DYs vji0puqq9I3fgOlerHTHY_WaGgOIxnADLTACdPsmGHl5q9du0_lA8APcVx_9ZvKuxLYyY6AqL0Le BqqSN7IxAM_yMouZttQAuFHJFdyQAqJgvcGjQdgTqHZMvd.fHi461E5MQExr17gR8j8gZicW2Gi2 dcupCDkTNYRKtGLdCOucMwe6aB4ysgLpSX.Rt5VwKl_NIuA0_HQu7lCQA9YvmVtgfx1pp4hh84e8 Um._o1tFoRCEHlkuvu8fYJo_jkQBv1KQiQDiNqdLVrkh_qq8ck9QSJD15xDqVuW58ghY.hsINvZD Zy_IsT0jsWQLUiM1HBaVg8STU4S3hfpTGjk0HmQaFO5O3PkHxEDhKN_YwQF0sFkxavTslJoTeNEJ v0IHUzYjW2gTmGmzVtPmUW9.NckkAxbNEcN3yj16R01ybJCAND8pgyW8uj9B.0A2aZ_L6QQAmZIu 9BzrKG6QeK5lCmpixmcMHlAe48Tng2kNf76BwwQkaSN8e8JuJAu87CgmE2Le.ku6RhmteuBdfySk 820RsnMoDlQRcsulIOlwOzgFLshW7e46gDgv4BJwhkLpdvTCfMNFYeha7unZ1CUnuNuVOALtVCuW 5LDNGNAZ_26t0xtycrbLgOvJCNo.Sdvx6STJd8FbEaNQrsczHMEH8sPddh4Z70497CRrr46o6xZy DZV6Ku5fBKguxa.c86O4NZ7Rc7k8IPjMsFPSd9YEAQe_vuVYFNw3oTOex2tKfje1AlutE65.Z4Jr 72MDFdBD3IM.fUzGOsfDE.EfoxH5uszu7jnFOlT5hBM0EKpdjWukZC.8pZvNdVJZcrX9rr82ny4v k7Z2cv9UQL_Sekt38FvytdXHPC.I0DBq4bbOCL3RglvV2TGYVCPCNcWbgxvU0FAFNVxqzeQZY.vJ PUG0qCWX3tlUUUNG1OLbxT6cEtwoPcnvTcKJZthi.Q1KhnJpTJUFn0PUjS0n4ytFiwBy56ZoTyR6 9aUJR1Jf6xGY1V6Xbx2YKQnMk9pnDEiO9JBgP8z2cB4gvae8coDK7urLhQr2SQv5zKVYejvZwgMx 602QmBLaamqwMJv2B9uWgSPn9iY6h9K7LE978LDzR6riZpA7Rh4t0NOni_K7AAQBDdszA2xc7BlX ybhu24OsynaNb4dXFs6DAYJyBV9DvSsvG12mUViOBXQgbhACjbvvGUxYoaSY6b1Lj0h7IOMC7Gwg aFTUPuL0OeUvLuOwz9v2gmFzwFOpaz72eTIy2C27hyl5_.d7PyDS4sTGTct1TVR0UFoc75ZUufbC ol6oqieqNJ4lCJMubPVQHgANEaZcDBc7qZAaxmrkh3b7Ti9uwsluu0CiJDE8vr8pHRnSxzqqCIxD JsRAzEjhY8xjxLNkexAUp7.XkBv5XRHZTf0xA5oVdHANJM4olUyiLsx24aS_jRxV_ij81Cx1ai28 KzJQDS0JlcNl7PmCy6cIq9I7pAJk70jr8_TIcOALjVzVcDQmVplWT23woNBKNgY7Sgr407Xe4JfB ao6CWJi9_ADJy50eYJ_x.HLG0S8RkqLZ0Jh4Tu6Zr6URRdcju9l6a7COM8L_zP7cghMK1DxQmFVR bPrZBnfDcDuDRH3tnxkPDr7QqKl7a_C1TSDh2V0JmncXFnZP9l7cm_Rue5Ha583FgiFXseiJPi8g 6kD_C88CGhJ8bTgEBvK0os7Zwv7SyA5pqmEixIo.UjT6Z0x7LT0M7UT8W6ecL3Xe1OhSSmu6gPsZ uIMKulUhu9riYcJMeR7CZKYbqeJ5UweyDf6.Pj0hGVP2G4T8xVf4_978AydCpt3bjMp3qBDHNNGy X26OjyJJUngBnW_5QQeN5xv.4qJLz9r5MUpWtwnrtHI7kCr94FZnINmFUqsVKZWdZbZ7KNtLdMoJ A6OwgurQeItWrzgDQ0uII28GYUBov.Dl9histDJOWb7g.sI6Uyw7jmPslFw34Rucuc5VKwpEg.3j pe1nMl87Ov3gz4DHpkWckT7XERgUQD6EUnYN0Bl0JrzuK_3BL6osK_aOzIlZe8aMr96amVtVQHyK y7wY5vNSt71ftPaK83_Mq2lLOU5Vra84uvYZ06m9MqsoJXquQaTCokga3GwV4DeODTcP.KwCc2tg JTuIxLyw7f4HA5tdqbbwj1srWP0SUwVBJAEKCHkxrAZnoB5Ff Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Thu, 14 Jan 2021 19:00:33 +0000 Received: by smtp423.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9c140821402804f808e7dca8f5345c7d; Thu, 14 Jan 2021 19:00:32 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Implicit assuptions (was: Re: Some fun with -O2) From: Mark Millard In-Reply-To: <12075361.5MqMfjp4zD@t450s.local.lan> Date: Thu, 14 Jan 2021 11:00:31 -0800 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <12075361.5MqMfjp4zD@t450s.local.lan> To: Walter von Entferndt X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DGttW2wJwz4mSZ X-Spamd-Bar: - X-Spamd-Result: default: False [-1.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.83:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[98.137.69.83:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 19:00:36 -0000 On 2021-Jan-14, at 09:44, Walter von Entferndt = wrote: > At Donnerstag, 14. Januar 2021, 13:00:00 CET, Konstantin Belousov = wrote: >> The time_t type is signed, then the loop >> for (time_t_max =3D 1; 0 < time_t_max; time_t_max *=3D 2) >> continue; >>=20 >> intent is to get signed overflow, which is UB. Modern compilers = prefer to >> shoot into your foot instead of following common sense. >>=20 > The next line in the program is: time_t_max--; >=20 > The problem here is one of the most common in programming: to rely on = an / > implicit assumption/ (e.g. how the compiler (or the CPU,...) handles = some=20 > expression). Obviously, the above loop condition (0 < time_t_max) is=20= > (mathematically) always true and thus can be optimized right away to = an=20 > infinite loop. Isn't that common sense, too? How should the compiler = (or the=20 > CPU) know that this was /not/ intended? >=20 >> Workaround is to add -fwrapv compiler switch. >>=20 > And the correct solution is: Do not rely on implicit assumptions. = Instead,=20 > write down /explicitely/ what you intend to do or get as result. If = that's=20 > not possible (or too complicated), at least add a comment explaining = your=20 > intention. >=20 > Since the behaviour on signed overflow is undefined in C, the above = statement=20 > must be rewritten completely. For the case above, it's obvious (also = from the=20 > name of the variable) that the author wants to have time_t_max =3D = the largest=20 > possible positive number of type time_t (all bits 1 except the sign = bit). OK,=20 > then write that instead: >=20 > [add #include ] > add #include > change static time_t time_t_max; > to static const time_t time_t_max =3D LONG_MAX; > [because time_t equals long int] Not on FreeBSD for 32-bit powerpc it is not: time_t is 64 bits wide there but long int is not: =46rom /usr/include/machine/_types.h : typedef __int64_t __time_t; /* time()... */ =46rom /usr/include/sys/types.h : typedef __time_t time_t; > del for (time_t_max =3D 1; 0 < time_t_max; time_t_max *=3D 2) > del continue; > del time_t_max--; >=20 > You may also > add #include > add printf ("time_t_max =3D %ld\n", time_t_max); >=20 > in main() to verify that's giving you what you want. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Thu Jan 14 19:03:38 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B455D4EAFE9 for ; Thu, 14 Jan 2021 19:03:38 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from erza.lautre.net (erza.lautre.net [80.67.160.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "lautre.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DGty14xcwz4nBR for ; Thu, 14 Jan 2021 19:03:37 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from graf.pompo.net (graf.pompo.net [78.225.128.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by erza.lautre.net (Postfix) with ESMTPSA id 670D1FA3BF for ; Thu, 14 Jan 2021 20:03:35 +0100 (CET) Received: by graf.pompo.net (Postfix, from userid 1001) id B3C0FA2D5BE; Thu, 14 Jan 2021 20:03:34 +0100 (CET) Date: Thu, 14 Jan 2021 20:03:34 +0100 From: Thierry Thomas To: freebsd-hackers@freebsd.org Subject: Re: Some fun with -O2 Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 12.2-STABLE amd64 Organization: Kabbale Eros X-Face: (hRbQnK~Pt7$ct`!fupO(`y_WL4^-Iwn4@ly-.,[4xC4xc; y=\ipKMNm<1J>lv@PP~7Z<.tKjAnXLs: X-PGP: 0xF1C516B3C8359753 X-Rspamd-Queue-Id: 4DGty14xcwz4nBR X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of thierry@pompo.net designates 80.67.160.89 as permitted sender) smtp.mailfrom=thierry@pompo.net X-Spamd-Result: default: False [-1.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.995]; FORGED_SENDER(0.30)[thierry@freebsd.org,thierry@pompo.net]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[80.67.160.89:from]; ASN(0.00)[asn:20766, ipnet:80.67.160.0/19, country:FR]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[thierry@freebsd.org,thierry@pompo.net]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[thierry]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[80.67.160.89:from:127.0.2.255]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 19:03:38 -0000 Le jeu. 14 janv. 21 ŕ 15:22:30 +0100, Ed Maste écrivait : > > Indeed, but the fun part is the different behaviour with / without -O2. > > Perhaps fun, but not surprising; this is a consequence of some optimization. > > Can we fix this in autoconf and then have math/oleo regenerate configure? Configure is written to analyze a lot of systems, but since we know our mktime, I just wanted to shunt this part of the script. -- Th. Thomas. From owner-freebsd-hackers@freebsd.org Thu Jan 14 19:09:30 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B562D4EB437 for ; Thu, 14 Jan 2021 19:09:30 +0000 (UTC) (envelope-from david@lapinbilly.eu) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DGv4n69hSz4nTt for ; Thu, 14 Jan 2021 19:09:29 +0000 (UTC) (envelope-from david@lapinbilly.eu) X-Originating-IP: 90.76.43.122 Received: from llanura.davidmarec.ddns.net (lfbn-tou-1-1219-122.w90-76.abo.wanadoo.fr [90.76.43.122]) (Authenticated sender: david@lapinbilly.eu) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id B18FC240004 for ; Thu, 14 Jan 2021 19:09:28 +0000 (UTC) Subject: Re: Some fun with -O2 To: freebsd-hackers@freebsd.org References: From: David Marec Message-ID: <129286cb-dce3-283d-48d4-d6a9623e7d20@lapinbilly.eu> Date: Thu, 14 Jan 2021 20:09:27 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr X-Rspamd-Queue-Id: 4DGv4n69hSz4nTt X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@lapinbilly.eu designates 217.70.183.193 as permitted sender) smtp.mailfrom=david@lapinbilly.eu X-Spamd-Result: default: False [0.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[217.70.183.193:from]; R_SPF_ALLOW(-0.20)[+ip4:217.70.183.192/28:c]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[217.70.183.193:from]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[217.70.183.193:from]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[lapinbilly.eu]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[217.70.183.193:from:127.0.2.255]; NEURAL_SPAM_SHORT(0.90)[0.903]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 19:09:30 -0000 On 14/01/2021 15:22, Ed Maste wrote: > On Thu, 14 Jan 2021 at 07:17, Thierry Thomas wrote: >>> Workaround is to add -fwrapv compiler switch. >> Indeed, but the fun part is the different behaviour with / without -O2. > Perhaps fun, but not surprising; this is a consequence of some optimization. Actually, this is documented in the /autoconf/ manual: https://www.gnu.org/software/autoconf/manual/autoconf-2.70/autoconf.html#Integer-Overflow-Basics -- It's a trap! David Marec http://wiki.fug-fr.org/doku.php?id=start From owner-freebsd-hackers@freebsd.org Thu Jan 14 22:08:16 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 918354EFA84 for ; Thu, 14 Jan 2021 22:08:16 +0000 (UTC) (envelope-from "") Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DGz334t4sz3Jxw for ; Thu, 14 Jan 2021 22:08:15 +0000 (UTC) (envelope-from "") Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 788D616005F for ; Thu, 14 Jan 2021 23:08:13 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4DGz30326Gz6tmf; Thu, 14 Jan 2021 23:08:12 +0100 (CET) From: Walter von Entferndt To: freebsd-hackers@freebsd.org Subject: Implicit assumptions (was: Re: Some fun with -O2) Date: Thu, 14 Jan 2021 23:08:08 +0100 Message-ID: <4569591.1rqTVSEV2j@t450s.local.lan> In-Reply-To: References: <12075361.5MqMfjp4zD@t450s.local.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 4DGz334t4sz3Jxw X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=posteo.net (policy=none); spf=none (mx1.freebsd.org: domain of mout01.posteo.de has no SPF policy when checking 185.67.36.141) smtp.helo=mout01.posteo.de X-Spamd-Result: default: False [-0.70 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[posteo.net : No valid SPF, No valid DKIM,none]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[185.67.36.141:from]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; CTE_CASE(0.50)[]; ASN(0.00)[asn:8495, ipnet:185.67.36.0/23, country:DE]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-hackers]; FREEMAIL_CC(0.00)[yahoo.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 22:08:16 -0000 At Donnerstag, 14. Januar 2021, 20:00:31 CET, Mark Millard wrote: > Not on FreeBSD for 32-bit powerpc it is not: time_t > is 64 bits wide there but long int is not: > > From /usr/include/machine/_types.h : > > typedef __int64_t __time_t; /* time()... */ > > From /usr/include/sys/types.h : > > typedef __time_t time_t; > Ha! Thx... Ok, then we have to use the *sizeof* operator and if you thought there's one holy constant in computer science - that a byte has 8 bits, and we can use that as an ... /implicit assumption/ ... - you might be surprised that it's declared explicitely in sys/param.h:#define NBBY 8 /* number of bits in a byte */ and you can find the number 8 (and 16, 24, 32, 48,...) all over other header files without using that definition (NBBY) so these are strictly speaking all wrong... ;) So now we have (errorneous!) [delete #include ] #include time_t time_t_max; ... for (i = time_t_max = 1; i < NBBY*sizeof time_t_max; i++) time_t_max *= 2; time_t_max--; which gives the intended result but is strictly speaking wrong, because it you don't do the decrement, the value is negative, and the decrement of a negative number should be negative, too. I.e. this only gives what we want because we make use of an undefined behaviour. So let's do better (and portable): #include signed_t signed_max, t1; for (int i = signed_max = 1; i < NBBY*sizeof signed_max - 1; i++) { signed_max *= 2; // eq: signed_max <<= 1; t1 = signed_max - 1; } signed_max += t1; // eq: signed_max |= t1; /* QED * hopefully the compiler optimizes *=2 and we're using binary numbers ;) */ -- =|o) "Stell' Dir vor es geht und keiner kriegt's hin." (Wolfgang Neuss) From owner-freebsd-hackers@freebsd.org Fri Jan 15 03:47:13 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C00704D7246 for ; Fri, 15 Jan 2021 03:47:13 +0000 (UTC) (envelope-from "") Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DH6Z8538xz3rrL for ; Fri, 15 Jan 2021 03:47:12 +0000 (UTC) (envelope-from "") Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 943F52400FC for ; Fri, 15 Jan 2021 04:47:10 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4DH6Z564lyz9rxK; Fri, 15 Jan 2021 04:47:09 +0100 (CET) From: Walter von Entferndt To: freebsd-hackers@freebsd.org Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) Date: Fri, 15 Jan 2021 04:47:06 +0100 Message-ID: <4842729.YNO7O01DYZ@t450s.local.lan> In-Reply-To: References: <12075361.5MqMfjp4zD@t450s.local.lan> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart3042245.bT80LyP3VS" Content-Transfer-Encoding: 7Bit X-Rspamd-Queue-Id: 4DH6Z8538xz3rrL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=posteo.net (policy=none); spf=none (mx1.freebsd.org: domain of mout02.posteo.de has no SPF policy when checking 185.67.36.142) smtp.helo=mout02.posteo.de X-Spamd-Result: default: False [-2.69 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[posteo.net : No valid SPF, No valid DKIM,none]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-patch]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[185.67.36.142:from]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.994]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; CTE_CASE(0.50)[]; ASN(0.00)[asn:8495, ipnet:185.67.36.0/23, country:DE]; MIME_TRACE(0.00)[0:+,1:+,2:+]; MAILMAN_DEST(0.00)[freebsd-hackers]; FREEMAIL_CC(0.00)[yahoo.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 03:47:13 -0000 This is a multi-part message in MIME format. --nextPart3042245.bT80LyP3VS Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Eventually we have a compile-time constant expression --nextPart3042245.bT80LyP3VS Content-Disposition: attachment; filename="check_mktime.c.diff" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="check_mktime.c.diff" --- check_mktime.c.orig 2021-01-15 03:19:33.962253000 +0100 +++ check_mktime.c 2021-01-15 04:04:22.291014000 +0100 @@ -1,13 +1,16 @@ /* Test program from Paul Eggert (eggert@twinsun.com) and Tony Leneis (tony@plaza.ds.adp.com). */ # include +# include /* NBBY: #bits of a byte */ # include # include +# include /* Work around redefinition to rpl_putenv by other config tests. */ #undef putenv -static time_t time_t_max; +const time_t t0 = (time_t) 1 << (NBBY*sizeof t0 - 2); /* unused elsewhere */ +static const time_t time_t_max = t0|(t0 - 1); /* Values we'll use to set the TZ environment variable. */ static const char *const tz_strings[] = { @@ -106,9 +109,6 @@ time_t t, delta; int i, j; - for (time_t_max = 1; 0 < time_t_max; time_t_max *= 2) - continue; - time_t_max--; delta = time_t_max / 997; /* a suitable prime number */ for (i = 0; i < N_STRINGS; i++) { --nextPart3042245.bT80LyP3VS-- From owner-freebsd-hackers@freebsd.org Fri Jan 15 07:02:57 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 52C3C4DA1D3 for ; Fri, 15 Jan 2021 07:02:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DHBw00d9cz4W9k for ; Fri, 15 Jan 2021 07:02:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1610694174; bh=hnt2gAclbALQzz1k+/QfhVRhX0AzQXRCFNYZ+TiZ3HV=; h=Subject:From:Date:To:From:Subject:Reply-To; b=EnytFjlieHcsUkTW+W8v3pU+CQ8S1AaVC8wkTfaL5rJL7se9YnjAfaWkRO21rpOxwAm8GzNlnjkjkovf7rp7iruIxsYCXH+ZIDFjYDxBUX1e89jSumE/Xku2CjNpEM81pxoE+wkHEsai60Eltzugzy2zvE7mSEk7kfKO2Q1hrRY+GT9t/xmPn+VXHPSGO+Vghp13DgDYFiWHLmYmnjTJh5suZLW1V43vJKdFFKBcutCo0wufZbCwCw936r5d4f1r60E2uOJGD7VhRlShWL/x5i5HPKke9D4+JVwckaMW1Nok+5ROLc6z7/SLLwl4vSE4kYxVwEY1cuaBIbskOhCUSw== X-YMail-OSG: r1z2QtQVM1nupESLVjJc.vfEVB3gCsdrVvx8ZK3uQPyrpx0J4zYd0R_I7gfNsr_ i4mcUv1IrqMSVtqdUyI5uel9Ove21Y.mfAyxTTkvLHQvzHDMYz2yaS.mfxIry4flzmxqnG96QrkH RfbRyoh838l69ezqZ8FEQvjB96afQ10DY_1OjlZrsTWiaxzWb5N7sodos0ES.rvp8ut1Qe92yDHj wFmDfnd1bPgo5DlzcGRFwoa.S9nOqk2JSTTBUS36B3KJp8npeBh3R_iSOepFilS1cLN9aOpJzIno RzRMRPBQ56cJAM.i4VBu0sz7WQBR9ufV6rghMRsvxdd1OuHsCBw8lPupfY_P1iDAqchaOjM3OBpV q0Xl7LGN4HJzu5R78oRfa5Wm90b4HWSooMWTBDEnAF8wPEF_BEgPtCT2vZX_bsY_.p5N73WQxKBG 3U7G_Ay91qeFLmRhklDgfCRhXKHGB5ktCQDvJ8gdDy1w4dGfdcmGtF3LOvFtbggH9HRwqfYgQVoe j9WvPR_c6bk7KHAtR2sUPeesI6aEtMKFz4RPUW9ti_kUDndvPnYJBlI6R24hZu3Ftn4qpgyNGW45 rdnAOQNcYt4Cis9ju_F0oI2xH3SJXNWiKZh32l2cFy0_CZioFUnjX201EWQhUt3ivrW40ah8MIiZ J.H.NDCPqRUu1q8Tu77xwkAOuEuKNsEuSHB4vN.dHCwaxB7Ho0QdGcSSSzIdSDxaQ_gljESEg2q4 89DcKkFOzvvdQ7z04RkEXLMSelF5A2yo1PM4v.zBU97jSr5fCvsLpdP43t0EXPffat8mDgf6ZwU8 Vhlc6nBxbCMj7vVPjMPhYziwge9nBUkvAD6jyVjdhrMvPnIs_n4GETbHzorydCcJY6TdEx5BrfHQ k.932g4_sFcGEQWFjYWIr9y740iom1GNnWRI5o2z.JZFylkPetyLtXtFeiHINPuAhQ5WEFqRMNRR 32I8SQ5oSx1pta.a9EozlT1_4kE3Tz.NbOjBFWZLhL3mI4rH4pTKwLc0JSZ2zr.6SinAZoMR0HcL SdaP6J2LrtURUX5dr9QOyfo2OxWaij8ekTFz6DPENXF0qaNxxro4ITT34DsZkOwido70z3INMziS aG.hawPXDHZdkmb8G_3wjuQjzRMsepGA6duk9o5kB01odrtpOSieRZ1YKbN4owy2DeZVW9dhaq0A L0YFfD1O3XBET.eh6B_Dx34IU1xMiMc5J0rNFXsZ9pQsuwmzZFIi4xaNjr0kWAATrSjc3ZRsGibD vh3Yheg_Emq_f2WkWOePlSSxCUI_cSlmDji6OYOXQqRJtbl4E2quk8KoAVGm_z23ZIyXDVnA9SNl nnsMQTnO5fWYkBJ4PoVj5G7.NgPQqRzZXfBHUxUZdMH.8.iVSi7xLydlvJ5PslJm0JYIpMD7kVyi Q13btJb63KEAM_BaHHYcnPPjkVGitejTTobrCOQ_fJLQC4BlljLTHndtlSQPximJYoq_Pf_3k4sL 7qaVqURnCiz5_4heZ8R_IqNkpLSbJn8rBvpgKepPQgmPt_.fsXbco7sNRKLKe4CYmT8mqChvrmtD CVoGEepRvy7iS6l4hW6PJct9gAJeWITJLgRul_vw1EDWNCmZJaB3gfaLsz0Dkm25nn6djWqovqaB QKECITSR.QOWfuZgQsuHF_PTVSDOa8h4rMVJ2N_kvATusZZNgonVcE81vHWeUC.b5XFf3ma4ODTE uaB83GBfXfJA2yNXUrG59FvPk64gMdwbbYQ5JqmZ47xw15iciZBAFYH7fQtdIlf1GjtnxriuacZZ BW48csX1Hz1cuomvnaWEZo64EuBFvMXHDrfhxIV29.V.Z2kaYsQ5yDAwiHw3uEgZnE.vDn3_tHYQ 9g1U1QG_GKoWvsFmO3XHWyvUJwX9DXq1Ke3s6MnywvU47OiKArvvTfnDCyzqoebQxSaQjzdZUE8d bHn0GLq.7rwynLOWFzMejFhVnqPXgu8LpyL4k0eitTWAM5w1UiiXhgEXEHB.FmXMLoLg6xdtaG_m b_rb34XUJF4k6hNGaMG1NeDQYIVALkXx2hHZM3PEjBiIjXSdzMKYXZ0jydYz.S1wwRw2PW5uRQxR LB2MH2Lzt8kDejrLyfXefwj1f8xcdcKGyDPfFMzYQXlBpXHAuQCnrNA5ADC6tP.PqLDtVoAQACZm .P5thYz52fWdOXgornZcrlBcI2l92f1ZeJMU.j7EyJ64glYxx1w0wYYgIE40U5MzGLRBiFT27ve3 dwD4RhVjeVz5cLgZHcWvjRingFR7J_moX42lST7dw6S8QWv8E8G4wMWTVFgA4nH2rzT_thcseM0y mY2YdYsflqktt_wardu5x490Ag.gYBfZW6AneYYVDXgYKzpWXkOf8ca55EfqA9faIqXO6TvJtG8g fkfTBSHe6.2erKVS5.O0xLO.nMwTleXzjmilJRqD.njY668xEHqRsitm51zfUfZbKbEz7eFHwg6L WdxcdwDLpZlDZaAIkjY6mzLZyi2qztODFSjZsLF57A4oLHWiHJFIFVAHe.14v78_94OuSp1C5fu2 F3iIA9Y6dbJVfEUaODcBZtw8b.y5i Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 15 Jan 2021 07:02:54 +0000 Received: by smtp409.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8aaa9fa53b89b0900da3dbb5ab153d08; Fri, 15 Jan 2021 07:02:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) From: Mark Millard In-Reply-To: <4842729.YNO7O01DYZ@t450s.local.lan> Date: Thu, 14 Jan 2021 23:02:49 -0800 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8D35ADAE-8904-4400-9DEB-7B274189BC30@yahoo.com> References: <12075361.5MqMfjp4zD@t450s.local.lan> <4842729.YNO7O01DYZ@t450s.local.lan> To: Walter von Entferndt X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DHBw00d9cz4W9k X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.49 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.99)[-0.995]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.204:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.204:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.204:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.204:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 07:02:57 -0000 On 2021-Jan-14, at 19:47, Walter von Entferndt wrote: > Eventually we have a compile-time constant = expression FYI: C itself has, in , CHAR_BIT for the number of bits in a Byte for how sizeof counts Bytes: sizeof(char), sizeof(signed char), and sizeof(unsigned char) are each always 1. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Fri Jan 15 18:11:58 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3F04B4EDB5C for ; Fri, 15 Jan 2021 18:11:58 +0000 (UTC) (envelope-from "") Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DHTlx2vK7z3Lc8 for ; Fri, 15 Jan 2021 18:11:57 +0000 (UTC) (envelope-from "") Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 7E7A0160062 for ; Fri, 15 Jan 2021 19:11:54 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4DHTlr47Ltz9rxS; Fri, 15 Jan 2021 19:11:52 +0100 (CET) From: Walter von Entferndt To: Mark Millard Cc: freebsd-hackers@freebsd.org Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) Date: Fri, 15 Jan 2021 19:11:47 +0100 Message-ID: <2310709.D6tDg3Ca2R@t450s.local.lan> In-Reply-To: <8D35ADAE-8904-4400-9DEB-7B274189BC30@yahoo.com> References: <4842729.YNO7O01DYZ@t450s.local.lan> <8D35ADAE-8904-4400-9DEB-7B274189BC30@yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 4DHTlx2vK7z3Lc8 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=posteo.net (policy=none); spf=none (mx1.freebsd.org: domain of mout01.posteo.de has no SPF policy when checking 185.67.36.141) smtp.helo=mout01.posteo.de X-Spamd-Result: default: False [-2.70 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[185.67.36.141:from]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; R_DKIM_NA(0.00)[]; CTE_CASE(0.50)[]; ASN(0.00)[asn:8495, ipnet:185.67.36.0/23, country:DE]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-hackers]; DMARC_POLICY_SOFTFAIL(0.10)[posteo.net : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 18:11:58 -0000 At Freitag, 15. Januar 2021, 08:02:49 CET Mark Millard wrote: > FYI: C itself has, in , CHAR_BIT for the number of bits in a > Byte for how sizeof counts Bytes: sizeof(char), sizeof(signed char), > and sizeof(unsigned char) are each always 1. > No, CHAR_BIT is the #bits in a *char*, which is the (standard) datatype for the binary representation of a character/letter/symbol in written human language, and for small integers. The name also suggests that, as well as the comment in the header file. That does not necessarily equal a "byte", which (by commonly accepted knowledge) is the smallest addressable entity in a computer's memory. Of course, e.g. https://code-reference.com/c/datatypes/ char tells a *char* occupies one byte. Sadly, AFAIK C itself does not define what a "byte" is, although that term is mentioned many times in reference manuals (implicit assumption). So /theoretically/ CHAR_BIT and NBBY can differ. In fact, many library funtions operating on characters/letters take an *int* instead of a *char* for performance reasons. From https://code-reference.com/c/stdlib.h/sizeof: "the *sizeof* operator returns the number of bytes to be reserved for a variable or a data type". Of course, for practical reasons, we can safely assume that a *char* will take one byte in storage space for the foreseeable future, since the consequences of changing that would be disastrous. -- =|o) "Stell' Dir vor es geht und keiner kriegt's hin." (Wolfgang Neuss) From owner-freebsd-hackers@freebsd.org Fri Jan 15 18:35:50 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 44A464EE812 for ; Fri, 15 Jan 2021 18:35:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DHVHT2ZbYz3MlJ for ; Fri, 15 Jan 2021 18:35:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1610735747; bh=lIB84cxvzAIWC+gvKvTPKN8DubCLYTlmUl1gf8zARNR=; h=Subject:From:Date:To:From:Subject:Reply-To; b=JqaZvxSbmG/CNq+fpc6FTBMSAPnT0uaa3NDy1hR+hTKoTFyXRzA9pvC7cRZeb9HdFIdz8ORaNNytTSZzTK0BJYo4n+CwTL5Uyd2bl4zZKU7pnYJ7PjE1LmOTqMmolgkDz760kRGC0vM5ZkySovSHoh4ChCrSFbDNcAbZQYV8+FD/+WiAms8xMjYWsQeK615EE3XxGRPUwb9OCds6KzeBnF+G0h9qneB8jWWmWGtlqTn63hh5iBItw6xHftMFcNqehtnCrDBN2J0TDsEwg/kfTcPJuU8N9Vx87il9PkidtiRA5r2Sd78qfY+8xYbo98qVtwN/f7t2OYsgLG3DeXnaNQ== X-YMail-OSG: 0FQaa_UVM1nkGDpwzEFlu2Gmy7UcyyC1ZTsrWOJHCedcZqvfV.Tgn7kTnem7.pa n8hbMshup4iNSaDsuM8GpaOtxoQtzg5FBeXip4k6OpVVfBvd_E4RjCF4FGku9gFmu5iDt5VoYOht bKV027g6dwqHWBtam_B8hX1PgSCw2U6G6OcmxwSXK94tiLPVpojWZj924ypvSSBOqcYT0b1mjyBe wTOLwRjjW_HMVTHewodhG0qBNCaxzGP8kgU7FPyfmjWwWOk66B0DIXqKn9lgyo2t3IiAI_21_B_R EdED46AuInbFCJpurg2GyiGTukKG34DYgutTfwq2FEzG232IWCWUgeXsksVzWANnDphdZ8skrHr2 9CMMcM1k_yRsMcCpns5cl6T8C9PDvEIxA0K0mucVz9p.N0ZxMD8_abhKgto.NehFDLkRh5KElDZ. Iy05kMNr8z_XDzJwxlDcevK4lbZXVlUCsTUmVZidOPMIvOKgm4JMU1QvwhR3P8pavfSXTHX.KbW1 IrpAO5usRj1Pb3G.URNJehYjP0Uq1Cd2wMB6C5MwcigBw3o7mj6hbM4Yzy1N4QDiKss9IJyXU8Y2 OHpWDH119i9DLguLJd83JHZsa3cPAxkbYFKRwkaPFpnbo5lT2uMUNBknNPumb68wX_mXLDM7jtEH 7wnISAQU1m9tbar8cLgFKYohCx0LpFixIFfqRmcm5AOwBpN1.oYKaeEO4sgcOAHrx8EcoXMfUM9i b_6_y5ftqI5CecUOVHfkmcKdbrSAsmwQKh_QG0gHgIWlSW1YIOdvI7edPpk0sXww8nTeESbAseRX w8PkdShZtX6K4sLJO0RpUDld47bTjD9Ei71NHnfsaJMsXr67LGeLHHQ4b1JqNxLQiEmg4_RInrtd YgZCwEJ0HEGG.bmgTqRsJcXeS7ByYEQMsL7k9ruNIEj.vIGFDhYh48rKQ9CcOD22vzArN0zPvmzG F6r27wBrOI5iZCaZ.0JyEPjYEWrgzyzLakIbCFdWgDSuVTyZf989ACJgA8LMJtfTkaZQAjiTsuzy 7o5bHt3XnHrDVTyOzcJS2j7adI7zsDQ576J76EKyNoKjFYvxsida_vRFJeZYuD7khR.aiWA.Z4O_ 8VSvZzmFLUuHRfjyeJXEExiE61FY4Mblwsm.kJIJo1vW9UXKkHvQp5bvpH8k0gXZfKKCTvuYBQC4 KBPrdeCpdn4t280aV8Kj1mP2z3ivEzjiZmKJ.FmkYbDLN9DezAfB8pODi2AaqWpWFsR4GDgedMGl OfYsAvx6Bl7ZT9K6TsISSIcSALK91jj7rImd4_D_BCDdqVowX8zEIlAYyfIdFw94FBeEDBCxsj0L 4LS2DElcg4wlkt9KsTjYtJwxgncyV6gZs6E.HexOX_bk4gfkZAtgvA4fltvPrzj6z1yXgRLT51fR CSTp0D6B4ZUMTBWagzNwGQKrCmPXhV03d9xO.di9TxEJDngoZwI28_WlNhk6pCAUlHMj2QGTg4Ce ficv9.huHcn67WMo8xRhY_99FodWTz1iLW7UNhvrGUHxI_U9D_1FehLiVxUvSLpEXLFqa.1D_QxA BlpF_fHynFgt2LGagZ8Fjn1nZQ5BiE.ncmJJpj9E2zlPAfmS0zhzu1Yj3dTD4Lj3GvRPeASWKXXT rwXDhAGk7iuWF5LFYiNYhVMVPqWURqJ057NLzb0oaDFmNS.GXNqZn6_9tak0mK9p5CIdziZox8Zp uxZsCHS7E93Oy0SVhWJZyk3kX5hMECcCdsVZCsSt5bfB7.Ru.IfW59ODSbOBiUMBLdFXh0x4ba3G NbUQgtrW07YmBrRn4olJ2OB47Tzb47kS3pFsAUnCDHdyGoPL6jtfw_K0CwRFWa_bfBXFwZKzQuBt lBf.eHAvsbeXGZL9ZXzqyg6QuCujWgcf_CB_b6_nhX.PY66BKagJIsMn1Q766yY5gU6F_1JgjIr9 ONP6an.zhR2V0hsHkEffWsL3PHogjmKFXUeB.JLrwSTquU04ofVKkNFBncnusDjJcfxIAjtBq8E1 FK15BQ6AiR.yvGl6vArN_IawdEtWV4tmgK_5qYzZGUnXgtDP_MWGg4a_ymm3X11kkkaQEuugVB9L AXpcEe9QNu9DsiW_JYWOec7oA2F66rZKleu7L.joGzxv75oY_p1QrUpIEG9ZBuMaBDsyD1Q3DW08 rufoBMz6XfB3wphznXjvRwknNuqPMoz9ygMzLNoN4Nym7b9Hlfxp25o_cGXn7x8Vmu11FVE0.jYy C0A4AYKIoTo22KDTBJQXBXJtrOzVuI23rwWuFMOi4W7XpmBLI5.PA7.R4HAT6gJxP4uuNCPvOmgO 5a2hx6sGpM0cgpmeTDZZj3fBn.C2fPpFoTgbwWHVT82PbT7r5EV4jUTvh_EY5JbSsswZ2UbhxTeX 6.bjnRQ4W.UFCgj2X3lEfWNitizvgITfTGcaoggVqi5KzroDmwyq_GjCVRyCdZbECHqwD3.13He7 ehSMLwLzlBZAiQ2RNYVhYQ.FOHvPP1evZXyUf6sn.akFMm7OINDU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 15 Jan 2021 18:35:47 +0000 Received: by smtp413.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID bb16447bb85ca7e565b5c209a3c5fd8a; Fri, 15 Jan 2021 18:35:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) From: Mark Millard In-Reply-To: <2310709.D6tDg3Ca2R@t450s.local.lan> Date: Fri, 15 Jan 2021 10:35:40 -0800 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4842729.YNO7O01DYZ@t450s.local.lan> <8D35ADAE-8904-4400-9DEB-7B274189BC30@yahoo.com> <2310709.D6tDg3Ca2R@t450s.local.lan> To: Walter von Entferndt X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DHVHT2ZbYz3MlJ X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.205:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.205:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.205:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 18:35:50 -0000 On 2021-Jan-15, at 10:11, Walter von Entferndt = wrote: > At Freitag, 15. Januar 2021, 08:02:49 CET Mark Millard wrote: >> FYI: C itself has, in , CHAR_BIT for the number of bits in = a >> Byte for how sizeof counts Bytes: sizeof(char), sizeof(signed char), >> and sizeof(unsigned char) are each always 1. >>=20 > No, CHAR_BIT is the #bits in a *char*, which is the (standard) = datatype for=20 > the binary representation of a character/letter/symbol in written = human=20 > language, and for small integers. The name also suggests that, as = well as the=20 > comment in the header file. That does not necessarily equal a "byte", = which=20 > (by commonly accepted knowledge) is the smallest addressable entity in = a=20 > computer's memory. Of course, e.g. = https://code-reference.com/c/datatypes/ > char tells a *char* occupies one byte. Sadly, AFAIK C itself does not = define=20 > what a "byte" is, although that term is mentioned many times in = reference=20 > manuals (implicit assumption). So /theoretically/ CHAR_BIT and NBBY = can=20 > differ. In fact, many library funtions operating on = characters/letters take=20 > an *int* instead of a *char* for performance reasons. =46rom = https://code-reference.com/c/stdlib.h/sizeof: "the *sizeof* operator = returns the number of=20 > bytes to be reserved for a variable or a data type". Of course, for = practical=20 > reasons, we can safely assume that a *char* will take one byte in = storage=20 > space for the foreseeable future, since the consequences of changing = that=20 > would be disastrous. Have you read a (fairly modern) C standard or its officially published rationle? You might want to. =46rom the officially published C99 rationale (page labeled 11, Terms and definitions): QUOTE ) All objects in C must be representable as a contiguous sequence of = bytes, each of which is at least 8 bits wide. ) A char whether signed or unsigned, occupies exactly one byte. (Thus, for instance, on a machine with 36-bit words, a byte can be = defined to consist of 9, 12, 18, or 36 bits, these numbers being all the exact divisors of 36 which are not less than 8.) These strictures codify the widespread presumption that any object can be treated an an array of characters, the size of which is given by the sizeof operator with that object's type as its operand. END QUOTE =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Fri Jan 15 18:40:57 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F3BE24EE5E1 for ; Fri, 15 Jan 2021 18:40:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DHVPN02jtz3NF2 for ; Fri, 15 Jan 2021 18:40:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1610736054; bh=Kse2ASgT+6lSD5nh/rA3myZiRuMU7DsK9XloPr7tUj3=; h=Subject:From:Date:To:From:Subject:Reply-To; b=T4S4elvBl9Z8/v899zrAN5xUmJHW6wvAD9+9uvltlnqE2jKXmWKndAwgpMlBKJMtadY4sFFIAW41Js81EnGii/kqfzKO4Fr7zInb8K1FCRt2Qa9WqIuSxjuV/0MZiDpmoa/VM/0Hc6P1TFdU+co1pECEcmuETbEYUJaP540ci/ZUmLC3NkPT+NF4R7KL73RW/JUJZrlGhSHOn88wq2Qwq2rwH9c10Mw6/ZHcEwBlsIREQsOi/AGRVlrz6nmYJGP3fWZyt2My0cGf36hSIHt0MO8DAkcAdzpJsJqAwcvsXZh8Ip4Mnh4rN25FyKhy2aWZMyjRy3QC1vYxK8EzGJaWDw== X-YMail-OSG: DQNd3VkVM1lLleuWYx4rpAo6FRfCQ2pySqo_P3UwviR9qa2qqcjyK.uGCYQb_.B 6TClYyFRmvseiEK07LBSYWNlzyGgaD9TdJlfXEv4wUzDXmiaKIB_6crYF4kcqmaDUymEVtLP3XV4 LJ8b8gtuyuwm2vEB9V8aMYPDtgghQmxgvXpCgIkvcNqTVsLivirOEjyTfh5gGQWQ1YIlpLyLs2Uy xHC9bYueAL9.bjJ.iGqKTeDjalHsc_Y50z9O1fNiaep9UnysMDhDvBpe3gLYku4qf3nR301r8fMh HrqN5E3QrWggSb2HJs20J6at8f9aTqYE1c4upRU6OZ7.qNkYvxUOMcTxwoB_6Qkjk09y_6CxOmP. srMOW.1MM6.eQt08hWgjgMKTKxrAjInTraqMQLZevqLe6ZgVLk_ebjzS919rVNFtHxd8B3meuPEb QkvsSO5SrpGmO5NmdWrY8OlnMcoighnPq12N2Cr7ZPLZerb2IMFk_ez0jvTpoeBG8Ktakjc.KUiS s52w5UEbp0kA.bwag.balHm9t7sNGuhx2wgT785l6G_l6qogZmtFdc6QtZIxu3Us8Fw0ejsDB3kl CAVwLRSIfOXXdTFJqDr5ZXXTk23X4IVbmTB6UBbahq_pV0.ft7HYhSIJ9Euot2zxQX4y8t1SIxDF FxviG9iHHqGu8WDK0ehkBYupSxfUy4TjAHIMeOK.d.BcLyjqNQdGLVzQ8lYqSmKMEVYezOmd0tWx xZSt_dbo.8YxGQ.jOPWzqAcPsc1z6csEJz9nYeGShzImBA7hsLMxu5Z6X4hxXvcCQLBjau864dfj U6i26kjxWka0Ul0qlu47VNlNlcK29c7l.PwOvUtkG.iz6Jd0Chli2EaXCKKYzc.voNlja1BY_y4h o0ScLia2d6z6wD.rsSG7pmRr43TSXUyQ7KhUsyq37bNwE7NiIJux8ToXila9gukDLPxlgJuJRHiL 54w1NHEW.OXEDADFay.uD.QF4cawz_JFPr5_Hx2BN8Xl5_paen0C__hJTaYoeX.2dKpFyL.wjcqJ XdKyZDg6_jeTWNIMTor9QxGbITpgrULfcsttevjkGkHOzRQnxwICD85pGV3jVfseLC5uMQbFDtjx QSEYpXRCC5VzdrrH4_rYsG6DgWhKh5FaeKOQoDrVUpbDo.yjV2HVzpsKey5OkwK39UKq.wAv9345 HsHRSnHhe4iYLi7nAswAETsMbmGdZ8i1YYIWc5e0Mkg.zsnVL_zbaWCC.ZlyGdmGKymo.qSzhRIn QREaR622wos8HTDgc4TIXCtAbncBj4DtI7A25yejsN5QSvC26Z5EzrkaWVPNquyVCoMgOy5STDA_ 7NY38qwP.9qQLSUnfzeZhGt820dxcufiz6NRwrIMRxOGU3BzIukTEMi.n8E.hIX72zduzN.wbadA 6Hra_rmNZ2q.kdTL9A1qozkHUVyTlPfMVX8leMrEQwTgrX.E8tuJTiGWAkF2y4DWbGdN1aaoExkE noCNo3kv5rzY41FC71K4iqxeHNWm_mddPByby98e84ENv2qjvNYTm3P1Hw6eR.i_B3rdG1RUS84q yopwLpTnU0cO3HXN74ZlxbPpsIMQKxNipujt_Z39P_tm2oolLJL.ELO27EC1GUfYXl480rayHYZP W2us720x3dOkkYTVRNNaLNXNhKQHuPCwcjKxmcBf_XMXdGzyz65BmPE_oCE.KEqeIvbjVc_NdhzX A2xjyRwG4_nQw_GiMhhe_9opquqPuIpPeyoMxabvXKBKFoDuySFrL4mM1NpgdMzU0.I3m0W5yMeS Sgzbp8F71SnSQihnJgNWosnzLy0WCbGqpcjm1e93z8pbokOzWuYLhu.304vjKIGY4t0EhM408lH7 JJ4wPa7QGoJp.isSNSnv0WRnSR4xmitxOoV.b41KtlwERFvLtqOp8IZWVozFo3VIkVqCm9U20VQ_ qLx_daa_XvMqK5k.cyPExBPVFzHTVE5Ef_wUz_sF7VG1DLzV6HGE6zkNHLdQQP2WtpzcnNutY71f 9VfJsZ3YPhz7Yqajj9pLQIY6gm9.jPfcIH_RtD08GoxP8qa4Fs.xx5p.ySrrN6b1RLI58MeWyKjY Ou_Wi0TPRoS.mmWnrr1Bk9q6Kl3U99yL09R6V4fIZiFz2cGW5g0nksfVYNXGOlATL7rL0aWA6eW. M0ICNmbXoz_82Bkc9nX.lo3oYQY3WLV5O75PiP0DhfNmJsH5A1PaxHvQievkiydAPWidp8rRqtOt 5A1.tSzIKCllMWAPGsekjJC3uxEJt6DHjH3CR9lUGdhGBbGkSzJE3lFm1s744nUVIIwhUUw3TjnM gFgIM0DYgvIUFGDu.MRFD4_rDibAa5zCEkJt_5xWhIQAA6W35asw6vg0GygQu66pdzSbi1vpTaKd X.VOMK4PGIQwIjkOazf4uUp8awkrn9bdHvwrnHJT9TUVzgCHNHPJiD9yQiZPq_Fe_467Ng7uEopg 9PK1rMeI8LDOfd9b_sKhKYBHpRzj3wIUx_yDnM53hUwebw5.4ypqj17YDV8ak4SyOfaSeD9htF0v 4cqrgp14dJKYPF.fxr4kv2wC24JrvhQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Fri, 15 Jan 2021 18:40:54 +0000 Received: by smtp411.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1a2eb6bb318856141277ebf9917865dc; Fri, 15 Jan 2021 18:40:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) From: Mark Millard In-Reply-To: Date: Fri, 15 Jan 2021 10:40:50 -0800 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4842729.YNO7O01DYZ@t450s.local.lan> <8D35ADAE-8904-4400-9DEB-7B274189BC30@yahoo.com> <2310709.D6tDg3Ca2R@t450s.local.lan> To: Walter von Entferndt X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DHVPN02jtz3NF2 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.83:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.83:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.83:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 18:40:58 -0000 On 2021-Jan-15, at 10:35, Mark Millard wrote: > On 2021-Jan-15, at 10:11, Walter von Entferndt = wrote: >=20 >> At Freitag, 15. Januar 2021, 08:02:49 CET Mark Millard wrote: >>> FYI: C itself has, in , CHAR_BIT for the number of bits = in a >>> Byte for how sizeof counts Bytes: sizeof(char), sizeof(signed = char), >>> and sizeof(unsigned char) are each always 1. >>>=20 >> No, CHAR_BIT is the #bits in a *char*, which is the (standard) = datatype for=20 >> the binary representation of a character/letter/symbol in written = human=20 >> language, and for small integers. The name also suggests that, as = well as the=20 >> comment in the header file. That does not necessarily equal a = "byte", which=20 >> (by commonly accepted knowledge) is the smallest addressable entity = in a=20 >> computer's memory. Of course, e.g. = https://code-reference.com/c/datatypes/ >> char tells a *char* occupies one byte. Sadly, AFAIK C itself does = not define=20 >> what a "byte" is, although that term is mentioned many times in = reference=20 >> manuals (implicit assumption). So /theoretically/ CHAR_BIT and NBBY = can=20 >> differ. In fact, many library funtions operating on = characters/letters take=20 >> an *int* instead of a *char* for performance reasons. =46rom = https://code-reference.com/c/stdlib.h/sizeof: "the *sizeof* operator = returns the number of=20 >> bytes to be reserved for a variable or a data type". Of course, for = practical=20 >> reasons, we can safely assume that a *char* will take one byte in = storage=20 >> space for the foreseeable future, since the consequences of changing = that=20 >> would be disastrous. >=20 > Have you read a (fairly modern) C standard or its officially > published rationle? You might want to. >=20 > =46rom the officially published C99 rationale (page labeled 11, > Terms and definitions): >=20 > QUOTE > ) All objects in C must be representable as a contiguous sequence of = bytes, > each of which is at least 8 bits wide. >=20 > ) A char whether signed or unsigned, occupies exactly one byte. >=20 > (Thus, for instance, on a machine with 36-bit words, a byte can be = defined > to consist of 9, 12, 18, or 36 bits, these numbers being all the exact > divisors of 36 which are not less than 8.) These strictures codify the > widespread presumption that any object can be treated an an array of > characters, the size of which is given by the sizeof operator with = that > object's type as its operand. > END QUOTE I should have reported that my rationale copy (.pdf) is of: QUOTE Rationale for International Standard-- Programming Languages -- C Revisision 5.10 April-2003 END QUOTE =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Fri Jan 15 18:45:29 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 47CAB4EEE2C for ; Fri, 15 Jan 2021 18:45:29 +0000 (UTC) (envelope-from "") Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DHVVc3bRgz3NbV for ; Fri, 15 Jan 2021 18:45:28 +0000 (UTC) (envelope-from "") Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 096AC16005F for ; Fri, 15 Jan 2021 19:45:27 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4DHVVY0hvWz9rxL for ; Fri, 15 Jan 2021 19:45:24 +0100 (CET) From: Walter von Entferndt To: freebsd-hackers@freebsd.org Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) Date: Fri, 15 Jan 2021 19:43:14 +0100 Message-ID: <179047366.Z9jOzuS0a2@t450s.local.lan> In-Reply-To: <8D35ADAE-8904-4400-9DEB-7B274189BC30@yahoo.com> References: <4842729.YNO7O01DYZ@t450s.local.lan> <8D35ADAE-8904-4400-9DEB-7B274189BC30@yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart12097100.5MqMfjp4zD" Content-Transfer-Encoding: 7Bit X-Rspamd-Queue-Id: 4DHVVc3bRgz3NbV X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=posteo.net (policy=none); spf=none (mx1.freebsd.org: domain of mout01.posteo.de has no SPF policy when checking 185.67.36.141) smtp.helo=mout01.posteo.de X-Spamd-Result: default: False [-2.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; CTE_CASE(0.50)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-patch]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_IN_DNSWL_MED(-0.20)[185.67.36.141:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ASN(0.00)[asn:8495, ipnet:185.67.36.0/23, country:DE]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; DMARC_POLICY_SOFTFAIL(0.10)[posteo.net : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 18:45:29 -0000 This is a multi-part message in MIME format. --nextPart12097100.5MqMfjp4zD Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Dear Sirs, the behaviour on signed overflow is /explicitely undefined/ in C... I'd like to kindly suggest to fix the bug instead of fiddling around with compiler switches to compile a buggy program: --- check_mktime.c.patch --- --- check_mktime.c.orig 2021-01-15 03:19:33.962253000 +0100 +++ check_mktime.c 2021-01-15 04:04:22.291014000 +0100 @@ -1,13 +1,16 @@ /* Test program from Paul Eggert (eggert@twinsun.com) and Tony Leneis (tony@plaza.ds.adp.com). */ # include +# include /* NBBY: #bits of a byte */ # include # include +# include /* Work around redefinition to rpl_putenv by other config tests. */ #undef putenv -static time_t time_t_max; +const time_t t0 = (time_t) 1 << (NBBY*sizeof t0 - 2); /* unused elsewhere */ +static const time_t time_t_max = t0|(t0 - 1); /* Values we'll use to set the TZ environment variable. */ static const char *const tz_strings[] = { @@ -106,9 +109,6 @@ time_t t, delta; int i, j; - for (time_t_max = 1; 0 < time_t_max; time_t_max *= 2) - continue; - time_t_max--; delta = time_t_max / 997; /* a suitable prime number */ for (i = 0; i < N_STRINGS; i++) { -- =|o) "Stell' Dir vor es geht und keiner kriegt's hin." (Wolfgang Neuss) --nextPart12097100.5MqMfjp4zD Content-Disposition: attachment; filename="check_mktime.c.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="check_mktime.c.patch" --- check_mktime.c.orig 2021-01-15 03:19:33.962253000 +0100 +++ check_mktime.c 2021-01-15 04:04:22.291014000 +0100 @@ -1,13 +1,16 @@ /* Test program from Paul Eggert (eggert@twinsun.com) and Tony Leneis (tony@plaza.ds.adp.com). */ # include +# include /* NBBY: #bits of a byte */ # include # include +# include /* Work around redefinition to rpl_putenv by other config tests. */ #undef putenv -static time_t time_t_max; +const time_t t0 = (time_t) 1 << (NBBY*sizeof t0 - 2); /* unused elsewhere */ +static const time_t time_t_max = t0|(t0 - 1); /* Values we'll use to set the TZ environment variable. */ static const char *const tz_strings[] = { @@ -106,9 +109,6 @@ time_t t, delta; int i, j; - for (time_t_max = 1; 0 < time_t_max; time_t_max *= 2) - continue; - time_t_max--; delta = time_t_max / 997; /* a suitable prime number */ for (i = 0; i < N_STRINGS; i++) { --nextPart12097100.5MqMfjp4zD-- From owner-freebsd-hackers@freebsd.org Fri Jan 15 19:22:08 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2FB744F031C for ; Fri, 15 Jan 2021 19:22:08 +0000 (UTC) (envelope-from "") Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DHWJv5Kt1z3hhj for ; Fri, 15 Jan 2021 19:22:07 +0000 (UTC) (envelope-from "") Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 1A42A160063 for ; Fri, 15 Jan 2021 20:22:05 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4DHWJr2q2Sz9rxG; Fri, 15 Jan 2021 20:22:04 +0100 (CET) From: Walter von Entferndt To: Mark Millard Cc: freebsd-hackers@freebsd.org Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) Date: Fri, 15 Jan 2021 20:22:01 +0100 Message-ID: <8830694.EFs4ROYVHJ@t450s.local.lan> In-Reply-To: References: <2310709.D6tDg3Ca2R@t450s.local.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 4DHWJv5Kt1z3hhj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=posteo.net (policy=none); spf=none (mx1.freebsd.org: domain of mout01.posteo.de has no SPF policy when checking 185.67.36.141) smtp.helo=mout01.posteo.de X-Spamd-Result: default: False [-2.70 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[185.67.36.141:from]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; R_DKIM_NA(0.00)[]; CTE_CASE(0.50)[]; ASN(0.00)[asn:8495, ipnet:185.67.36.0/23, country:DE]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-hackers]; DMARC_POLICY_SOFTFAIL(0.10)[posteo.net : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 19:22:08 -0000 At Freitag, 15. Januar 2021, 19:35:40 CET Mark Millard wrote: > Have you read a (fairly modern) C standard or its officially > published rationle? You might want to. > Honestly, no. The price to download the official standard PDF from https:// www.iso.org/standard/74528.html is ~200 CHF. If you can send me a link to download a copy, I'd be thankful. Any other good reference manual either in PDF or HTML (tarball or thelike) would also be fine. I showed my source (https://code-reference.com/c/) which I quickly looked up on the net. > From the officially published C99 rationale (page labeled 11, > Terms and definitions): > > QUOTE > ) All objects in C must be representable as a contiguous sequence of bytes, > each of which is at least 8 bits wide. > > ) A char whether signed or unsigned, occupies exactly one byte. > That means it does not make any difference to use either NBBY or CHAR_BIT? Maybe CHAR_BIT is preferable, because it is C standard (guaranteed to exist on all platforms), whereas NBBY is not since it's in include/sys? Beside that, can you affirm the fix I suggested is correct & portable? -- =|o) "Stell' Dir vor es geht und keiner kriegt's hin." (Wolfgang Neuss) From owner-freebsd-hackers@freebsd.org Fri Jan 15 20:57:27 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6B0A04F2D8E for ; Fri, 15 Jan 2021 20:57:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DHYQs3nV2z3pvP for ; Fri, 15 Jan 2021 20:57:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1610744243; bh=VM36DrVieqsPVppApsAm5S4bZ4OkW3L54o6344iKA3t=; h=Subject:From:Date:To:From:Subject:Reply-To; b=dxDdzS3yvZ744fU3nE7S7j+MlbC48SdhhHgb+TvmNhvUnU/ix3HBHn2ngZS1C97IY5uIAlP3QHswBQgmDq6ojtFDOTovBVXOToZBWOe/htbu2go6WAfGgcGMd8tkHNoDy+Xlo1ekSuwRpJCIUrOykZkJMTXhMdqOx5+A9NqsFAxMIWACepPxLHrRp/KslYi7KhrSRoaGF1LJesWx0yn9ZZdpIS/TMkECQoxVdPEREomBgxu49zY6YVW6OT7l3sQ8yUtmwLRU+IF7LW1FaFIBGULwZCqoAMlJOH5sneC8ZvFU3f1XBAFyWqyyETyBsfmtBxd0PmfTUa5DiBQQnpAURQ== X-YMail-OSG: P7ZBQBUVM1n44yuOJ.Ql2ZWqkKdFIgtrCcNY7AJDnUpb7Tu2msNzRcI6pughZaS SajepQskolgGL7ZAmzbUCupfHvo_qd7AT90ZOvNeEAcQzwAIcw8yIeEnzsihDyLPMB1BNhnT6Nai nAIHjBtkHCxBU_WGXouGKOKrqnf0Uy8f9KpQw_0sXrbkb2VTNBYU3vGyfCqYvPQP_n82yqEYIDf7 HmRsp4uziKmqWde3kpVEm.P_m9loS_wNNmbKQo6v7dhIwrYvJKJgAs72VOXrFZ9mTOKpgMjNi5Hq MZvSs4wBsKje7e.1YqCKRiLxWM2YRO4rZUBdhPPGoLphoY6Q1vsJvGfSz66SXdAkJBuny8uC2oO. okdYKZoU_CAhH7OVa0fz2eAoi4TCjerksi5NNLzmPF8yWz.rlnFY2s_F.4WJrWhKvAmmCi3HcX6w qJ.8O1hsZZkYnBFx6YI0OmG35ElhI1hyg5wxaoHDF07tTIbQPXT3QGtsZEOB4Pxg7GiRNg4yXoJ. UG7CzETlMl1zHG0zoZ3lbXo8vuFsJsWgrw9yevpU9oyeh5UnVgd2whso0g.iv7guNRaLGD_GPwIH dhM.Qj9HahG0Lw2XjoPyJyPld.BM0QASTVgy.DhuhEVoKE7bbmsfHFF9P2Cw6S6Uvblh977hXYpa QFMOGYMeDThEwvHT3_QkgG2_oMQzf703LpI.nHhOnHtqYfSf4atHrOt4jEL4kfRyHsu3Nzk_aFaS JlkFT2DdJZRO.36d5XB8d4DidGUoDFLbrRKl9XogFCbCVeqJEtFREzjIkp2fLPlii_87_r3C8qqM 6at46LUNqPHVWveUPKZ9lBWdiFQNhvzlzI3pqfl67XLjwSqKhYoGEgTIPgileifFyNKAzJDYc7hh 4k7JPuABtdLya93NVTnMBAv2NOe9tMWo_7dNVykavAB8Ob1ucHRm18JG40.iLxjPR.94ctDOO2uF jvSUez6fS1xftDd6F1uK95O3XcnB7I.1QwlP_dfRL10dbsibRjr7j0g1JAjAu9_YB7R9W3V2UYuS JUEiQ.iK6SeZLGQdlBIvt1Hr0pi2rktlq1MPX5s9Upx6w.Yd.hZzSiJdfeCfHXslrQV.qhr_WJzk yDOMAQXJdsaChuHMZOg5DjvC209moPmJaqHGQc2o__KH1It3VQQOiOQHgAoE97E.IuIVv_3XJoAX 7_hcF0o8dIgwclqNozvPaBhzoeDfqgevNLwR2_d2XM4u.eQGb7I7MD_f4vQIWRm76R0_MVpuLWEm sbNKSKRfwBg.j4z8HnHQESDJslDuU8hdUYSFLox3KY1ODV9uBqLlpjS4stO8COugHyJItggK3Gd3 lqmhg5937vIf2EecSi61jyB.Qgt4wB8b2runvdjxj06wvEhpIeGQ4GgJGphhP_gtDp9wGwqIUjAk 2ff44JFOs8TRMOT38kjnUqUS5.aClcnYDTO.1ECzYx42QuRouYcMUm1BcEubSOmaIYQChZWEmqqE 5ZRjfXNyJZwNlQ1MElOh5uh.wxETiIpNO4yiVhwuHfGPpCY71Y5SjjporOtnl0A0uvzx1nVFmogo vV5pZBHAlJ7fcuE2h1p5_B4oLNuIIuebCB5Jpm_KNwgoTJsCbw7kbQOfdvSxDAq6BsgfWnGVtEwG 1FoH6reVV8cs55Hb.NBm1eAiz0kACkRqOCPI3iTlHdbKciQaxKQ.N1oFhC_UWsRwzoD6.WA7OdXW Q1fZqEv7yXy34cnoOOZzDXYw8QCTeBgHtgaC6SvubN.m0dXFXynlX7UfMNGVRsIH4jkAKkjQJPTE 3C9CcvOGDUGYjaJzCl14GrawRxqM1szpgLaSlP7DFGhI8QYH_Yx1ExKAJ5XmLC9Uw.xf979X1L4e tODKrTstdpasmYpqq9l95dWHWWUUjaNMtnxHN0BA.Q4mUAIiJtlUvveVbNLxP62X_hHMGaqyDmv2 6ah.6KPWKXmy6hbu0pQLphEcLrbFhQLJIbOByRMzMH5lG.thfaSQTw1ZsVYdP3W3vB4BuDixQ7jz 9yoD18T_8IyWycyII2Ib2ae4V.Nq2HcNgOMhHpL4wkOrRaI5dNMv.yBE.Ehuz6xcMEupDQi6_y4. 7O2PLkP4E4D9FujZYa9uKWLmiEU.1Y1t8q7MKEbkJN5dW_TwzJNcRYJ6kafB_hWe4L64SJIIKy8x 7Xx8VTBUzBXjsX7Xxi.7L8aqLPcppWKPfSk8B2PKbknr5u06lj3vTybpDwY2z0BhlWTKM54B9rtO IGx3z.4FYH8UdPV7Us7aZLpj.vZjuB952.YEgIs3DS65oDRMC2oFm7aGjMr2YL4Cj1OGkjJDpiwj oiWcc.wjf0YBa1Kkf8X6f4sInSjC5r4afjUzM0a5ELkjAZCt8nkLhqOilFDipLHCxolFYtT0p5ZE jTMxKtyQwJhK_3A9MTSzFJucAFow6UNu5X.J0onNW.eVJhKvStcmU_t7suJ1i_xrk8448_2.ZsCc BMDclGWIF1Cf0um4ia8x7BVxKU3siUggKBHt7x9OFEwGaF_Q- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 15 Jan 2021 20:57:23 +0000 Received: by smtp403.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ebb494291fcb57c7589b53b35fc81ff5; Fri, 15 Jan 2021 20:57:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) From: Mark Millard In-Reply-To: <8830694.EFs4ROYVHJ@t450s.local.lan> Date: Fri, 15 Jan 2021 12:57:14 -0800 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4E90FC92-D255-4082-9F89-2BEE4D4C4E92@yahoo.com> References: <2310709.D6tDg3Ca2R@t450s.local.lan> <8830694.EFs4ROYVHJ@t450s.local.lan> To: Walter von Entferndt X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DHYQs3nV2z3pvP X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.147:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.147:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 20:57:27 -0000 On 2021-Jan-15, at 11:22, Walter von Entferndt = wrote: > At Freitag, 15. Januar 2021, 19:35:40 CET Mark Millard wrote: >> Have you read a (fairly modern) C standard or its officially >> published rationle? You might want to. >>=20 > Honestly, no. The price to download the official standard PDF from = https:// > www.iso.org/standard/74528.html is ~200 CHF. If you can send me a = link to=20 > download a copy, I'd be thankful. The rationale vintage that I have a copy of is available at: http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf The rationale is normally a better starting point than the standard for guiding understanding of the standard --but is not normative. What makes the rationale a matter starting point for interpreting the standard is that, while the standard should have the more overall properties documented in the rationale, one has to infer various properties from more detailed rules that were designed to have the properties (and may be better at covering limiting conditions than the more overall rationale material). But the rationale can not be used to answer all questions. As for drafts of vintages of the standard: http://www.open-std.org/jtc1/sc22/wg14/www/projects#9899 has links (the first 4 N???? links) to final drafts (or very-early next-standard drafts) of the standards for C2x, C17, C11, and C99. My understanding is that C17 mostly dealt with clarification requests, other than the ATOMIC_VAR_INIT one leading to depreciating ATOMIC_VAR_INIT instead. As I understand, FreeBSD basically targets C99 (possibly without things made optional or depreciated in C11 or later: future compatibility biased). > Any other good reference manual either in=20 > PDF or HTML (tarball or thelike) would also be fine. I showed my = source=20 > (https://code-reference.com/c/) which I quickly looked up on the net. >=20 >> =46rom the officially published C99 rationale (page labeled 11, >> Terms and definitions): >>=20 >> QUOTE >> ) All objects in C must be representable as a contiguous sequence of = bytes, >> each of which is at least 8 bits wide. >>=20 >> ) A char whether signed or unsigned, occupies exactly one byte. >>=20 > That means it does not make any difference to use either NBBY or = CHAR_BIT? =20 > Maybe CHAR_BIT is preferable, because it is C standard (guaranteed to = exist on=20 > all platforms), whereas NBBY is not since it's in include/sys? I'd say that using C's CHAR_BIT means less variation in the code from = system to system and less knowledge of system specifics required. So in code = not intended to be system specific, CHAR_BIT would be preferred. That does = not cover code intended to be system specific. > Beside that, can you affirm the fix I suggested is correct & portable? Before I could make any grand overall claim about the code, I'll need to take time to think about all of it, instead of just reporting things that I happen to quickly notice while scanning the exchange. I may get to this, but I'm not sure when. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Fri Jan 15 22:26:39 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8FB7D4F45AC for ; Fri, 15 Jan 2021 22:26:39 +0000 (UTC) (envelope-from "") Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DHbPp2qWzz3tvD for ; Fri, 15 Jan 2021 22:26:38 +0000 (UTC) (envelope-from "") Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 1E49616005C for ; Fri, 15 Jan 2021 23:26:35 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4DHbPl1H9Vz9rxM; Fri, 15 Jan 2021 23:26:35 +0100 (CET) From: Walter von Entferndt To: Mark Millard Cc: freebsd-hackers@freebsd.org Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) Date: Fri, 15 Jan 2021 23:25:25 +0100 Message-ID: <5358091.mMMZhaHaU6@t450s.local.lan> In-Reply-To: <4E90FC92-D255-4082-9F89-2BEE4D4C4E92@yahoo.com> References: <8830694.EFs4ROYVHJ@t450s.local.lan> <4E90FC92-D255-4082-9F89-2BEE4D4C4E92@yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart5430162.XOh7uYVVfo" Content-Transfer-Encoding: 7Bit X-Rspamd-Queue-Id: 4DHbPp2qWzz3tvD X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=posteo.net (policy=none); spf=none (mx1.freebsd.org: domain of mout01.posteo.de has no SPF policy when checking 185.67.36.141) smtp.helo=mout01.posteo.de X-Spamd-Result: default: False [-0.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; CTE_CASE(0.50)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-patch]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; HAS_ATTACHMENT(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[185.67.36.141:from]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ASN(0.00)[asn:8495, ipnet:185.67.36.0/23, country:DE]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; DMARC_POLICY_SOFTFAIL(0.10)[posteo.net : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 22:26:39 -0000 This is a multi-part message in MIME format. --nextPart5430162.XOh7uYVVfo Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" At Freitag, 15. Januar 2021, 21:57:14 CET, Mark Millard wrote: > The rationale vintage that I have a copy of is available at: > > http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf > Thank you very much. Now I found that "The result of shifting by a bit count greater than or equal to the word's size is undefined behavior in C and C++" (https://en.wikipedia.org/wiki/Bitwise_operation#C-family ; likewise http:// www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf). So we'll have to go back to the loop-solution with the multiply-by-2: --- check_mktime.c.patch --- --- check_mktime.c.orig 2021-01-15 03:19:33.962253000 +0100 +++ check_mktime.c 2021-01-15 23:22:01.951385000 +0100 @@ -3,6 +3,10 @@ # include # include # include +# include +# include /* printf() */ +# include /* format spec PRIX64: ll/l + X on 32/64-bit arch */ +# include /* CHAR_BIT */ /* Work around redefinition to rpl_putenv by other config tests. */ #undef putenv @@ -106,9 +110,15 @@ time_t t, delta; int i, j; - for (time_t_max = 1; 0 < time_t_max; time_t_max *= 2) - continue; - time_t_max--; + /* portably compute the maximum of a signed type: + * NOTE: << is undefined if the shift width >= word length + * i.e. shifting a 64-bit type by 62 on a 32-bit machine: undef + */ + for (i = t = 1; i < CHAR_BIT*sizeof t - 1; i++) + t *= 2; + time_t_max = t|(t - 1); + printf ("time_t_max = 0x%"PRIX64"\n", time_t_max); + delta = time_t_max / 997; /* a suitable prime number */ for (i = 0; i < N_STRINGS; i++) { -- =|o) "Stell' Dir vor es geht und keiner kriegt's hin." (Wolfgang Neuss) --nextPart5430162.XOh7uYVVfo Content-Disposition: attachment; filename="check_mktime.c.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="check_mktime.c.patch" --- check_mktime.c.orig 2021-01-15 03:19:33.962253000 +0100 +++ check_mktime.c 2021-01-15 23:22:01.951385000 +0100 @@ -3,6 +3,10 @@ # include # include # include +# include +# include /* printf() */ +# include /* format spec PRIX64: ll/l + X on 32/64-bit arch */ +# include /* CHAR_BIT */ /* Work around redefinition to rpl_putenv by other config tests. */ #undef putenv @@ -106,9 +110,15 @@ time_t t, delta; int i, j; - for (time_t_max = 1; 0 < time_t_max; time_t_max *= 2) - continue; - time_t_max--; + /* portably compute the maximum of a signed type: + * NOTE: << is undefined if the shift width >= word length + * i.e. shifting a 64-bit type by 62 on a 32-bit machine: undef + */ + for (i = t = 1; i < CHAR_BIT*sizeof t - 1; i++) + t *= 2; + time_t_max = t|(t - 1); + printf ("time_t_max = 0x%"PRIX64"\n", time_t_max); + delta = time_t_max / 997; /* a suitable prime number */ for (i = 0; i < N_STRINGS; i++) { --nextPart5430162.XOh7uYVVfo-- From owner-freebsd-hackers@freebsd.org Fri Jan 15 22:51:09 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0193D4F4B33 for ; Fri, 15 Jan 2021 22:51:09 +0000 (UTC) (envelope-from dmilith@gmail.com) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DHby40vTqz3vqS for ; Fri, 15 Jan 2021 22:51:08 +0000 (UTC) (envelope-from dmilith@gmail.com) Received: by mail-vs1-xe31.google.com with SMTP id j17so315762vso.9 for ; Fri, 15 Jan 2021 14:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=WEu4rkGtlK0I3IhVy1/SEZ2hcI8lWzRneQSTifuTDMI=; b=VUrINwgx2UtVxD1SrQv6wSWBGPmpirfaAaFe7QPHnp5onebL6BuPujspE5HOdU/XBK e6+rLh9cY0i81PihkynptUNyMYZJOmC/+TBJwDCtjPY4EPS63YEkL5MYfkMBnQOF+wO5 wKQrxSIpudP1XLnG6rglaLlo5vW52WCgymOvN85kOWQef5FH6Zv1kuHfhKavdJhPvwBB N8/4doVl6bqyRjWPg5uJQZ+fULd+TRtZ1+IVJqphwFosRpokjcSxCkQqfiqZprrqTaKL 9fMhNzS2LyzSiMR6DfbHyn58MdZNCxbY3aWoBcIa0LZTXfYodKl/x9CNVvRYO0B2c8Wd 1aoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WEu4rkGtlK0I3IhVy1/SEZ2hcI8lWzRneQSTifuTDMI=; b=ry3Hbx1GVszmMyqZMFldArr7DvIAvG8rcs6RXaNSF1MQtKJe9DRi0P28nQci/6cHvW zcKHvd+m5FQhVptqB7PYkCU2dCNLCVD2FucuBtP7BdRewRva4Y42Bq1GVEcYjfQL46Eg TYGYJQ/dTI6QTotygcZ8w6PBBRy4epXIZBeNgDqgtI3bipPI0LxpcBM3/+K82tSE8dZy uwLusP+zADE7qO7RSWBx625CvmEWt8fYW1u/fdDo3JS2c2G41ufICsokCZntBwi4GjuZ yyWBE74++Z/94dVqFlZ0G5Vjh7qHMbLoFL1EgOCjjhXaF/qJzrFGuHF9YcQkqk3nAgXv NerQ== X-Gm-Message-State: AOAM5305eqq9fLVZg9LJpLT8BIXBxIo/xO816E+Elgj1ujFTKNXQ4g58 oagGHxM68YzruD99Pr9kouJvWPPYHjgs8IhiEiSbBzFbhxc= X-Google-Smtp-Source: ABdhPJwve/SbKChdxBo7r8X4Id8ZJ3tCsG4v2wpgEYoVGZn6qXBO75bz+lhgDGwOE7djpdV/xcm8TXFXhgzqfD23cfk= X-Received: by 2002:a05:6102:21cd:: with SMTP id r13mr12761933vsg.5.1610751066693; Fri, 15 Jan 2021 14:51:06 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a1f:b2d1:0:0:0:0:0 with HTTP; Fri, 15 Jan 2021 14:51:05 -0800 (PST) From: "dmilith ." Date: Fri, 15 Jan 2021 23:51:05 +0100 Message-ID: Subject: Problem building releng/12.2 branch To: freebsd-hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4DHby40vTqz3vqS X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=VUrINwgx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dmilith@gmail.com designates 2607:f8b0:4864:20::e31 as permitted sender) smtp.mailfrom=dmilith@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::e31:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::e31:from:127.0.2.255]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e31:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 22:51:09 -0000 Hello, I'm trying to build releng/12.2 branch on 12.2-RELEASE system and build crashes with: /usr/src/contrib/ofed/libibverbs/ibverbs.h:39:10: fatal error: 'infiniband/driver.h' file not found #include ^~~~~~~~~~~~~~~~~~~~~ ===> lib/ofed/libibumad (obj,all,install) 1 error generated. Is there a way to avoid that problem? Do I have to build a stable system from current? kind regards -- Daniel Dettlaff Versatile Knowledge Systems verknowsys.com From owner-freebsd-hackers@freebsd.org Fri Jan 15 23:13:59 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C45A94F551C for ; Fri, 15 Jan 2021 23:13:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DHcSQ4CJYz4RMB for ; Fri, 15 Jan 2021 23:13:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1610752436; bh=Qw1RcsmnSShlqbXkxJunnyg8yBys7uRjlvcaONyvXF4=; h=Subject:From:Date:To:From:Subject:Reply-To; b=uK3OhktFC4/6+XbmtX5qhQInV0/Hh4kfo6CUXTVWXhKnW68X5vhEBv3uwkfXEhCk+LG0ROcCiUR0Nt14iw3TvdKecxXn574jnSYEmeNSjOBJvEM/0NUaQaYaFDBbVUhU52jGNm7GLvFsryn05JWSV9UnBwhw0U3j/2tFfnDK8CxObxOBR0a9GKakEiNOV/MsFPcKNW65DY54yA/9QuqGGdmO7MkdtnRr9it/M207HYQ1thQ5UQvNqnMEft73n4TZUCwQvT0SdXY2O1QBCHrwMqWn3nPdd7lDOTDzJY4Zh8OSiJefHRm9rCcddbZtzOj+ANHwBJ8brLZ+Du1C64iTzA== X-YMail-OSG: KuisbWsVM1nC6dJkisbpwTJDAE_HuADgkZ94CTIapJdIQFOuqOf.TJL143imBXj CrVpwlqLt2TaHy3oAVqwr.G5dtuWj9dRsKb_OjS7Ooep7vQRYiXA5bnTyva1XLu0ossWqqg3fBkP vQtgSV7zfcqY7uiBCvLPiN6zMPTsr1iZhmFsjhYy54jJaTXbCifyMxHBy9WRIgHr_vVaIltL9Ebf _1pX7NkjJ8_vCzQXYI7V7y_CIn6fqiRUxjzX7vkkRhad79sLLm.12bqpkKDoU3qEglN2S2K2H6TT 7ShtwgnMlJmPL77XjnZ7K85pVMqSC0PcUyFKRyArXfpoS3KKUQltyk6SliTAlWxweatDvYtqTg_1 QNoXj0BTEOCoDGqTDpk9SIW4Fjr4VyYfG4Y3qjJk51MxLbPyf9Y2m0HnsgcTHqC.8YepHp_oMyGz d.UHun5Nt5sXU6jVmcr7yve.9u4AgJXI5GXtX5D6YbXZdhVkvOufi26WLKhuV0_aFBxnjQV350Qo JShqXnn4tnb73bWhIhQ41hvJ9WqARDljwpE_CFSKTlf_2xzxavko1sCK8ASq.oToOeFdui1N5NCK YLXp8riX.wLWqAnsllwo5_kHGd6E9YiHh1WSgGuROi2rclLgCUfxG49cUwm4XOl9k9LZjPZvwwrK 3TaTm3QOHvISHPdi1NaIVOrmbW_g.1s8_XbO32iB5ZRXRQAi1Txv72aX.GqyM2gq5fXWkzM8Mrv2 zOrV.nw_zeGc6zHGIJRhEVxfdPo4DRiN4f1bLqdKb4TrAee4vLgEUHxiZqhOb73WR.HBBHxOsIwo t5R9nNd..MhW7bKKEOcmmz3pzR1ebmi4sOG5rNNMEoQVgo9sjCzGGduW.MS5eD1dd31FlhuNn7m9 9576wmzFkIa.hcwJA5ES0MZiFWMQtTH4JR.ip5V04rPKf4JeNZC9UoTh2YsduLvTgR1RB1TnmY_Z 8ho3p2PenEbfzLk9LvUKo63iafqshhTaINh0qW8dM3gHGm4KLtEFkxrYcTgE6RG4GCtjTxazhaD. .esPcV.LbqGVI3t__yYBbHIOMZWieszEHUcUvyr2O8hBkCtFAIlUaEyPqz7MBFVazbrNggb8UMvi BoLXkywXUVaRCtY0tIliozKafDdI9d1ZQnfFJVrxXdXXCkkvZ8qHWNwBHNO7QN7p9pcZaGQ6ag1D LFe.gqpa_H4LZ_6uZ_cqM6zJd7crkl6zOHeFEfI6Pn8aKhQC3g2kFZly.32EenFpI9t4MXTsaa1O D1N.5cAgJQtvuKqBWOlvF3m_A_8KCaIi3_BXjc8sNv5svWcM98Ysm9cgbgRHb_uTAB5ZaPy.BIj4 2t.cUnTOqwXnG1FvzVoRQVN8WynMkT9T4W5r_dSbTnfLHVLEwE8dvFH1G_3zY6HrC4YxkDAqIPhw MoRg40cvIqeS.aZMsrUSGpeSW9baS8GbaJsLq2yu9UNdtvEO48a4IWcUDE7hu3rbpf97idBbPVRh RFGjKIJSCMtp0W8MK7Cre2EcmEwZpOCLyKc3hxeyd44qC9JwsMISyxdVFIHCB0J3tNRziZBYtQLX OwBUVLH5u0.nyDYnVnckUHaMZjk.8NuwMgBiXktvgXN_SnK.pWxrIypEF6DCCxnEnNRhK18QpdCO U8o3PGE_SvxQUpcCiq7fVpq5N2GEBswev6qC0EZ1nUvN3.dqN5WPi9zTdXvySo5nsRM8xxZK8x61 dGD33xhxGtaH7Vees1YoGhgxxT0o37XT2tRnTHH2W38BS6kAc2K4YqmoEO2.uDfI3ULENi.b7IAZ JYwyDbOvPlTO9sK2p.4RntQMudaQQ8uEBd9crgx6r5WJcDsPtgLQkv0TKPCseOCPfHrUPdZbtGh6 0Qciu62mL.Aa3t.4dc1YBMxV3jLpAt1w0hGNu29jux9dcYf6z6zRp3ru23TIMhg6DclcvOunfTln uj47tX4zhfBEnSR31RQuHG0UqghWilrtupvtJLc8xNYEoG31uT_GFo1tSH5q2HAxo3mj4fEJxh5n YU74_kPzJ5Jo7e1tzyNjd4Yf94o2oTXxEsVMsqKC03WOAjO3ZnjIypQtDZ.oKfnYnaFue6M5elbx 3plzCuCnVYnOyiamVZ1QnV6CAH4Lky7DfIGM6kay603MqecgjNdrgLTfCfrbnCOVSfDcMCgJ.DJm XfxAhj6On2kEXKPbyBhqBsbQ9CxQdu6MTPBTtCHg88p8IgAvJT8Nh8UQ0XUKH4dUifvsHqsxNNY. cP.EFKGw8Bz56RtohEWmy2g8XTavr03HxbFKwO0XsF7VsGEtrmRohaWIVx9a2j.Ph5vxDAnNra_E 0zx5Gp9oGVmPqupFEYgl0pxQayr0Mp5ibtV4zZBg84LZtc8ZDnKfxH.qaqFqWcGGP9MlmTsyPx_u 6wbLxYqwOjS.Y8gj2xnZjrDie9DCkDDoomlgZLNVr4EMG5ZEaDeq5OdEZdEGTjtP2QVP8pTIq8UR PVLKKVSIflmhqkwwV6BblSf_FO02IY8pQcA_xtrpdpe0TP8hB5MDBEZwa28r_XRAybQzGFqqH_Pj KGwpNRcI0AysQ4Lw31P.bR920cok_gQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Fri, 15 Jan 2021 23:13:56 +0000 Received: by smtp420.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1707180ebd8a69d531c51f3cfee1fe5f; Fri, 15 Jan 2021 23:13:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) From: Mark Millard In-Reply-To: <5358091.mMMZhaHaU6@t450s.local.lan> Date: Fri, 15 Jan 2021 15:13:51 -0800 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <37B00E45-ABCC-4C8D-9BF6-C0DC5142F63A@yahoo.com> References: <8830694.EFs4ROYVHJ@t450s.local.lan> <4E90FC92-D255-4082-9F89-2BEE4D4C4E92@yahoo.com> <5358091.mMMZhaHaU6@t450s.local.lan> To: Walter von Entferndt X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DHcSQ4CJYz4RMB X-Spamd-Bar: - X-Spamd-Result: default: False [-1.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.148:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 23:13:59 -0000 On 2021-Jan-15, at 14:25, Walter von Entferndt wrote: > At Freitag, 15. Januar 2021, 21:57:14 CET, Mark Millard wrote: >> The rationale vintage that I have a copy of is available at: >>=20 >> http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf >>=20 > Thank you very much. Now I found that "The result of shifting by a = bit count=20 > greater than or equal to the word's size is undefined behavior in C = and C++"=20 > (https://en.wikipedia.org/wiki/Bitwise_operation#C-family ; likewise = http:// > www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf). The "word size" wording on that wikipedia page is unfortunate and inaccurate. N1570 talks of "negative or is greater than or equal to the width of the promoted left operand". That phrase is not tied to something like 32 on a 32-bit machine. long long is 64 bits wide (or potentially more) and so would allow 0 through 63 based on just this much of the criteria. (But see what follows.) The language standard (various vintages) also tend to talk about "is representable in the result type" vs. not for "<<", as an example. unsigned defines the "not" cases in terms of modulo arithmetic. signed types only define non-negative value left-hand-side cases, and those only when the result "is representable in the result type". signed types otherwise get a "behavior is undefined" classification, or some such wording. The "<<" operation is described via the mathematical multiplication by the power of 2 (the right hand side) as far as what may or may not be "representable". For ">>" and positive values on the left, division by the power of 2 is used. But a negative signed value on the left is described via something like "is implementation defined". For both ">>" and "<<", negative right hand sides result in a "behavior is undefined" classification. > So we'll have to go back=20 > to the loop-solution with the multiply-by-2: > --- check_mktime.c.patch --- > --- check_mktime.c.orig 2021-01-15 03:19:33.962253000 +0100 > +++ check_mktime.c 2021-01-15 23:22:01.951385000 +0100 > @@ -3,6 +3,10 @@ > # include > # include > # include > +# include > +# include /* printf() */ > +# include /* format spec PRIX64: ll/l + X on 32/64-bit = arch */ > +# include /* CHAR_BIT */ >=20 > /* Work around redefinition to rpl_putenv by other config tests. */ > #undef putenv > @@ -106,9 +110,15 @@ > time_t t, delta; > int i, j; >=20 > - for (time_t_max =3D 1; 0 < time_t_max; time_t_max *=3D 2) > - continue; > - time_t_max--; > + /* portably compute the maximum of a signed type: > + * NOTE: << is undefined if the shift width >=3D word length > + * i.e. shifting a 64-bit type by 62 on a 32-bit machine: undef > + */ > + for (i =3D t =3D 1; i < CHAR_BIT*sizeof t - 1; i++) > + t *=3D 2; > + time_t_max =3D t|(t - 1); > + printf ("time_t_max =3D 0x%"PRIX64"\n", time_t_max); > + > delta =3D time_t_max / 997; /* a suitable prime number */ > for (i =3D 0; i < N_STRINGS; i++) > { =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Sat Jan 16 00:26:43 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CCF4F4F6FAC for ; Sat, 16 Jan 2021 00:26:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DHf4L5KCSz4W69 for ; Sat, 16 Jan 2021 00:26:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1610756800; bh=cWd+zYb2Q0HcJSbl6U9Ka3iM0agMm0t3mUL0hXfcpmq=; h=Subject:From:Date:To:From:Subject:Reply-To; b=AuQGbmXZcMXQv36P+m/+BWxjkTua6HmPb+PmV1LB5xnDVSdPtSpqgCvOkKFMqsVH17eC5xk/fczGkNHCoWNhfJse57aq8PmqMU7eGkOYPQkTgaDcZv/5S41/zF9wW42CFqEFgP+OO1phG2rOg4BWJOZ/z2Ga4+ikmnkvrJU/oQBlXor2GcGoOoak95Ghn6qHd9mEnH6dwLqeP4W6oIQwb7JZPpnVG1vlT+WzeOfixrF+dDboxbs32XRzYZYOri055Z/VL1SmfDmLRXAYkr/YBhYGG6jp3VKWUDTmBwmefBuAdRKyXEKu+HNDduMoD7HiK61Fh/I/wqNz+DUKqIyqxQ== X-YMail-OSG: fnkEe5AVM1muud.tUJCsat.vUlrhChpp1paxjJmAoOknruJZpzOIWfeYJYjZMEU _WWopiYxDVIse_XiodS91ELbMrxD8v0pqV6RRwOffHNAa2bKJglUmRZJklbPQsyMxtduwUHLJHmQ bUFXY1KJD0l1ZNQkoJlCjW_5899SmKvLTEKRmcVLyqsBwlyetU6sCcsJJJWiqpAX6O5fByMXC.pz .mFLflbkkT8iD8aprvlf9KlEWAKk.OGD0X8vg7XRgtE8X1EuT8dZoC9tnLiOTcMG217TlbnwiUHr pqXA8aWKr8O4QHHpsj38snxQ9_jQtaOMLJJge8t_6Pa6KIUIzLIno9h1d7dhshm9EuFMuWb.FyfG it9ql.cttAfxKWCXa6pIyusgxhMGaEG.SEy0l0vL9hWxEBisBQtJ9YrFX1N0O7oPEi0Rrmft7yRA 98BvyYpxAE6GH1c0iPAsZJs0l6NL0LW7wg9RJxhLshohaDWdtOKovLC5tP4gq4MeSBYBEokmNhn4 1L._xZaKVOPZIgwsPQhJvGCk4_x6XySssFtyS3xe2E39_.hsi8RU2L4WCGUMhFw3TQas_2egZYaj NH_Nh9g8K2PR0IdZvSuTnWVjdr1_vxAmkJNt5nJYFhohahHIC9aHc_CYSWqboeg0xprbkJbjIB.4 4qT6AO7811c02ZY_uZYu1NUbRFy3D8Ouwd5CtIlp6KlP9K.MoQVhO5mBBRfXtk3sa4P0D_dm7gGm cJHcpRbCOy3opzfz6ev3yXOcQ5G8FsBcnSQKZWh.t.0VjNB.QMEuWmM8UY6wd1HZl3Yt3ritm8dy ANhYRN4X_kpiphKdIBuxd6wKRAshGER9FSIEbiZXyn0XROR5QE179AgDtwCdTTk5wWyDIpLTccaD Uo1zk23UwUeq5BDw.OPBblR4P6qDCvrJgbaRE29TQFCgSjo3SZl7ZWH14I4FVS7cfYEmUQ1HeXYx 5nRNqmZKKX1OLWQRNuWv9RMxEnA0x4YvU.0oJRX_B2aTjI6em6JG9n7g1xfIuNgbteH__TMiOJK6 3IN1RXEqS.m0TjgGuf0OdI3SFOUpLRhz1NqZCop_L5xOapV8QEK33RzCo0BqfPpYuhCZ_rV5xGBc OaJd3GWJQcotnLd7l.NhWEulSJo6pA1yV74EH1KCLssrRk98JlOrQC.ERavqND.uL2CPpgr8ei.j eUnmscMgTIzvDfZfTCGLFSkTiiWyw.1FQ9fK59DyH9hnr0SxZRw0CdwXkNLmqjzIEbMTmdOla16z E3fBZCoEeVb_hmEEcR8vzKhOp9bGbLiwyqqkj9lAN1uVj5MR2nwEHoZvsZZB9sqZ_KejXUpdD8Yd dP3ON7srrlvZwt9SkyMrurWYrWRDWAPWZ7hCSVGdlIQm.K4AgBDAHn_sZbbJNnPdCE_pjSB4sJa6 esN4SGvz.RKnszKSu0utP02yeF5UKqc3d6.6kD6AQebpGOVO2a.OGx3dm3yByqiLR.WZZnjnVyTN JPLBpMcBPKtcpFAt8yX.1AkRB4AjUHnhUmXOEzUTPC.1SAKv1Icbwm6prGPC1.ymNQGSGxOzWd8r qgq3tlpIs_m9hSNnjD2mwaYClzm.weWbeqiUONKXAimaWPnKsp0c4.4qcWRg8I4qqoOrLjE9rUQV _7twhJA.9r.veRw3All2TMxbqF7sphxL9v4WNslRnfFrz2TQEvoTAaePujulCrfi7x4RnCvi5fS2 3RExAd5S5DDqG6SHV5K45OUMGPTHfHfvoqflZdRfpW1aUdyxy9m3ZQHPS_pHZ0t9AcyzMuf7kjTS FxTrWYrOrLo1Bta_AGZFWD.eoyx7T4SqQFdk9d.pTxdEY7YNjtpIWsYTt4o9ZKkgFkz6fS5qCYxE u3d.t7GM3sWJ1XcdQCqa9cZf9_iBDWvsmvflmvMgixM8SeKGhtr3L7.9Vz6oGjlUHK6NUHsu4NZ4 qkAV5eJ4LqXxoaY3ynhHdktyGUbbIjGlQrQdeGvPx7Hpr3ngEvOVAatGUO_YgWZn9t42hLv_44ru jTdU4WPEcv3VgZEXekPyxhlOlZ94YCK3HFIP73J2vc29.c07NtOxIVnFFyvB7dBDxzhiZX9bdCjD _1mmtBl_TUFAh3AV9VqceI0VjhC1sjJOyAiQxCEMqR01djmmkxQBrr3O_M3i_sBIDgR6v7C1uWH3 TT1E0HM8Gy2iXsWJlM6MICLidaRODctm399tXtHrtTwLqwe0XiIHlkRVAQXUsLLsAEvcQaNqyfDz bxxppjfpgmYiW1WVm7a9_aSfRZgyonPEP3qnYz2QmT3S13oo.s56n.wUmJsARV8iKm1s_DBWTB_G aZ7qu0F1LEwtwzFIevqyoELr5V0TfHHerxWIYHv5ZyiXuWtjg9xH_ePzHRZWYmqEezPPZ_1__lz. LotTQgYXOd2XtbsQOC1iX8Od6tOidjMXg13hED9uN5SnGFYyKeT5jKBDcHFo3I.EuJR0qiVQxQfd FHbGmi0Vrg0UpZpwX.wnd4qX07s0oUTEqvqKNgv9L_gh9sdiWaxV2scaN0VeCZBK.xieHEb4Lbcb 6DITSqD86PzG.kWL6ivLTq8kIJX5nXQA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sat, 16 Jan 2021 00:26:40 +0000 Received: by smtp424.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a20b56617c36da7d50b8f21530bf991d; Sat, 16 Jan 2021 00:26:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) From: Mark Millard In-Reply-To: <37B00E45-ABCC-4C8D-9BF6-C0DC5142F63A@yahoo.com> Date: Fri, 15 Jan 2021 16:26:37 -0800 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <7AA78AA9-8010-483F-A33B-C50EA17539F1@yahoo.com> References: <8830694.EFs4ROYVHJ@t450s.local.lan> <4E90FC92-D255-4082-9F89-2BEE4D4C4E92@yahoo.com> <5358091.mMMZhaHaU6@t450s.local.lan> <37B00E45-ABCC-4C8D-9BF6-C0DC5142F63A@yahoo.com> To: Walter von Entferndt X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DHf4L5KCSz4W69 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.206:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.206:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2021 00:26:43 -0000 Walter, you had written: > Beside that, can you affirm the fix I suggested is correct & portable? I'm going to suggest some language generality that you might not want to deal with. N1570 documents such material, as an example. Modern C defines that Integer types other than char, unsigned char, and signed char are made up of: signed types: value bits, pad bits (zero or more), and a sign bit unsigned types: value bits, pad bits (zero or more). There are also things called "trap representations", that includes pad bits possibly being something like a parity bit but there will be some other allowed examples listed below. (unsigned char only has value bits and signed char has one sign bit and the rest being value bits. No form of char has any pad bits. char is like one of the two that are explicit about signed vs. unsigned.) In modern C, signed Integers are limited to: A) two's complement (by far the typical context) B) sign and magnitude C) one's complement For (A) the sign bit being 1 and the rest of the value bits being 0 is either a trap representation or a normal value. (Normal value is by far the typical context.) For (B) the sign bit being 1 and the rest of the value bits being 0 is either a trap representation or a normal value. As a normal value, it is the value called "negative zero". For (C) the sign bit being 1 and the rest of the value bits being 1 is either a trap representation or a normal value. As a normal value, it is the value called "negative zero". I'll note that modern C++ has only (A), with zero pad bits and no trap representations. You might want to target (A) with zero pad bits and no trap representations (all bit partterns being normal values) but still avoiding other undefined behavior and possibly avoiding implementation-defined behavior. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Sat Jan 16 09:12:50 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4292B4D90CA for ; Sat, 16 Jan 2021 09:12:50 +0000 (UTC) (envelope-from "") Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DHslP3Gz1z3LPS for ; Sat, 16 Jan 2021 09:12:49 +0000 (UTC) (envelope-from "") Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 40B632400FB for ; Sat, 16 Jan 2021 10:12:46 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4DHslK3d1pz9rxH; Sat, 16 Jan 2021 10:12:45 +0100 (CET) From: Walter von Entferndt To: Mark Millard Cc: freebsd-hackers@freebsd.org Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) Date: Sat, 16 Jan 2021 10:04:04 +0100 Message-ID: <1725854.nNRVL2rNYg@t450s.local.lan> In-Reply-To: <37B00E45-ABCC-4C8D-9BF6-C0DC5142F63A@yahoo.com> References: <5358091.mMMZhaHaU6@t450s.local.lan> <37B00E45-ABCC-4C8D-9BF6-C0DC5142F63A@yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Rspamd-Queue-Id: 4DHslP3Gz1z3LPS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=posteo.net (policy=none); spf=none (mx1.freebsd.org: domain of mout02.posteo.de has no SPF policy when checking 185.67.36.142) smtp.helo=mout02.posteo.de X-Spamd-Result: default: False [-3.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[185.67.36.142:from]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8495, ipnet:185.67.36.0/23, country:DE]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; DMARC_POLICY_SOFTFAIL(0.10)[posteo.net : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2021 09:12:50 -0000 At Samstag, 16. Januar 2021, 00:13:51 CET, Mark Millard wrote: > > Thank you very much. Now I found that "The result of shifting by a bit > > count greater than or equal to the word's size is undefined behavior in= C > > and C++" (https://en.wikipedia.org/wiki/Bitwise_operation#C-family ; > > likewise http:// www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf). >=20 > The "word size" wording on that wikipedia page is > unfortunate and inaccurate. >=20 > N1570 talks of "negative or is greater than or equal > to the width of the promoted left operand". >=20 Thx for the clarification. That means the compute-at-compile-time solution= =20 would be ok, if there were not... At Samstag, 16. Januar 2021, 01:26:00 CET, Mark Millard wrote: [... about pad bits, trap representations, and 1's-complement ...] Hallelujah. I did not know that integer representations other than 2's- complement are allowed in C, and did not take into account these other=20 pitfalls. I've heard of that long ago, but forgot about it. 1's-complemen= t=20 is obviously no problem as long we're dealing with non-zero positives. And= I=20 did not find anything about the order of any padding bits and the sign bit,= =20 but I'd strongly assume the sign bit is always adjacent to the value bits? = =20 At least, no arithmetic operation can alter padding bits (not even a shift)? https://duckduckgo.com/?q=3DSEI+CERT+C+Coding provides a simple /popcount()= /=20 routine to portably detect padding bits for any integer datatype when given= =20 it's maximum value. That could be useful. If INTMAX_MAX has N padding bit= s,=20 do all other integer types (except *char*) have the same #padding bits? Can we safely assume this: a *time_t* is either a *long long* iff *long lon= g*=20 is supported and it's a 32-bit arch, else *long*? Or can it be of any of t= he=20 minimum- or least-width integer types? Or is a *time_t* always of *intmax_= t*?=20 In the latter case, this gives us a very simple solution: #include static const time_t time_t_max =3D INTMAX_MAX; Or do we have to come up with adjacent probing =C3=A0 la: #include #include #include if (sizeof(intmax_t) =3D=3D sizeof(time_t)) time_t_max =3D INTMAX_MAX; else #ifdef __LONG_LONG_SUPPORTED /* is this macro portable? */ if (sizeof(long long) =3D=3D sizeof(time_t)) time_t_max =3D LLONG_MAX; else #endif if (sizeof(long) =3D=3D sizeof(time_t)) time_t_max =3D LONG_MAX; else if (sizeof(int) =3D=3D sizeof(time_t)) time_t_max =3D INT_MAX; else { fprintf (stderr, "What the heck is going on?\n"); exit (EXIT_FAILURE); } But reading the standard: time.h declares *clock_t* and *time_t* wich are / real types/ ... and: "The integer and real floating types are collectively= =20 called /real types/." Now I'm out. Bye. I tried to be helpful, but this = is=20 too much... =2D-=20 =3D|o) "Stell' Dir vor es geht und keiner kriegt's hin." (Wolfgang Neuss) From owner-freebsd-hackers@freebsd.org Sat Jan 16 09:53:04 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 30A164D9C50 for ; Sat, 16 Jan 2021 09:53:04 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DHtdq35cfz3MS9 for ; Sat, 16 Jan 2021 09:53:03 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 6F4CF26044C; Sat, 16 Jan 2021 10:52:55 +0100 (CET) Subject: Re: Problem building releng/12.2 branch To: "dmilith ." , freebsd-hackers References: From: Hans Petter Selasky Message-ID: Date: Sat, 16 Jan 2021 10:52:44 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DHtdq35cfz3MS9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[88.99.82.50:from]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[88.99.82.50:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2021 09:53:04 -0000 On 1/15/21 11:51 PM, dmilith . wrote: > Hello, I'm trying to build releng/12.2 branch on 12.2-RELEASE system > and build crashes with: > > /usr/src/contrib/ofed/libibverbs/ibverbs.h:39:10: fatal error: > 'infiniband/driver.h' file not found > #include > ^~~~~~~~~~~~~~~~~~~~~ > ===> lib/ofed/libibumad (obj,all,install) > 1 error generated. > > > Is there a way to avoid that problem? Do I have to build a stable > system from current? > Maybe you need to do: make installincludes first, to get your /usr/include directory updated. --HPS From owner-freebsd-hackers@freebsd.org Sat Jan 16 10:23:14 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E8E6E4DAB81 for ; Sat, 16 Jan 2021 10:23:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-54.consmr.mail.gq1.yahoo.com (sonic308-54.consmr.mail.gq1.yahoo.com [98.137.68.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DHvJd2JRlz3P1J for ; Sat, 16 Jan 2021 10:23:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1610792591; bh=joVLyDPEim9urM2GeHQ4Ksj+Us/1BC/umHbf5DEbvD5=; h=Subject:From:Date:To:From:Subject:Reply-To; b=R0NI929bq0LlsQ4DUIVxfjow9xVzjzGaaXsR/oc819gthx/S7Rwo3nMNu+rW+bUg5CK2ir3lRzyAAZ2rkooaG19E7pgTUmZka62f6TjdrQzIRXsVJTkj1w9FCplc+FgytbSGGWAT1GYa1EH9h7zhmTZ+k28bbi+C25nwSRcalwRMsS3nQDx3gPCDkwD6HDJvXk4BavIIroaj3bSYneCKShJy4lwNdH8/JfwbkkAm4SqMAkl3jBZvuwgPCUDKv9qT4+Mxu4XSFWgO6Cc44SuL6nEn5yLLSVikhMD6Sja2kM5kyaL8F56MqVYrJZ3SkFI5cTzExBSrXE7oYtNfY/hOPA== X-YMail-OSG: A9C6Lk8VM1nu7M8n5sWgzBKlFPkfvznXH8qooZx3qR91vn0GpA8Dj60ru5oYo9y WJ5iD_3VV3v.H4qmvkfkIWez_eMwo2siZ0bqqfcIO1sE34eRizx7kvqSeQya4HNDmciApODn1mog pcXnWgrl1nzSc.CxBfqta8y4smNY9kW._tkJu.aZTehfIan_60rxlF23GwZgR.CnuMXSXTfsKX1s IGvyDAUINzDH1Mdw1TwYspy9WEnPKa7V_K7P6fslRFt45kEJi2amL6Ndyl.X4Z99a.V5WtPOclP9 z5OsOB2xj_jqaMGfoBIP0F6d8y1zMdrmTBhuxRryvb.O0X9j9MlUNiWSHV65VDCQNW8fZRG9QwDu 7MqwhoEwTSYitdlu5p0BZvYlKV24l6IhBiLyPqLQvKZDkYJRzes43zy67b5ml9MGot6c0AtJxZ4a soWrqKxMmjQI3AcxaJNTN3OcJieX0SCTkdtRzecq3_FTWSjlqJ258y.qn2lnSXsOGa7rsSOIrZvr tEKVTdrDKD.09JyW46A4tnVHu0Nb0uC0Pi.vNB9LkzU97Vx3oJgNK8HJu6Tlgb4RYhdYrG4ywiz5 K32u2io69FdS7ukRSVPVxKgy7QPG0IXjHefB46BUVdxoaRyhxuzOSY_LFIAJrlSv_p_1GJM5iObR _XkSxlQBq40tN.Ru1Kb94a3_NnVT_ctBL_iqj_T.XHwz8bsutTozzbgXHV11HTmjkMg7Bhwc0Gr0 3N95YpSM5f4JMUiHruHsfBI_quVxqZb_WQMG9bZqduQ2b5T_M9NKrpSYwdCgU95H0bx1FfW4y_tE gguvJkgJZBo4.Aos6zF9hKdSuwo7NV6l7oYpEUSRV3jeN4JGHLVV1ZfU0l2b41r3dvj3MMVAztNh Q5XQKYEU4ONtFWaTDwb69w2WD30OaXff7yhW_w4ky7v0Vg9MsiOrcwdv8DpFwgu2r4FEzbLfjFLI QphChtNZr3S4xtm4MxkLBkMr7ORyjYUOlmsaLnnJmlH3WkhgJuzMgkAdNB0n6qQKwk4Xvqqv5Si3 _7dLzwHb62DZkkQZ5h2YcCwcasHWDlsCB07dSY2n8kkDICY7eia.q53coO7yNi4o4hS876996tPg geHGqX_4KOimgs4DEADheBxKBkIZ0Ek5.CdYR.hwJfld5k8GOI9NWklJivDx2psewJXv5qhgIk7y ZrPLRRmfZe2H7fjzfk4q2HuTvidz46GNqkkp93ImIVO5dPS8prUElSGr0TKrbNQimXi41AFdomt2 EF2k79QzePDVe07oLqy1HsDBTM0XB5F4MLbCbYjGSXbrWP8LydvI0DS9UdTjR4UDZaI_73sVUYYE aWZPKBHZlRR27tyBCGzehoPaC_R0N0kT4icCK5G_hGIEQX.ONl8.hgVmZym8WOklMrBDlJ7xLMRp TbZ1pp1rMCVSanaN66s.r9T1TbOIstUWcRvYyaE8O0JzK5RaUCEFbUUj8ep9PtSiTquGkiUHG7I_ gHWbmqBLZCxNOxFKgutiQCjSZa2_HvU9yuYU7FBToTzLfMjNxwOlKBZnCL2OEojdrBv.xGOsSzzt thoJDiBzk3NXMl2zPjozkPHKRIBYxzO64bQ73nwgJW9f1hV5mPYFF2skk3WD97HF.8hzmBkJKCH1 sADPDfZKjqrWUZaUzTftlbXrYzWn0Eoqms7kDsGZiBo1soHtddF6l5SC5MBjrb0eM62yxhJN.im4 5zYLDNTWnVJj2pRAgBW.jzNk0eePsILL1_wJ_037SBOn9VuoMgZiVvRNIVKXCseJGB.wYg9baCss _sv0LIxJe9SaKvvxMktriMOg1Eh3ET2G3NtAIsnSkh9CBw.6QTBLmndj0QrJLdzFrhofirVNePag yjnJ9OCXD38BwJZPrB3IzvlM8JcKT59F_EAdcqjXFJ1121faJYwI.aEeSplGfvZOKZKFVPAFcFBy l9kkWtdFm7fXEMoYbIL9h_PNqacqqTan43XobMfzh95oQlEPROoD.sr3hTb9CsLrfrhq4EDQCA6v qtoYm1VeF7UUwCpdjDdF8juPHyliqFRT2KT.wZASt8cq89bZuwWkNxFABCoNAKQkw3MIwq3A5sEE Vnf1dl8uKc1kbIO_ixWLMfemeyc2q5E5JSOppYEUp63zhsr31BuM76yjpg832KjC3cZj1GS1eIOV .y7V5zO1z7_JSbVKAMQNLwrz1zivs9sjRXKogfxdprORBujzX0sPOWdf8nlQ4dtShr7nsc2eDvbq z5LcDqkBmoq7_RJmPqQsWt7IdfmkbWriStq4bPxjSKh1Ey8ic7V_havWWXc8XmisTf1QhYQWVq8o IUP49PtG3A5OrPXzIjZ59i1miSSY1RhWN_DROxsGe3tSm8x4O73tEko20.LxazCH_NRJiBJIjaw5 7rSN5IOr0fgyt9_l4LT4.alYHKfXhnedhszhDjlmOwl0tWJVn4WOVbEw9lcU4w3HMf4SSCb5o6sh 4b7AQfi6HYeIBiJSS1YPe67R40uMc3574RcgntL_uQa5Kv3RHnkTHpQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sat, 16 Jan 2021 10:23:11 +0000 Received: by smtp414.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9f7b39ad2a171aee68eba2b1b5c4fe24; Sat, 16 Jan 2021 10:23:05 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) From: Mark Millard In-Reply-To: <1725854.nNRVL2rNYg@t450s.local.lan> Date: Sat, 16 Jan 2021 02:23:03 -0800 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7623BADF-5FA9-4712-8D85-A1D2B82E3F74@yahoo.com> References: <5358091.mMMZhaHaU6@t450s.local.lan> <37B00E45-ABCC-4C8D-9BF6-C0DC5142F63A@yahoo.com> <1725854.nNRVL2rNYg@t450s.local.lan> To: Walter von Entferndt X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DHvJd2JRlz3P1J X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.30:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.30:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.30:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.30:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2021 10:23:15 -0000 On 2021-Jan-16, at 01:04, Walter von Entferndt wrote: > At Samstag, 16. Januar 2021, 00:13:51 CET, Mark Millard wrote: >>> Thank you very much. Now I found that "The result of shifting by a = bit >>> count greater than or equal to the word's size is undefined behavior = in C >>> and C++" (https://en.wikipedia.org/wiki/Bitwise_operation#C-family ; >>> likewise http:// = www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf). >>=20 >> The "word size" wording on that wikipedia page is >> unfortunate and inaccurate. >>=20 >> N1570 talks of "negative or is greater than or equal >> to the width of the promoted left operand". >>=20 > Thx for the clarification. That means the compute-at-compile-time = solution=20 > would be ok, if there were not... >=20 > At Samstag, 16. Januar 2021, 01:26:00 CET, Mark Millard wrote: > [... about pad bits, trap representations, and 1's-complement ...] >=20 > Hallelujah. I did not know that integer representations other than = 2's- > complement are allowed in C, and did not take into account these other=20= > pitfalls. I've heard of that long ago, but forgot about it. = 1's-complement=20 > is obviously no problem as long we're dealing with non-zero positives. = And I=20 > did not find anything about the order of any padding bits and the sign = bit,=20 > but I'd strongly assume the sign bit is always adjacent to the value = bits? =20 > At least, no arithmetic operation can alter padding bits (not even a = shift)? > https://duckduckgo.com/?q=3DSEI+CERT+C+Coding provides a simple = /popcount()/=20 > routine to portably detect padding bits for any integer datatype when = given=20 > it's maximum value. That could be useful. If INTMAX_MAX has N = padding bits,=20 > do all other integer types (except *char*) have the same #padding = bits? >=20 > Can we safely assume this: a *time_t* is either a *long long* iff = *long long*=20 > is supported and it's a 32-bit arch, else *long*? Or can it be of any = of the=20 > minimum- or least-width integer types? Or is a *time_t* always of = *intmax_t*?=20 > In the latter case, this gives us a very simple solution: >=20 > #include > static const time_t time_t_max =3D INTMAX_MAX; >=20 > Or do we have to come up with adjacent probing =C3=A0 la: >=20 > #include > #include > #include >=20 > if (sizeof(intmax_t) =3D=3D sizeof(time_t)) > time_t_max =3D INTMAX_MAX; > else > #ifdef __LONG_LONG_SUPPORTED /* is this macro portable? */ > if (sizeof(long long) =3D=3D sizeof(time_t)) > time_t_max =3D LLONG_MAX; > else > #endif > if (sizeof(long) =3D=3D sizeof(time_t)) > time_t_max =3D LONG_MAX; > else if (sizeof(int) =3D=3D sizeof(time_t)) > time_t_max =3D INT_MAX; > else { > fprintf (stderr, "What the heck is going on?\n"); > exit (EXIT_FAILURE); > } >=20 > But reading the standard: time.h declares *clock_t* and *time_t* wich = are / > real types/ ... and: "The integer and real floating types are = collectively=20 > called /real types/." Now I'm out. Bye. I tried to be helpful, but = this is=20 > too much... This is the sort of thing where FreeBSD and Linux use a C subset for the specific issue, as defined by POSIX.1-2017/"The Open Group Base Specifications" Issue 7, 2018 edition/IEEE STd 1003-2017/... . For example: = https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html= reports (in its own terminology that may not be a full match to C's): QUOTE clock_t shall be an integer or real-floating type. time_t shall be an = integer type. END QUOTE Limiting to such a time_t is easier to cover. (Note: POSIX in parts is a superset of C as well.) One of the things about standards: there are so many to choose from or to mix and match. Or as some of the pages put it: QUOTE The functionality described on this reference page is aligned with the = ISO C standard. Any conflict between the requirements described here and = the ISO C standard is unintentional. This volume of POSIX.1-2017 defers = to the ISO C standard. END QUOTE Restricting time_t to integer types leaves a compatible context. So: no "conflict" in that respect. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Sat Jan 16 15:15:45 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2F7994E1D5E for ; Sat, 16 Jan 2021 15:15:45 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DJ1p90KKTz3wH7 for ; Sat, 16 Jan 2021 15:15:45 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 0531C4E1F11; Sat, 16 Jan 2021 15:15:45 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 046D04E1E11; Sat, 16 Jan 2021 15:15:45 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJ1p86R8Xz3wFG; Sat, 16 Jan 2021 15:15:44 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1610810145; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=EUcutSG1wne0Qa92WM+TqNAuMgRv3i5KBtmsr83LceY=; b=YkJI5kohOLuhXD0NgiLTXAARRk1JUprrZWcCSYq1/uBmUT4k7by1b7azN2Gha6UDd1MACX 9OFndfMSqBh93Ee1mru/v+NRZBhfBdHuiCz62Z9nxw5DqGVPBFBz7fMtCOSw5YlX3cZXO2 dmqILT1rcteYG9oh3wpSIvj+g27la3afxn/z4zpFUE5NpLDD3+YJyNPS70vCBx+Su72vnj c+qHIT1Nlu/7Ahu9u5Pd9RX3UblLy+OCoZIhlnNrB27pbooFNESppBlb0BR84vdHiuILHd zcXvjnKn/L9lWTdIXNmT15bw6OeORX+57jEzrih+bnBMw+Mx5roHKJOwAvatCQ== Received: by freefall.freebsd.org (Postfix, from userid 1471) id D0BEA17DC3; Sat, 16 Jan 2021 15:15:44 +0000 (UTC) Date: Sat, 16 Jan 2021 16:15:43 +0100 From: Daniel Ebdrup Jensen To: hackers@freebsd.org Cc: current@FreeBSD.org, stable@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Fourth Quarter 2020 Message-ID: <20210116151543.6oroumphxvcgyxbu@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , hackers@freebsd.org, current@FreeBSD.org, stable@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zy55m5us4qgrxnhl" Content-Disposition: inline ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1610810145; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=EUcutSG1wne0Qa92WM+TqNAuMgRv3i5KBtmsr83LceY=; b=jsE+beqb/RlbLnSY1LGEZAuAYryv2oEXZ+vWnRYVhFbk8+DovZlIC+dDiPw8bBjqr/yGOO 5oiWA4yImP6Ba0OO29bEcUiU/3MrXFnBGQbfEOHAqrFztX0aS4iZIikcU91CszpGYuCh8O Y1LwmvYQ3nAfouHoyqBu8iQvzNCFneOEs9cNofaLjMI2X+6W04L8aOTs3iBof/k7FGzzQ3 FeAAj9fRETlkAEqzOrWjIizRgO49d7bXCNOKMpWjeU21g28C6lhIt2dJFzN4ai9DBs8Tun /CwVOUzk5S+N2B2DoQssQkncblKZTeADnhI6Em1Q2ZQhmAa1XyuvMx6HWdkD7Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1610810145; a=rsa-sha256; cv=none; b=WiWl/dHrGZAvkloLMv0kPlD1Gyyj0HH2wlIjYUXwqncaUMv2tJFgHlD5eJAv/9oIrlT+ku hUMpeNjDbZfygr7IqzYNg+KcUIREZPPPrJZ1H0P8L2bRK/ODwgQBp/ihreoJfRzSbCi6H0 d5lNjSurx6oHNj3ETHdwGX+XZX/s3bMGEe/OGbqaZse3fzTl5b2+jWnE6txNN1u9AZO8md IGy68xTmVSYA2ZzdiloT9PmrQRJUjzRqd8rZoUEu9Ra4MGljeAF/7cOCqj4tIXap6cqlkp ZPw4SSk2TnFrmfw/UT7m+r1LWFYWGDl2DWGGP7bJ5i484TDlwG15KUFNsc8thg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2021 15:15:45 -0000 --zy55m5us4qgrxnhl Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD Project Quarterly Status Report - Fourth Quarter 2020 Introduction This report covers FreeBSD related projects for the period between October and December, and is the fourth of four planned reports for 2020. This quarter had quite a lot of work done, including but certainly not limited to, in areas relating to everything from multiple architectures such as x86, aarch64, riscv, and ppc64 for both base and ports, over kernel changes such as vectored aio, routing lookups and multipathing, an alternative random(4) implementation, zstd integration for kernel dumps, log compression, zfs and preparations for pkg(8), along with wifi changes, changes to the toolchain like the new elfctl utility, and all the way to big changes like the git migration and moving the documentation from DocBook to Hugo/AsciiDoctor, as well as many other things too numerous to mention in an introduction. This report with 42 entries, which don't hold the answer to life, the universe and everything, couldn't have happened without all the people doing the work also writing an entry for the report, so the quarterly team would like to thank them, as otherwise, we wouldn't have anything to do. Please note that the deadline for submissions covering the period between January and March is March 31st. We hope you'll enjoy reading as much as we enjoyed compiling it. Daniel Ebdrup Jensen, on behalf of the quarterly team. __________________________________________________________ FreeBSD Team Reports * FreeBSD Foundation * FreeBSD Release Engineering Team * Cluster Administration Team * Continuous Integration * Ports Collection * Office Hours Projects * GPL in Base * Git Migration Working Group * Linux compatibility layer update * LLDB Debugger Improvements * Upstreaming NetApp Changes * NFS over TLS implementation * OpenBSM Synchronisation * Tool Chain Kernel * ENA FreeBSD Driver Update * Intel wireless update * Fenestras X random(4) * pf performance improvement * IP Routing lookup improvements * Scalable routing multipath support * Thunderbolt3/USB4 stack * Vectored AIO * ZSTD Compression in ZFS Architectures * arm64 platform updatesq * FreeBSD/RISC-V Project Userland Programs * Dual-stack ping command Ports * KDE on FreeBSD * FreeBSD Office team * Ports On Non-x86 Architectures * Python 2.7 removal from Ports * Xfce on FreeBSD Documentation * FreeBSD Translations on Weblate * DOCNG on FreeBSD Miscellaneous * Prometheus NFS Exporter Third-Party Projects * FreeBSD Aarch64 under VMWare ESXi-ARM Fling * Bastille * CheriBSD * Embedded Lab Project * helloSystem * K8S-bhyve * Puppet __________________________________________________________ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Foundation Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases and supports hardware to improve and maintain FreeBSD infrastructure and provides resources to improve security, quality assurance, and release engineering efforts; publishes marketing material to promote, educate, and advocate for the FreeBSD Project; facilitates collaboration between commercial vendors and FreeBSD developers; and finally, represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: COVID-19 Impact to the Foundation Like most organizations, we transitioned all of our staff to work from home. We also put a temporary ban on travel for staff members, which didn't affect our output too much, since most conferences went virtual. We continued supporting the community and Project, even though some of our work and responses may have been delayed because of changes in some of our priorities and the impact of limited childcare for a few of our staff members. Partnerships and Commercial User Support We help facilitate collaboration between commercial users and FreeBSD developers. We also meet with companies to discuss their needs and bring that information back to the Project. Not surprisingly, the stay at home orders, combined with our company ban on travel during Q4 made in-person meetings non-existent. However, the team was able to continue meeting with our partners and commercial users virtually. These meetings help us understand some of the applications where FreeBSD is used. An event we help plan and organize, that helps with vendor/developer engagement, is the annual Bay Area Vendor Summit. We weren't going to let a pandemic stop us from holding this invaluable yearly event, so we went virtual! From the feedback we received from the vendor community on how we should run this, so it would be beneficial for them, we decided to hold this over 3 half days in November. One unexpected result was that more commercial users from around the world attended. Since a Vendor/Developer Summit is typically invitation only, we opened this up to FreeBSD contributors from around the world to watch the livestream. Because of the success and excitement of this event, we are planning to hold another one around June or July. Fundraising Efforts We want to take a moment to say thank you to all the individuals and corporations that stepped up to help fund our efforts last year. As of this writing, we raised $1,235,926, and will have the final tally by mid-January. The companies that gave generous financial contributions include Arm, NetApp, Netflix, Juniper Networks, Beckhoff, VMware, Stormshield, Tarsnap, and Google. We also want to say thank you to the Koum Family Foundation for awarding us a large grant, and to "the employees of Ngnix" who also made generous financial contributions. We truly appreciate these large contributions, which makes the most impact on how much we can contribute back to the Project. However, it's the individual donations that have the most meaning to us. Those are the folks who are giving because they trust we will invest their personal donations, whether large or small, into improving the operating system and Project. As stewards of your donations, we want to thank you for your trust in us and your commitment to making FreeBSD the best platform for products, education, research, computing, and more. You'll find out how we used your donations for Q4 in our report, as well as in individual reports throughout this status report. Though we know this is a Q4 status report, we are excited about our plans for 2021, including growing our software development team! We'll be posting two job descriptions for a Senior Software Developer and Project Coordinator soon. Please consider making a donation to help us continue and increase our support for FreeBSD in 2021: https://www.FreeBSDfoundation.org/donate/. We also have the Partnership Program, to provide more benefits for our larger commercial donors. Find out more information at https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/ and share with your companies! OS Improvements The Foundation provided many project grants over the last quarter, and you can read about OpenZFS Zstd support, Linuxulator application compatibility improvements, LLDB target support, test lab infrastructure, and WiFi projects in other entries in this quarterly report. The Foundation hired six co-op students from the University of Waterloo during the 2020 fall term, as well as one intern. Former co-op student Tiger returned, and new students Yang and Zac joined us for the first time. Tiger worked on improvements to the code-coverage guided kernel fuzzing tool Syzkaller, adding new system call definitions so that Syzkaller can expand the code it tests. A number of FreeBSD kernel bug fixes have already resulted from this work. Tiger also contributed a number of improvements to the ELF Tool Chain set of binary utilities, and worked on tooling to run tests from other tool suites against ELF Tool Chain. Zac worked on an improvement to the pkg package management tool, investigating and upstreaming patches for FreeBSD support in FreePBX, and investigating compiler support for addressing the stack clash vulnerability. Yang investigated and fixed a compilation bug with the kernel's Skein-1024 assembly implementation (used by ZFS), and then a number of projects related to Capsicum: applying Capsicum to sort(1), implementing a Capsicum service to execute utilities, and finally working with developers of the Game of Trees (got) version control system to adapt it for Capsicum support. Our intern Ka Ho focused on improving the desktop experience of the FreeBSD. He fixed and improved many items of OBS (Open Broadcaster Software) on FreeBSD, worked on FreeBSD native audio support on Firefox, adding a facility that user-space audio programs could make use of to enumerate a list of audio devices. He also ported the fcitx5 input method framework. The five Foundation staff members continued contributions in 2020 in both ongoing operational tasks (including the Git working group and security team) and software development for a number of projects. Staff members responded to reported security vulnerabilities and release errata, prepared patches, and participated in the security advisory process. We also worked on proactive security vulnerability mitigations. Syzkaller also provided many reports of kernel issues that resulted in Foundation-sponsored bug fixes. We worked on several issues relating to FreeBSD/arm64 to move it along the path of being a Tier-1 architecture. We participated in code reviews and supported community members in integrating changes into FreeBSD, and triaged incoming bug reports. We contributed enhancements to many kernel and userland subsystems, including the x86 pmap layer, ELF run-time linker and kernel loader, the Capsicum sandboxing framework and Casper services, the threading library, some RISC-V changes, the build system, tool chain and freebsd-update, network stack stability improvements, machine-dependent optimizations, new kernel interfaces, DTrace bug fixes, documentation improvements, and others. ### Continuous Integration and Quality Assurance The Foundation provides a full-time staff member and funds projects on improving continuous integration, automated testing, and overall quality assurance efforts for the FreeBSD Project. During the fourth quarter of 2020, Foundation staff continued improving and monitoring the Project's CI infrastructure, and working with experts to fix the failing builds and the regressions found by tests. The work was focused on pre-commit tests and development of the CI staging environment. The other main working item is working on the VCS migration to change the src and doc source from Subversion to Git. There are also many work-in-progress tasks like analysis and improve the tests of non-x86 platforms. See the FreeBSD CI section of this report for completed work items and detailed information. Supporting FreeBSD Infrastructure The Foundation provides hardware and support to improve the FreeBSD infrastructure. Last quarter, we continued supporting FreeBSD hardware located around the world. We coordinated efforts between the new NYI Chicago facility and clusteradm to start working on getting the facility prepared for some of the new FreeBSD hardware we are planning on purchasing. NYI generously provides this for free to the Project. We also worked on connecting with the new owners of the NYI Bridgewater site, where most of the existing FreeBSD infrastructure is located. Some of the purchases we made for the Project last quarter to support infrastructure includes: * 5 application servers to run tasks like bugzilla, wiki, website, cgi, Phabricator, host git, etc. * 1 server to replace the old pkg server, which will provide a lot more IOPS to avoid the slowdowns seen during peak times of the day where the disks simply cannot keep up with the request volume. * 1 server for exp-runs and to make them faster. * 1 server to build packages more frequently. FreeBSD Advocacy and Education A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting using FreeBSD or contributing to the Project easier; and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and to facilitate collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. While we were still unable to attend in-person meetings due to COVID-19, we were able to attend virtual events at new venues and facilitate the first online FreeBSD Vendor Summit. In addition to attending and planning virtual events, we are continually working on new training initiatives and updating our selection of how-to guides to facilitate getting more folks to try out FreeBSD. Check out some of the advocacy and education work we did last quarter: * Continued our FreeBSD Fridays series of 101 classes. Topics included an Introduction to Capsicum, Introduction to Bhyve, Introduction to DTrace, and more. Videos of the past sessions can be found here. We'll be back with new sessions in early 2021. * Gave a FreeBSD talk at the nerdear.la conference on October 20th. * Participated in the podcast: What the Dev: A Dive into the FreeBSD Foundation on its 20th Anniversary * Promoted the Foundation's 20th Anniversary in the FossBytes article: 20 Years of The FreeBSD Foundation * Continued to promote the FreeBSD Office Hours series. Videos from the one hour sessions can be found on the Project's YouTube Channel. See the Office Hours section of this report for more information. * Added two new How-To Guides: Contributing FreeBSD Documentation and How to Submit a Bug Report. * Worked with the organizing committee to host the November 2020 Vendor Summit * Promoted the use of FreeBSD in regards to CHERI and ARM's Morello Processor * Authored a Beginners Guide to FreeBSD for Fosslife. * Sponsored All Things Open as a Media Sponsor. * Sponsored OpenZFS Developers Summit at the Bronze level. * Applied for a virtual stand at FOSDEM 2021. * Committed to attend the online Apricot 2021. Keep up to date with our latest work in our newsletters: https://www.freebsdfoundation.org/news-and-events/newsletter/ Netflix provided an update on how and why they use FreeBSD in our latest Contributor Case Study. We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues at https://www.FreeBSDfoundation.org/journal/. You can find out more about events we attended and upcoming events at https://www.FreeBSDfoundation.org/news-and-events/. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to http://www.FreeBSDfoundation.org to find out how we support FreeBSD and how we can help you! __________________________________________________________ FreeBSD Release Engineering Team Links FreeBSD 12.2-RELEASE schedule URL: https://www.freebsd.org/releases/12.2R/schedule.html FreeBSD 13.0-RELEASE schedule URL: https://www.freebsd.org/releases/13.0R/schedule.html FreeBSD development snapshots URL: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. During the fourth quarter of 2020, the Release Engineering Team completed work on 12.2-RELEASE, the third release from the stable/12 branch, released on October 27. Thank you to all involved for the hard work that went into this release. Additionally throughout the quarter, several development snapshots builds were released for the head, stable/12, and stable/11 branches. Development snapshot builds for 13.0-CURRENT have recently been built from the Git tree within the project, while further snapshot builds for 12.x and 11.x will continue to be built from Subversion. As we approach the end of 2020, continued preparations are being put in place for the upcoming 13.0 release, which will be the first release from Git. Much of this work was sponsored by Rubicon Communications, LLC (netgate.com) and the FreeBSD Foundation. __________________________________________________________ Cluster Administration Team Links Cluster Administration Team members URL: https://www.freebsd.org/administration.html#t-clusteradm Contact: Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the Project relies on for its distributed work and communications to be synchronised. In this quarter, the team has worked on the following: * Finished setting up the Malaysia mirror site, generously hosted by the Malaysian Research & Education Network. Traffic from Oceania and parts of Asia is now going to this mirror instead of farther away sites like Japan and California. * Upgraded the package building machines to a version of head from mid-October 2020. * Upgraded developer machines in the cluster (freefall, ref\* and universe\*) to a version of head from mid-October 2020. * Installed eight new x86 servers in our New Jersey site: five application servers, two package builders and one mirror server. + The new mirror server is in production (pkg0.nyi.freebsd.org). + The two package builders are in production. + Two of the application servers have been put into production as the Git source of truth and the cgit web frontend, respectively. * Installed two new aarch64 servers in our New Jersey site. Both are now building aarch64 packages. * Fixed package mirror synchronisation for powerpc64 packages. * Rebuilt the ZFS pool on the UK mirror server (pkg0.bme.freebsd.org) for better I/O parallelism. This should improve download performance especially at peak times. * Ongoing systems administration work: + Accounts management for committers. + Backups of critical infrastructure. + Keeping up with security updates in 3rd party software. Work in progress: * Hardware refreshing for web services, backup version control system in NYI * Upgrading production machines in the FreeBSD cluster to 12.2 + Most machines have been upgraded as of mid-December 2020 + Remaining machines will be decommissioned / repurposed after services migrate to newer hardware * Supporting Git migration and infrastructure setup * powerpc pkgbuilder/ref/universal machines * Preparations for a new mirror site in Australia, to be hosted by IX Australia. * Setup Brazil (BRA) mirror. * Review the service jails and service administrators operation. * Searching for more providers that can fit the requirements for a generic mirrored layout or a tiny mirror. __________________________________________________________ Continuous Integration Links FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD Hardware Testing Lab URL: https://ci.FreeBSD.org/hwlab FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org FreeBSD CI weekly report URL: https://hackmd.io/@FreeBSD-CI FreeBSD Jenkins wiki URL: https://wiki.freebsd.org/Jenkins Hosted CI wiki URL: https://wiki.freebsd.org/HostedCI 3rd Party Software CI URL: https://wiki.freebsd.org/3rdPartySoftwareCI Tickets related to freebsd-testing@ URL: https://preview.tinyurl.com/y9maauwg FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet The FreeBSD CI team maintains the continuous integration system of the FreeBSD project. The CI system firstly checks the committed changes can be successfully built, then performs various tests and analysis over the newly built results. The artifacts from those builds are archived in the artifact server for further testing and debugging needs. The CI team members examine the failing builds and unstable tests and work with the experts in that area to fix the code or adjust test infrastructure. The details of these efforts are available in the weekly CI reports. During the fourth quarter of 2020, we continued working with the contributors and developers in the project to fulfil their testing needs and also keep collaborating with external projects and companies to improve their products and FreeBSD. Important changes: * doc jobs were changed to use git to follow VCS migration: + https://ci.freebsd.org/job/FreeBSD-doc-main/ + https://ci.freebsd.org/job/FreeBSD-doc-main-igor/ Thanks Brandon Bergren (bdragon@) * head and stable/12 build environment have been upgraded to 12.2-RELEASE New jobs added: * LINT kernel of head on riscv64 Work in progress: * Follow VCS migration, change src jobs to use Git - PRs are available Thanks Brandon Bergren (bdragon@) * Collecting and sorting CI tasks and ideas here * Testing and merging pull requests in the the FreeBSD-ci repo * Designing and implementing pre-commit CI building and testing * Reducing the procedures of CI/test environment setting up for contributors and developers * Setting up the CI stage environment and putting the experimental jobs on it * Setting up public network access for the VM guest running tests * Implementing automatic tests on bare metal hardware * Adding drm ports building tests against -CURRENT * Planning to run ztest and network stack tests * Adding more external toolchain related jobs * Improving the hardware lab to be more mature and adding more hardware * Helping more software get FreeBSD support in their CI pipeline Wiki pages: 3rdPartySoftwareCI, HostedCI * Working with hosted CI providers to have better FreeBSD support * The build and test results will be sent to the dev-ci mailing list soon. Feedback and help with analysis is very appreciated! Please see freebsd-testing@ related tickets for more WIP information, and don't hesitate to join the effort! Sponsor: The FreeBSD Foundation __________________________________________________________ Ports Collection Links About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/= ports-contributing.html FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/index.html Ports Management Team URL: https://www.freebsd.org/portmgr/index.html Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/ Contact: Ren=E9 Ladan Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. For the last quarter the dashboard looks like: * 41500 ports (including flavors) * 2516 open PRs of which 625 are unassigned * 8715 commits to the HEAD branch by 164 committers * 420 commits to the 2020Q4 branch by 59 committers Compared to the third quarter, the PR statistics mostly stayed the same. There were slightly fewer commits by the same number of people. The number of ports again grew steadily, this time by almost 4 percent. During the last quarter, we welcomed Juray Lutter (otis@) as a new ports committer and said goodbye to cpm, jadawin, knu, araujo, mmokhi and scottl. Traditionally merges to the quarterly ports branches, which are more conservative versions of the HEAD tree, required approval of either the Ports Security Team (ports-secteam@) or portgmr@. There were already a number of blanket approvals for tested commits, ranging from fixing typing mistakes to upgrading web browsers to their latest version. As of last December, all ports committers are free to merge on their own, lessening the burden on ports-secteam@. Patent limitations have been disconnected from the license framework, given that patents are a complex topic with implications varying from one jurisdiction to another. The last quarter saw a number of updates to default versions of ports: * librsvg2: "rust" on supported platforms, "legacy" otherwise * Mono: 5.10 * FPC switched to 3.2.0 * GCC switched to 10 for powerpc64le * Lazarus switched to 2.0.10 * Ruby switched to 2.7.X * Samba switched to 4.12 During the last quarter, a new virtual category was added: "education" for ports that for instance help the user to learn about a certain topic or help facilitating examinations. The @shell and @sample keywords have been rewritten in Lua which makes root-dir compliant (see pkg -r) and ensures they are Capsicum-sandboxed. The last quarter also saw updates to several user-facing ports: * Firefox 84.0.1 * Firefox-esr 78.6.0 * Chromium 87.0.4280.88 * Ruby 2.7.2 * Qt5 5.15.2 * XFce 4.16 As always, antoine@ was busy running exp-runs, 37 this quarter, testing: * various ports upgrades * changing sys/cdefs.h in base * adding "set pipefail" to most framework scripts to catch errors earlier * changing the default locale to C.UTF-8 in base * using bsdgrep as /usr/bin/grep __________________________________________________________ Office Hours Contact: Allan Jude Contact: Ed Maste During the final quarter of 2020 three office hours sessions were held. The first was hosted by the core team in a time slot conducive to Asia and Australia, covering topics including the transition to git, recruiting for project teams, and core's todo list. The second was hosted by the git transition team, and answered attendee questions about the transition to git and how it would impact the project's workflows. The third session was hosted by bhyve maintainers Peter Grehan and John Baldwin to present recent development efforts and answer questions about bhyve. The project is looking for volunteers to host future office hours sessions, as well as taking topic suggestions. We also hope to improve the system to allow people to submit questions ahead of time, so that we can take maximum advantage of subject matter experts when we have them for these calls. You can find the schedule for future office hours, and videos of past office hours on the FreeBSD Wiki Sponsor: ScaleEngine Inc. __________________________________________________________ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. GPL in Base Links GPL Software in the Base System=20 URL: https://wiki.freebsd.org/GPLinBase Contact: Ed Maste Contact: Kyle Evans Contact: Baptiste Daroussin A long-standing goal of the FreeBSD project is for the base system to migrate to modern, copyfree or more permissively licensed components. In this quarter, the following components have been successfully removed or replaced: * gdb (removed in favor of lldb in base or devel/gdb in ports) * gnugrep (replaced with bsdgrep) * libgnuregex (removed) The following component(s) have yet to be claimed. Some replacement prospects may be listed on the above-linked wiki page. Interested parties are welcome to evaluate the options to restart the discussion: * dialog * gcov (kernel) The following component(s) have a principal investigator to coordinate work. Note that partial completion likely means that a component is partially compatible, but could use evaluation and patches to bring parity with the component that it is replacing. * diff3 (Contact bapt@ if interested) __________________________________________________________ Git Migration Working Group Links src (base system) git repo URL: https://cgit.FreeBSD.org/src doc git repo URL: https://cgit.FreeBSD.org/doc Beta ports git repo URL: https://cgit-dev.FreeBSD.org/ports Warner's git documentation repo URL: https://github.com/bsdimp/freebsd-git-docs FreeBSD-git mailing list URL: https://lists.freebsd.org/mailman/listinfo/freebsd-git Git conversion tooling repo URL: https://github.com/freebsd/git_conv Game of Trees URL: http://gameoftrees.org/ gitup URL: https://github.com/johnmehr/gitup Contact: Li-Wen Hsu Contact: Warner Losh Contact: Ed Maste Contact: Ulrich Sp=F6rlein The Git working group largely completed the migration of the doc and src (base system) trees from Subversion to Git in December 2020. We are currently working on some minor outstanding issues and preparing for the ports tree migration. We set up new hosts to serve as the Git repositories and mirrors, and developed commit hooks for restrictions on commits to various branches, generation of commit mail, and similar needs. The doc tree migration occurred on December 8th and 9th. After the conversion some minor changes to the documentation build infrastructure were necessary. The src tree migration occurred between December 20th and 23rd for the main branch; some additional tasks occurred over the next week or so. These included enabling the stable branches, vendor (contrib) code updates, and the git->svn gateway. We are translating stable branch commits to Subversion for the stable/11 and stable/12 branches and associated release branches. This allows FreeBSD users who follow stable branches or releases to continue using existing processes and tooling. An experimental Git conversion of the ports tree is available at the link above. There are some unique challenges in the ports tree (that do not impact the doc or src repos in the same way), so additional work is ongoing. The window for migrating the ports tree is immediately prior to a quarterly branch, so we anticipate a migration at the end of March 2021. Over the next few months testing of the experimental ports repo is very welcome. Process documentation for developer and user interaction with FreeBSD's repositories is currently available in Warner's GitHub repository at the link above. It will be moved to the FreeBSD developer's handbook and/or other suitable locations following the documentation project's asciidoc conversion. The working group is experimenting with two permissively-licensed tools that are compatible with Git servers or repositories. Game of Trees is a version control system that is compatible with Git repositories. It is being developed by Stefan Sperling along with some OpenBSD developers and other contributions. John Mehr's gitup is a minimal, dependency-free program that clones and synchronizes a local tree with a remote repository. It is intended for use cases that would otherwise be served by tools like portsnap. Sponsor: The FreeBSD Foundation (in part) __________________________________________________________ Linux compatibility layer update Contact: Edward Tomasz Napierala Linuxulator improvements have been ongoing for the last two years, with support from the FreeBSD foundation over a few distinct project grants as well as contributions from the community. The goal of this project is to improve FreeBSD's ability to execute unmodified Linux binaries. Current status is being tracked at Linux app status Wiki page. The work has now shifted from command-line apps to desktop applications. There wasn't much Foundation-sponsored work done during this quarter, apart from extending fuse(4) to make it possible to run Linux FUSE servers, which is one of the things required to run AppImages. The Foundation-sponsored effort will continue into the first quarter of 2021 in order to make sure the 13.0-RELEASE ships with Linuxulator in a good shape. There was a very significant contribution from Conrad Meyer in the form of SO_PASSCRED setsockopt(2) support, PR_SETDUMPABLE and PR_GETDUMPABLE prctl(2) flags, and also CLONE_FS and CLONE_FILES handling. This, along with some more cleanups and improvements, leads to working Linux Chromium; it has been tested with Netflix and Spotify clients. It still requires three flags (--no-sandbox --no-zygote --in-process-gpu) to be passed on the command line to work around missing functionality, though. Also, the name_to_handle_at(2) and open_by_handle_at(2) syscalls are now supported. There are also much better debug messages for unrecognized socket options. Sponsor: The FreeBSD Foundation __________________________________________________________ LLDB Debugger Improvements Links Moritz Systems Project Description URL: https://www.moritz.systems/blog/lldb-debugger-improvements-for-fre= ebsd/ FreeBSD Foundation Blog URL: https://freebsdfoundation.org/blog/guest-blog-foundation-sponsors-= freebsd-lldb-improvements/ Git Repository URL: https://github.com/moritz-systems/llvm-project Contact: Kamil Rytarowski Contact: Michal/ G=F3rny The LLDB project builds on libraries provided by LLVM and Clang to provide a great modern debugger. It uses the Clang ASTs and the expression parser, LLVM JIT, LLVM disassembler, etc so that it provides an experience that "just works". It is also blazing fast and more permissively licensed than GDB, the GNU Debugger. LLDB is the default debugger in Xcode on macOS and supports debugging C, Objective-C, and C++ on the desktop and iOS devices and the simulator. FreeBSD includes LLDB in the base system. At present, it has some limitations in comparison with the GNU GDB debugger, and does not yet provide a complete replacement. It used to rely on an obsolete plugin model in LLDB that was a growing technical debt. This project aimed to bring LLDB closer to a fully featured replacement for GDB, and therefore for FreeBSD to feature a modern debugger for software developers. The legacy monolithic target support executed the application being debugged in the same process space as the debugger. The modern LLDB plugin approach, used on other supported targets, executes the target process under a separate lldb-server process. This improves reliability and simplifies the process / thread model in LLDB itself. In addition, remote and local debugging is now performed using the same approach. After the migration to the new process model on 32 and 64-bit x86 CPUs, the project focused on reviewing the results of LLDB's test suite and fixing tests as time permits. During the Moritz Systems work, the FreeBSD Project gained numerous important improvements: in the kernel, userland base libraries (the dynamic loader) and the LLVM toolchain FreeBSD support. The introduced changes are expected to be shipped with LLDB 12.0, and where applicable in FreeBSD 13.0. The overall experience of FreeBSD/LLDB developers and advanced users on this rock solid Operating System reached the state known from other environments. Furthermore, the FreeBSD-focused work also resulted in generic improvements, enhancing the LLDB support for Linux and NetBSD. Sponsor: The FreeBSD Foundation __________________________________________________________ Upstreaming NetApp Changes Links Klara Inc. URL: https://klarasystems.com/freebsd-development/ Contact: Alexander Sideropoulos Contact: Allan Jude NetApp has started an effort to upstream bug fixes and other improvements from the ONTAP code line into FreeBSD. These changes benefit the FreeBSD community by providing many fixes that NetApp has made over the past few years, while allowing NetApp to reduce the number of customizations needed when bringing in the latest FreeBSD changes back into the ONTAP tree. NetApp has partnered with Klara to facilitate this project, to help identify interesting and useful changes to send upstream, to rework and generalize those changes as required to make them suitable for upstreaming, and to shepherd them through the FreeBSD code review process. During the fourth quarter, Klara has made 40 upstream fixes in the FreeBSD kernel in various subsystems including geom, dev, amd64, net, kern, netinet, and several other areas of the tree on behalf of NetApp. NetApp intends to continue to sponsor this effort throughout 2021. Sponsor: NetApp __________________________________________________________ NFS over TLS implementation Contact: Rick Macklem In an effort to improve NFS security, an Internet Draft titled "Towards Remote Procedure Call Encryption By Default" specifies use of TLS 1.3 to encrypt all data traffic on a Sun RPC connection used for NFS. Although NFS has been able to use sec=3Dkrb5p to encrypt data on the wire, this requires a Kerberos environment and, as such, has not been widely adopted. It also required that encryption/decryption be done in software, since only the RPC message NFS arguments are encrypted. Since Kernel TLS is capable of using hardware assist to improve performance and does not require Kerberos, NFS over TLS may be more widely adopted, once implementations are available. The coding for this project has now been completed. All required changes to the NFS and kernel RPC code have been committed to the head/current kernel and will be in FreeBSD13. The daemons can now be built from a port that depends upon the security/openssl-devel port of Openssl3 that includes patches for support of ktls. The port for the daemons is called sysutils/nfs-over-tls and should be committed to the ports framework soon. In the meantime, the port can easily be fetched, as described in https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt. To support clients such as laptops, the daemons that perform the TLS handshake may optionally handle client X.509 certificates from a site local CA. There are now exports(5) options to require client(s) to provide a valid X.509 certificate. The case where a "user" name is stored in the certificate and is used to map all RPC credentials to that user is probably in violation of the Internet Draft. This is only enabled when the "-u" command line option is provided to rpc.tlsservd(8). The code is now available for testing. See: https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt Setting up system(s) for testing still requires building a custom kernel with "options KERN_TLS" from recent head/FreeBSD13 sources plus installing the port for the daemons, as explained by the above document. The main limitation in the current implementation is that it uses TLS1.2 and not TLS1.3, as required by the Internet Draft. This should change once the KERN_TLS rx patch includes TLS1.3 support. Third party testing would be appreciated. __________________________________________________________ OpenBSM Synchronisation Links TrustedBSD / OpenBSM URL: http://www.trustedbsd.org/openbsm.html OpenBSM Github Sources URL: https://github.com/openbsm/openbsm Synchronisation with macOS Catalina URL: https://github.com/openbsm/openbsm/commit/54a0c07cf8bac71554130e8f= 6760ca68e5f36c7f Apple OpenSource URL: https://opensource.apple.com Contact: Gordon Bergling OpenBSM is a crucial part of FreeBSD, which provides auditing features for the operating system. OpenBSM is incorporated into FreeBSD and macOS. Both Apple and FreeBSD have currently made changes to the OpenBSM framework, which weren't upstreamed. This small project aims to consolidate these changes and upstream them to the OpenBSM github repository, so that both development efforts can be merged to FreeBSD later on. The tricky part of this project is the manual comparison, since Apple doesn't provide any changelogs. I am currently working on on the macOS Catalina sources and hopefully Apple will release the sources of macOS Big Sur in time for FreeBSD 13. __________________________________________________________ Tool Chain Links ELF Tool Chain homepage URL: https://sourceforge.net/p/elftoolchain Contact: Dimitry Andric Contact: Ed Maste In October Clang/LLVM was updated to 11.0.0, followed by a number of bug fixes from upstream, including improvements for a number of Tier-2 architectures. We also enabled the -fstack-clash-protection flag to enable compiler mitigation for the "stack clash" vulnerability and are coordinating with upstream. Upstream LLDB support for FreeBSD improved substantially over the last quarter, as detailed elsewhere in this report. These improvements will make it into the FreeBSD base system early in 2021 when LLVM is next updated to 12.0. As also mentioned elsewhere, we removed the obsolete copy of GDB 6.1.1. The ELF Tool Chain received a number of bug fixes, as well as support for readelf -z (handling compressed ELF debug sections) and an improvement to addr2line to report based on labels when other debug information is not available. We are working to upstream these changes to the ELF Tool Chain project. There are a number of open issues and opportunities for improvements in various ELF Tool Chain components. Contributions in these areas are very welcome, Sponsor: The FreeBSD Foundation (in part) __________________________________________________________ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. ENA FreeBSD Driver Update Links ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/R= EADME Contact: Michal Krawczyk Contact: Artur Rojek Contact: Marcin Wojtas ENA (Elastic Network Adapter) is the smart NIC available in the virtualized environment of Amazon Web Services (AWS). The ENA driver supports multiple transmit and receive queues and can handle up to 100 Gb/s of network traffic, depending on the instance type on which it is used. Completed since the last update: * MFC of the ENA v2.3.0 driver to the FreeBSD 11-STABLE branch * MFC of the ENA v2.3.0 driver to the upcoming FreeBSD 12-STABLE branch * Add feature that allows reading extra ENI (Elastic Network Interface) metrics about exceeding BW/pps limits * Add SPDX license tag to the ENA driver files * Add Rx offsets (hardware feature) support for the ENA driver * Fix completion descriptors alignment for the ENA device - on some of the platforms ENA needs alignment to 4k Work in progress: * Introduce full kernel RSS API support. * Allow reconfiguration of the RSS indirection table and hash key * Prototype the driver port to the iflib framework Sponsor: Amazon.com Inc __________________________________________________________ Intel wireless update Links The freebsd-wireless mailing list URL: https://lists.freebsd.org/mailman/listinfo/freebsd-wireless Contact: Bjoern A. Zeeb The Intel Wireless driver update project aims to bring support for newer chipsets and also get station side to 11ac in a first step. During the last months connection code between net80211 and the Linux driver KPI was implemented and scanning is working. Currently the focus is on sending and driving one state machine from the other and syncing state between net80211 and the Linux compat code. In addition the driver and firmware was updated from upstream sources to include support for the AX210 hardware generation, which was already tested to attach. The hope is that by the time the status report gets published authentication and association are working and basic data packet passing will work soon. Sponsor: The FreeBSD Foundation __________________________________________________________ Fenestras X random(4) Links SVN revision 1/3 URL: https://svnweb.freebsd.org/base?view=3Drevision&revision=3D366620 SVN revision 2/3 URL: https://svnweb.freebsd.org/base?view=3Drevision&revision=3D366621 SVN revision 3/3 URL: https://svnweb.freebsd.org/base?view=3Drevision&revision=3D366622 FX Design (PDF) URL: https://aka.ms/win10rng Fortuna Design URL: https://www.schneier.com/academic/fortuna/ Contact: Conrad Meyer Contact: FreeBSD CSPRNG group Since FreeBSD 11, the default random(4) implementation is based on the Fortuna (2003) design by Ferguson and Schneier. At a high level, Fortuna accumulates entropy into a series of pools, and reseeds a single generator from some of these pools according to some criteria. In 2019, Ferguson (at Microsoft) published a whitepaper on the design of the Windows 10 system random number generator. Fenestras X is a random(4) implementation based on the published Windows 10 design. The Fenestras X / Windows 10 design is similar to Fortuna, so it is probably most interesting to describe their differences: * Fenestras X has per-CPU generators seeded from a root generator. Fortuna only has the root generator. This change eliminates lock contention between random(4) readers running on multiple cores. * Generators in Fenestras X form a tree from the root RNG. When read, generators efficiently check if their parent generator has been seeded with newer entropy. If so, child generators reseed themselves before serving the read operation. This is integrated with arc4random(9), as well as userspace arc4random(3). * Fenestras X generators are buffered. Requests smaller than some arbitrary threshold (currently 128 bytes) are served from the buffer. Bytes read from the buffer are securely erased when they are consumed. The buffer is refreshed if the request consumes more bytes than were available in the buffer. This amortizes the cost of rekeying and generating output from a cryptographic CTR-mode cipher, which is especially slow with AES. There are other important differences, and readers interested in system CSPRNGs should read Ferguson's whitepaper. It is short and accessible. For more information on the FreeBSD implementation, please see the SVN commit messages -- especially r366620. The Fenestras X implementation is available in CURRENT, but disabled by default. (The default remains Fortuna.) At this time, you must set the RANDOM_FENESTRASX option in your custom kernel configuration and rebuild your kernel to use the new design. There are no known bugs or weaknesses relative to the Fortuna implementation. Future work and call to action: * Additional design review, implementation review, and testing is welcome. * Additional entropy sources: we could use implementations of some of the sources described in the whitepaper, in both Fortuna and Fenestras X. In particular, we're missing a jitter entropy source. __________________________________________________________ pf performance improvement Links First commit URL: https://cgit.freebsd.org/src/commit/?id=3D1c00efe98ed7d103b9684ff6= 92ffd5e3b64d0237 D27707 URL: https://reviews.freebsd.org/D27707 D27756 URL: https://reviews.freebsd.org/D27756 D27757 URL: https://reviews.freebsd.org/D27757 D27758 URL: https://reviews.freebsd.org/D27758 D27759 URL: https://reviews.freebsd.org/D27759 D27760 URL: https://reviews.freebsd.org/D27760 D27761 URL: https://reviews.freebsd.org/D27761 D27762 URL: https://reviews.freebsd.org/D27762 D27763 URL: https://reviews.freebsd.org/D27763 D27764 URL: https://reviews.freebsd.org/D27764 Contact: Kristof Provost The performance of pf was not as good as it could be. Some investigation with the invaluable hwpmc tooling eventually pointed to very poor cache behaviour. The longest_lat_cache.miss event was very informative. This turned out to be due to pf doing packet and byte counting in states, rules and interfaces. The pf code took the very straightforward approach of having a simple uint64_t variable and incrementing it for every packet. The downside of this is that when multiple cores do it simultaneously the CPU ends up having to write this to memory very often, slowing packet processing down greatly. Happily the counter(9) framework is designed for this exact situation. One additional complication is that pf uses the same structure definitions for its internal data as it uses for configuration from user space. To avoid breaking user space these data structures have been decoupled. That is, where pf_rule used to be used both to set rules via the ioctl() interface and to evaluate rules while processing packets we now only use pf_rule for configuration. The new pf_krule structure is used when evaluating packets. This allows us to change the pf_krule structure, to change uint64_t to counter_u64_t, without affecting user space. Olivier Cochard-Labb=E9 tested the full set of changes, and found (depending on hardware) substantial improvements in throughput: Sponsor: Orange Business Services __________________________________________________________ IP Routing lookup improvements Links Add modular routing lookup framework. URL: https://reviews.freebsd.org/D27401 Contact: Alexander Chernikov This work adds a fib lookup framework, allowing to attach custom IP lookup algorithms to any routing table on the fly. It allows to use more performant and efficient lookup algorithms, dynamically selected based on the number of routes in the routing table. Finally, it provides an implementation of modified DIR-24-8 for IPv4/IPv6, speeding IP lookups for the large-fib use case. This work is a part of a larger effort to modernise the routing subsystem. Background FreeBSD runs diverse workloads on both low-end and high-end devices, resulting in different networking/memory requirements for each case. Small boxes with a couple of routes are different from routers with full-view. IPv4 lookups are different from IPv6 ones. Conditions can change dynamically: one may easily reconfigure a system to receive full view instead of a default route. Currently, FreeBSD uses radix (compressed binary tree) to perform all unicast route manipulations, including routing lookups. Radix implementation requires storing key length in each item, allowing to use sockaddrs, transparently supporting virtually any address family. This flexibility comes at a cost: radix is relatively slow, cache-unfriendly and adds locking to the hot path. Finally, radix is closely coupled to the rest of the system, making it hard to switch to something else. Implementation overview Overview Modular fib IP lookup framework has been designed to address flexibility and performance requirements. It keeps system radix as the "control plane" source of truth, simplifying actual algorithms implementation. It allows dynamic load new algorithms as the kernel modules and abstracts most OS-specific details, reducing algorithm "glue" code. It automatically adapts to the current system state by picking the best matching algorithm for the routing table on-the-fly. The following algorithms are provided by default. IPv4: * bsearch4 (lockless binary search in a specially-crafted IP array), tailored for small-fib (less than 16 routes) * radix4_lockless (lockless immutable radix, re-created on every routing table change), tailored for small-fib (less than 1000 routes) * radix4 (base system radix backend) * dpdk_lpm4 (DPDK DIR24-8-based lookups), lockless datastructure optimised for large-fib ( D27412 ) IPv6: * radix6_lockless: lockless immutable radix, re-created on every routing table change, tailored for small-fib (less than 1000 routes) * radix6: wrapper around existing system radix * dpdk_lpm6: DPDK DIR24-8-based lookups, lockless datastructure optimised for large-fib ( D27412 ) Performance changes Micro benchmarks (i7-7660U, single-core lookups, 2048 destinations, benchmark code in D27604). IPv4: * 8 routes: radix4: ~20mpps, radix4_lockless: ~25mpps, bsearch4: ~69mpps, dpdk_lpm4: ~67 mpps * 700k routes: radix4_lockless: 3.3mpps, dpdk_lpm4: 46mpps IPv6: * 8 routes: radix6_lockless: ~20mpps, dpdk_lpm6: ~70mpps * 100k routes: radix6_lockless: ~14mpps, dpdk_lpm6: ~57mpps Forwarding performance: * +10-15% IPv4: small-fib, bsearch4 * +25% IPv4: full-view, dpdk_lpm4 * +20% IPv6: full-view, dpdk_lpm6 Status * Modular longest-prefix-match lookup algorithms (D27401) [ DONE ] + Design control plane framework for attaching algorithms [ DONE ] + Port DPDK IPv6 lockless lookup algorithm ( D27412) [ DONE ] + Port DPDK IPv4 lockless lookup algorithm ( D27412) [ DONE ] __________________________________________________________ Scalable routing multipath support Links Implementation of scalable multipath URL: https://reviews.freebsd.org/D24141#change-ZOjdMqgDgUr7 Introduce scalable route multipath URL: https://reviews.freebsd.org/D26449 Contact: Alexander Chernikov This work targets implementing scalable routing multipath support and enabling it by default. It closes the long-standing feature gap with other modern networking OSes. This work is a part of on-going efforts to modernize the routing subsystem. Background Initial FreeBSD multipath implementation, RADIX_MPATH, was added back in 2008. It was based on the radix changes and represented multipath routes as a linked-list of chained paths. It was not fully finished and tested, resulting in many crash reports. Implementation overview Multipath-related change changes are based on the introduction of the concept of next hops. Nexthops are separate data structures, containing the necessary information to perform packet forwarding. They are shared among the routes, providing more pre-computed cache-efficient data while requiring less memory. Interested readers can find a more detailed description in D24141. They can find another overview in Nexthop objects talk describing Linux kernel implementation. Multipath implementation extends the nexthop concept further by introducing nexthop groups. Nexthop group is simply an array of nexthops, compiled according to each nexthop relative weight. Each route has a pointer to either nexthops or a nexthop group, decoupling lookup algorithm from the routing stack internals. Both nexthops and nexthop groups are immutable and use epoch(9)-backed reclamation. Status * Nexthop objects (D24232) [ DONE ] + Introduction of nexthop objects [ DONE ] + Conversion of old KPI users to the new one [ DONE ] o Conversion of route caching to nexthop caching [ DONE ] + Conversion of struct rtentry field access to nhop field access [ DONE ] + Eliminating old lookup KPI and hiding struct rtentry [ DONE ] * Multipath routing (D26449) [ DONE ] + Switch control plane customers to use (rtentry, nexthop) pairs instead of rtentry to allow multipath changes happen transparently [ DONE ] + Introduce nexthop group objects [ DONE ] + Add multipath support for the rib (routing information base) manipulation functions [ DONE ] + Add flowid generation for outbound traffic to enable load balancing [ DONE ] * Routing daemon support + Add net/bird support for multipath routing [ NOT STARTED ] + Add explicit nexthop/nexthop groups control via rtsock [ IN PROGRESS ] + Work with FRR developers to add nexthop-based route control [ NOT STARTED ] __________________________________________________________ Thunderbolt3/USB4 stack Contact: Scott Long This project implements a driver stack for Thunderbolt3 and USB4. These technologies differ radically from USB3 and prior, and require completely new drivers for the host interface adapter and topology as well as configuration management layers. At their most fundamental level, a TBT3/USB4 topology appears as PCI bridges and buses, and attached devices appear as either PCI devices, USB3 devices, or DisplayPort devices. Early TBT3 controllers don't even appear in the system topology unless a TBT3 device is plugged in. These early TBT3 systems also implement a security policy meant to protect against unauthorised or malicious devices, though that scheme has been proven to not be effective and has been removed from later TBT3 and USB4 implementations. Besides security control, the TBT3/USB4 stack controls power management and topology hotplug. The FreeBSD driver currently supports Alpine Ridge and Ice Lake TBT3 controllers, and can perform basic security validation and topology awareness. USB4 support as well as full connection manager and power management support is still being worked on. The current driver will be committed to FreeBSD in early January 2021. Though this work is not sponsored, it has been done with the encouragement and support of the FreeBSD Foundation and Netgate. __________________________________________________________ Vectored AIO Contact: Alan Somers POSIX AIO is a facility for asynchronous I/O to files and devices. FreeBSD's implementation is efficient, especially when writing to disk files. But a long-standing defect in the standard API is a lack of vectored functions. That is, there is no asynchronous equivalent of pwritev(2) and preadv(2). A common workaround is to use lio_listio(2) instead. However, that has several drawbacks. It's more effort for the programmer, it might return early with only a subset of the operations completed, it requires more total syscalls, and there is no guarantee that the operations will complete in-order. This quarter I added two new syscalls: aio_writev(2) and aio_readv(2). They work just like their non-vectored counterparts, but they take an array of iovec elements, just like pwritev and preadv. You can't use them in combination with lio_listio, but that could be added in the future. __________________________________________________________ ZSTD Compression in ZFS Contact: Allan Jude Zstandard (ZSTD) is a modern high-performance compression algorithm designed to provide the compression ratios of gzip while offering much better performance. ZSTD has been adopted in FreeBSD for a number of other uses, including compressing kernel crash dumps, as a replacement for gzip or bzip for compressing log files, and for future versions of pkg(8). This effort to complete the integration of ZSTD into ZFS is funded by the FreeBSD Foundation. During the four quarter the final tasks in the project to integrate ZSTD into OpenZFS were completed. Completed milestones in this project: * Integrated ZSTD in the FreeBSD boot loader (Warner Losh imp@freebsd.org) * Added a section to the FreeBSD Handbook ZFS chapter explaining ZSTD * Wrote a FreeBSD Journal Article explaining considerations when selecting a suitable compression level * Monitored for bug reports after the changes were integrated into -CURRENT With all of these changes in place, it is now possible to boot from pools compressed with zstd or zstd-fast. For comparison, a standard installation of FreeBSD 13 (without debug symbols) uncompressed is 1175 MB, and when compressed with LZ4, is only 570 MB (2.15x) but when compressed with ZSTD's default level of 3 is only 417 MB (3.00x), and with the maximum level, 19, only 374 MB (3.36x). Sponsor: The FreeBSD Foundation __________________________________________________________ Architectures Updating platform-specific features and bringing in support for new hardware platforms. arm64 platform updatesq Contact: Mitchell Horne In the interest of seeing the arm64 architecture promoted to Tier-1 status, an effort was undertaken to test building and serving of release and patch-level updates via freebsd-update(1). The conclusion of this investigation is that the process works with very few changes required; a small tweak is needed for the update build scripts, and a minor bugfix in the bsdiff(1) utility was committed. The hope is that the project can begin providing security updates for the platform with the release of FreeBSD 13.0, removing the requirement that users compile these updates from source. Added this quarter was arm64 support for the new ossl(4) crypto driver. This driver provides acceleration of SHA-1 and SHA-2 cryptographic operations by leveraging OpenSSL's assembly routines. These routines will detect and use optimized instructions, as supported by the CPU. This support benefits userland applications via the cryptodev(4) device, and in-kernel consumers of the crypto(9) interface, such as the IPSec Authentication Header protocol and kernel TLS. Finally, work was done to add the necessary machine-dependent bits for the kernel's gdb(4) interface. This enables remote debugging of the kernel with gdb(1) over a serial line. Sponsor: The FreeBSD Foundation __________________________________________________________ FreeBSD/RISC-V Project Links Wiki URL: https://wiki.freebsd.org/riscv Contact: Mitchell Horne Contact: freebsd-riscv Mailing List Contact: IRC #freebsd-riscv on freenode The FreeBSD/RISC-V project is providing support for running FreeBSD on the RISC-V Instruction Set Architecture. This quarter saw a number of improvements and bugfixes from committers and contributors alike. A few small items from this quarter: * Added riscv64 LINT kernel config plus CI job (FreeBSD-head-riscv64-LINT) * Switched emulators/riscv-isa-sim to official upstream and updated to 2020-11-02 snapshot * Created sysutils/u-boot-sifive-fu540, a u-boot port for the HiFive Unleashed * Improved SBI extension support Further progress was made this quarter in building ports for RISC-V. Build and runtime issues with large dependencies devel/python-setuptools and devel/glib20 were fixed, enabling several thousand skipped ports. There is some in-progress work to address failures in other significant ports, such as devel/nspr and databases/sqlite3. By addressing some of these small-effort issues, some 15000+ ports can now be built for the platform with qemu-user-static. Finally, December saw the arrival of the first riscv64 weekly development snapshots. This includes the usual memstick installer, a virtual machine image, and a generic SD card image. There are still some minor tweaks to be made, but this marks a significant step forward for the platform, and lowers the barrier of entry for running a FreeBSD/RISC-V system. This also means that FreeBSD 13 will likely be the first downloadable release for the architecture. For those interested in trying out the VM image for themselves, see the Quick Start instructions on the wiki. __________________________________________________________ Userland Programs Changes affecting the base system and programs in it. Dual-stack ping command Contact: Alan Somers The venerable ping command has until now only supported IPv4. A separate utility, ping6, was originally written by WIDE as a research tool to develop IPv6. As a research tool, it didn't need IPv4 support, but since then, it's been put to practical use by countless developers and sysadmins everywhere. The ping/ping6 split has been a perennial complaint. It's annoying that two separate commands are needed, even though they do almost exactly the same thing. This quarter, I merged J=E1n Sucan's GSoC work, which merged the two commands. Now ping can handle either protocol, based on the -4 and -6 switches, or based on the format of the target. A ping6 hard link is provided for backwards compatibility. Sponsor: Google Summer of Code __________________________________________________________ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. KDE on FreeBSD Links KDE FreeBSD URL: https://freebsd.kde.org/ KDE Community FreeBSD URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project aims to package all of the software produced by the KDE Community for the FreeBSD ports tree. The software includes a full desktop environment called KDE Plasma, graphics applications, instant-messengers, a video-editing suite, as well as a tea timer and hundreds of other applications that can be used on any FreeBSD machine. The KDE team (kde@) is part of desktop@ and x11@ as well, building the software stack to make FreeBSD beautiful and usable as a daily-driver graphics-based desktop machine. This quarter the kde@ team: * Landed the October, November and December updates to KDE Applications and to KDE Plasma * Landed all of the bi-weekly KDE Frameworks releases * Updated Qt to 5.12.2, including Qt5 WebEngine * Followed up with two cmake patch releases * Followed up one ninja patch release There was lots of infrastructural work and individual application updates and a new Matrix client from the KDE community as well, which we typically fail to administer and write about so this report is fairly short with mostly big-ticket items. We had fun, we chased the things that are most useful to us, and got through the year. Here's to next year with actually seeing FreeBSD people again. I (adridg@) would like to especially thank Kai Knoblich (kai@) for chasing WebEngine: that's a huge and painful codebase to deal with, and here we are, all up-to-date. __________________________________________________________ FreeBSD Office team Links The FreeBSD Office project URL: https://wiki.freebsd.org/Office Contact: FreeBSD Office team ML Contact: Dima Panov Contact: Li-Wen Hsu The FreeBSD Office team works on a number of office-related software suites and tools such as OpenOffice and LibreOffice. Work during this quarter focused on providing the latest stable release of LibreOffice suite and companion apps to all FreeBSD users. Latest and quarterly ports branches got a series of updates of the LibreOffice suite from 7.0.1 thru 7.0.4 releases, compilation patches for all Tier 1 architectures, and updates of all companion libraries. Some of our local and critical to build patches were sent to and accepted by upstream. Meanwhile, our WIP repository was moved to new home under official github.org/freebsd resources. The WIP repository also has a major update with development versions of the LibreOffice suite, version 7.1.0.0.beta1 for now. Release will be planned in March, 2021. We are looking for people to help the project. All unstable work with LibreOffice snapshots is staged in our WIP repository. The open bugs list contains all filed issues which need some attention. Patches, comments and objections are always welcome in the mailing list and bugzilla. __________________________________________________________ Ports On Non-x86 Architectures Contact: Mark Linimon It has been some time since the last report on the status of FreeBSD ports on non-x86 architectures. Traditionally, we have referred to these as "tier-2 architectures". However, aarch64 and powerpc64 have aspirations for tier-1. Also, although riscv64 is currently tier-3, it has aspirations for tier-2. * The big news is that, thanks to the FreeBSD Foundation (and the assistance of Philip Paeps), FreeBSD now has two new aarch64 boxes, which have replaced the previous, badly-aging, alternatives. For the first time since August, we once again have up-to-date aarch64 packages. * Thanks to the above, and the work of Emmanuel Vadot and others, some bitrot in aarch64 ports has been reversed. * Piotr Kubaj (pkubaj@) continues QA on powerpc64 (big-endian) ports. Almost everything that is buildable now does so. The Linux ports and some of the graphics drivers are excluded. Otherwise, powerpc64 is up to parity with amd64. * Piotr has also begun the task of bringing powerpc64le (little-endian) up to parity with powerpc64. Although several of the powerpc64 src committers (and your author) have a fondness for big-endian, the fact is that our most feasible path to getting graphics capability anywhere near parity with x86 is via the little-endian choice. * Mark Linimon (linimon@) has begun his own test-builds of ports on riscv64 just to ascertain overall buildability. Surprisingly, many ports do indeed build. Thanks to contributions from several people already working on riscv64, including John Baldwin (jhb@) with an LLVM fix, we are now able to build around 20,000 packages. NB: these packages are unofficial and not guaranteed. * The work of Kyle Evans (kevans@) on chasing bitrot in qemu has been key to work on both aarch64 and riscv64. All users are encouraged to update to the latest version. * Unfortunately mips/mips64 are badly in need of work. The fact that devel/libffi does not build on mips64 blocks nearly half the ports tree. Tasklist: * We need users of riscv64 to actually test the packages that have been built (so far, they have only been tested for buildability). Contact linimon@ if you are interested. * If anyone is still using mips/mips64 for other than the most trivial tasks, we would welcome patches. __________________________________________________________ Python 2.7 removal from Ports Links About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Ports Management Team URL: https://www.freebsd.org/portmgr/index.html [meta] Ports broken by Python 2.7 End-of-Life and removal URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D249337 Contact: Ren=E9 Ladan Contact: FreeBSD Ports Management Team As of January 2020, Python 2.7 reached its end-of-life after several years of extensions. Portmgr subsequently started the project of phasing Python 2.7 out of the Ports Tree by tagging lang/python27 for expiration on 2020-12-31. Last year, some 740 ports were removed from the Ports Tree as they were incompatible with Python 3, mostly because these ports were either unmaintained or abandoned upstream. During this process, there were several instances of an upstream still being active but where the upstream have not had the resources yet to upgrade their software to Python 3. A noticeable example of this is www/chromium and derived software, such as devel/electron7 and www/qt5-webengine. Portmgr is currently looking into ideas on how to minimize the impact of Python 2.7 on the Ports Tree while keeping Chromium and KDE 5 functional. As various software packages on the FreeBSD cluster itself also use Python 2.7, portmgr started coordinating with affected parties on upgrade plans. Currently there are 40 ports left that directly depend on Python 2.7 to build or run, and an unknown number of indirect ports. All those ports should eventually be upgraded to Python 3 or be removed too, ideally some time this year. Portmgr is currently cleaning up (unused) Python 2.7 code from ports which do not need Python 2.7. New ports should not be using Python 2.7 anymore, i.e. they should not have USES=3Dpython but instead something like USES=3Dpython:3.6+. So while this all looks rather invasive, it is not feasible to keep Python 2.7 around for much longer. Over time security vulnerabilities might show up which will likely no longer be fixed, because the Python Software Foundation no longer supports Python 2.7. Other problems are that the software gets outdated over time and thereby loses its usefulness as part of a development kit. Help needed: * Coordinate with postmaster on isolating or migrating away from mail/mailman * Coordinate with clusteradm (?) for upgrading svnweb and our wiki __________________________________________________________ Xfce on FreeBSD Links Xfce 4.16 Upstream Release Announcement URL: https://xfce.org/about/news/?post=3D1608595200 Xfce meta-port on FreshPorts URL: https://www.freshports.org/x11-wm/xfce4 Contact: Xfce team Contact: Guido Falsi The FreeBSD Xfce team (xfce@) work to ensure the Xfce desktop environment is maintained and fully functional on FreeBSD. This quarter the Xfce team are pleased to welcome Xfce 4.16 to the FreeBSD ports tree! Some of the highlights of this Xfce 4.16 release: * The panel now supports dark mode (enabled by default) and an animated autohide transition * A new panel plugin dubbed "statustray" which combines both StatusNotifier and legacy Systray items * Fractional scaling support was added to the display dialog (helpful on HiDPI displays) * A new tab in the "About Xfce" dialog shows basic system information like CPU or GPU type * The settings manager has improved search and filter capabilities * All settings dialogs now use window decorations drawn by Gtk (client side decorations) * The "Mime Settings" and "Preferred Applications" dialogs were merged into the "Default Applications" dialog * The Thunar file manager now supports pause for copy/move operations, and queued file transfer * Generating thumbnails for .epub (e-book format) was added to tumbler * A new default wallpaper and icon theme * The application finder now allows for sorting applications by "frecency" - a combination of frequency and recency * Dropped GTK2 support from all components and plugins For further details, refer to the Xfce 4.16 upstream release announcement. Due to GTK2 and libxfce4gui support being removed, some panel plugins and libraries will be removed since they no longer work with Xfce 4.16: * deskutils/orage * deskutils/xfce4-volumed * print/xfce4-print * science/xfce4-equake-plugin * x11/xfce4-embed-plugin * x11/xfce4-quicklauncher-plugin * x11/xfce4-wmdock-plugin * x11-toolkits/libxfce4gui WARNING: Unfortunately this update can reveal a bug in pkg which can cause files from the libexo package to be absent after upgrade. To avoid the issue, upgrade the libexo package by itself before the rest of the packages, as described in UPDATING entry 20210102. Thanks also to riggs@, Olivier Duchateau duchateau.olivier@gmail.com, woodsb02@, Sergey Dyatko sergey.dyatko@gmail.com, and ehaupt@ for their help and contributions. __________________________________________________________ Documentation Noteworthy changes in the documentation tree, in manpages, or in external books/documents. FreeBSD Translations on Weblate Links Translate FreeBSD on Weblate wiki URL: https://wiki.freebsd.org/DocTranslationOnWeblate FreeBSD Weblate Instance URL: https://translate-dev.freebsd.org/ Contact: Danilo G. Baio Contact: Edson Brandi In search of new contributors an article was published in the September/October 2020 issue of the FreeBSD Journal about How to Become a FreeBSD Translator. During the whole year we received new contributors to the effort; numbers are still growing and we are receiving translations almost daily on our Weblate platform. Q4 2020 Status * 11 languages (1 new language) * 116 registered users (69 new users since 2020q1) Languages * Chinese (Simplified) (zh_CN) * Chinese (Traditional) (zh_TW) * Dutch (nl_NL) - Added * French (fr_FR) * German (de_DE) * Italian (it_IT) * Norwegian (nb_NO) * Persian (fa_IR) * Portuguese (pt_BR) * Spanish (es_ES) * Turkish (tr-TR) We want to thank everyone that contributed, translating or reviewing documents. And please, help promote this effort on your local user group, we always need more volunteers. __________________________________________________________ DOCNG on FreeBSD Links DOCNG Website Repo URL: https://gitlab.com/carlavilla/freebsd-hugo-website DOCNG Documentation Repo URL: https://gitlab.com/carlavilla/freebsd-hugo-documentation DOCNG Share Repo URL: https://gitlab.com/carlavilla/freebsd-hugo-data Contact: Sergio Carlavilla The Doc New Generation project is finished. The switch-over date will be Saturday, January 23rd. The objective of using Hugo and AsciiDoctor is to reduce the learning curve and let people to start quickly contributing to our documentation system. Other benefits of using Hugo is that we can use other technologies aside from AsciiDoctor, like MarkDown, RST, Pandoc, etc. You can find a work in progress on updating the FreeBSD Documentation Project Primer to Hugo/AsciiDoctor. __________________________________________________________ Miscellaneous Objects that defy categorization. Prometheus NFS Exporter Links Contact: Alan Somers FreeBSD's nfsstat(8) utility provides a wealth of statistics, but I wanted to monitor them with Prometheus. Screen-scraping the --libxo output would've been possible, but some of the stats are preprocessed in a way that interferes with my Prometheus processing. So I wrote a separate utility that publishes the raw stats provided by the kernel. Along the way I found and fixed a few bugs in nfsstat, too. If anybody is interested, I can add a port for it. Sponsor: Axcient __________________________________________________________ Third-Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. FreeBSD Aarch64 under VMWare ESXi-ARM Fling Links ESXi-ARM Fling URL: https://flings.vmware.com/esxi-arm-edition FreeBSD Under VMWare ESXi-ARM Fling URL: https://vincerants.com/freebsd-under-vmware-esxi-on-arm-fling/ FreeBSD on ESXi-ARM Fling: Fixing Virtual Hardware URL: https://vincerants.com/freebsd-on-esxi-arm-fling-fixing-virtual-ha= rdware/open-vm-tools for FreeBSD VMWare ESXi-ARM Fling URL: https://vincerants.com/open-vm-tools-on-freebsd-under-vmware-esxi-= arm-fling/ Contact: Vincent Milum Jr VMWare is a company that produces a commercial hypervisor known as vSphere ESXi for AMD64 and i386. In early October, they released a tech demo hypervisor for ARM Aarch64 which runs on ARM ServerReady hardware as well as single board computers such as the Raspberry Pi 4b (4GB and 8GB models). This new hypervisor is known as VMWare ESXi-ARM Fling. Since the release of ESXi-ARM Fling, work has been done on both the hypervisor as well as FreeBSD, to make the two more compatible with one another. Even though the work was initially done to make these two work better together, the work overall has been more general purpose for FreeBSD in support of both bare-metal Aarch64 installations as well as running FreeBSD under other hypervisors such as QEMU. An example of others building off of this work is Twitter user astr0baby getting FreeBSD working under QEMU on a new Apple M1 system. When ESXi-ARM Fling first released, to get FreeBSD to work under it, the process required taking the Aarch64 premade VMDK file, uploading it to the hypervisor storage, and then running a series of CLI commands to convert the disk image to a supported file format. The initial work done was to get the FreeBSD Aarch64 ISO bootable and with the required drivers to complete the install process. With this, users can do fresh installs of FreeBSD Aarch64 using the same methods they would use for AMD64 or i386 under ESXi. The CD-ROM driver's inclusion into FreeBSD 12 barely missed the cut-off date for 12.2-RELEASE. However, the very first 12.2-STABLE build published for Aarch64 includes the CD-ROM driver. FreeBSD 13-CURRENT also includes this driver. Due to this, only 12-STABLE and 13-CURRENT support fresh CD ISO installations. The next step was getting the major pieces of virtual hardware working. This included adding more USB controllers, the vmxnet virtual network card, and pvscsi para-virtual SCSI drivers added to Aarch64 GENERIC. There is a known bug in ESXi-ARM Fling's virtual UEFI that prevents booting from pvscsi, so for the time being the boot device must be on a virtual disk attached to the SATA controller inside the VM. ESXi-ARM Fling uses a new virtual SVGA device which currently does not have working drivers on any platform, as the specifications are not finalized yet. Due to this, only efi-fb/scfb is available for console and Xorg for the time being. The VMCI driver is currently not compiling at all. This driver has sections of x86 assembly code that will need to be converted over to ARM. This would be a great area for anyone to look into that is experienced with converting assembly language! At ESXi-ARM Fling launch, there was a hypervisor bug preventing more than 1 vCPU from working inside FreeBSD. This has since been fixed, allowing up to 8 vCPUs. Going beyond this requires a a patch to FreeBSD, which was authored by VMWare developer Cypou. Things that are currently fixed/working: * Booting from CD ISO image * Virtual USB 2.0 controller * Virtual USB 3.1 controller * Virtual USB Keyboard * Virtual USB Mouse * vmxnet3 Virtual Network Card * pvscsi Para-Virtual SCSI Storage Controller * open-vm-tools Guest Virtual Machine Tools * Xorg Enhanced Mouse Driver (untested) * Multi-Core CPU (up to 8 vCPUs inside guest) Things that are still broken: * Booting from pvscsi * Xorg SVGA Driver * vmci Virtual Machine Communication Interface * Multi-Core CPU (more than 8 vCPUs) With all of this done, it has made working on the Aarch64 ports collection easier by having a high quality virtualization environment for development and testing. This environment has already been used to update the ZeroTier port and Facebook's RocksDB used in the MariaDB port. FreeBSD now has a Discord chat! Discussion about FreeBSD on Aarch64 in general takes place in our #embedded channel. Despite the name, we discuss all levels of ARM development, from large servers, to virtualized environments, all the way down to single board computers. __________________________________________________________ Bastille Links Bastille GitHub URL: https://github.com/bastillebsd/bastille Bastille Templates URL: https://gitlab.com/bastillebsd-templates Bastille Website URL: https://bastillebsd.org Contact: Christer Edwards Bastille is an open-source system for automating deployment and management of containerised applications on FreeBSD. Bastille Templates automate container setup allowing you to easily reproduce containers as needed. Bastille is available in ports as sysutils/bastille. Q4 2020 Status In Q4 2020 Bastille merged some exciting new features. Changes include: * full adoption of the previously experimental Bastillefile format * new config sub-command * default templates included and applied by default * support for -CURRENT jails on -CURRENT hosts * support for 32bit containers on 64bit hosts * support in templates for dynamic arguments & defining variables * over two dozen bug fixes and general improvements More details about Bastille Releases. upstream was updated to 0.8.202010101 (latest). ports (sysutils/bastille) was updated to 0.7.20200414. __________________________________________________________ CheriBSD Links Contact: Alex Richardson Contact: Andrew Turner Contact: Brooks Davis Contact: Edward Tomasz Napierala Contact: George Neville-Neil Contact: Jessica Clarke Contact: John Baldwin Contact: Robert Watson Contact: Ruslan Bukin CheriBSD extends FreeBSD to implement memory protection and software compartmentalization features supported by the CHERI instruction-set extensions. There are three architectural implementations of the CHERI protection model: CHERI-MIPS, CHERI-RISC-V, and Arm's forthcoming experimental Morello processor (due late 2021). CheriBSD is a research operating system with a stable baseline implementation into which various new research features have been, or are currently being, merged: * Arm Morello - In October, we released a developer preview of CheriBSD ported to Arm's Morello architecture. This release supports a dynamically linked runtime and is generally functional. It was cut from a development branch and work is in progress to merge the contents of this branch with the CheriBSD main line. We anticipate producing a new release from this branch in early 2021. * Kernel spatial memory safety (pure-capability kernel) - The current CheriBSD kernel is a hybrid C program where only pointers to userspace are CHERI capabilities. This ensures that the kernel follows the intent of the application runtime and cannot be used to defeat bounds on application pointers. We have developed and will soon merge a pure-capability kernel where all pointers in the kernel are appropriately bounded capabilities. This vastly reduces the opportunity for buffer overflows. This spatial memory safety lays the groundwork for future work such as device driver compartmentalization and kernel temporal safety. * Userspace heap temporal memory safety (Cornucopia) - CHERI capabilities provide the necessary features to enable robust and efficient revocation of freed pointers. With Cornucopia we have implemented a light-weight revocation framework providing protection from use-after-reallocation bugs with an average cost below 2%. We aim to bring these overheads down further over the next year and merge this functionality into the mainline CheriBSD. * Syncing with upstream FreeBSD - We spent considerable time this quarter catching up with FreeBSD-CURRENT. As of the beginning of December, we had caught up. Merges are currently paused while we work to land Morello and pure-capability kernel changes. In the interim, we have performed a test merge between our tree based on the legacy export of the FreeBSD tree to git and the new FreeBSD git repository. The process went smoothly and is expected to have few impacts. * We have been working on updating the arm64 bhyve from Politehnica University of Bucharest to have it committed to FreeBSD. We have been upstreaming initial changes to help support this. __________________________________________________________ Embedded Lab Project Links FreeBSD Embedded Lab Design URL: https://www.funkthat.com/gitea/jmg/fbsdembdev Lab API code URL: https://www.funkthat.com/gitea/jmg/bitelab Contact: John-Mark Gurney The Embedded Lab Project's goal is to make SBCs and other devices more accessible to developers. Despite SBCs often being inexpensive, it is not inexpensive to maintain them, in terms of the cost of time to keep them up to date, infrastructure to support them, etc. The goal of this project is to support and enhance the existing CI work but also make it easier for developers to test their code and changes on one, or many different boards. Once the work is [mostly] complete, I will host a lab that will be freely available to everyone who has a FreeBSD.org account. Information about this will be sent once it is closer to launch. The core part of the architecture is each time a board is reserved via the API, a new jail is created which contains the serial console tty, an interface for internet access, and an interface that is connected to the board's ethernet port (assuming it has one). This allows a clean system for each run, and allows complete control over the network interfaces to support netbooting and other development. The jail will have a basic set of FreeBSD packages installed that matches the board. Part of the API will also allow power cycling the board to aid in debugging. This part is relatively extensible, so adding additional modules to provide additional support should not be difficult. The API includes support for running interactive commands in the jail. This will make it easy to script control of the environment, such as directly running an expect script against the serial console, or even just running a script in the jail. The work is progressing well, and currently a single board, a Pine64 A64-LTS, is integrated and working. Board reserves and releases are working, along with the ability to run commands in the jail via the API. Power control is functional, and is currently using a PoE smart switch to control power. Work has stalled on being able to use the SDWire with an environment due to power issues. USB is not made for power isolation, which is causing issues w/ power control. The existing board, the A64-lTS, is using a USB serial console adapter that is opto-isolated, ensuring that there is no problems w/ power control. But there I have not found a solution for high speed USB. I believe that cutting the VBUS (power) line of a USB cable would allow fine grain power control, but tests have not been conducted yet. Sponsor: The FreeBSD Foundation FreshPorts FreshPorts blog Dan Langille dan@langille.org FreshPorts, and its sister site, FreshSource, have reported upon FreeBSD commits for 20 years. They cover all commits, not just ports. FreshPorts tracks the commits and extracts data from the port Makefiles to create a database of information useful to both port developers and port users. For example, https://www.freshports.org/security/acme.sh/ shows the history of this port, back to its creation in May 2017. git The work to become git-ready is mostly complete. Both src and doc commits are flowing into devgit.freshports.org. Some work is required on various issues, but nothing that stops the flow of commits into the database. Help wanted Amazon have donated enough to try FreshPorts on AWS. I need help with the following: * getting IPv6 working * working with RDS If you can help with this, please contact me. Thank you. Thank you __________________________________________________________ helloSystem Links Documentation URL: https://hellosystem.github.io/docs/ Contact: Simon Peter Contact: #helloSystem on irc.freenode.net, mirrored to #helloSystem:matrix.org on Matrix helloSystem is FreeBSD preconfigured as a desktop operating system with a focus on simplicity, elegance, and usability. Its design follows the "Less, but better" philosophy. It is intended as a system for "mere mortals", welcoming to switchers from a world in which a global menu bar exists, the Command key is used rather than Control, and applications are contained in .app bundles. helloSystem grew out of frustration with usability shortcomings of existing open source desktop environments. FreeBSD was chosen as the base because it offers one consistent base system rather than a fragmented landscape of distributions lacking a common platform. helloSystem aims at providing a "it just works" out-of-the-box user experience in which a non-technical user can just use the system without ever opening the terminal, without having to configure anything, and without ever seeing white text on a black background scroll by during system boot. Technologies embraced include DNS-SD/Zeroconf (also known as Bonjour), IPP Everywhere (also known as AirPrint), eSCL (also known as AirScan), etc. Prerelease installable Live ISO images are available. Help is needed in a number of areas, especially: * FreeBSD/kernel: allowing to put the system into a read-only disk image with a writable overlay, e.g., using unionfs * Qt, Python: writing various easy-to use frontends for FreeBSD/OpenZFS functionality, e.g., Disk Utility.app * Testing and bugfixing __________________________________________________________ K8S-bhyve Links K8S-bhyve URL: https://k8s-bhyve.convectix.com K8S-bhyve URL: https://github.com/k8s-bhyve Kubernetes URL: https://kubernetes.io/ Contact: Kirill Ponomarev Contact: Oleg Ginzburg K8S-bhyve is opensource project concentrating primarily on deploying and use of kubernetes on FreeBSD/bhyve in a more agile and more comfortable manner. We are going to provide distributed multi-DC environment or just stand-alone clusters with native PV/PVC support. For 2020Q4 we made and published a k8s-bhyve image which you might install with ISO/memstick, as well as with bsdinstall. __________________________________________________________ Puppet Links Puppet URL: https://puppet.com/docs/puppet/latest/puppet_index.html Puppet's FreeBSD slack channel URL: https://puppetcommunity.slack.com/messages/C6CK0UGB1/ Bolt URL: https://puppet.com/docs/bolt/latest/bolt.html Choria URL: https://choria.io/ Contact: Puppet Team Since our last status report a few months ago, the FreeBSD ports tree has seen the addition of the Choria (sysutils/choria) orchestration tool, and the Puppet Platform 7 with the Puppet Agent (sysutils/puppet7), Puppet Server (sysutils/puppetserver7) and PuppetDB (databases/puppetdb7). Older versions of Puppet (5 and 6) are still in the ports tree, allowing a smooth transition, but please note that Puppet 5 will reach EOL soon, and as it is not compatible with the recent ecosystem provided by FreeBSD (i.e. it is not compatible with the latest version of Ruby and depends on old FreeBSD primitives not available anymore), it is recommended to update at least to Puppet 6 as soon as possible. Ports depending on Puppet (e.g. sysutils/rubygem-bolt) have been updated to add options allowing to choose which version of Puppet to depend on. For now, the default is Puppet 6, but we plan to switch the default to Puppet 7 in a few weeks, probably when Puppet 5 will have reached EOL. __________________________________________________________ --zy55m5us4qgrxnhl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAmADAx9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87o4Pwf9HmTH71pcgj7E/CUgvuu8bIpiBZ94xO5o21s0f/mxcZkrJd2TZkFzea1q iswjG2co4TzgQ1bSnKqbeXGhVshVbywR0fWPpS/Wv9umpef40qKtJTbNyme7MYSV HmUMC2/QxiAJaKJDf6N5wHHxlJMKtLVT2HccdlsXpU+2rkqsPnDYsAPr6s2wew9K yfl2Sl2rjFf41uXrpBXYwlJq9qDMCWBLkFQUAkgTzTmlfbC0LM8oUvH4B2DIuWQ6 D3jqbE3IG/d47J3sJWZmgNsbfdG7uMJ8ikWUiZaBP7srFV7Dc17qKuX+RSzlaTHt Zj7EuxfDsoTtGNkJxH/ni/d7SIHAkA== =XcDq -----END PGP SIGNATURE----- --zy55m5us4qgrxnhl-- From owner-freebsd-hackers@freebsd.org Sat Jan 16 17:36:23 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E1FA24E5E13 for ; Sat, 16 Jan 2021 17:36:23 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJ4wR1Zt6z4ZpL for ; Sat, 16 Jan 2021 17:36:22 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f48.google.com with SMTP id u17so24612296iow.1 for ; Sat, 16 Jan 2021 09:36:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E/TwBEjxjlyRKMHqz6hOLtg6nNAIdohIHrM5MTJaRKk=; b=sxT9OxhM+pDkHlSsZMnmh3Z0rHi2gPUWExoyyipzpaJlTSnvZWNotdOWiBeWo9hbla s1Esj9D+y+OI7noo/TxBnValmB7yLbmcHcl5gKPsZ4T4LrbB7uExAOznL93ZV6Q7vdZV ukkmi5NCTImrIplkMYv6M9ZjUr4/9VEHLYjNuvtLzMFrWvBk66BG2lH6SUXubrUVu3st bq2N6r30BxE+a9srCJF0BruQCkPJRRoYsSpX7xLeNLG6pd6ZA34g3rRBN1HsOX51qdnM cPpFH7GEnf32BqXB1OVTlB1BBTcK8T2GIh5SB6FWCpUp4Ph94kIyoWH51nc3sET8dJR7 hJ7w== X-Gm-Message-State: AOAM533v6ZRnuARpFA3vLkxZdldib+nmiQ6vfb/S1GhbuftejdSSvxFw VgWUnbRssifUreslTpYtFRf0zStpoMnHuCM7teQ= X-Google-Smtp-Source: ABdhPJxiDXjnBc3npo+kbkTyyFohjHNUXGAtqqPov7B4K0NYsnuMYgGK9h63hfLex1rphTOj1Giupgl05Tm6F6GDxmM= X-Received: by 2002:a92:1fd6:: with SMTP id f83mr10443577ilf.11.1610818581937; Sat, 16 Jan 2021 09:36:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Sat, 16 Jan 2021 12:36:03 -0500 Message-ID: Subject: Re: Problem building releng/12.2 branch To: "dmilith ." Cc: freebsd-hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4DJ4wR1Zt6z4ZpL X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.48 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.166.48:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[carpeddiem]; R_DKIM_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; SPAMHAUS_ZRD(0.00)[209.85.166.48:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.48:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.48:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2021 17:36:23 -0000 On Fri, 15 Jan 2021 at 17:51, dmilith . wrote: > > Hello, I'm trying to build releng/12.2 branch on 12.2-RELEASE system > and build crashes with: > > /usr/src/contrib/ofed/libibverbs/ibverbs.h:39:10: fatal error: > 'infiniband/driver.h' file not found > #include > ^~~~~~~~~~~~~~~~~~~~~ > ===> lib/ofed/libibumad (obj,all,install) > 1 error generated. Is your build host FreeBSD or HardenedBSD? Building releng/12.2 from 12.2-RELEASE certainly works. From owner-freebsd-hackers@freebsd.org Sat Jan 16 20:20:13 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2145B4E9462 for ; Sat, 16 Jan 2021 20:20:13 +0000 (UTC) (envelope-from "") Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJ8YS1zSwz4lHn for ; Sat, 16 Jan 2021 20:20:12 +0000 (UTC) (envelope-from "") Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 147632400FD for ; Sat, 16 Jan 2021 21:20:10 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4DJ8YP1Qs8z9rxw; Sat, 16 Jan 2021 21:20:09 +0100 (CET) From: Walter von Entferndt To: Mark Millard Cc: freebsd-hackers@freebsd.org Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) Date: Sat, 16 Jan 2021 21:19:44 +0100 Message-ID: <1648904.MsCH1bHPGx@t450s.local.lan> In-Reply-To: <7623BADF-5FA9-4712-8D85-A1D2B82E3F74@yahoo.com> References: <1725854.nNRVL2rNYg@t450s.local.lan> <7623BADF-5FA9-4712-8D85-A1D2B82E3F74@yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1974885.4WAli8B44Z" Content-Transfer-Encoding: 7Bit X-Rspamd-Queue-Id: 4DJ8YS1zSwz4lHn X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=posteo.net (policy=none); spf=none (mx1.freebsd.org: domain of mout02.posteo.de has no SPF policy when checking 185.67.36.142) smtp.helo=mout02.posteo.de X-Spamd-Result: default: False [-2.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; CTE_CASE(0.50)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-patch]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[185.67.36.142:from]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ASN(0.00)[asn:8495, ipnet:185.67.36.0/23, country:DE]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; DMARC_POLICY_SOFTFAIL(0.10)[posteo.net : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2021 20:20:13 -0000 This is a multi-part message in MIME format. --nextPart1974885.4WAli8B44Z Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" At Samstag, 16. Januar 2021, 11:23:03 CET, Mark Millard wrote: > This is the sort of thing where FreeBSD and Linux use a C subset > for the specific issue, as defined by POSIX.1-2017/"The Open Group > Base Specifications" Issue 7, 2018 edition/IEEE STd 1003-2017/... . > For example: > > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html > > reports (in its own terminology that may not be a full match to C's): > > QUOTE > clock_t shall be an integer or real-floating type. time_t shall be an > integer type. END QUOTE > > Limiting to such a time_t is easier to cover. [...] > Restricting time_t to integer types leaves a compatible context. > So: no "conflict" in that respect. > My understanding is that check_mktime.c is a test program called by autoconf or such, designed to run on various UNIX platforms? I mean it does not only need to run on BSD & Linux. Maybe something like this will cover the most cases in practice: --- check_mktime.c.patch --- --- check_mktime.c.orig 2021-01-15 03:19:33.962253000 +0100 +++ check_mktime.c 2021-01-16 21:00:36.160616000 +0100 @@ -3,6 +3,13 @@ # include # include # include +# include +#include +# include /* printf() */ +# include /* CHAR_BIT */ +#if 0 +# include /* format spec PRIX64: ll/l + X on 32/64-bit arch */ +#endif /* Work around redefinition to rpl_putenv by other config tests. */ #undef putenv @@ -16,6 +23,78 @@ }; #define N_STRINGS (sizeof (tz_strings) / sizeof (tz_strings[0])) +/* Count the bits set in any unsigned integer type. + * Returns the precision (width - padding bits - sign bit) iff given + * the xxx_MAX value of any integer type, signed or unsigned. + * From SEI CERT C Coding Standard: + * Rules for Developing Safe, Reliable, and Secure Systems (2016) + */ +size_t +popcount (num) +uintmax_t num; +{ + size_t cnt = 0; + + while (num != 0) + { + if (num % 2 == 1) + cnt++; + num >>= 1; + } + return cnt; +} +#define PRECISION(max_value) popcount(max_value) + +/* Guess the maximum value of a time_t from it's storage width. + * ASSERT time_t is not a floating point, or of any arcane width, or unsigned. + * Only 4...8 byte width of a time_t are tested. + * On error: returns (time_t)(-1) + */ +time_t +guess_time_t_max () +{ + time_t t0, t1 = (time_t)(-1); + size_t size, prec; + + switch ((size = sizeof(time_t))) + { + case 4: + prec = PRECISION((time_t) 0xFFFFFFFF); + break; + case 5: + prec = PRECISION((time_t) 0xFFFFFFFFFF); + break; + case 6: + prec = PRECISION((time_t) 0xFFFFFFFFFFFF); + break; + case 7: + prec = PRECISION((time_t) 0xFFFFFFFFFFFFFF); + break; + case 8: + prec = PRECISION((time_t) 0xFFFFFFFFFFFFFFFF); + break; + default: + prec = 1; + break; + } + prec--; /* assumption: time_t is signed */ + if (prec) + { + t0 = (time_t) 1 << (prec - 1); + t1 = t0|(t0 - 1); + } + + /* FIXME not portable: time_t can be floating point type, + * or another integer type other than long or long long. + * + fprintf (stderr, "time_t_max\t= 0x%"PRIX64"\n", t1);*/ + fprintf (stderr, "sizeof(time_t)\t= %2zd byte\n", size); + fprintf (stderr, "precision\t= %2zd bit\n", prec); + fprintf (stderr, "padding\t\t= %2zd bit\n", size*CHAR_BIT - prec - 1 /* sign */); + + return t1; +} + /* Fail if mktime fails to convert a date in the spring-forward gap. Based on a problem report from Andreas Jaeger. */ static void @@ -106,9 +185,7 @@ time_t t, delta; int i, j; - for (time_t_max = 1; 0 < time_t_max; time_t_max *= 2) - continue; - time_t_max--; + time_t_max = guess_time_t_max (); delta = time_t_max / 997; /* a suitable prime number */ for (i = 0; i < N_STRINGS; i++) { @@ -128,3 +205,4 @@ spring_forward_gap (); exit (0); } +/*! vi: set ai tabstop=8 shiftwidth=2: */ --- -- =|o) "Stell' Dir vor es geht und keiner kriegt's hin." (Wolfgang Neuss) --nextPart1974885.4WAli8B44Z Content-Disposition: attachment; filename="check_mktime.c.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="check_mktime.c.patch" --- check_mktime.c.orig 2021-01-15 03:19:33.962253000 +0100 +++ check_mktime.c 2021-01-16 21:00:36.160616000 +0100 @@ -3,6 +3,13 @@ # include # include # include +# include +#include +# include /* printf() */ +# include /* CHAR_BIT */ +#if 0 +# include /* format spec PRIX64: ll/l + X on 32/64-bit arch */ +#endif /* Work around redefinition to rpl_putenv by other config tests. */ #undef putenv @@ -16,6 +23,78 @@ }; #define N_STRINGS (sizeof (tz_strings) / sizeof (tz_strings[0])) +/* Count the bits set in any unsigned integer type. + * Returns the precision (width - padding bits - sign bit) iff given + * the xxx_MAX value of any integer type, signed or unsigned. + * From SEI CERT C Coding Standard: + * Rules for Developing Safe, Reliable, and Secure Systems (2016) + */ +size_t +popcount (num) +uintmax_t num; +{ + size_t cnt = 0; + + while (num != 0) + { + if (num % 2 == 1) + cnt++; + num >>= 1; + } + return cnt; +} +#define PRECISION(max_value) popcount(max_value) + +/* Guess the maximum value of a time_t from it's storage width. + * ASSERT time_t is not a floating point, or of any arcane width, or unsigned. + * Only 4...8 byte width of a time_t are tested. + * On error: returns (time_t)(-1) + */ +time_t +guess_time_t_max () +{ + time_t t0, t1 = (time_t)(-1); + size_t size, prec; + + switch ((size = sizeof(time_t))) + { + case 4: + prec = PRECISION((time_t) 0xFFFFFFFF); + break; + case 5: + prec = PRECISION((time_t) 0xFFFFFFFFFF); + break; + case 6: + prec = PRECISION((time_t) 0xFFFFFFFFFFFF); + break; + case 7: + prec = PRECISION((time_t) 0xFFFFFFFFFFFFFF); + break; + case 8: + prec = PRECISION((time_t) 0xFFFFFFFFFFFFFFFF); + break; + default: + prec = 1; + break; + } + prec--; /* assumption: time_t is signed */ + if (prec) + { + t0 = (time_t) 1 << (prec - 1); + t1 = t0|(t0 - 1); + } + + /* FIXME not portable: time_t can be floating point type, + * or another integer type other than long or long long. + * + fprintf (stderr, "time_t_max\t= 0x%"PRIX64"\n", t1);*/ + fprintf (stderr, "sizeof(time_t)\t= %2zd byte\n", size); + fprintf (stderr, "precision\t= %2zd bit\n", prec); + fprintf (stderr, "padding\t\t= %2zd bit\n", size*CHAR_BIT - prec - 1 /* sign */); + + return t1; +} + /* Fail if mktime fails to convert a date in the spring-forward gap. Based on a problem report from Andreas Jaeger. */ static void @@ -106,9 +185,7 @@ time_t t, delta; int i, j; - for (time_t_max = 1; 0 < time_t_max; time_t_max *= 2) - continue; - time_t_max--; + time_t_max = guess_time_t_max (); delta = time_t_max / 997; /* a suitable prime number */ for (i = 0; i < N_STRINGS; i++) { @@ -128,3 +205,4 @@ spring_forward_gap (); exit (0); } +/*! vi: set ai tabstop=8 shiftwidth=2: */ --nextPart1974885.4WAli8B44Z-- From owner-freebsd-hackers@freebsd.org Sat Jan 16 22:08:41 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 10B2E4EC9D2 for ; Sat, 16 Jan 2021 22:08:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJByc0RGkz4tF2 for ; Sat, 16 Jan 2021 22:08:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1610834918; bh=4aJX7R16KF7lyY/K0Zrurqhi/C3QkrrvcPKLDzPEKi0=; h=Subject:From:Date:To:From:Subject:Reply-To; b=tBR6cL1sf8yerseyze6T8cI1RvZ2e9yvdHbhwcfYsydLqKNIJ7mWaG92NGtQCbgWIgNeT3oaLwTXjBjdSJyNbqvxoRqqZurtQ/qBHpY2KCPv1UycxjUGkux9tZDY/VdiWYXkD/PL8F5SjMvOAxT7MpBAIYq7GtV0vXK5GCFOmvZstYP+rDirI/HVWDDt15haS0UaPCOpOsPzOXf4QMFnbsdbxiLNC3gXZwlqb9fSFAwSIx7qSvOAvH/asE3LkL56hzclL4cqwdwu4GXGgtZrJQegpRqmfUhAoDPO8wSreBZnENZKM1t5AOA6icL/54lTnIDR/2FxDGQSEeP2JkL0+w== X-YMail-OSG: iEM4MhgVM1kL3I83halJpBo6obnSy7ZtEIY4q8WiOTL4JtuQBGHqd2.cQUXZd4i M8ysuM0sXZhUwGHD7_Y4irNCKYNHWv6CaoPBg6l_hs_PVvr4txiMepa75mM0ks0iM7Itf8Oh67By rF9FwJo7f0rVt6X47.9_lM0mJl3a6qcrCplas1v7Q_5sVdTnn3Sa5P6grm2YeBYpzZW35LN6Yp9F zf6iyRciGm7093G6mfdD_GSo_BAg0LFlRbiDUNay1m.9SGyyIjXJALLbF3DJlXDGgjIkoWuRvH7Z LP0lowUq3DnbK6wJyULLVJ_mAKTO7qLVgxe8m1a_64JtyzFPaRV9tubNMpLAx1f60YdxzUkV03oW fi6zPcI80lXlaBNaflxLRUPPRJh42yJjgKUOkybbH8tBQNULXo0wAZf_OwBy8Slo1kYyeuN7bjhJ rkqFUZeNVHuN7TxBmzC0w1RmyZveDwAuSg7FFZb_xxGyukvIzvocF78WSZ.OzJXmwaCfKtaPrvI6 cMgbTa4WRXQ7WQGk6Fzsgyx7WeS_JeJqR4Xx_z_lniRNdr.JVd3WM9qxZFQ5UdsLiTDNC29nfr2i G6tLsOIpjoQYmFX1_baS4UDofBEUJjX6NCSlK14xnGtiXM.l7wSsJdXGsEG6uJuIAahUXLPLyiBW aJm6MOVJ79DBeGmB_K.5Wvna05z62HLgse5VC1bvZuMECa7jg66dAHCyxZHo2g63uJnvvZMEODfY jFijaN7PiKoINWQ4xyMbYKJlwIVnhOaE3adyIjsZ0F9CQmhMUmP4wPdR0SE_sAAhQxKsoMa79zFq 65xXZMeB69QgGtzOY15LlThqkGXOhNni8yGOIh8Foz53914EOPeE77AiAX4.Gl_Da3F6btRE_zu9 wMVRQc.Jxagl2p0ebNl7i4CZSNvQlapXL.AhKuFkMwKh1SC5ZMEgqRYnrhoiBXAnKceCRpSZQyuK hxNWBog1EJ3ddadB5KisXJOkMNPR7dT.baBgp5..m79R6NItUhTd07tsqn5nqlG8RibW55icTzCA q9LdHwVeiaCSjw90M2pJbv60ZVUzFVUA7B1TajtWHb3_WzjbUHu8G6orV4LBJazeExYcx99p.25Z 2nAtpT50wfMbbCTs7GOd2CwBupWt4hg7lfREyY.ZBH.9cmOFeN1PwcxOWbbBzdnk6pDifohc_oND XY3T0x9J5eD0vT0uFThnNIcWI_frntpVzuJRr78kGdWSCirUkBuzVaDvWgkAJMTVV2tQ2.oQ956p Q09JZrTu..x9kQ7vjT9h4xoAzbXdn.u4ycIqMJ6lDFDoSorvRug5EyJUDJA2YnPWTEGxTQkq3Dq4 HF83yW.mKPUINyZ0AGAXbA6ZbPAOHnm4Tq1a0PScsh0sAKEe9spgSzCeZCuxmPB1lhkebG3HLOyt HBX85xJjTWyLJAtJKyn9PZB2WnpNcpSvG0Ojnv4POVF6Smwre65icdlht0hEPZEI8GMB636bMLF6 Oe5RaAVlzUBoxlpLChoTdygoSsX7sZz0WLLjG6M60dIqThdcyttBGfSHUnaoIe0GnEqYWWhZZmZC UABreTwgNLpZ7BoctfAIqN_kgHytc3aNtmZqFXeaqertz_vBUJhX6LZURXQco7ujrxxikomVL4Uy qiZq88Q3cTS1xWgH8PX9ins5lB42tY6r2xmhuiBAj.QNicaMIbYvsNon4BMaZyhNmF3thMpdx4b3 uIMAdCz337h9mDcLVGamRha51gdxlJ9EDDJHMzGCEVvp2J7uvllV6E3CdsPMgDE1g5RqeCqvONK5 CXfdjcY.stvPBOsXuPv2N0MMCDorpLoFqNt8H829vK6HUS_g5ui1SP8bZo27CtJPO5EfvumsUbvu Ktjyz4hgPXYGW4GScIgw0Mpl0Ix0JObL7A1j690f318WQDK32fS94sWq_n3nYVWgbtIVtJMthU89 p8ws4hwSXYobO_CpVdGW5Z8rQ1vFjIS19Go5cYwdODrf.wfE0Ct7LwaaRyOgH7_OebmaVPbs28Wz jMIhP0KZvSVyy7FwvrJtd5Mj.EUO.Kqo_TEZhkur4ISPASVyyKMdbm1o6Uj_KOxqdH_nJHzpJazt IcG.vRYfE.DZkUvdHVj7QLP7YOlOIxYBKAStFBo_JThrumn1v7W7VF0JbM._r548EZ1M2RnPmJug E7UTO_MdOivjcmlIYHtsG9a0rlzeyM4oh2mwEP2yXnrLcgbbXXn5OVdfYNt.X4jX_1y2RzG6bVaf pIUTA7qo9U78sgyXO6NFE2zgu8WgbwTwVmPpiOrVN_xifIGSLb0U8NgZD0tN3BYBFHNiew_IkRA1 PnpuRVrn1opHR6Oi7dLBvhRKDxTAhYduvRx7D4JAgNiLw33R4F37rWh51YD7MRLtKn.MBFjxBPfm CI2vbax_WXwYhiOT7KfqL.Vo46jupM2GkPIJ8QIZZ_fmNNRL3H8Bk.ia.qQH2TtG3y0nGhXiqrDK SYSItnW.SBCXJgu5z2RdizUkrUnHg42QknV114qiUGM0Ugvi1dXHlsgkHOQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 16 Jan 2021 22:08:38 +0000 Received: by smtp415.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 82fc3c64ba34c705184f81013a2bbfc7; Sat, 16 Jan 2021 22:08:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) From: Mark Millard In-Reply-To: <1648904.MsCH1bHPGx@t450s.local.lan> Date: Sat, 16 Jan 2021 14:08:30 -0800 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1725854.nNRVL2rNYg@t450s.local.lan> <7623BADF-5FA9-4712-8D85-A1D2B82E3F74@yahoo.com> <1648904.MsCH1bHPGx@t450s.local.lan> To: Walter von Entferndt X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DJByc0RGkz4tF2 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.147:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.147:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2021 22:08:41 -0000 On 2021-Jan-16, at 12:19, Walter von Entferndt wrote: > At Samstag, 16. Januar 2021, 11:23:03 CET, Mark Millard wrote: >> This is the sort of thing where FreeBSD and Linux use a C subset >> for the specific issue, as defined by POSIX.1-2017/"The Open Group >> Base Specifications" Issue 7, 2018 edition/IEEE STd 1003-2017/... . >> For example: >>=20 >> = https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html= >>=20 >> reports (in its own terminology that may not be a full match to C's): >>=20 >> QUOTE >> clock_t shall be an integer or real-floating type. time_t shall be an >> integer type. END QUOTE >>=20 >> Limiting to such a time_t is easier to cover. [...] >> Restricting time_t to integer types leaves a compatible context. >> So: no "conflict" in that respect. >>=20 > My understanding is that check_mktime.c is a test program called by = autoconf=20 > or such, designed to run on various UNIX platforms? I mean it does = not only=20 > need to run on BSD & Linux. QUOTE ( from https://en.wikipedia.org/wiki/POSIX ) The Portable Operating System Interface (POSIX) is a family of standards = specified by the IEEE Computer Society for maintaining compatibility = between operating systems.[1] POSIX defines the application programming = interface (API), along with command line shells and utility interfaces, = for software compatibility with variants of Unix and other operating = systems. END QUOTE The section "POSIX-oriented operating systems" lists many OSs that are either certified, mostly-compliant, have means of having a POSIX environment (includes Microsoft Windows, OS/2, DOS), or have a (optional) POSIX compatibility layer. I'll not make a full list here. You can use that to help judge if only supporting time_t as an integer type is worthwhile in your view. > Maybe something like this will cover the most cases in practice: There are more details here that I'd need to think about that I've not dealt with yet. > --- check_mktime.c.patch --- > --- check_mktime.c.orig 2021-01-15 03:19:33.962253000 +0100 > +++ check_mktime.c 2021-01-16 21:00:36.160616000 +0100 > @@ -3,6 +3,13 @@ > # include > # include > # include > +# include > +#include > +# include /* printf() */ > +# include /* CHAR_BIT */ > +#if 0 > +# include /* format spec PRIX64: ll/l + X on = 32/64-bit arch */ > +#endif >=20 > /* Work around redefinition to rpl_putenv by other config tests. */ > #undef putenv > @@ -16,6 +23,78 @@ > }; > #define N_STRINGS (sizeof (tz_strings) / sizeof (tz_strings[0])) >=20 > +/* Count the bits set in any unsigned integer type. > + * Returns the precision (width - padding bits - sign bit) iff given > + * the xxx_MAX value of any integer type, signed or unsigned. > + * =46rom SEI CERT C Coding Standard: > + * Rules for Developing Safe, Reliable, and Secure Systems (2016) > + */ > +size_t > +popcount (num) > +uintmax_t num; > +{ > + size_t cnt =3D 0; > + =20 > + while (num !=3D 0) > + { > + if (num % 2 =3D=3D 1) > + cnt++; > + num >>=3D 1; > + } > + return cnt; > +} > +#define PRECISION(max_value) popcount(max_value) > + > +/* Guess the maximum value of a time_t from it's storage width. > + * ASSERT time_t is not a floating point, or of any arcane width, or=20= > unsigned. > + * Only 4...8 byte width of a time_t are tested. > + * On error: returns (time_t)(-1) > + */ > +time_t > +guess_time_t_max () > +{ > + time_t t0, t1 =3D (time_t)(-1); > + size_t size, prec; > + > + switch ((size =3D sizeof(time_t))) > + { > + case 4: > + prec =3D PRECISION((time_t) 0xFFFFFFFF); > + break; > + case 5: > + prec =3D PRECISION((time_t) 0xFFFFFFFFFF); > + break; > + case 6: > + prec =3D PRECISION((time_t) 0xFFFFFFFFFFFF); > + break; > + case 7: > + prec =3D PRECISION((time_t) 0xFFFFFFFFFFFFFF); > + break; > + case 8: > + prec =3D PRECISION((time_t) 0xFFFFFFFFFFFFFFFF); > + break; > + default: > + prec =3D 1; > + break; > + } > + prec--; /* assumption: time_t is signed */ > + if (prec) > + { > + t0 =3D (time_t) 1 << (prec - 1); > + t1 =3D t0|(t0 - 1); > + } > + > + /* FIXME not portable: time_t can be floating point type, > + * or another integer type other than long or long long. > + * > + fprintf (stderr, "time_t_max\t=3D 0x%"PRIX64"\n", t1);*/ > + fprintf (stderr, "sizeof(time_t)\t=3D %2zd byte\n", size); > + fprintf (stderr, "precision\t=3D %2zd bit\n", prec); > + fprintf (stderr, "padding\t\t=3D %2zd bit\n", size*CHAR_BIT - prec = - 1 /*=20 > sign */); > + > + return t1; > +} > + > /* Fail if mktime fails to convert a date in the spring-forward gap. > Based on a problem report from Andreas Jaeger. */ > static void > @@ -106,9 +185,7 @@ > time_t t, delta; > int i, j; >=20 > - for (time_t_max =3D 1; 0 < time_t_max; time_t_max *=3D 2) > - continue; > - time_t_max--; > + time_t_max =3D guess_time_t_max (); > delta =3D time_t_max / 997; /* a suitable prime number */ > for (i =3D 0; i < N_STRINGS; i++) > { > @@ -128,3 +205,4 @@ > spring_forward_gap (); > exit (0); > } > +/*! vi: set ai tabstop=3D8 shiftwidth=3D2: */ >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)