lkml.org 
[lkml]   [2000]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: time_t size: The year 2038 bug?
    On Tue, 11 Jan 2000, Horst von Brand wrote:
    > Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> said:
    > [...]
    > > yes it is. but the number of bits is not. On a 32 bit system "long long" is
    > > 64 bits. On a 64bit system it is 128. And if you need more bits that
    > > that you are out of luck. "long long" is imprecise, I'd prefer a construct
    > > like "int var: 64". This way I know exactly how many bits are available.
    > > If I need 128 bits for something (or even 4096) then I can define them. Or
    > > is there going to be a "long long long long" for 128 bits, and "long long
    > > long long long long .... long" to reach 4096?
    >
    > COBOL gives you this (sort of) >:-}

    I was just thinking last night that this is one advantage that Multics
    had, being written in PL/I:

    %DCL time_t char;
    %time_t = 'FIXED BINARY(64)';
    ...
    DCL foo time_t;
    DCL bar AUTO time_t;

    (or however it is you'd do typedefs in the PL/I preprocessor -- it's been
    too long....)

    --
    Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
    "Where's the kaboom? There was supposed to be an Earth-shattering kaboom!"
    -- Marvin Martian, 01/01/2000 00:00:00


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:0.020 / U:119.704 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site