Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #100891
| 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> |
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
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