Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: "Death To C" |
| Date | 2015-05-05 06:48 +0000 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <mi9p38$m67$1@speranza.aioe.org> (permalink) |
| References | <mi8hvq$p37$1@dont-email.me> <1d3d39e1-3907-4222-9369-154784461fbd@googlegroups.com> <20150504224134.0e897c71@maxa-pc> <gq6gkapsgtcnsrmulg96q7nvd1v919i5u6@4ax.com> |
Robert Wessel <robertwessel2@yahoo.com> wrote: (snip) >> It's easy enough to implement safe arrays in another >>> language, but they you lose the speed of raw writes to memory. >>It's easy enough to bounds check but who does it? > 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. Yes it has to be done for whole allocations, as that is the way C defines what you can do with pointers. If that isn't good enough, you just have to specifically allocate each object you want checked. In the OS/2 1.x days, I could easily do this, and with no additional overhead. (That is, no more than 80286 protected mode does for far pointer access.) Instead of calling malloc(), I directly called the OS/2 segment allocator, allocating the exact length needed. Then supply a zero offset and store into a pointer. The 80286 hardware traps access to non-allocated segment selectors, and access past the end of the allocated length for each segment. One thing not checked is that offsets will wrap at 64K, and so could come back into the actual segment. Then again, with 16 bit int, subscript calculation itself could wrap. But you don't have to worry about overwriting any other segment. For the 80386, segments and segment selectors are still there, and the Watcom C compiler will generate large model 32 bit code (pointers have a 16 bit segment selector, and 32 bit offset). It might be that OS/2 2.0 and up can use that, but pretty much all the other OS expect to allocate one big segment (maybe two, a code and a data segment). No help in bounds checking. -- glen
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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