Re: Bounds checking, Optimization techniques and undefined behavior

Jan Ziak <0xe2.0x9a.0x9b@gmail.com>
Mon, 6 May 2019 05:39:16 -0700 (PDT)

          From comp.compilers

Related articles
[15 earlier articles]
Re: Bounds checking, Optimization techniques and undefined behavior gneuner2@comcast.net (George Neuner) (2019-05-05)
Re: Bounds checking, Optimization techniques and undefined behavior gneuner2@comcast.net (George Neuner) (2019-05-05)
Re: Bounds checking, Optimization techniques and undefined behavior anw@cuboid.co.uk (Andy Walker) (2019-05-06)
Re: Bounds checking, Optimization techniques and undefined behavior DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2019-05-06)
Re: Bounds checking, Optimization techniques and undefined behavior christopher.f.clark@compiler-resources.com (Christopher F Clark) (2019-05-06)
Re: Bounds checking, Optimization techniques and undefined behavior bc@freeuk.com (Bart) (2019-05-06)
Re: Bounds checking, Optimization techniques and undefined behavior 0xe2.0x9a.0x9b@gmail.com (Jan Ziak) (2019-05-06)
Re: Bounds checking, Optimization techniques and undefined behavior anw@cuboid.co.uk (Andy Walker) (2019-05-06)
Re: Bounds checking, Optimization techniques and undefined behavior david.brown@hesbynett.no (David Brown) (2019-05-06)
Re: Bounds checking, Optimization techniques and undefined behavior david.brown@hesbynett.no (David Brown) (2019-05-07)
Re: Bounds checking, Optimization techniques and undefined behavior david.brown@hesbynett.no (David Brown) (2019-05-07)
Re: Bounds checking, Optimization techniques and undefined behavior david.brown@hesbynett.no (David Brown) (2019-05-07)
Re: Bounds checking, Optimization techniques and undefined behavior david.brown@hesbynett.no (David Brown) (2019-05-07)
[13 later articles]
| List of all articles for this month |

From: Jan Ziak <0xe2.0x9a.0x9b@gmail.com>
Newsgroups: comp.compilers
Date: Mon, 6 May 2019 05:39:16 -0700 (PDT)
Organization: Compilers Central
References: 19-04-021 19-04-023 19-04-037 19-04-039 19-04-042 19-04-044 19-04-047 19-05-004 19-05-006 19-05-016 19-05-020 19-05-024 19-05-025 19-05-028
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="37475"; mail-complaints-to="abuse@iecc.com"
Keywords: C, standards, comment
Posted-Date: 06 May 2019 10:50:28 EDT
In-Reply-To: 19-05-028

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().


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


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]


Post a followup to this message

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