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


Groups > comp.lang.c > #100891

Re: Automatic null checks

From Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups comp.lang.c
Subject Re: Automatic null checks
Date 2017-01-02 18:48 +0000
Organization A noiseless patient Spider
Message-ID <871swll2ma.fsf@bsb.me.uk> (permalink)
References (1 earlier) <33078933-d344-4aa3-b6ea-e657c7e28cb5@googlegroups.com> <87y3yumln1.fsf@bsb.me.uk> <08b6c636-00d1-4f36-805a-9b2b5ef53f7e@googlegroups.com> <878tqumcxg.fsf@bsb.me.uk> <ae340449-b836-408f-b390-0916eadf49a4@googlegroups.com>

Show all headers | View raw


supercat@casperkitty.com writes:

> On Sunday, January 1, 2017 at 8:08:17 PM UTC-6, Ben Bacarisse wrote:
>> supercat writes:
>> > 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"?
>
> There are many situations where it will be necessary to read some items out
> of an array of pointers before any objects *exist* to which some other
> items could meaningfully point.

You are simply stating the problem with nullable pointers.  I sketched
out how other languages get round this situation.  You can't use an
array of pointers because, since they can't be null, there is nothing
for them to point at.

<snip>
-- 
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