On Mon, Oct 5, 2020 at 12:27 PM Roderick wrote:
...
> Back to tar files: there is place for 11 octal digits, that is
> only twice the time you can count with 32 bits, in years:
>
> 2^33/(60*60*24*365.25*2)=136.09930083403047126524
>
> Also not too much. Is it not a better solution to begin a new
On Mon, 5 Oct 2020, Christian Weisgerber wrote:
There's an #ifdef __LP64__ ...
Yes. That is not to oversee, but I oversaw it, because I wanted to
oversee it.
For lazyness I use snprintf to fill the mtime field of a component of
a v7 tar file I generate:
snprintf(&hd[136],12,"%011lo", time(
On 2020-10-05, Roderick wrote:
> The source of my confusion with FreeBSD:
> /usr/include/x86/_types.h contains:
>typedef __int32_t __time_t;
>typedef int __int32_t;
$ fgrep time_t /usr/include/x86/_types.h
typedef __int64_t __time_t; /* time()... */
typedef __int32_t
On 2020-10-05, "Peter N. M. Hansteen" wrote:
> I hadn't looked in a while, but it amazes me that FreeBSD still has
> 32-bit time_t.
Only on FreeBSD/i386. On all other architectures, time_t is int64_t.
See src/sys/*/include/_types.h.
--
Christian "naddy" Weisgerber na.
The source of my confusion with FreeBSD:
/usr/include/time.h contains: typedef __time_t time_t; and includes
/usr/include/sys/types.h includes
/usr/include/machine/_types.h includes
/usr/include/x86/_types.h contains:
typedef __int32_t __time_t;
typedef int __int32_t;
Of course I am
Thanks anybody for the instructive answers!
On Mon, 5 Oct 2020, Todd C. Miller wrote:
Are you sure about that? FreeBSD declares __time_t to be __int64_t
on amd64. On FreeBSD/amd64 __int64_t is defined as a long.
You are right. My error. I just run:
#include
#include
int main() {printf(
Hi Peter,
Peter J. Philipp wrote on Mon, Oct 05, 2020 at 05:47:59PM +0200:
> When time_t was made, I think, positive integers meant time forwards, and
> negative integers meant time backwards from epoch so that people born in
> 1938 for example could be processed.
https://man.openbsd.org/time.
On Mon, Oct 05, 2020 at 03:16:24PM +, Roderick wrote:
>
> The result of time() has type time_t and we know what kind of number
> goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1,
> 1970, Coordinated Universal Time.
>
> In my FreeBSD running on a 64 bit processor this type is
The universe didn't start in 1970
On Monday, October 5, 2020, Roderick wrote:
>
> The result of time() has type time_t and we know what kind of number
> goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1,
> 1970, Coordinated Universal Time.
>
> In my FreeBSD running on a 64 bit p
Hi Rodrick,
Roderick wrote on Mon, Oct 05, 2020 at 03:16:24PM +:
> The result of time() has type time_t and we know what kind of number
> goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1,
> 1970, Coordinated Universal Time.
>
> In my FreeBSD running on a 64 bit processor th
On Mon, 05 Oct 2020 15:16:24 -, Roderick wrote:
> The result of time() has type time_t and we know what kind of number
> goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1,
> 1970, Coordinated Universal Time.
32-bit time_t rolls over at 03:14:07 on Tuesday, 19 January 2038.
>
On Mon, Oct 05, 2020 at 03:16:24PM +, Roderick wrote:
>
> The result of time() has type time_t and we know what kind of number
> goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1,
> 1970, Coordinated Universal Time.
>
> In my FreeBSD running on a 64 bit processor this type is
On Mon, Oct 05, 2020 at 03:16:24PM +, Roderick wrote:
>
> The result of time() has type time_t and we know what kind of number
> goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1,
> 1970, Coordinated Universal Time.
>
> In my FreeBSD running on a 64 bit processor this type is
Theo de Raadt wrote:
double (or even better long double) would be a better underlying
type for time_t than long long.
If you believe strongly in this idea, you should take an entire
operating system base and prove the case
15 years ago a gen-yoo-wine software engineer in our department suggest
http://pubs.opengroup.org/onlinepubs/9699919799/
On Mon, Nov 18, 2013 at 17:47, Peter Fraser wrote:
> double (or even better long double) would be a better underlying type for
> time_t than long long.
>
> Programs that are using time_t properly would not notice the difference.
> Programs that ver
> double (or even better long double) would be a better underlying
> type for time_t than long long.
If you believe strongly in this idea, you should take an entire
operating system base and prove the case. By converting the entire
base. By showing that it will work. By getting X and firefox ru
16 matches
Mail list logo
