[#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...

Unexpected pointer behavior with unpack

From: "Justin Bailey" <jgbailey@...>
Date: 2006-07-14 15:36:37 UTC
List: ruby-core #8223
I have had the opportunity to work [1] a lot with Ruby's ability to create
and manipulate pointers via pack/unpack recently, and have discovered
surprising behavior when dealing with nested pointers. I'm interested in
other's thoughts on the analysis below. I wasn't able to find a lot of
straightforward documentation about this Ruby ability.

If I take a string, pack it to a pointer, and then pack that pointer into
another string, I lose the ability to retrieve the inner pointer. However,
if I make a reference to the "inner" pointer in a local variable, I can
still retrieve it. An example is best:

  puts (inner = ["foo"].pack("P")).inspect # "xxxx" - some 4 byte string
  puts inner.unpack("P3").first.inspect # "foo"
  puts (outer = [inner].pack("P")).inspect # "yyyy" - another 4 byte string
  puts outer.unpack("P4").first.inspect # "xxxx" - first 4 byte string from
above
  puts inner.unpack("P3").first.inspect # "foo" - still can get to inner
structure

As is shown, I can create a two packed pointers and get access to them
through individual variables. However, if I try to access the inner
structure from the outer, like so:

  puts outer.unpack("P4").first.unpack("P3") # ArgumentError - no associated
pointer

I get an error. Now, I think I understand why this happens - pointers have
to be associated with variables. It would be dangerous to unpack to treat
any string as a pointer. However, I do think the above is surprising
behavior. It took me awhile to understand why my nested structures didn't
seem to work.

Does anyone else agree with that this is suprising behavior or am I missing
something?

Justin

[1] I needed to call some complex Win32 API functions which took nested
structures, that were allocated in Ruby but filled out by the API, and
that's what led me down this path.

In This Thread

Prev Next