On Wed, 26 Sep 2001, Hong Zhang wrote:
>
> You are using the wrong flag. The expression in second is long long.
> So you should use flag "%llx". Since printf uses vararg, it is
> undefined behavior if there is type mismatch with argument.
Oops. :-)
Andy Dougherty [EMAIL PROTEC
On Wed, 26 Sep 2001, Andy Dougherty wrote:
[Spoiler below]
> On Wed, 26 Sep 2001, Hong Zhang wrote:
>
> > There should be no need. ~0xfff is singed int, which will be signed extended
> > by compilers as needed. Unless you are using a buggy compiler.
>
> Hehehe. Ok. Guess what the following w
You are using the wrong flag. The expression in second is long long.
So you should use flag "%llx". Since printf uses vararg, it is
undefined behavior if there is type mismatch with argument.
Hong
> Hehehe. Ok. Guess what the following will print:
>
> #include
> int main(void) {
> int x
On Wed, 26 Sep 2001, Hong Zhang wrote:
> There should be no need. ~0xfff is singed int, which will be signed extended
> by compilers as needed. Unless you are using a buggy compiler.
Hehehe. Ok. Guess what the following will print:
#include
int main(void) {
int x = 511;
printf("x = %
> > ># > 0xf000 for 64 bit systems. With that changed
>
> > Don't bother. Make the constant be ~0xfff. :)
>
> Umm, are you sure? It's used in an integer context and masked against an
> IV, so you might need an 'int', a 'long', or a 'long long'. I'm unsure
> what type to portably
On Wed, 26 Sep 2001, Dan Sugalski wrote:
> ># > Tru64 core dumps because the value of MASK_CHUNK_LOW_BITS
> ># > 0xf000 for 64 bit systems. With that changed
> Don't bother. Make the constant be ~0xfff. :)
Umm, are you sure? It's used in an intege
I'm not sure this always works. On systems with 32 bit pointers but 64 bit
integers this might produce undesired results...I'm not sure though.
-Original Message-
From: Simon Cozens
To: [EMAIL PROTECTED]
Sent: 9/26/2001 12:15 PM
Subject: Re: Tru64 core dumps
On Wed, Sep 26,
On Wed, Sep 26, 2001 at 06:15:02PM +0100, Simon Cozens wrote:
> On Wed, Sep 26, 2001 at 01:11:56PM -0400, Dan Sugalski wrote:
> > Don't bother. Make the constant be ~0xfff. :)
>
> Oh yeah. *blush*.
All tests successful, 5 subtests skipped.
Yeah!
--
Writing software is more fun than working.
On Wed, Sep 26, 2001 at 01:11:56PM -0400, Dan Sugalski wrote:
> Don't bother. Make the constant be ~0xfff. :)
Oh yeah. *blush*.
--
It would be different if I had an actual ambition to be a corporate pitbull
and be the righteous, noble paperwork warrior tirelessly fighting for the
future vision
On Wed 26 Sep 2001 19:00, Andy Dougherty <[EMAIL PROTECTED]> wrote:
> On Wed, 26 Sep 2001, Brent Dax wrote:
>
> > Configure Man To The Rescue! (Trumpets sound, then stop abruptly.)
> > Now, how do I figure out if we're on a 64-bit system? :^)
>
> ivsize, nvsize, ptrsize, and opcode_t_size (as
At 09:46 AM 9/26/2001 -0700, Brent Dax wrote:
>Simon Cozens:
># On Wed, Sep 26, 2001 at 09:47:08AM -0500, Gibbs Tanton - tgibbs wrote:
># > Tru64 core dumps because the value of MASK_CHUNK_LOW_BITS
># is designed for a
># > 32 bit system. It needs to be changed in the Conf
On Wed, 26 Sep 2001, Brent Dax wrote:
> Configure Man To The Rescue! (Trumpets sound, then stop abruptly.)
> Now, how do I figure out if we're on a 64-bit system? :^)
ivsize, nvsize, ptrsize, and opcode_t_size (as yet uncomputed, but will be
needed) come to mind. A '64-bit' system is an impre
On Wed, Sep 26, 2001 at 09:46:42AM -0700, Brent Dax wrote:
> Now, how do I figure out if we're on a 64-bit system? :^)
$Config{ptrsize} == 8;
--
Some people claim that the UNIX learning curve is steep, but at least you
only have to climb it once.
Simon Cozens:
# On Wed, Sep 26, 2001 at 09:47:08AM -0500, Gibbs Tanton - tgibbs wrote:
# > Tru64 core dumps because the value of MASK_CHUNK_LOW_BITS
# is designed for a
# > 32 bit system. It needs to be changed in the Configure.pl
# script to be
# > 0xf000 for 64 bit syste
On Wed, Sep 26, 2001 at 09:47:08AM -0500, Gibbs Tanton - tgibbs wrote:
> Tru64 core dumps because the value of MASK_CHUNK_LOW_BITS is designed for a
> 32 bit system. It needs to be changed in the Configure.pl script to be
> 0xf000 for 64 bit systems. With that changed it w
Tru64 core dumps because the value of MASK_CHUNK_LOW_BITS is designed for a
32 bit system. It needs to be changed in the Configure.pl script to be
0xf000 for 64 bit systems. With that changed it works fine.
-Original Message-
From: Mattia Barbon
To: Simon Cozens
Cc: Gibbs
I also get six, I miscommunicated that one.
-Original Message-
From: Simon Cozens
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTECTED]'
Sent: 9/26/2001 8:42 AM
Subject: Re: Tru64 core dumps
On Wed, Sep 26, 2001 at 08:42:52AM -0500, Gibbs Tanton - tgibbs wrote:
> I'm gett
On Wed, 26 Sep 2001, Simon Cozens wrote:
>On Wed, Sep 26, 2001 at 08:42:52AM -0500, Gibbs Tanton - tgibbs wrote:
>> I'm getting a core dump on Tru64 for stacks.t. Does anyone else get this?
>
>Just the one? I'm getting six of the damned things.
The 01:00 UTC snapshot segfaulted on all tests beca
On Wed, Sep 26, 2001 at 08:42:52AM -0500, Gibbs Tanton - tgibbs wrote:
> I'm getting a core dump on Tru64 for stacks.t. Does anyone else get this?
Just the one? I'm getting six of the damned things.
--
Mohandas K. Gandhi often changed his mind publicly. An aide once asked him
how he could so
I'm getting a core dump on Tru64 for stacks.t. Does anyone else get this?
20 matches
Mail list logo
