Path: csiph.com!xmission!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end
From: Jan Ziak <0xe2.0x9a.0x9b@gmail.com>
Newsgroups: comp.compilers
Subject: Re: reliability features and Optimization techniques
Date: Mon, 29 Apr 2019 04:33:26 -0700 (PDT)
Organization: Compilers Central
Lines: 35
Sender: news@iecc.com
Approved: comp.compilers@iecc.com
Message-ID: <19-04-040@comp.compilers>
References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <19-04-020@comp.compilers> <19-04-025@comp.compilers> <19-04-035@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="86952"; mail-complaints-to="abuse@iecc.com"
Keywords: optimize, C
Posted-Date: 29 Apr 2019 11:33:23 EDT
X-submission-address: compilers@iecc.com
X-moderator-address: compilers-request@iecc.com
X-FAQ-and-archives: http://compilers.iecc.com
In-Reply-To: <19-04-035@comp.compilers>
Xref: csiph.com comp.compilers:2224

On Monday, April 29, 2019 at 12:31:16 AM UTC+2, Bart wrote:
> On 26/04/2019 09:33, alexfrunews@gmail.com wrote:
> Jan Ziak wrote:
>  >> I don't fully understand. Are you suggesting to add buffer overflow
> checks to
>  >> the C language?
>  >
>  > No. However, I think the language could provide a designated
>  > tuple-like type containing a pointer and a count/size and maybe some
>  > functions/macros to check the range. Or something like that. But...
>
> Yes, that's a feature I call a slice, which is a pointer and length.
> That would be quite useful, except that typical C doesn't even use
> arrays properly:
>
> Instead of a function parameter being of type T(*)[] (pointer to array
> of T), usually it is just T* (pointer to its element type). The array is
> implied, which means it is possible to pass a pointer to anything: a
> single T value; 2 successive T members of a struct. Or even just the
> middle of an array.
>
> It is undisciplined, with the 'length' of the implied array of such a
> pointer being badly defined. (It can't even be the bounds of an
> allocated memory block, because that can be bigger than the array.)
>
> So C is pretty much a lost cause.

You don't necessarily need to introduce slices to C in order to enable the
safety checks (slice-like safety checks). By sacrificing a bit of runtime
performance and slightly increasing memory consumption, the generated assembly
code can perform the checks even if the pointer size remains to be 8 bytes (or
4 bytes in case of a 32-bit address space).

Sincerely
Jan