Re: reliability features and Optimization techniques

Jan Ziak <0xe2.0x9a.0x9b@gmail.com>
Mon, 29 Apr 2019 04:33:26 -0700 (PDT)

          From comp.compilers

Related articles
Re: Optimization techniques martin@gkc.org.uk (Martin Ward) (2019-04-25)
Re: Optimization techniques alexfrunews@gmail.com (2019-04-26)
Re: reliability features and Optimization techniques bc@freeuk.com (Bart) (2019-04-28)
Re: reliability features and Optimization techniques 0xe2.0x9a.0x9b@gmail.com (Jan Ziak) (2019-04-29)
| List of all articles for this month |

From: Jan Ziak <0xe2.0x9a.0x9b@gmail.com>
Newsgroups: comp.compilers
Date: Mon, 29 Apr 2019 04:33:26 -0700 (PDT)
Organization: Compilers Central
References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> 19-04-020 19-04-025 19-04-035
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
In-Reply-To: 19-04-035

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


Post a followup to this message

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