Re: C local auto-initialized?
Re: C local auto-initialized?
- Subject: Re: C local auto-initialized?
- From: Laurence Harris <email@hidden>
- Date: Thu, 20 Sep 2007 22:24:00 -0400
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