Agreed, I forgot to add that warning.
I was using it to put fingerprints against alloc calls, retain/release cycles, and some other methods so I could track down memory leaks and some less then compliant code in debug builds.
It should not end up in release builds.


On Mar 9, 2008, at 6:06 PM, Bill Bumgarner wrote:

On Mar 9, 2008, at 2:59 PM, stephen joseph butler wrote:
On Sun, Mar 9, 2008 at 4:45 PM, Tony Becker <[EMAIL PROTECTED]> wrote:
If you're on Leopard, there is a new backtrace(3) call.
If you're on Tiger, it's a little more complex...

      You can use the compiler function
              (long)__builtin_return_address(0)
      to find the address of your caller. Alas, there is no
__builtin_return_symbol()

Interesting. The manpage for backtrace mentions dladdr, which is
available on 10.4. Maybe you can use that instead of launching atos.
Particularly, I'm looking at the dli_sname member.

You really *do not* want to write code that relies upon stack introspection for normal use.

Debugging tool?  Go for it.

Two reasons:

(1) From a design perspective, relying upon identification of the calling method is just... odd. And fragile. It also greatly limits the reusability of code and makes all kinds of refactoring operations rather dangerous as it vastly increases the complexity of the dependency graph on any given method name.

(2) Stack introspection is inherently architecture specific and very fragile. There is no guarantee that the caller of a method is an Objective-C method in and of itself nor, even, that the calling function actually has a fully formed stack frame. In the presence of optimization, registers and local variables may be reused and such reuse is not necessarily limited from blasting self and _cmd of the calling frame.

b.bum
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/aebecker%40mac.com

This email sent to [EMAIL PROTECTED]

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to