Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #74838 > unrolled thread
| Started by | G G <gdotone@gmail.com> |
|---|---|
| First post | 2015-11-04 06:22 -0800 |
| Last post | 2015-11-05 21:24 -0800 |
| Articles | 20 on this page of 184 — 23 participants |
Back to article view | Back to comp.lang.c
One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-04 06:22 -0800
Re: One over another: (*structp).component structp->component Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-04 09:37 -0500
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-04 06:59 -0800
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-04 15:52 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-04 22:05 +0000
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-04 22:20 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-04 23:32 +0000
Re: One over another: (*structp).component structp->component "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-04 15:55 -0800
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-05 00:21 +0000
Re: One over another: (*structp).component structp->component "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-04 15:58 -0800
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-05 00:26 +0000
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-04 16:27 -0800
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-05 00:25 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-05 00:59 +0000
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-05 01:22 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-05 10:30 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-04 18:09 -0800
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-06 01:08 +0000
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-06 01:19 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-06 11:30 +0000
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-06 11:55 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-06 13:29 +0000
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-06 14:00 +0000
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-06 14:24 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-06 16:58 +0000
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-06 17:55 +0000
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-06 18:07 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-06 19:51 +0000
Re: One over another: (*structp).component structp->component Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-06 13:09 -0500
Re: One over another: (*structp).component structp->component Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-06 13:15 -0500
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-06 18:58 +0000
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-06 10:30 -0800
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-06 19:09 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-06 12:35 -0800
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-06 12:38 -0800
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-06 19:43 +0000
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-10 16:39 +0000
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-10 17:28 +0000
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-10 18:04 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-10 11:19 -0800
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-10 21:04 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-10 13:31 -0800
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-10 22:15 +0000
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-10 23:33 +0000
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-10 23:59 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-11 10:46 +0000
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-11 11:01 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-11 08:43 -0800
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-11 16:58 +0000
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-11 09:14 -0800
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 00:47 +0000
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-18 04:12 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-17 20:27 -0800
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 08:11 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-17 20:14 -0800
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 08:14 +0000
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-18 08:12 -0500
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 14:33 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-18 09:05 -0800
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 23:16 +0000
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-18 18:23 -0500
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-19 00:27 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-19 00:44 +0000
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-19 04:11 +0000
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-19 00:19 -0500
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-19 00:52 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-20 02:24 -0800
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-20 15:07 +0000
Re: One over another: (*structp).component structp->component Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-20 10:19 -0500
Re: One over another: (*structp).component structp->component Philip Lantz <prl@canterey.us> - 2015-11-23 00:06 -0800
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-18 16:21 +0000
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-18 13:29 -0500
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-18 22:00 +0000
Re: One over another: (*structp).component structp->component Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-18 17:33 -0500
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 15:38 -0800
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 23:23 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-19 00:12 +0000
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-12 09:00 +0000
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-12 10:12 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-11 17:31 +0000
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-11 18:42 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-11 23:38 +0000
Re: One over another: (*structp).component structp->component David Brown <david.brown@hesbynett.no> - 2015-11-11 10:56 +0100
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-11 10:52 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-11 08:28 -0800
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-11 16:52 +0000
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-11 16:35 +0000
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-10 15:43 -0800
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-13 22:13 +0000
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-13 23:52 +0000
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:02 +0000
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-17 23:56 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-17 20:10 -0800
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-18 11:51 +0000
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-19 10:33 +0000
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-19 10:23 +0000
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-19 11:46 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-06 11:13 -0800
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-06 19:42 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-04 16:33 -0800
Re: One over another: (*structp).component structp->component Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-04 13:11 -0500
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-04 11:49 -0800
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-04 20:00 +0000
Re: One over another: (*structp).component structp->component Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-04 15:36 -0500
Re: One over another: (*structp).component structp->component Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-04 15:16 -0800
Re: One over another: (*structp).component structp->component "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-04 15:28 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-04 16:25 -0800
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-05 00:47 +0000
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-04 19:24 -0800
Re: One over another: (*structp).component structp->component Ian Collins <ian-news@hotmail.com> - 2015-11-05 16:34 +1300
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-05 09:39 +0000
Re: One over another: (*structp).component structp->component David Brown <david.brown@hesbynett.no> - 2015-11-05 13:45 +0100
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-05 13:30 +0000
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-05 08:14 -0800
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-05 08:25 -0800
Re: One over another: (*structp).component structp->component Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-05 12:00 -0500
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-05 09:09 -0800
Re: One over another: (*structp).component structp->component "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-05 11:02 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-05 09:28 -0800
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-05 12:50 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-05 13:38 -0800
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-05 17:29 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-05 17:43 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-05 20:02 -0800
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-06 08:01 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-06 08:35 -0800
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-06 11:10 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-06 13:35 -0800
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-06 12:04 -0800
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-06 13:14 -0800
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-10 13:40 -0800
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-10 14:13 -0800
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-13 05:36 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-13 14:32 -0800
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-14 12:09 -0800
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:03 +0000
Re: One over another: (*structp).component structp->component David Thompson <dave.thompson2@verizon.net> - 2015-12-06 07:56 -0500
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-05 09:26 -0800
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-05 18:06 +0000
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-05 10:10 -0800
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-05 14:08 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-05 14:24 -0800
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-05 18:08 -0500
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-05 17:13 -0800
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-05 13:08 -0500
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-05 10:33 -0800
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-05 21:44 -0500
Re: One over another: (*structp).component structp->component David Brown <david.brown@hesbynett.no> - 2015-11-05 10:38 +0100
Re: One over another: (*structp).component structp->component Reinhardt Behm <rbehm@hushmail.com> - 2015-11-05 21:01 +0800
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-05 09:06 -0500
Re: One over another: (*structp).component structp->component "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-05 06:11 -0800
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-05 14:19 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-05 09:20 -0800
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-05 12:56 -0500
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-06 11:32 +0000
Re: One over another: (*structp).component structp->component David Brown <david.brown@hesbynett.no> - 2015-11-05 20:26 +0100
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-05 07:50 -0800
Re: One over another: (*structp).component structp->component Martin Shobe <martin.shobe@yahoo.com> - 2015-11-05 11:46 -0600
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-06 11:33 -0800
Re: One over another: (*structp).component structp->component Philip Lantz <prl@canterey.us> - 2015-11-07 00:32 -0800
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-13 03:43 -0800
Re: One over another: (*structp).component structp->component David Brown <david.brown@hesbynett.no> - 2015-11-07 20:03 +0100
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-10 16:42 +0000
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-13 04:03 -0800
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-04 19:42 -0800
Re: One over another: (*structp).component structp->component Reinhardt Behm <rbehm@hushmail.com> - 2015-11-05 12:54 +0800
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-05 10:36 +0000
Re: One over another: (*structp).component structp->component Reinhardt Behm <rbehm@hushmail.com> - 2015-11-05 20:46 +0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-05 09:02 -0800
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-06 11:07 +0000
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-06 11:26 +0000
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-06 15:58 +0000
Re: One over another: (*structp).component structp->component Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-06 11:10 -0500
Re: One over another: (*structp).component structp->component Philip Lantz <prl@canterey.us> - 2015-11-07 01:13 -0800
Re: One over another: (*structp).component structp->component Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-07 11:11 -0500
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-10 16:47 +0000
Re: One over another: (*structp).component structp->component Siri Cruz <chine.bleu@yahoo.com> - 2015-11-04 06:49 -0800
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-04 09:55 -0500
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-04 07:00 -0800
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-04 13:19 -0500
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-04 16:17 +0000
Re: One over another: (*structp).component structp->component "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-04 14:53 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-04 15:29 -0800
Re: One over another: (*structp).component structp->component luser droog <luser.droog@gmail.com> - 2015-11-05 21:24 -0800
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | G G <gdotone@gmail.com> |
|---|---|
| Date | 2015-11-05 14:08 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <1ed57b1c-9055-44c7-bc4b-a4be3bca1d40@googlegroups.com> |
| In reply to | #74997 |
On Thursday, November 5, 2015 at 1:06:45 PM UTC-5, Ben Bacarisse wrote:
> G G <gdotone@gmail.com> writes:
>
char *
strcpy(char *s1, const char *s2)
{
char *s = s1;
while ((*s++ = *s2++) != 0)
;
return (s1);
}
> What difference does overlapping make?
> The fact that the specification says the result is undefined when the
> source and the destination overlap means that the implementation is off
> the hook. It can do whatever it likes. Step though the execution of
>
> char test[] = "test";
> strcpy(test + 1, test);
>
> to see how the code exploits that permission.
Ok, I believe I see what you and James are describing, exampling.
I see why so many in the group say a programmer would not do this,
but it is definitely possible that it could happen.
I would like to believe i would not do this, but, well, that's not the point,
it could be done.
That said shouldn't the compiler refuse to allow this. It is modifying
a space of memory that is define to be const or to hold
a const. (constant and not changeable)
If you would please explain const and memory: this is my wrong headed
thought, once a variable (let's say) is declared to be a const, is it's memory
space not protected from any writes to it, that would change value in
that memory location.
Apparently not, but shouldn't it?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-05 14:24 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <c2f482e1-649a-4784-9a22-8e15693fdb74@googlegroups.com> |
| In reply to | #75026 |
On Thursday, November 5, 2015 at 4:08:44 PM UTC-6, G G wrote: > That said shouldn't the compiler refuse to allow this. It is modifying > a space of memory that is define to be const or to hold > a const. (constant and not changeable) The string literal will get copied to a modifiable character array before strcpy executes, and the strcpy function will start out legitimately modifying that array. The problem is that it won't stop when it hits the end of the array. > If you would please explain const and memory: this is my wrong headed > thought, once a variable (let's say) is declared to be a const, is it's memory > space not protected from any writes to it, that would change value in > that memory location. > > Apparently not, but shouldn't it? Computers are generally not able to write-protect individual bytes of memory; some can write-protect parts of memory after storing things declared "const" there, but there are various reasons why such write protection may or may not be effective. In any case, there's a lot that can go wrong from programs which go crazy overwriting things in modifiable storage even if they don't trash any "const" information.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-05 18:08 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1gnd5$9g1$1@dont-email.me> |
| In reply to | #75026 |
On 11/05/2015 05:08 PM, G G wrote:
> On Thursday, November 5, 2015 at 1:06:45 PM UTC-5, Ben Bacarisse wrote:
>> G G <gdotone@gmail.com> writes:
>>
>
> char *
> strcpy(char *s1, const char *s2)
> {
> char *s = s1;
> while ((*s++ = *s2++) != 0)
> ;
> return (s1);
> }
>
>> What difference does overlapping make?
>
>> The fact that the specification says the result is undefined when the
>> source and the destination overlap means that the implementation is off
>> the hook. It can do whatever it likes. Step though the execution of
>>
>> char test[] = "test";
>> strcpy(test + 1, test);
>>
>> to see how the code exploits that permission.
>
> Ok, I believe I see what you and James are describing, exampling.
>
> I see why so many in the group say a programmer would not do this,
> but it is definitely possible that it could happen.
> I would like to believe i would not do this, but, well, that's not the point,
> it could be done.
The rest of your response gives the impression that the problem has
something to do with 'const'. I'll answer your questions about 'const'
down below, but those answers aren't relevant to the overlap problem.
The fundamental problem with an overlap between the source and the
destination of a strcpy() call is that, if strcpy() is implemented as
shown above (and the above is one way a conforming implementation is
allowed to implement it), then the first pas through the loop will set
test[1] to 't'. The second pass through the loop will retrieve the
current value of test[1], which is 't', and then write it to test[2].
This continues until test[4] gets overwritten with 't'. At that point,
test is an array of 5 characters, containing the values {'t', 't', 't',
't', 't'}. During the next pass through the loop, strcpy() reads that
't', instead of reading the '\0' character it was intended to read, and
attempts to write that 't' to test[5]. The behavior of such code is
undefined. On many systems it will keep going, filling up memory with
copies of 't' until it reaches a point it's not allowed to write to. If
there is no such point, it's likely to get stuck in an infinite loop.
Note that, because the behavior is undefined when the source and
destination overlap, this is NOT the only way strcpy(test+1, test) can
malfunction. This version only reads and writes one character at a time,
but there's many real-world systems where it would be more efficient,
particularly for long strings, to read and write 8 characters at a time.
In that case, the read might pick up all 5 characters of "test", before
any of them get written to. It will then write all of those 5 characters
shifted by one. This still results in an attempt to write to test[5],
which has undefined behavior. However, before it does so, test will
contain {'t', 't', 'e', 's', 't'}.
The example I provided in my response doesn't run over the end of the
array, but it still produces results that might not be what you would
have wanted it to produce.
> That said shouldn't the compiler refuse to allow this. It is modifying
> a space of memory that is define to be const or to hold
> a const. (constant and not changeable)
No, it isn't. There's not such memory referred to in the code above.
Here's what it would look like if there were such memory:
const char ctest[] = "ctest";
strcpy(ctest+1, test);
That call to strcpy() would be a constraint violation because of the
'const' on the declaration of ctest. A diagnostic message is required.
The standard allows an implementation to refuse to compile such code,
but an implementation is free to not do so.
The only 'const' anywhere in the above code is in the declaration of s2.
That declaration means that any attempt to use s2 to modify the memory
that it points at would be a constraint violation - but strcpy() doesn't
contain any code that violates that constraint.
Memory that is pointed at by s2 at one point in the loop is modified by
using s1 during a different pass through the loop - but that doesn't
violate any constraints - s1 is not declared as "const char *".
> If you would please explain const and memory: this is my wrong headed
> thought, once a variable (let's say) is declared to be a const, is it's memory
> space not protected from any writes to it, that would change value in
> that memory location.
There's two main aspects of the 'const' keyword, neither of which
matches perfectly what you are saying.
If the definition of an object declares that the object itself is
'const', then any attempt to modify the value of that object has
undefined behavior. This is NOT protection - what it means is that such
code is allowed to malfunction.
Because such code has undefined behavior, an implementation is free to
place such an object in read-only memory. On some systems, it's possible
to set aside a block of memory, set it's value, and then mark it as
read-only; on such systems, even local variables might be placed in
read-only memory if declared 'const'. On other systems, read-only memory
is only a realistic possibility for objects with static storage duration.
There's (at least) two different possible meanings for "read-only
memory". The first meaning is very passive: any attempt to write to that
memory is a no-op - nothing actually changes. The second, more active
meaning, is that any attempt to write to that memory causes execution of
your program to halt. "undefined behavior" covers both of those
possibilities (and many others as well).
If, instead of defining that an object is 'const', you define it as
pointing at a 'const' object, entirely different issues arise. What that
declaration means is that most of the ways you could use that pointer to
put the object that it points at it in danger of being modified would be
constraint violations. The implementation is required to issue a
diagnostic message if your code contains any such violations. On any
decent implementation, the diagnostic message will provide enough
information to help you identify and correct the relevant piece of code.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | G G <gdotone@gmail.com> |
|---|---|
| Date | 2015-11-05 17:13 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <9f00c5f5-19aa-47e8-82b7-21df90e26b13@googlegroups.com> |
| In reply to | #75029 |
On Thursday, November 5, 2015 at 6:08:48 PM UTC-5, James Kuyper wrote:
Something that really helpful, really, really helpful.
I saw the first change of what s2 pointed to and it was not the expected
behavior I thought should so i stop there.
But, thanks, you really clear up a big misconception I had about declaring
const char *s2.
const char ctest[] = "ctest";
strcpy(ctest+1, test);
ok, yes.
I've got some rereading to do, with a bunch of experimentation too.
James, THANKS!
The following program is from Deitel and Deitel.
1 // Fig. 7.11: fig07_11.c
2 // Printing a string one character at a time using
3 // a non-constant pointer to constant data.
4
5 #include <stdio.h>
6
7 void printCharacters( const char *sPtr );
8
9 int main( void )
10 {
11 // initialize char array
12 char string[] = "print characters of a string";
13
14 puts( "The string is:" );
15 printCharacters( string );
16 puts( "" );
17 } //endmain
18
19 // sPtr cannot modify the character to which it points,
20 // i.e., sPtr is a "read-only" pointer
21 void printCharacters( const char *sPtr )
22 {
23 // loop through entire string
24 for ( ; *sPtr != '\0'; ++sPtr ) { // no initialization
25 printf( "%c", *sPtr );
26 } // end function printCharacters
Man, this was confusing section: ok here the author say this
about what is being demoed.
A non-constant pointer to constant data can be modified to point to any data item of the appropriate type, but the data to which it points cannot be modified. Such a pointer might be used to receive an array argument to a function that will process each element without modifying the data. For example, function printCharacters (Fig. 7.11) declares param- eter sPtr to be of type const char * (line 21). The declaration is read from right to left as "sPtr is a pointer to a character constant." The function uses a for statement to output each character in the string until the null character is encountered.
I just misunderstood. Here's the thing that threw me I guess
char string[] = "print characters of a string"
This is a const? no right? string[] can be changed, right?
I'll grab another book in a bit. my mind was blown.
thanks again James.
g.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-05 13:08 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1g5ql$ssc$1@dont-email.me> |
| In reply to | #74990 |
On 11/05/2015 12:26 PM, G G wrote:
...
> #import <string.h>
>
> /* XXX This routine should be optimized. */
>
> /* ANSI sez:
> * The `strcpy' function copies the string pointed to by `s2' (including
> * the terminating null character) into the array pointed to by `s1'.
> * If copying takes place between objects that overlap, the behavior
> * is undefined.
> * The `strcpy' function returns the value of `s1'. [4.11.2.3]
> */
> char *
> strcpy(char *s1, const char *s2)
> {
> char *s = s1;
> while ((*s++ = *s2++) != 0)
> ;
> return (s1);
> }
>
> What difference does overlapping make?
char array[] = "Hello world!";
123456789012
Think very carefully about what you expect to occur if you call
strcpy(array+4, array, 8). Then actually perform the copy, and compare
with your expectations. If they don't match, think it over carefully
again, and if you're still confused, feel free to ask questions.
Note: there are ways to implement strcpy() for some platforms that are
significantly faster than the code given above; if those methods are
used, strcpy(array+4, array, 8) could produce different results from
what you would get with this version. Because the behavior is undefined,
those implementations can be fully conforming. If the standard mandated
the results that you would get with this implementation of strcpy(),
those faster methods would not be allowed.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-05 10:33 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <2eda4987-5fff-4ee3-be33-456637038afe@googlegroups.com> |
| In reply to | #74998 |
On Thursday, November 5, 2015 at 12:08:35 PM UTC-6, James Kuyper wrote:
> Think very carefully about what you expect to occur if you call
> strcpy(array+4, array, 8)....
>
> Note: there are ways to implement strcpy() for some platforms that are
> significantly faster than the code given above; if those methods are
> used, strcpy(array+4, array, 8) could produce different results from
> what you would get with this version. Because the behavior is undefined,
> those implementations can be fully conforming. If the standard mandated
> the results that you would get with this implementation of strcpy(),
> those faster methods would not be allowed.
In the indicated case, the traditional implementation will overwrite an unbounded area of memory until something stops it, but it's generally not
possible to predict anything useful about the state of the system at that
point, so the fact that some other implementation didn't trash the system
could not generally be regarded as "undesirable".
A more interesting scenario would be one where the destination pointer is
below the source. Some platforms can perform "search-for-zero" followed
by "copy n bytes" faster than they can perform "copy while searching for
zero", and it would not be unreasonable for such an implementation to
use code equivalent to something like [may not be quite perfect]
char *strcpy(char *dest, char *src)
{
size_t n = -1; // Max unsigned value
while(n && *src) n--, src++; // Hardware instruction
n = -n; // Number of bytes needing to be copied
dest += n;
src++;
while(n--) *--dest = *--src; // Hardware instruction
return src;
}
Note that unlike the traditional strcpy function, this one doesn't need to
waste a temporary variable to return the original string pointer; note also
that some hardware instructions might use post-decrement rather than pre-
decrement, but such instructions would usually run on platforms that won't
mind if a pointer is post-decremented past the start of an object and then
incremented.
Compare the behavior of this function with the traditional one in the case
of e.g.
char dat[] = "--123456789";
strcpy(dat, dat+2);
The original would yield "123456789" followed by a NUL, a '9' and the
original NUL byte. What would the version shown above do?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-05 21:44 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1h41k$7ii$1@dont-email.me> |
| In reply to | #74998 |
On 11/05/2015 01:08 PM, James Kuyper wrote:
> On 11/05/2015 12:26 PM, G G wrote:
> ...
>> #import <string.h>
>>
>> /* XXX This routine should be optimized. */
>>
>> /* ANSI sez:
>> * The `strcpy' function copies the string pointed to by `s2' (including
>> * the terminating null character) into the array pointed to by `s1'.
>> * If copying takes place between objects that overlap, the behavior
>> * is undefined.
>> * The `strcpy' function returns the value of `s1'. [4.11.2.3]
>> */
>> char *
>> strcpy(char *s1, const char *s2)
>> {
>> char *s = s1;
>> while ((*s++ = *s2++) != 0)
>> ;
>> return (s1);
>> }
>>
>> What difference does overlapping make?
>
> char array[] = "Hello world!";
> 123456789012
>
> Think very carefully about what you expect to occur if you call
> strcpy(array+4, array, 8).
Sorry - I was thinking of memcpy() rather than strcpy(). The '8'
shouldn't be there. Without that '8', the implementation of strcpy()
given above will keep running past the end of array, which would not
have been the case with the memcpy() call I was thinking of.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-05 10:38 +0100 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1f7v9$7vd$1@dont-email.me> |
| In reply to | #74917 |
On 05/11/15 04:24, Tim Rentsch wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >> On 04/11/15 23:16, Malcolm McLean wrote: >>> On Wednesday, November 4, 2015 at 7:49:27 PM UTC, G G wrote: >>> >>>> Could you please point me to perhaps a website that has >>>> a list of the unsafe functions in the C libraries. Yes, my books >>>> are rather old, and they are showing their age here. :-) Thanks. >>>> >>>> Also, any up to date, books would also be greatly appreciated. >>>> I mean titles of course. Unless... :-) >>>> >>>> Thanks everyone. >>> >>> These are the ones Microsoft considers insecure >>> >>> https://msdn.microsoft.com/en-us/library/bb288454.aspx >> >> Let's just take strcpy, shall we? >> >> Microsoft's "safe" replacement is strcpy_s, which takes a length >> argument. If strSource is (a pointer to the first character of an >> array that is) longer than that argument, the function fails, setting >> strDestination to "". >> >> So how do you fix that? Well, you fix it by making sure that >> strDestination is long enough to fit the whole of strSource into it. >> >> And since you have to do that anyway, you might as well use strcpy >> afterwards, since you now know it's safe to do so. >> >> Microsoft didn't think it through. > > A strong claim considering the origins of strcpy_s() and that of > Annex K generally. I daresay the people responsible for defining > those interfaces have more security chops than almost anyone > posting in comp.lang.c. Do you have any reason to offer for > why someone should take your judgment over theirs? > The origins of strcpy_s are Microsoft - the version in Annex K is based on the Microsoft implementation (with some minor details, such as the MS version being explicit about the non-zero return codes). So if Richard is correct that the "inventors" of strcpy_s didn't think things through, then that would be Microsoft. If you need your call to strcpy_s to succeed, then Richard is right - you must first do something (such as a strlen() or strnlen_s() on strSource and an appropriate malloc) to ensure that strDestination is big enough, and then a straight strcpy (or strncpy), or memcpy. If you accept the possibility of failure, however, then strcpy_s has advantages - you can use its return code (which is more helpful than that of strcpy) to see if the copy has succeeded or not, and take other action as needed. So strcpy_s is not useless, as far as I can see. But like all other string functions before it (including the much derided strncpy), it is safe if and only if it is used correctly - people who think "strcpy_s" is "safe" and use it without checking the return value will get in trouble just like those who used strcpy carelessly.
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2015-11-05 21:01 +0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1fjrr$ikl$1@dont-email.me> |
| In reply to | #74937 |
David Brown wrote: > So strcpy_s is not useless, as far as I can see. But like all other > string functions before it (including the much derided strncpy), it is > safe if and only if it is used correctly - people who think "strcpy_s" > is "safe" and use it without checking the return value will get in > trouble just like those who used strcpy carelessly. If people start to "rely" on the assumed safety of such functions, you get the same effects as with ABS in cars. When people feel more safe they start to act more carelessly. In the end you have the same number of accidents as before. Security and safety of programs starts much earlier than at the place where the actual "accident" like buffer overflow happens. If you are at the point, where such bounds checking would prevent an overwrite it is much too late. In many cases you then do not have any sensefull way to react than to kill the program or at least a major part of the current transaction. I myself have more to with safety critical systems (avionics) than security. There you learn to program in a way to prevent such problems much earlier. For an aircraft at 30,000ft altitude there is no way of stopping the engine controller because of an index out of bounds check. You have to prevent such things from happening beforehand. -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-05 09:06 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1fnkh$2jp$1@dont-email.me> |
| In reply to | #74957 |
On 11/05/2015 08:01 AM, Reinhardt Behm wrote: ... > If people start to "rely" on the assumed safety of such functions, you get > the same effects as with ABS in cars. When people feel more safe they start > to act more carelessly. ... Have you ever actually used ABS? It's a frightening experience to those not experienced with it. They usually misinterpret the vibration as indicating that something's broken. The last thing it does is incur a feeling of increased safety. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-11-05 06:11 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <0d99bbd3-dd76-43a2-ae0f-ef7b38a13174@googlegroups.com> |
| In reply to | #74969 |
On Thursday, November 5, 2015 at 9:06:28 AM UTC-5, James Kuyper wrote: > On 11/05/2015 08:01 AM, Reinhardt Behm wrote: > ... > > If people start to "rely" on the assumed safety of such functions, you get > > the same effects as with ABS in cars. When people feel more safe they start > > to act more carelessly. ... > > Have you ever actually used ABS? It's a frightening experience to those > not experienced with it. They usually misinterpret the vibration as > indicating that something's broken. The last thing it does is incur a > feeling of increased safety. First time ABS ever engaged on a car I was driving I totally freaked out. Not only did it vibrate oddly through the foot pedal, but also through the steering wheel. It was an earthquake-like experience. Momentary shock and confusion not knowing what's happening. Second time wasn't so bad though. :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-05 14:19 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1fodj$61r$1@dont-email.me> |
| In reply to | #74969 |
On 05/11/15 14:06, James Kuyper wrote: > On 11/05/2015 08:01 AM, Reinhardt Behm wrote: > ... >> If people start to "rely" on the assumed safety of such functions, you get >> the same effects as with ABS in cars. When people feel more safe they start >> to act more carelessly. ... > > Have you ever actually used ABS? Yes. > It's a frightening experience to those not experienced with it. Agreed (for a few seconds, after which I figured out what had happened and I was fine with it). > They usually misinterpret the vibration as > indicating that something's broken. The last thing it does is incur a > feeling of increased safety. Rather, one gets the feeling of having just had a narrow escape. Nevertheless, I see his point. Recently on YouTube there were a spate of advertisements for safety features in cars, one of which was automatic braking (at low speeds) when the car judged that it was approaching an obstacle too quickly. I can imagine people getting very blase' about that after a while, possibly to the point of trusting to it even in cars where it isn't fitted (which could easily turn out to be their last mistake ever). I am also reminded of the urban legend of the RV driver who thought that cruise control was an "autopilot" - with unfortunate consequences. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-05 09:20 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <lnk2pw5pne.fsf@kst-u.example.com> |
| In reply to | #74969 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 11/05/2015 08:01 AM, Reinhardt Behm wrote:
> ...
>> If people start to "rely" on the assumed safety of such functions, you get
>> the same effects as with ABS in cars. When people feel more safe they start
>> to act more carelessly. ...
>
> Have you ever actually used ABS?
No (or at least I've never had it engage).
> It's a frightening experience to those
> not experienced with it. They usually misinterpret the vibration as
> indicating that something's broken. The last thing it does is incur a
> feeling of increased safety.
I think the point is that if you know (or incorrectly believe)
the car you're driving has ABS, you might drive more recklessly on
the assumption that the ABS will save you if you get into trouble.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-05 12:56 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1g54f$pog$1@dont-email.me> |
| In reply to | #74988 |
On 11/05/2015 12:20 PM, Keith Thompson wrote: > James Kuyper <jameskuyper@verizon.net> writes: >> On 11/05/2015 08:01 AM, Reinhardt Behm wrote: >> ... >>> If people start to "rely" on the assumed safety of such functions, you get >>> the same effects as with ABS in cars. When people feel more safe they start >>> to act more carelessly. ... >> >> Have you ever actually used ABS? > > No (or at least I've never had it engage). > >> It's a frightening experience to those >> not experienced with it. They usually misinterpret the vibration as I should have said that it "It can be a frightening ..."; I was adequately warned before the first time I bought an car with ABS, and I deliberately tested it in a safe location in order to familiarize myself with the vibration. >> indicating that something's broken. The last thing it does is incur a >> feeling of increased safety. > > I think the point is that if you know (or incorrectly believe) > the car you're driving has ABS, you might drive more recklessly on > the assumption that the ABS will save you if you get into trouble. That's not necessarily a bad thing, unless overdone. There's two benefits to be achieved when implementing a new safety measure. The first one is simple, obvious, and the one most people pay attention to: it makes it safer to continue doing things you're already doing. This unambiguously involves a reduction in the total number of accidents. However, there's also things that you aren't currently doing, because the benefits of doing them are too small to justify the associated risks. When a new safety measure reduces the risks, some of those things become worth doing - there's a risk of getting into an accident, but it's extremely small, and there's some corresponding benefit that is sufficiently valuable to justify taking that risk. I'm not talking about incorrectly evaluated risks - I'm talking about an evaluation that correctly concludes that the benefits are high enough. For instance, how high a risk to your life would you be willing to take, in order to get a Pizza for your party? You say that there's no way that any risk is justified by Pizza? You prove that you don't really mean that whenever you actually drive to the Pizza parlor to pick one up - because there's no such thing as a risk-free drive; but there is such a thing as a drive where you correctly judge that the risk of dying from an accident is so small that getting a Pizza justifies taking that risk. Maybe Pizza is something that you would never drive somewhere for - but the same principle applies to anything you're willing to use your car for (or any other method of transportation - there's no such thing as risk-free transportation - for that matter, there's no such thing as risk-free standing-still). Therefore, one of the benefits of any safety measure is that it allows people to take risks to gain benefits that would not have been worth the risk, before the safety measure was available. People will drive in slightly worse weather conditions, or on roads in slightly worse condition, and some of that driving will produce additional accidents - but it's entirely possible that they will acquire benefits from doing so that justify the additional accidents. Whether the number of additional accidents caused by this effect is larger or smaller than the number avoided by the main effect of the safety measure is something that has no general answer - it depends upon a wide variety of details. But in general, I wouldn't expect the total number of accidents to rise due to the introduction of a safety measure, not even after taking this effect into consideration. Richard described cases where people took risks because of mistaken understanding about the safety measure - thinking that it was installed when it wasn't, or that it would protect them in ways that it can't. Incorrectly assessed risks are an entirely different issue from the risks I'm discussing here. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-06 11:32 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <563c8e40.10768531@news.xs4all.nl> |
| In reply to | #74995 |
James Kuyper <jameskuyper@verizon.net> wrote: > For instance, how high a risk to your life would you be willing to take, > in order to get a Pizza for your party? You say that there's no way that > any risk is justified by Pizza? You prove that you don't really mean > that whenever you actually drive to the Pizza parlor to pick one up - > because there's no such thing as a risk-free drive; but there is such a > thing as a drive where you correctly judge that the risk of dying from > an accident is so small that getting a Pizza justifies taking that risk. No, what you prove is that the risk of getting killed on any normal journey is lower than the risk of being an absolute recluse. Which is true. It doesn't prove anything about the risk you are _willing_ to take - what it proves is that you, correctly, judge that the risk of getting pizza is negligible comparable to the risk of not being willing to go outside your house. You might well prefer not even to take the smaller risk, that of being willing to interact with the risky world; but you are even less willing to take the greater one, that of turning yourself into a hikikomori. That's the difference between ABS and strcpy_s(): we _all_ die, eventually, and the choice is merely that between a small chance of dying on the road or a large chance of hanging ourself in the basement, but rest assured: at least strcpy() can be used safely. Richard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-05 20:26 +0100 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1gadm$edo$1@dont-email.me> |
| In reply to | #74957 |
On 05/11/15 14:01, Reinhardt Behm wrote: > David Brown wrote: > >> So strcpy_s is not useless, as far as I can see. But like all other >> string functions before it (including the much derided strncpy), it is >> safe if and only if it is used correctly - people who think "strcpy_s" >> is "safe" and use it without checking the return value will get in >> trouble just like those who used strcpy carelessly. > > If people start to "rely" on the assumed safety of such functions, you get > the same effects as with ABS in cars. When people feel more safe they start > to act more carelessly. In the end you have the same number of accidents as > before. That is a worthwhile point. (For another car analogy, it's amazing the number of people that think they don't need seatbelts because their car has airbags. You /really/ don't want to feel that airbag go off when you don't have a seatbelt on.) No amount of "safety equipment" replaces knowledge and sense. > > Security and safety of programs starts much earlier than at the place where > the actual "accident" like buffer overflow happens. If you are at the point, > where such bounds checking would prevent an overwrite it is much too late. > In many cases you then do not have any sensefull way to react than to kill > the program or at least a major part of the current transaction. > > I myself have more to with safety critical systems (avionics) than security. > There you learn to program in a way to prevent such problems much earlier. > For an aircraft at 30,000ft altitude there is no way of stopping the engine > controller because of an index out of bounds check. You have to prevent such > things from happening beforehand. >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-05 07:50 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <kfn8u6c5tue.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #74937 |
David Brown <david.brown@hesbynett.no> writes: > On 05/11/15 04:24, Tim Rentsch wrote: >> Richard Heathfield <rjh@cpax.org.uk> writes: >> >>> On 04/11/15 23:16, Malcolm McLean wrote: >>>> On Wednesday, November 4, 2015 at 7:49:27 PM UTC, G G wrote: >>>> >>>>> Could you please point me to perhaps a website that has >>>>> a list of the unsafe functions in the C libraries. Yes, my books >>>>> are rather old, and they are showing their age here. :-) Thanks. >>>>> >>>>> Also, any up to date, books would also be greatly appreciated. >>>>> I mean titles of course. Unless... :-) >>>>> >>>>> Thanks everyone. >>>> >>>> These are the ones Microsoft considers insecure >>>> >>>> https://msdn.microsoft.com/en-us/library/bb288454.aspx >>> >>> Let's just take strcpy, shall we? >>> >>> Microsoft's "safe" replacement is strcpy_s, which takes a length >>> argument. If strSource is (a pointer to the first character of an >>> array that is) longer than that argument, the function fails, setting >>> strDestination to "". >>> >>> So how do you fix that? Well, you fix it by making sure that >>> strDestination is long enough to fit the whole of strSource into it. >>> >>> And since you have to do that anyway, you might as well use strcpy >>> afterwards, since you now know it's safe to do so. >>> >>> Microsoft didn't think it through. >> >> A strong claim considering the origins of strcpy_s() and that of >> Annex K generally. I daresay the people responsible for defining >> those interfaces have more security chops than almost anyone >> posting in comp.lang.c. Do you have any reason to offer for >> why someone should take your judgment over theirs? > > The origins of strcpy_s are Microsoft - the version in Annex K is > based on the Microsoft implementation (with some minor details, > such as the MS version being explicit about the non-zero return > codes). [snip] That doesn't match my understanding of the history. Can you provide some independent evidence that people from Microsoft, and only people from Microsoft, are responsible for defining the strcpy_s() interface? I don't doubt that some people from Microsoft contributed to the discussions, but they certainly weren't the only people in the room while these interfaces were being worked out, strcpy_s() included.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-11-05 11:46 -0600 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1g4h4$n9l$1@dont-email.me> |
| In reply to | #74977 |
On 11/5/2015 9:50 AM, Tim Rentsch wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 05/11/15 04:24, Tim Rentsch wrote: >>> Richard Heathfield <rjh@cpax.org.uk> writes: >>> >>>> On 04/11/15 23:16, Malcolm McLean wrote: >>>>> On Wednesday, November 4, 2015 at 7:49:27 PM UTC, G G wrote: >>>>> >>>>>> Could you please point me to perhaps a website that has >>>>>> a list of the unsafe functions in the C libraries. Yes, my books >>>>>> are rather old, and they are showing their age here. :-) Thanks. >>>>>> >>>>>> Also, any up to date, books would also be greatly appreciated. >>>>>> I mean titles of course. Unless... :-) >>>>>> >>>>>> Thanks everyone. >>>>> >>>>> These are the ones Microsoft considers insecure >>>>> >>>>> https://msdn.microsoft.com/en-us/library/bb288454.aspx >>>> >>>> Let's just take strcpy, shall we? >>>> >>>> Microsoft's "safe" replacement is strcpy_s, which takes a length >>>> argument. If strSource is (a pointer to the first character of an >>>> array that is) longer than that argument, the function fails, setting >>>> strDestination to "". >>>> >>>> So how do you fix that? Well, you fix it by making sure that >>>> strDestination is long enough to fit the whole of strSource into it. >>>> >>>> And since you have to do that anyway, you might as well use strcpy >>>> afterwards, since you now know it's safe to do so. >>>> >>>> Microsoft didn't think it through. >>> >>> A strong claim considering the origins of strcpy_s() and that of >>> Annex K generally. I daresay the people responsible for defining >>> those interfaces have more security chops than almost anyone >>> posting in comp.lang.c. Do you have any reason to offer for >>> why someone should take your judgment over theirs? >> >> The origins of strcpy_s are Microsoft - the version in Annex K is >> based on the Microsoft implementation (with some minor details, >> such as the MS version being explicit about the non-zero return >> codes). [snip] > > That doesn't match my understanding of the history. Can you > provide some independent evidence that people from Microsoft, and > only people from Microsoft, are responsible for defining the > strcpy_s() interface? I don't doubt that some people from > Microsoft contributed to the discussions, but they certainly > weren't the only people in the room while these interfaces were > being worked out, strcpy_s() included. > The first time I heard of them was with Visual Studio 2005. (See https://msdn.microsoft.com/en-us/library/8ef0s5kh(v=vs.80).aspx ). Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-06 11:33 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <kfnvb9e53eb.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #74994 |
Martin Shobe <martin.shobe@yahoo.com> writes: > On 11/5/2015 9:50 AM, Tim Rentsch wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 05/11/15 04:24, Tim Rentsch wrote: >>>> Richard Heathfield <rjh@cpax.org.uk> writes: >>>> >>>>> On 04/11/15 23:16, Malcolm McLean wrote: >>>>>> On Wednesday, November 4, 2015 at 7:49:27 PM UTC, G G wrote: >>>>>> >>>>>>> Could you please point me to perhaps a website that has >>>>>>> a list of the unsafe functions in the C libraries. Yes, my books >>>>>>> are rather old, and they are showing their age here. :-) Thanks. >>>>>>> >>>>>>> Also, any up to date, books would also be greatly appreciated. >>>>>>> I mean titles of course. Unless... :-) >>>>>>> >>>>>>> Thanks everyone. >>>>>> >>>>>> These are the ones Microsoft considers insecure >>>>>> >>>>>> https://msdn.microsoft.com/en-us/library/bb288454.aspx >>>>> >>>>> Let's just take strcpy, shall we? >>>>> >>>>> Microsoft's "safe" replacement is strcpy_s, which takes a length >>>>> argument. If strSource is (a pointer to the first character of an >>>>> array that is) longer than that argument, the function fails, setting >>>>> strDestination to "". >>>>> >>>>> So how do you fix that? Well, you fix it by making sure that >>>>> strDestination is long enough to fit the whole of strSource into it. >>>>> >>>>> And since you have to do that anyway, you might as well use strcpy >>>>> afterwards, since you now know it's safe to do so. >>>>> >>>>> Microsoft didn't think it through. >>>> >>>> A strong claim considering the origins of strcpy_s() and that of >>>> Annex K generally. I daresay the people responsible for defining >>>> those interfaces have more security chops than almost anyone >>>> posting in comp.lang.c. Do you have any reason to offer for >>>> why someone should take your judgment over theirs? >>> >>> The origins of strcpy_s are Microsoft - the version in Annex K is >>> based on the Microsoft implementation (with some minor details, >>> such as the MS version being explicit about the non-zero return >>> codes). [snip] >> >> That doesn't match my understanding of the history. Can you >> provide some independent evidence that people from Microsoft, and >> only people from Microsoft, are responsible for defining the >> strcpy_s() interface? I don't doubt that some people from >> Microsoft contributed to the discussions, but they certainly >> weren't the only people in the room while these interfaces were >> being worked out, strcpy_s() included. > > The first time I heard of them was with Visual Studio 2005. (See > https://msdn.microsoft.com/en-us/library/8ef0s5kh(v=vs.80).aspx ). That is a useful data point. Not really the evidence requested, but still good to know.
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-11-07 00:32 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <MPG.30a7570ba83ab5f385@news.eternal-september.org> |
| In reply to | #75164 |
Tim Rentsch wrote: > David Brown writes: >> The origins of strcpy_s are Microsoft - the version in Annex K is >> based on the Microsoft implementation (with some minor details, >> such as the MS version being explicit about the non-zero return >> codes). [snip] > > That doesn't match my understanding of the history. Can you > provide some independent evidence that people from Microsoft, and > only people from Microsoft, are responsible for defining the > strcpy_s() interface? I don't doubt that some people from > Microsoft contributed to the discussions, but they certainly > weren't the only people in the room while these interfaces were > being worked out, strcpy_s() included. My understanding is that they were completely designed, specified, implemented, and promulgated by Microsoft, and that they were adopted into the standard later with very little revision. Unfortunately, I can't provide any evidence of that, since I don't recall where I read it (but my first guess would be here). Do you have any evidence that it happened differently? Philip
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web