Date: Sat, 16 Jan 2021 10:04:04 +0100 From: Walter von Entferndt <walter.von.entferndt@posteo.net> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) Message-ID: <1725854.nNRVL2rNYg@t450s.local.lan> In-Reply-To: <37B00E45-ABCC-4C8D-9BF6-C0DC5142F63A@yahoo.com> References: <mailman.29.1610625600.45116.freebsd-hackers@freebsd.org> <5358091.mMMZhaHaU6@t450s.local.lan> <37B00E45-ABCC-4C8D-9BF6-C0DC5142F63A@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <stdint.h> static const time_t time_t_max =3D INTMAX_MAX; Or do we have to come up with adjacent probing =C3=A0 la: #include <limits.h> #include <stdlib.h> #include <stdio.h> 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1725854.nNRVL2rNYg>