time_t always an integer?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

time_t always an integer?

Asko Kauppi

I sent a separate mail to Lua authors on this, but... a more common  
survey wouldn't hurt? :)

Lua 5.1 beta still uses "pushNumber" in the os.time() function, but  
as far as I know, any 'time_t' is always an integer, albeit the  
interpretation of that value may differ. Is this right?

In other words, there is no system anywhere, that'd use 'float' or  
'double' for time_t.

If so, the return of os.time() should imho use "pushInteger()", which  
does make a difference on float/int32 patched systems, where pushing  
an integer allows full 32-bit range, but pushing a number (float)  
does not.

Small thing, unless one stumbles accross it.. (and one does, since  
current time_t values are outside of float range, so values change  
only every now and then, not by each second)

thanks for opinions,
-asko

Reply | Threaded
Open this post in threaded view
|

Re: time_t always an integer?

Olivier Delannoy
On 1/11/06, Asko Kauppi <[hidden email]> wrote:

>
> I sent a separate mail to Lua authors on this, but... a more common
> survey wouldn't hurt? :)
>
> Lua 5.1 beta still uses "pushNumber" in the os.time() function, but
> as far as I know, any 'time_t' is always an integer, albeit the
> interpretation of that value may differ. Is this right?
>
> In other words, there is no system anywhere, that'd use 'float' or
> 'double' for time_t.
>
> If so, the return of os.time() should imho use "pushInteger()", which
> does make a difference on float/int32 patched systems, where pushing
> an integer allows full 32-bit range, but pushing a number (float)
> does not.
Isn't it something that must address the patch by providing a
specialized version of os.time() ?
>
> Small thing, unless one stumbles accross it.. (and one does, since
> current time_t values are outside of float range, so values change
> only every now and then, not by each second)
>
> thanks for opinions,
> -asko
>
>
Reply | Threaded
Open this post in threaded view
|

Re: time_t always an integer?

Roberto Ierusalimschy
In reply to this post by Asko Kauppi
> If so, the return of os.time() should imho use "pushInteger()", which  
> does make a difference on float/int32 patched systems, where pushing  
> an integer allows full 32-bit range, but pushing a number (float)  
> does not.

Not all integers have 32 bits. If we change to pushinteger, we can
hurt people that are using standard Lua in small machines.

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: time_t always an integer?

Rici Lake-2
In reply to this post by Asko Kauppi

On 11-Jan-06, at 10:46 AM, Asko Kauppi wrote:

> If so, the return of os.time() should imho use "pushInteger()", which
> does make a difference on float/int32 patched systems, where pushing
> an integer allows full 32-bit range, but pushing a number (float) does
> not.

What if time_t happened to be "long long" (as it is on at least some
OS's)? Then coercing it to an int would also truncate it.

Reply | Threaded
Open this post in threaded view
|

Re: time_t always an integer?

Mike Pall-41
In reply to this post by Asko Kauppi
Hi,

Asko Kauppi wrote:
> Lua 5.1 beta still uses "pushNumber" in the os.time() function, but  
> as far as I know, any 'time_t' is always an integer, albeit the  
> interpretation of that value may differ. Is this right?

time_t is always an integral value, but not necessarily an 'int'
and not necessarily 32 bits. It's an int64 on many (but not all)
64 bit systems (but int is still 32 bits there!). Even some 32 bit
systems have switched to int64 (e.g. MSVC8) and others will follow.

> If so, the return of os.time() should imho use "pushInteger()" [...]

Nope. This would truncate time_t to an int. See above.

Bye,
     Mike
Reply | Threaded
Open this post in threaded view
|

Re: time_t always an integer?

Rici Lake-2
In reply to this post by Asko Kauppi

On 11-Jan-06, at 10:46 AM, Asko Kauppi wrote:

> In other words, there is no system anywhere, that'd use 'float' or  
> 'double' for time_t.

SAS/C -- a programming environment used on IBM zSeries and System/390  
mainframes -- uses double for time_t. See  
<http://support.sas.com/documentation/onlinedoc/sasc/doc750/html/lr1/ 
timing.htm>

Whether anyone uses Lua on such a system, I don't know :)

Reply | Threaded
Open this post in threaded view
|

Re: time_t always an integer?

Asko Kauppi
In reply to this post by Mike Pall-41

Okay, thanks. I'll make some safety code around there, using sizeof
(time_t) and sizeof(int).

-asko


Mike Pall kirjoitti 11.1.2006 kello 18.46:

> Hi,
>
> Asko Kauppi wrote:
>> Lua 5.1 beta still uses "pushNumber" in the os.time() function, but
>> as far as I know, any 'time_t' is always an integer, albeit the
>> interpretation of that value may differ. Is this right?
>
> time_t is always an integral value, but not necessarily an 'int'
> and not necessarily 32 bits. It's an int64 on many (but not all)
> 64 bit systems (but int is still 32 bits there!). Even some 32 bit
> systems have switched to int64 (e.g. MSVC8) and others will follow.
>
>> If so, the return of os.time() should imho use "pushInteger()" [...]
>
> Nope. This would truncate time_t to an int. See above.
>
> Bye,
>      Mike

Reply | Threaded
Open this post in threaded view
|

Re: time_t always an integer?

Dave Dodge
In reply to this post by Mike Pall-41
On Wed, Jan 11, 2006 at 05:46:15PM +0100, Mike Pall wrote:
> Asko Kauppi wrote:
> > as far as I know, any 'time_t' is always an integer, albeit the  
> > interpretation of that value may differ. Is this right?
>
> time_t is always an integral value,

C defines it as an "arithmetic" type.  It could legitimately be any
floating type, including something exotic like "long double _Complex",
without violating the Standard.  Even POSIX explicitly allows a
floating type for time_t.

                                                  -Dave Dodge