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

Groups > comp.lang.c > #61629

Re: "Death To C"

Show all headers | View raw

On 06/05/2015 17:43, Malcolm McLean wrote:
> On Wednesday, May 6, 2015 at 1:49:37 PM UTC+1, Richard Heathfield wrote:
>>
>> The latter would be a better option. Not quite sure how you'd implement
>> it in C, though, given that the compiler may not be able to tell how
>> many items forall should cover. Consider:
>>
>> void foo(int *p)
>> {
>>     size_t n;
>>     forall(p, n) /* how does the compiler know how many times to run this
>> loop? */
>>     {
>>       foo(p[n]);
>>     }
>> }
>>
>> It would be a fairly major change to the language, and would almost
>> certainly involve information about the array being squirrelled away by
>> the compiler, which squirrelling would inevitably incur a performance
>> overhead.
>>
> What you'd have to do (I'm not sure this is a good idea, but might as well float it)
> is have some syntax to indicate that a pointer is the return value from malloc().
> You could say int [] ptr or something.
> Then you have a function called msize( void [] ptr) that returns the size of the
> block. That puts constraints on malloc() internals. But it means that if you allocate
> arrays dynamically, and don't try to slice and dice them, you the size can't become
> detached from the array.

If changes are going to be made which aren't just syntax, then a 
relatively simple addition is to introduce a 'slice'. This is just a 
composite type consisting of a pointer, and a length.

So when a dynamic array of type T is allocated, the result is a slice of 
type T. Slices of T are passed around instead of T* values (where you 
can't even tell if this is a single value, or a part of an array, or an 
element of an array that nevertheless you want to treat as a single value).

With a slice, then bounds checking becomes far more practical. However, 
because a slice (the pointer and/or length) can be modified, there is 
still some trust that the compiler has to place in the programmer that 
the correct length is present for that pointer. But this is still better 
than taking any random pointer P and a random index i and being able to 
do P[i], no questions asked, and no bounds checking because it is 
impossible other than when it strays outside program memory.

Slices can also refer to sub-arrays inside a larger one, and to counted 
substrings of a string. They are handy.

(To some extent some of this can be done now by manually defining such a 
composite type, but without proper language support it will look 
terrible, worse than dealing with separate pointers and lengths.

Also, for dynamic arrays that are going to change size, you will need a 
slice that contains a bit more info. But these are details.)

-- 
Bartc

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

"Death To C" Lynn McGuire <lmc@winsim.com> - 2015-05-04 14:41 -0500
  Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-04 22:16 +0200
    Re: "Death To C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-04 13:26 -0700
      Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-04 22:51 +0200
      Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-04 22:02 +0100
        Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-05 00:06 +0200
  Re: "Death To C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-04 13:22 -0700
    Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-04 22:41 +0200
      Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-04 20:25 -0500
        Bounds checking in C (Was: "Death To C") gazelle@shell.xmission.com (Kenny McCormack) - 2015-05-05 02:15 +0000
          Re: Bounds checking in C (Was: "Death To C") BGB <cr88192@hotmail.com> - 2015-05-06 10:23 -0500
        Re: "Death To C" Les Cargill <lcargill99@comcast.com> - 2015-05-04 21:36 -0500
          Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 01:01 -0500
            Re: "Death To C" Les Cargill <lcargill99@comcast.com> - 2015-05-05 12:23 -0500
          Re: "Death To C" CHIN Dihedral <dihedral88888@gmail.com> - 2015-05-05 03:06 -0700
        Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 17:43 +1200
          Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 01:00 -0500
            Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 01:13 -0500
              Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 19:15 +1200
                Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 02:41 -0500
                Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 20:12 +1200
        Re: "Death To C" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-05 06:48 +0000
        Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-05 10:57 +0100
          Re: "Death To C" asetofsymbols@gmail.com - 2015-05-05 16:53 -0700
          Re: "Death To C" Nobody <nobody@nowhere.invalid> - 2015-05-06 08:10 +0100
            Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-06 09:53 +0100
              Re: "Death To C" Richard Heathfield <rjh@cpax.org.uk> - 2015-05-06 13:49 +0100
                Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-06 14:29 +0100
                Re: "Death To C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-06 09:43 -0700
                Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-06 18:24 +0100
          Re: "Death To C" asetofsymbols@gmail.com - 2015-05-08 00:44 -0700
            Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-08 13:49 +0100
    Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-04 22:15 +0100
      Re: "Death To C" BGB <cr88192@hotmail.com> - 2015-05-08 09:09 -0500
    Re: "Death To C" Stephen Sprunk <stephen@sprunk.org> - 2015-05-04 16:18 -0500
    Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 12:49 +1200
  Re: "Death To C" raltbos@xs4all.nl (Richard Bos) - 2015-05-08 21:52 +0000
  Re: "Death To C" Merikissa <merikissa@no.spam.net> - 2015-05-10 04:04 +0300
  Re: "Death To C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-05-13 08:11 -0700
    Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-13 10:00 -0700
      Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-13 18:20 +0100
        Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-14 10:47 -0700
          Re: "Death To C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-05-14 11:09 -0700
          Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-15 19:21 +0100
            Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-16 09:10 -0700
              Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-16 20:45 +0100
                Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-17 09:38 -0700
        Re: "Death To C" raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:47 +0000
          Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-17 12:20 +0100
      Re: "Death To C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-05-13 10:24 -0700
        Re: "Death To C" David Brown <david.brown@hesbynett.no> - 2015-05-13 22:01 +0200
    Re: "Death To C" Nobody <nobody@nowhere.invalid> - 2015-05-14 07:48 +0100

csiph-web