• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Facing an issue with leaks utility in mac in usage with the xcode project
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Facing an issue with leaks utility in mac in usage with the xcode project


  • Subject: Re: Facing an issue with leaks utility in mac in usage with the xcode project
  • From: Steve Checkoway <email@hidden>
  • Date: Sat, 2 May 2009 03:38:16 -0700


On Apr 30, 2009, at 9:39 AM, Howard Moon wrote:

It *may* be true, however, that the code shown is simple enough that the compiler optimizes out the two statements altogether. After all, it's an assignment to a variable followed by an another assignment to that same variable. But I'm not sure whether the compiler is allowed to do that here. It seems to me that the function call to malloc, by definition, has side-effects (the allocation of memory, specifically) that cannot be simply ignored. Consider, for instance, if you had written your own malloc() function, and it popped up a dialog before returning the pointer. How could you optimize out a dialog? However, given that compiler knows exactly what malloc does, perhaps it also knows that it can optimize out the resulting assembler code. The best way to know for sure, though, would be to examine the actual assembler code that is generated by that source code. I forget how to do that in XCode offhand, but it should be easy enough to check out.


#include <stdlib.h>
int main()
{
	void *c = malloc(5000);
	c = malloc(5000);
	c = NULL;
	return 0;
}

compiles (with -O3) to

_main:
mflr r0
li r3,5000 ; r3 is the argument to malloc
stw r0,8(r1)
stwu r1,-80(r1)
bl L_malloc$stub; the result is returned in r3
li r3,5000 ; the result is overwriten with the argument to malloc
bl L_malloc$stub; the result is returned in r3
addi r1,r1,80
li r3,0 ; the result is overwritten with main()'s return value
lwz r0,8(r1)
mtlr r0
blr


So no, gcc does not optimize that away. (x86 code looks very similar although it uses 24 bytes of stack space instead of 80.)

--
Steve Checkoway

    "Anyone who says that the solution is to educate the users
    hasn't ever met an actual user." -- Bruce Schneier




Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Prev by Date: Couldn't find minimal bounds for "_sigtramp" - backtraces may be unreliable
  • Next by Date: Re: Removing "Missing images" from Interface Builder
  • Previous by thread: Fwd: Couldn't find minimal bounds for "_sigtramp" - backtraces may be unreliable
  • Next by thread: Re: Removing "Missing images" from Interface Builder
  • Index(es):
    • Date
    • Thread