[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    64-bit time_t
From:       Adriaan de Groot <adridg () cs ! kun ! nl>
Date:       2003-09-29 8:01:44
[Download RAW message or body]

Porting of KDE on FreeBSD to the IA64 has begun, and this gives lots of
new buglets. In particular, time_t is 64 bits there, while the utmp login
structure still contains 32 bit fields (for the login time). The fields
_must_ remain 32 bit to retain backwards compatibility, but meanwhile
time() and the like expects a pointer to a 64-bit time_t. This breaks
konsole, for instance, and this patch:

Index: TEPty.cpp
===================================================================
RCS file: /home/kde/kdebase/konsole/konsole/TEPty.cpp,v
retrieving revision 1.75.2.1
diff -u -r1.75.2.1 TEPty.cpp
--- TEPty.cpp	26 Aug 2003 19:15:50 -0000	1.75.2.1
+++ TEPty.cpp	29 Sep 2003 07:50:48 -0000
@@ -624,7 +624,14 @@
   if (strncmp(str_ptr, "/dev/", 5) == 0)
        str_ptr += 5;
   strncpy(l_struct.ut_line, str_ptr, UT_LINESIZE);
-  time(&l_struct.ut_time);
+
+  // Handle 64-bit time_t properly, where it may be larger
+  // than the integral type of ut_time.
+  {
+      time_t ut_time_temp;
+      time(&ut_time_temp);
+      l_struct.ut_time=ut_time_temp;
+  }

   login(&l_struct);
 #endif


does the fix, by using the right pointer size and then assigning a 64-bit
quantity to a 32-bit field (might cause a warning, I haven't tried).

Now the question is: where to fix this? I could keep the patches local to
FBSD, or I can commit in KDE CVS. It's a few cycles wasted here and there
where time_t is 32-bit, but hey. It's also a little code convolution that
needs to be documented all over the place.


Can you conditionalize on sizeof? ie.  would

#if sizeof(time_t) > sizeof(l_struct.ut_time)

work? I doubt it, since sizeof() isn't something known at preprocess time.


Lastly, how to the 64-bit Linuxen deal with this? I imagine SuSE has KDE
running on 64-bit architectures already (or has the binary format of
struct utmp just changed along with the data sizes there?).

-- 
 Adriaan de Groot    adridg@cs.kun.nl     Kamer A6020     024-3652272
GPG Key Fingerprint 934E 31AA 80A7 723F 54F9  50ED 76AC EE01 FEA2 A3FE
               http://www.cs.kun.nl/~adridg/research/

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]