[#8136] Confused exception handling in Continuation Context — "Robert Dober" <robert.dober@...>

Hi all

13 messages 2006/07/06

[#8248] One-Click Installer: MinGW? or VC2005? — "Curt Hibbs" <ml.chibbs@...>

I just posted this to ruby-talk. But I would also like to discuss this

33 messages 2006/07/18
[#8264] Re: One-Click Installer: MinGW? or VC2005? — Charlie Savage <cfis@...> 2006/07/19

From my experience using both tool chains on Windows (for the ruby-prof

[#8266] Re: One-Click Installer: MinGW? or VC2005? — "Curt Hibbs" <ml.chibbs@...> 2006/07/19

Tim, I'm going to top reply since your post was so long. I'm interested in

[#8267] Re: One-Click Installer: MinGW? or VC2005? — Charlie Savage <cfis@...> 2006/07/19

> Tim, I'm going to top reply since your post was so long. I'm interested in

[#8271] my sandboxing extension!! — why the lucky stiff <ruby-core@...>

I have (what feels like) very exciting news. I finally sat down to code up my

17 messages 2006/07/19

[#8430] Re: doc patch: weakref. — "Berger, Daniel" <Daniel.Berger@...>

> -----Original Message-----

19 messages 2006/07/28
[#8434] Re: doc patch: weakref. — Yukihiro Matsumoto <matz@...> 2006/07/29

Hi,

[#8436] Re: doc patch: weakref. — Daniel Berger <djberg96@...> 2006/07/29

Yukihiro Matsumoto wrote:

[#8437] Re: doc patch: weakref. — Mauricio Fernandez <mfp@...> 2006/07/29

On Sat, Jul 29, 2006 at 07:37:24PM +0900, Daniel Berger wrote:

[#8441] Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...>

I have the following code:

18 messages 2006/07/30
[#8442] Re: Inconsistency in scoping during module_eval? — nobu@... 2006/07/30

Hi,

[#8443] Re: Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...> 2006/07/30

Why does this:

[#8445] Re: Inconsistency in scoping during module_eval? — Yukihiro Matsumoto <matz@...> 2006/07/30

Hi,

[#8454] Re: Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...> 2006/07/31

So to clarify...

Ruby 1.8.5 stable, Process::RLIM_SAVED_CUR issue

From: Daniel Berger <djberg96@...>
Date: 2006-07-14 16:20:34 UTC
List: ruby-core #8224
Hi,

Linux, Suse 10.1
gcc 4.1
Ruby 1.8.5, stable (2006-07-14)

I built a 32 bit Ruby:

> irb
irb(main):001:0> (2**33).class
=> Bignum
irb(main):002:0> VERSION
=> "1.8.5"

Yet, when I check the value of Process::RLIM_SAVED_CUR, I get this
value:

irb(main):003:0> Process::RLIM_SAVED_CUR
=> 18446744073709551615

But, this doesn't match with what I get from C:

#include <stdio.h>
#include <wait.h>

int main(){
   printf("RLIM_SAVED_CUR: %lu\n", RLIM_SAVED_CUR);
   printf("RLIM_SAVED_MAX: %lu\n", RLIM_SAVED_MAX);
   return 0;
}

The above program produces:

RLIM_SAVED_CUR: 4294967295
RLIM_SAVED_MAX: 4294967295

Looking in limits.h, I see this:
/* Maximum value an `unsigned long int' can hold.  (Minimum is 0.)  */
#  if __WORDSIZE == 64
#   define ULONG_MAX    18446744073709551615UL
#  else
#   define ULONG_MAX    4294967295UL
#  endif

So, somehow Ruby picked up the 64 bit value.  I *am* on an AMD 64 laptop
here, btw.  Maybe gcc is doing something funky, but attempting to
explicitly build with -m64 fails.  It tells me 64 bits support was not
builtin to the version of gcc that I have.  Here's the result of gcc -v:

Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,java,ada --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/4.1.0 --enable-ssp
--disable-libssp --enable-java-awt=gtk --enable-gtk-cairo
--disable-libjava-multilib --with-slibdir=/lib --with-system-zlib
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--without-system-libunwind --with-cpu=generic --host=i586-suse-linux
Thread model: posix
gcc version 4.1.0 (SUSE Linux)

I've attached the config.log file in case that helps.

Regards,

Dan

Attachments (1)

config.log (173 KB, text/x-log)

In This Thread

Prev Next