comp.lang.c
[Top] [All Lists]

Re: What's the deal with C99?

Subject: Re: What's the deal with C99?
From: CBFalconer
Date: Fri, 28 Mar 2008 11:08:34 -0500
Newsgroups: comp.lang.c

Paul Hsieh wrote:
> CBFalconer <cbfalco...@xxxxxxxxx> wrote:
>
... snip ...
> 
>> [...] 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.
> 
> Huh?  Look, you want the block with its header to be aligned.  But
> you also want the base pointer to be aligned.  That means you have
> *LOTS* of header space.  If you do an approximation of (uint32_t)
> SHA2({ptr,size}) (you can go waaay simpler, I am just giving an
> overkill example to illustrate the point) and store it in the
> header somewhere, then that's it; the memory allocation is marked
> in a pseudo-unique fashion.  You aren't going to run into flukey
> internal or static pointers that randomly reproduce this signature.

Consider:

 void *cpymem(void* restrict s1, const void* restrict s2, size_t
n);

How is that code going to tell the three types of pointers
mentioned above (apart from other subdivisions) apart?  How is it
to tell that the n passed is one-off?  Every time.

The compiler and its tables do not go along with the object code. 
For C large and complex run-time tables are needed, and total
indirection of all pointers.  This gives up the fundamental
advantage of C, i.e. its closeness to the underlying machine.

-- 
 [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


<Prev in Thread] Current Thread [Next in Thread>
Privacy Policy