Re: Bounds checking, Optimization techniques and undefined behavior

On 06/05/2019 14:39, Jan Ziak wrote:
> On Sunday, May 5, 2019 at 8:01:05 PM UTC+2, Bart wrote:
>> But how do they get there? Take this:
>>
>> int A[10], *p;
>> p = &A[3];
>>
>> You intend p to refer to the 4-element slice A[3..6], but how does the
>> language know that? How can it stop code from writing to p[5]?
>>
>> Or you intend to index p[-2] to get at the preceding elements. Actually
>> using negative indexing is quite common, but surely all array bounds in
>> C are presumed to start from 0?
>
> How are you suggesting to implement malloc() and free() in C if all memory
> accesses through pointers are bounds checked? An implementation of free(p)
> might need to access memory at ((size_t*)p)[-1] to read metadata of the memory
> block such as the block size. This memory access if outside of the bounds of
> the "p" passed to free().


Currently, it is impossible to implement malloc() and free() in strictly
conforming standard C.


The folks working on new documents formalising "pointer provenance" are
taking this into account, and trying to make it possible.


>
> One solution is to introduce unsafe code regions and unsafe functions like in
> Rust.


That would be conceivable, but I think inappropriate for C. The kind of
tracking and pointer provenance that C does now is at the compiler level
- it does not involve run-time checking. Having "safe" and "unsafe"
areas would imply different kinds of guarantees and checks - the kind
that C avoids for efficiency. (If you want checking, use a different
language.)


A more likely choice is to introduce a way to remove the provenance from
a pointer, and also its type information.


>
> Another solution would be to implement memory allocation functions in a non-C
> language. For example, older versions of the Go programming language were
> implementing memory management in a non-Go language (which happens to be C).
> (Newer versions of Go are implementing memory management in Go by using unsafe
> pointers and in assembly.)
>
> (I didn't read all posts in this discussion so it is possible that you already
> answered this question.)
>
> Sincerely
> Jan
> [There's all sorts of stuff in the C library that you can't write in
> standard C. How would you write a C version of longjmp()?
> This isn't a new issue and the approaches you suggest are the ones
> people use. -John]
>


There is not a lot that can't be written in standard C.
setjmp()/longjmp() is one case, as are malloc()/free(), and the
offsetof() macro. And clearly printf, file I/O, etc., need external
code to do the actual work. But generally the majority of any standard
C library is written in C.

Return to the comp.compilers page.
Search the comp.compilers archives again.