Re: C local auto-initialized?
Re: C local auto-initialized?
- Subject: Re: C local auto-initialized?
- From: alex <email@hidden>
- Date: Fri, 21 Sep 2007 08:19:37 -0700
While I agree with you completely, most of my experience with software has been interfacing with other people's/company's libraries and or source code. In those cases (where you didn't write the code yourself and there may be say 1M lines to sort thru), the more tools you have the faster you get to market. :)
alex
At 10:24 PM -0400 9/20/07, Laurence Harris wrote:
>On Sep 20, 2007, at 9:29 PM, alex wrote:
>
>>Perhaps you can substitute a debug allocator library that overrides new/delete/malloc/free. On other platforms these libraries come for free. They cause memory that was once used and freed to be set to 0xCC, or some other value that is easily detected. They also set the stack to bogus values for easy detection.
>>
>>This approach coupled with a bit of 'tricky stack manipulation' will get you tons of uninitialized values other than 0 for your autos. With just alittle debug assembler glue you can 'wipe' your current stack will help tremendously. I can't tell you how many times this technique has saved me weeks of debugging intermittent bugs.
>>
>>The problem here is that while this is an important thing to teach, the best way to code against it is to force your allocator to initialize your variables to bogus values with the hopes of catching these accesses to uninitialized memory. Better yet, _always_ initialize your variables (unless you are in a tight loop of course :))
>
>The best way to avoid this problem is to initialize variables as you declare them and take the time to code carefully. Nothing against using tools to catch errors, but I think too many people write sloppy code and then expect tools or testers to flush out the bugs. The obvious flaw in that approach is that bugs can manifest themselves in subtle ways and with varying frequency. The bug that causes a crash every time is identified quickly. The bug that causes a slightly incorrect result may not be found until after the product is released, if at all. Ditto for bugs that only manifest themselves on certain hardware, when the user is using a different language, only once every 10,000 passes through the code, only after the code's been running a few months, and so on. So while debugging tools are great, there's no substitute for being careful and thorough if you want to write solid code.
>
>Larry
_______________________________________________
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