Hi David and Martin,
Thanks so much for your time (heh, punny) and thoughts, and for taking the ball
and running with it.
cheers,
jon
- "David Holmes" wrote:
> Hi Martin,
>
> Martin Buchholz said the following on 07/08/10 15:38:
> > On Wed, Jul 7, 2010 at 18:08, David Holmes
> wrote:
- "Martin Buchholz" wrote:
> On Thu, Jul 1, 2010 at 10:05, wrote:
> > Hi Martin,
> >
> > Thanks for your input.
> >
> > - "Martin Buchholz" wrote:
> >
> >> It's not at all clear that one cannot solve the y2038 problem on
> >> systems with a 32-bit time_t.
> >> That's what Michael Schw
Hi Martin,
Martin Buchholz said the following on 07/08/10 15:38:
On Wed, Jul 7, 2010 at 18:08, David Holmes wrote:
I think there has been some confusion here. It seems to me that the
anti-inlining that is being referred to is javac's "inlining" of
compile-time constants - BUT that doesn't appl
On Wed, Jul 7, 2010 at 18:08, David Holmes wrote:
> I think there has been some confusion here. It seems to me that the
> anti-inlining that is being referred to is javac's "inlining" of
> compile-time constants - BUT that doesn't apply to reference types other
> than String, so it seems to me tha
I think there has been some confusion here. It seems to me that the
anti-inlining that is being referred to is javac's "inlining" of
compile-time constants - BUT that doesn't apply to reference types other
than String, so it seems to me that the current code contortions serve
no useful purpose
Hi Jon, Alan, Chris,
Jon, I have a more conservative version of your patch,
that uses blank finals, only calls currentTimeMillis once instead of 3 times,
and only fails in the unlikely event of currentTimeMillis == Long.MIN_VALUE.
I'm too afraid to remove the anti-inlining entirely.
http://cr.op
On Wed, Jul 7, 2010 at 08:00, wrote:
>
> - "Martin Buchholz" wrote:
>
>
>> The JDK should find some other anti-inlining technique.
>>
>
> I would go one step further, and say that perhaps this anti-inlining is no
> longer necessary. I tried taking these methods out entirely and simply
> s
On Thu, Jul 1, 2010 at 10:05, wrote:
> Hi Martin,
>
> Thanks for your input.
>
> - "Martin Buchholz" wrote:
>
>> It's not at all clear that one cannot solve the y2038 problem on
>> systems with a 32-bit time_t.
>> That's what Michael Schwern is trying to do here:
>> http://code.google.com/p/
- "Martin Buchholz" wrote:
> The JDK should find some other anti-inlining technique.
>
I would go one step further, and say that perhaps this anti-inlining is no
longer necessary. I tried taking these methods out entirely and simply setting
the in/out/err streams to null initially. Th
Hi Martin,
Thanks for your input.
- "Martin Buchholz" wrote:
> It's not at all clear that one cannot solve the y2038 problem on
> systems with a 32-bit time_t.
> That's what Michael Schwern is trying to do here:
> http://code.google.com/p/y2038/
> His code is available.
>
Unfortunately un
It's not at all clear that one cannot solve the y2038 problem on
systems with a 32-bit time_t.
That's what Michael Schwern is trying to do here:
http://code.google.com/p/y2038/
His code is available.
The JDK should find some other anti-inlining technique.
The code should be agnostic about the cur
Hello all,
We've been having a discussion on the downstream IcedTea bugzilla about a
potential jdk bug, and it seems prudent to bring it up here. Link:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=394
Please ignore discussion there RE 32-bit *nix time overflow in 2038; this is a
glib
12 matches
Mail list logo
