Re: C local auto-initialized?
Re: C local auto-initialized?
- Subject: Re: C local auto-initialized?
- From: Laurence Harris <email@hidden>
- Date: Fri, 21 Sep 2007 16:20:32 -0400
On Sep 21, 2007, at 11:19 AM, alex wrote:
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. :)
Understood. I'm not against using the tools we have available to us,
only against using them as a substitute for writing the best code we
can in the first place.
Larry
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