Path: csiph.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: David Brown Newsgroups: comp.compilers Subject: Re: Bounds checking, Optimization techniques and undefined behavior Date: Tue, 7 May 2019 15:42:31 +0200 Organization: A noiseless patient Spider Lines: 63 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-05-048@comp.compilers> References: <19-04-021@comp.compilers> <19-04-023@comp.compilers> <19-04-037@comp.compilers> <19-04-039@comp.compilers> <19-04-042@comp.compilers> <19-04-044@comp.compilers> <19-04-047@comp.compilers> <19-05-004@comp.compilers> <19-05-006@comp.compilers> <19-05-016@comp.compilers> <19-05-020@comp.compilers> <19-05-024@comp.compilers> <19-05-025@comp.compilers> <19-05-028@comp.compilers> <19-05-038@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="24053"; mail-complaints-to="abuse@iecc.com" Keywords: C, standards Posted-Date: 07 May 2019 18:41:29 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Content-Language: en-GB Xref: csiph.com comp.compilers:2283 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.