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)