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


Groups > comp.lang.c > #61612

Re: Bounds checking in C (Was: "Death To C")

From BGB <cr88192@hotmail.com>
Newsgroups comp.lang.c
Subject Re: Bounds checking in C (Was: "Death To C")
Date 2015-05-06 10:23 -0500
Organization albasani.net
Message-ID <midbs8$hls$1@news.albasani.net> (permalink)
References <mi8hvq$p37$1@dont-email.me> <1d3d39e1-3907-4222-9369-154784461fbd@googlegroups.com> <20150504224134.0e897c71@maxa-pc> <gq6gkapsgtcnsrmulg96q7nvd1v919i5u6@4ax.com> <mi994l$agr$1@news.xmission.com>

Show all headers | View raw


On 5/4/2015 9:15 PM, Kenny McCormack wrote:
> In article <gq6gkapsgtcnsrmulg96q7nvd1v919i5u6@4ax.com>,
> Robert Wessel  <robertwessel2@yahoo.com> wrote:
> ...
>> No it's really not.  C makes thorough bounds checking almost
>> impossible.  You *can* check named (static/automatic) and allocated
>> objects as a whole fairly easily (although with fairly high overhead,
>> usually with some sort of fat pointer scheme), doing that within
>> objects is nearly, if not actually, impossible while maintaining full
>> C semantics.
>
> There are two ways of doing it, both of which have been done (at least in
> theory):
>
>      1) Implement "Fat Pointers" and require that they be used exclusively.
> 	People can program in C, but they can't (in your new regime) use
> 	regular (non-fat) pointers.  Anyone who does, get fired.
>
>      2) Implement a "safe runtime" that takes a C program and runs the
> 	program on that runtime.  Essentially, C becomes an interpreted
> 	language.  Again, anyone who doesn't conform to the new regime gets
> 	shot, er, I mean, fired.
>

alternatively, one can use narrow pointers, but do operations via 
runtime functions which do safety checks via lookups, though still at a 
reasonably high performance cost (though, if done right, the lookups can 
be done in O(1), which is generally useable except in 
performance-sensitive code).

IME, the performance costs between a lookup for every operation roughly 
balances that of using fat-pointers (which need to be endlessly copied 
around in memory), but waste less memory (and fits better in cache).


for performance sensitive code though, bounds checks in general can kill 
performance (and thus make them unuseable in general). some runtimes 
though (for high level languages) are capable of optimizing away runtime 
checks (generally by proving that the access can be done without 
exceeding array bounds).


for my scripting language, I had made a distinction between 
object-reference and pointer cases, using narrow pointers for object 
references and similar, and fat pointers for explicit pointer types.

in the C FFI (and for storing into structs), they were converted to 
narrow pointers, and generally runtime lookups were used to regenerate 
the fat-pointer form when loading them back in.


I have a VM for running a C variant, but this currently only uses 
unchecked pointers (for the current use-case, performance is more 
important than safety).

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