Implicit assumptions (was: Re: Some fun with -O2)

[Mark Millard]

On 2021-Jan-17, at 13:25, Walter von Entferndt <walter.von.entferndt at posteo.net> wrote:

> . . .
> -      for (j = 1; 0 < j; j *= 2)
> +      /* NOTE This does not reach very large values > time_t_max/2
> +         neither the (susceptible for overflow) version
> +         for (j = 1; 0 < j; j *= 2) does  */
> +      for (i = j = 1; i < PRECISION(INT_MAX); i++, j *= 2)

I'm unclear on why INT_MAX here. 32767 <= INT_MAX for C (and the
LP32 data model), but 2147483647 == INT_MAX is common (IPL32,
LLP64, LP64). The bigtime_test(j) call has j being 2**(i-1),
inventing notation for an exponent. So for the 2 identified
cases varying the exponent calls for:

2**(1-1) to 2**(14-1) for 0x7FFF==INT_MAX
2**(1-1) to 2**(30-1) for 0x7FFFFFFF==INT_MAX

>         bigtime_test (j);

and so for the below bigtime_test(j-1):

(2**(15-1))-1 for 0x7FFF==INT_MAX
(2**(31-1))-1 for 0x7FFFFFFF==INT_MAX

>       bigtime_test (j - 1);

The above notes are independent of time_t.

I'm also unsure of your intended relationship to
time_t in general (if any). For example, for
time_t being 64 bits (63 value bits) on powerpc
(32-bit and  64-bit) for FreeBSD but 32-bit (31
value bits) for i386 for FreeBSD and 64-bit (63
value bits) for amd64 for FreeBSD. (As I understand,
FreeBSD does not claim to support INT_MAX<2147483647
even though C of itself does. FreeBSD is just an
example here.)

It leaves me to wonder about using something that
invovled PRECISION(time_t_max). (Not that I've
thought that through enough to claim just what
would always be appropriate.)

>     }
>   irix_6_4_bug ();
>   spring_forward_gap ();
> -  exit (0);
> +  exit (EXIT_SUCCESS);
> }
> +/*! vi: set ai tabstop=8 shiftwidth=2: */

Again, I do not make a claim of having thought every
aspect of the code through. The above is just what
stood out on a quick read.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)