Date: Sat, 16 Jan 2021 02:23:03 -0800 From: Mark Millard <marklmi@yahoo.com> To: Walter von Entferndt <walter.von.entferndt@posteo.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) Message-ID: <7623BADF-5FA9-4712-8D85-A1D2B82E3F74@yahoo.com> In-Reply-To: <1725854.nNRVL2rNYg@t450s.local.lan> References: <mailman.29.1610625600.45116.freebsd-hackers@freebsd.org> <5358091.mMMZhaHaU6@t450s.local.lan> <37B00E45-ABCC-4C8D-9BF6-C0DC5142F63A@yahoo.com> <1725854.nNRVL2rNYg@t450s.local.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jan-16, at 01:04, Walter von Entferndt <walter.von.entferndt at = posteo.net> 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 <stdint.h> > 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 <limits.h> > #include <stdlib.h> > #include <stdio.h> >=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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7623BADF-5FA9-4712-8D85-A1D2B82E3F74>