|
|
Paul Hsieh wrote:
> CBFalconer <cbfalco...@xxxxxxxxx> wrote:
>> Paul Hsieh wrote:
>> ... snip ...
>>> The one feature that there simply is NO controversy about at all:
>>> Memory management. I don't think programmers could yell any louder
>>> for better support for any (practical) other feature. (Obviously
>>> the other one is bounds checked arrays, however, that runs into
>>> practicality problems.) Show me a document anywhere that
>>> demonstrates that the ISO C language committee gave a flying fig
>>> about memory management; that they were working towards some sort
>>> of library extensions or API enhancements to deal with the leaking,
>>> corruption and examination of memory.
>>
>> You obviously don't realize that the fundamental C technique of
>> 'taking addresses' and 'forming pointers' to things in various
>> types of storage makes such memory checking totally impossible.
>
> What the hell is your problem? You know very well that I am a supreme
> expert about such things.
>
>> Unless you are willing to give up all efficiency by making all
>> pointers indirect, and keeping a master list, and modifying that on
>> every *p++ coding.
>
> When you are in a corrupted state, indeed there is nothing you can do
> that is *guaranteed*. But there is a lot you can do with 99.99%
> certainty. This is the whole premise behind the very concept of a
> debugger, for example.
>
> My point is that it is very typical that debuggers which are too
> general, have very little insight into the state and structure of
> memory. Yet, with some work, its easily possible to make a very
> useful self-checking memory manager that takes very little performance
> and very little extra space overhead. Having written a heap manager
> yourself, you must be very well aware of this -- it costs basically
> nothing to have a very rich debugging environment for memory.
>
> For example, its trivial to track the base/system heap memory regions
> that your manager allocates from. So writing a function like:
>
> int isInAllocatedMemoryRange (void * ptr, int size);
>
> is both useful and easy to do, and *you* of all people ought to know
> that you can do this. Of course its not a guarantee that the pointer
> is in the right format, or aligned properly, or pointing at live
> allocated memory. So we can try to add the following:
I have ignored the remainder. Getting too complex for me.
However, my point is that there is no way (apart from comprehensive
runtime tables) to tell that a pointer is to malloced memory,
static memory, or automatic memory. There is also no way to tell
that that pointer is the the whole chunk, or to a miniscule chunk
of that. This makes memory checking virtually impossible, if you
want to preserve efficiency.
Sure, I can do some things with a subset of those pointers, which I
have allocated and manipulated since birth. But those operations
won't function on another system. They will be totally confused if
ever passed non-malloced pointers, or even malloced pointers using
another malloc package.
I just don't like any software that 'works sometimes'. If its
purpose is to tell me that memory is being misused, I want a
definite answer. Barring that, I prefer no answer.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from www.teranews.com">http://www.teranews.com
|
|