aboutsummaryrefslogtreecommitdiff
path: root/open_issues/glibc/0.4.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/glibc/0.4.mdwn')
-rw-r--r--open_issues/glibc/0.4.mdwn44
1 files changed, 43 insertions, 1 deletions
diff --git a/open_issues/glibc/0.4.mdwn b/open_issues/glibc/0.4.mdwn
index 8991d4c0..33ef8f3a 100644
--- a/open_issues/glibc/0.4.mdwn
+++ b/open_issues/glibc/0.4.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013, 2014 Free Software Foundation,
+Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -15,6 +16,8 @@ Things to consider doing when bumping the glibc SONAME.
There are some comments in the sources, for example `hurd/geteuids.c`: `XXX
Remove this alias when we bump the libc soname.`
+[[!toc]]
+
# IRC, freenode, #hurd, 2012-12-14
@@ -33,3 +36,42 @@ In context of [[packaging_libpthread]]/[[libpthread]].
[[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id
"4BFA500A.7030502@gmail.com"]].
+
+
+# `time_t` -- Unix Epoch vs. 2038
+
+## IRC, freenode, #hurd, 2013-12-12
+
+ <azeem> because it gets discussed in #debian-devel for the Linux i386
+ architecture right now: what's the deal with hurd-i386 and the 32bit
+ epoch overflow in 2038?
+ <braunr> what do you mean ?
+ <azeem> braunr: http://lwn.net/Articles/563285/
+ <braunr> ok but what do you mean ?
+ <braunr> i don't think there is anything special with the hurd about that
+ <azeem> well, time_t is 64bit on amd64 AIUI
+ <braunr> it's a signed long
+ <azeem> so maybe the Hurd guys were clever from the start
+ <azeem> k, k
+ <braunr> our big advantage is that we can afford to break things a little
+ without too much trouble
+ <braunr> in a system at work, we use unsigned 32-bit words
+ <braunr> which overflows in 2106
+ <braunr> and we already include funny comments that predict our successors,
+ if any, will probably fail to deal with the problem until short before
+ the overflow :>
+ <azeem> luckily, no nuclear reactors are running the Hurd sofar
+ <braunr> i wonder how the problem will be dealt with though
+ <braunr> ah, openbsd decided to break their abi
+ <azeem> yeah
+ <braunr> that's probably the simplest solution
+ <azeem> "just recompile"
+ <braunr> and they can afford it too
+ <azeem> yeah
+ <braunr> good to see people actually worry about it
+ <azeem> I guess people are getting worried about where Linux embedded is
+ being put into
+ <braunr> they're right about that
+ <azeem> "Please, don't fix the 2038 year issue. I also want to have some
+ job security :)"
+ <braunr> haha