[OpenIndiana-discuss] How to tell for sure what bit your OS is?

Alan Coopersmith alan.coopersmith at oracle.com
Fri Jun 2 01:38:51 UTC 2017


On 05/31/17 10:30 AM, Richard L. Hamilton wrote:
>
>> On May 31, 2017, at 13:01, Alan Coopersmith <alan.coopersmith at oracle.com> wrote:
>>
>> On 05/31/17 09:43 AM, Richard L. Hamilton wrote:
>>> The alternative would be a large times analog of large file support; why that wasn't done when 64-bit began, I don't understand. :-)
>>
>> It was considered at Sun in the late 90's but discarded as going full LP64
>> already provided a solution without combinatorial explosion of test matrices
>> for large files x large times.  The large files API was created before LP64
>> was an option on most Unixes, including Solaris.
>>
>
> Testing, yes; that makes sense.
>
> How are the time conversion functions doing with regard to time_t past INT32_MAX?  I see that (with a 64-bit executable) at least ctime() seems to work enough beyond for usual life and commercial purposes (aside from radioactive waste :-) ):
>
> 13:15:32[13]monster:/home/rlhamil> ./maxtime
> time overflow after Tue Jan 19 03:14:07 2038
>  in 32-bit signed two's complement
> timestamp 9223372036854775807 (INT64_MAX) cannot be processed by ctime()
> t=2147483647: Tue Jan 19 03:14:07 2038
>
> t=4294967294: Sun Feb  7 06:28:14 2106
>
> t=8589934588: Wed Mar 16 12:56:28 2242
>
> t=17179869176: Wed May 30 01:52:56 2514
>
> t=34359738352: Tue Oct 26 03:45:52 3058
>
> t=68719476704: Sun Aug 20 07:31:44 4147
>
> t=137438953408: Wed Apr  8 15:03:28 6325
>
> t=274877906816: (null)

On Solaris, ctime() is defined as returning a string of exactly 26 characters,
so it gives up when the year requires a 5th digit and doesn't fit.

Converting to strftime and compiling with -std=c99 -m64 -D_XOPEN_SOURCE=700
gets a bit further here:

	for (t=INT32_MAX;t<=INT64_MAX && t>=0L;t<<=1) {
		char s[100] = "";
		struct tm *l = localtime(&t);
		if (l != NULL)
			strftime(s, sizeof(s), "%a %b %e %H:%M:%S %Y", l);
		else
			snprintf(s, sizeof(s), "localtime(%ld) == NULL", t);
		printf("t=%ld: %s\n", t, s);
	}

time overflow after Tue Jan 19 03:14:07 2038
  in 32-bit signed two's complement
timestamp 9223372036854775807 (INT64_MAX) cannot be processed by ctime()
t=2147483647: Tue Jan 19 03:14:07 2038
t=4294967294: Sun Feb  7 06:28:14 2106
t=8589934588: Wed Mar 16 12:56:28 2242
t=17179869176: Wed May 30 01:52:56 2514
t=34359738352: Tue Oct 26 03:45:52 3058
t=68719476704: Sun Aug 20 07:31:44 4147
t=137438953408: Wed Apr  8 15:03:28 6325
t=274877906816: Wed Jul 14 06:06:56 10680
t=549755813632: Tue Jan 25 12:13:52 19391
t=1099511627264: Mon Feb 20 00:27:44 36812
t=2199023254528: Fri Apr 10 00:55:28 71654
t=4398046509056: Sat Jul 19 01:50:56 141338
t=8796093018112: Mon Feb  4 03:41:52 280707
t=17592186036224: Fri Mar  8 07:23:44 559444
t=35184372072448: Sat May 14 14:47:28 1116918
t=70368744144896: Tue Sep 25 05:34:56 2231866
t=140737488289792: Sun Jun 19 11:09:52 4461763
t=281474976579584: Wed Dec  5 22:19:44 8921556
t=562949953159168: Wed Nov 10 20:39:28 17841143
t=1125899906318336: Wed Sep 19 17:18:56 35680317
t=2251799812636672: Wed Jun  7 10:37:52 71358665
t=4503599625273344: Tue Nov 11 21:15:44 142715360
t=9007199250546688: Mon Sep 24 18:31:28 285428751
t=18014398501093376: Sat Jun 17 13:02:56 570855533
t=36028797002186752: Tue Dec  1 02:05:52 1141709096
t=72057594004373504: localtime(72057594004373504) == NULL
t=144115188008747008: localtime(144115188008747008) == NULL
t=288230376017494016: localtime(288230376017494016) == NULL
t=576460752034988032: localtime(576460752034988032) == NULL
t=1152921504069976064: localtime(1152921504069976064) == NULL
t=2305843008139952128: localtime(2305843008139952128) == NULL
t=4611686016279904256: localtime(4611686016279904256) == NULL
t=9223372032559808512: localtime(9223372032559808512) == NULL

I suggest anyone working with such precise timestamps more than a billion years
in the future use a system more oriented towards such scientific calculations
than the C standard library.  I'm sure it's timezone code does not account for
the changes in the Earth's rotation nor the tectonic plate migration that will
have occurred over that timespan.

	-alan-



More information about the openindiana-discuss mailing list