Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: "Death To C" |
| Date | 2015-05-05 20:12 +1200 |
| Message-ID | <cqrcbkFcphdU3@mid.individual.net> (permalink) |
| References | (4 earlier) <cqr3kbFcphdU1@mid.individual.net> <khmgka15778o8koo8u2iib2a96vn06r25o@4ax.com> <ngngka9bb2ij7jvdhcejlsnf3qdos2f5l4@4ax.com> <cqr90dFcphdU2@mid.individual.net> <ussgkalcga3b71ulg118n6ejctrl67q7i6@4ax.com> |
Robert Wessel wrote:
> On Tue, 05 May 2015 19:15:25 +1200, Ian Collins <ian-news@hotmail.com>
> wrote:
>> Robert Wessel wrote:
>>>
>>> A more direct example of the difficulty:
>>>
>>> struct s {char s[8]; char t[8]; void (*fp)();} s1;
>>> void *vp = &s1;
>>> char *cp = vp;
>>> cp += offsetof(s, t);
>>> strcpy(cp, "abcdefghihjk");
>>>
>>> How do you prevent the strcpy from overlaying the function pointer?
>>> Assume that these five lines are wildly separated.
>>
>> You can't...
>>
>> These are the sorts of examples where an idiomatic C++ solution can lead
>> to much safer code, often where the only overhead is in the bounds checking.
>
> I'm confused. I came in with "C makes thorough bounds checking almost
> impossible. You *can* check named (static/automatic) and allocated
> objects as a whole fairly easily (…), doing that within objects is
> nearly, if not actually, impossible while maintaining full C
> semantics." And I got people disagreeing with me.
Not me...
> Certainly following some good coding techniques can help a great deal,
> but you're relying on the programmer to do it right, and it can't be
> easily enforced by the compiler.
One very common coding rule in C++ is not to expose raw pointers, which
while unenforceable by the compiler, is enforceable through code review.
Not foolproof, but better than C where you often cant avoid exposing
raw pointers.
I guess you could enforce a similar rule in C through code review: if a
struct has a raw pointer, it must be used as an opaque type.
--
Ian Collins
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