Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #2224

Re: reliability features and Optimization techniques

Show all headers | View raw

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

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Optimization techniques Martin Ward <martin@gkc.org.uk> - 2019-04-25 16:46 +0100
  Re: Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-04-25 23:01 +0000
  Re: Optimization techniques alexfrunews@gmail.com - 2019-04-26 01:33 -0700
    Re: language design and Optimization techniques Martin Ward <martin@gkc.org.uk> - 2019-04-27 11:56 +0100
    Re: Optimization techniques 0xe2.0x9a.0x9b@gmail.com - 2019-04-27 04:56 -0700
      Re: C language andOptimization techniques alexfrunews@gmail.com - 2019-04-27 19:47 -0700
    Re: reliability features and Optimization techniques Bart <bc@freeuk.com> - 2019-04-28 11:58 +0100
      Re: reliability features and Optimization techniques Jan Ziak <0xe2.0x9a.0x9b@gmail.com> - 2019-04-29 04:33 -0700
    Re: Optimization techniques Gene Wirchenko <genew@telus.net> - 2019-04-30 18:11 -0700
    Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-05-07 16:43 +0200
  Re: Optimization techniques Hans Aberg <haberg-news@telia.com> - 2019-04-27 23:01 +0200
    Re: Optimization techniques, C++ numeric representations David Brown <david.brown@hesbynett.no> - 2019-04-29 17:24 +0200
      Re: Optimization techniques, C++ numeric representations Hans Aberg <haberg-news@telia.com> - 2019-04-30 15:01 +0200

csiph-web