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

Groups > comp.lang.c > #100848

Re: Automatic null checks

Show all headers | View raw

supercat@casperkitty.com writes:

> On Sunday, January 1, 2017 at 5:00:09 PM UTC-6, Ben Bacarisse wrote:
>> supercat writes:
>> > A fundamental difficulty with non-nullable pointer/reference types, which
>> > renders absurd the notion that null pointers were a "billion-dollar mistake",
>> > is that it will often be necessary to read some items out of an array of
>> > pointers before all members of the array have been written, and *something*
>> > has to happen if code attempts to read from an array element which has not
>> > been written.
>> 
>> But something can (and should) always be written.  Other languages deal
>> with this using a discriminated union or "maybe" type of some sort and
>> the array is always initially filled with values of the "nothing" type.
>
> The problem is that it's generally not possible to statically ensure that
> no element of the array will be written without having been read first,
> except by imposing severe restrictions on the order in which things are
> done (E.g. requiring that all elements be written in a loop which is
> statically verifiable as writing all of them, and no element is read
> before or within that loop except using forms that can be statically
> verified as only accessing subscripts which have previously been written).
> Even if code isn't supposed to read elements that haven't been written,
> a compiler which is trying to offer any kind of safety will have to be
> prepared for the possibility that it might (it would be silly for a
> compiler to try to offer static safety, but then have programs jump the
> rails, rather than terminating in controlled fashion, if e.g. an array
> which is supposed to hold a permutation of the numbers 0 to 49 instead
> has a duplicated value and a missing value and, as a consequence, the
> array element corresponding to the missing value never gets written).

I can't unpick that.  Are you changing the "fundamental difficulty" into
"making it type-safe will be less efficient"?

-- 
Ben.

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

Thread

Automatic null checks Thiago Adams <thiago.adams@gmail.com> - 2017-01-01 09:53 -0800
  Re: Automatic null checks Thiago Adams <thiago.adams@gmail.com> - 2017-01-01 10:16 -0800
    Re: Automatic null checks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 19:26 +0000
      Re: Automatic null checks Thiago Adams <thiago.adams@gmail.com> - 2017-01-02 05:56 -0800
        Re: Automatic null checks Thiago Adams <thiago.adams@gmail.com> - 2017-01-02 08:26 -0800
    Re: Automatic null checks jacobnavia <jacob@jacob.remcomp.fr> - 2017-01-01 22:39 +0100
  Re: Automatic null checks supercat@casperkitty.com - 2017-01-01 14:24 -0800
    Re: Automatic null checks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 23:00 +0000
      Re: Automatic null checks supercat@casperkitty.com - 2017-01-01 16:42 -0800
        Re: Automatic null checks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 02:08 +0000
          Re: Automatic null checks supercat@casperkitty.com - 2017-01-02 09:38 -0800
            Re: Automatic null checks Thiago Adams <thiago.adams@gmail.com> - 2017-01-02 10:25 -0800
            Re: Automatic null checks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 18:48 +0000
    Re: Automatic null checks Thiago Adams <thiago.adams@gmail.com> - 2017-01-02 07:45 -0800
  Re: Automatic null checks Les Cargill <lcargill99@comcast.com> - 2017-01-03 07:11 -0600
    Re: Automatic null checks Thiago Adams <thiago.adams@gmail.com> - 2017-01-03 17:43 -0800

csiph-web