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 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-11-04 13:11 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1dhkt$pts$1@dont-email.me> |
| In reply to | #74845 |
On 11/4/2015 9:59 AM, G G wrote:
> On Wednesday, November 4, 2015 at 9:37:28 AM UTC-5, Eric Sosman wrote:
>> On 11/4/2015 9:22 AM, G G wrote:
>>> (*structp).component structp->component
>
>> We can tell by the syntax (in either form) that `structp' is a
>> pointer to some kind of struct or union. The struct or union type
>> has an element named `component', but from what you have shown there
>> is no way to discern the type of that element.
>
> let me give the example from the book. I understand it, but how would you say it.
>
> #define STRSIZ 10
> typedef struct {
> char name[STRSIZ];
> double diameter;
> int moons;
> double orbit_time,
> rotation_time;
> } planet_t;
>
> typedef struct {
> double diameter;
> planet_t planets[9];
> char galaxy[STRSIZ];
> } solar_sys_t;
>
> int
> scan_planet(planet_t *plnp) /* output - address of planet_t structure
> to fill */
> {
> int result;
>
> result = scan("%s%lf%d%lf%lf", (*plnp).name,
> &(*plnp).diameter,
> &(*plnp).moons,
> &(*plnp).orbit_time,
> &(*plnp).rotation_time);
Aside: Assuming scan() is really scanf(), using the "%s"
specifier is unsafe for exactly the reason the gets() function
is unsafe. It will happily read and (try to) store as many
characters as are offered, whether or not there's enough room
in the destination array to hold them. Give it "Gallifrey" and
all will be well, but give it "Tralfamadore" and all bets are
off. If the book teaches you to use scanf() this way, get a
better book.
(You could make it safe again by using "%9s", but even that
would come to grief over "Altair IV". scanf() only seems simple;
it can actually be quite tricky to use.)
> if (result == 5)
> result = 1;
> else if (result != EOF)
> result = 0;
>
> return (result);
> }
>
> or it could be written as:
>
> result = scanf("%s%lf%d%lf%lf", plnp->name,
> &plnp->diameter,
> &plnp->moons,
> &plnp->orbit_time,
> &plnp->rotation_time);
>
> I understand that they are equivalent.
>
> but how do you express in words: (*plnp).name and plnp->name?
> like: int *ptr, ptr is a pointer to a type int.
I'm not sure what confuses you, in part because your two
examples don't seem to resemble each other: One is a reference
to a struct or union element, while the other is a declaration.
But I'll make an attempt anyhow:
"(*plnp).name" is a reference to the "name" member of
the struct or union "plnp" points at.
"plnp->name" is a reference to the "name" member of the
struct or union "plnp" points at.
The only differences are that the second form uses two fewer keystrokes
and is *much* more widely used, hence (perhaps) more readable because
readers are more accustomed to it.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | G G <gdotone@gmail.com> |
|---|---|
| Date | 2015-11-04 11:49 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <a3bc819a-b78d-4847-b096-050e637aaccf@googlegroups.com> |
| In reply to | #74858 |
On Wednesday, November 4, 2015 at 1:11:58 PM UTC-5, Eric Sosman wrote: Aside: Assuming scan() is really scanf(), using the "%s" > specifier is unsafe for exactly the reason the gets() function > is unsafe. It will happily read and (try to) store as many > characters as are offered, whether or not there's enough room > in the destination array to hold them. Give it "Gallifrey" and > all will be well, but give it "Tralfamadore" and all bets are > off. If the book teaches you to use scanf() this way, get a > better book. > 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.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-04 20:00 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1do1l$lhn$1@dont-email.me> |
| In reply to | #74866 |
On 04/11/15 19:49, G G wrote: <snip> > 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. No need, really. The only standard C function that cannot be used safely is - or rather, was - gets(). This function was deprecated in C99, and removed in C11. The scanf function is easy to get wrong (and easy to use unsafely), but it /can/ be used safely. -- 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 | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-11-04 15:36 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1dq4u$ufl$1@dont-email.me> |
| In reply to | #74866 |
On 11/4/2015 2:49 PM, G G wrote:
> On Wednesday, November 4, 2015 at 1:11:58 PM UTC-5, Eric Sosman wrote:
>
>
> Aside: Assuming scan() is really scanf(), using the "%s"
>> specifier is unsafe for exactly the reason the gets() function
>> is unsafe. It will happily read and (try to) store as many
>> characters as are offered, whether or not there's enough room
>> in the destination array to hold them. Give it "Gallifrey" and
>> all will be well, but give it "Tralfamadore" and all bets are
>> off. If the book teaches you to use scanf() this way, get a
>> better book.
>
> 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.
That's a hard one. Quite a few of the Standard library functions,
maybe even "most," are unsafe if used improperly. For example, you
can get into trouble with strcpy() if the destination is too small to
hold the source, or with longjmp() if its jmp_buf was initialized in
a function that has already returned, or even with qsort() if the
comparison function is inconsistent.
These functions, however, can be used safely with sufficient
care: Everything about their use is under the programmer's control,
and if she's diligent about ensuring that the circumstances are as
they should be, she'll get no unwelcome surprises. C is perhaps a
bit unusual in the amount of diligence required (and sometimes in
the amount lacking!), but at least in principle the functions can
be used safely. (Which is not to say that they are "always safe;"
after all, a perfectly well-executed remove() might do exactly as
it was told and delete an important file!)
Functions that take input from external sources, though, are
exposed to something that is not under the programmer's control:
to wit, the input. If that input is not as the programmer expected,
trouble can ensue. The thing about gets() is that the programmer has
no way to know how many characters the function will attempt to store;
that is governed entirely by the input stream itself. Yet it's the
programmer's job to provide an array of sufficient size, which forces
her to answer the old question: "How long is a piece of string?"
There's no satisfactory answer, and *that* is why gets() is unsafe.
(It's even been removed from the latest C Standard, despite the
usual respect for backwards compatibility.)
The scanf() family is not as bad as gets() because the programmer
can set an upper bound on how many characters it will swallow and
try to store. However, they do not force the programmer to specify
such a bound, and if she doesn't she's back in gets() Hell. There
are two conversion specifiers that accept and store a potentially
unlimited number of characters: "%s" and "%[". To avoid reopening
the gets() can of worms, the programmer must instead write "%40s" or
"%99[" (and be sure to leave extra space for the final '\0').
> Also, any up to date, books would also be greatly appreciated.
> I mean titles of course. Unless... :-)
I'm afraid I can't help here. I learned C forty years ago, and
the books I used back then must be even more outdated than yours!
Keeping an eye on this group can be informative, if you're good at
filtering out nonsense. (It can be hard to distinguish nonsense from
consensus here, since almost everything will be contradicted at some
point.) Another helpful resource is the C Frequently Asked Questions
(FAQ) page at <http://www.c-faq.com/>, sometimes rather telegraphic
and definitely showing its age, but a good heads-up about a number of
potential stumbling blocks.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-04 15:16 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <f8311728-8666-4ef5-b262-09cb25b1addb@googlegroups.com> |
| In reply to | #74866 |
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
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-11-04 15:28 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <765e5ec2-1712-492d-9a3b-9e169890a389@googlegroups.com> |
| In reply to | #74886 |
On Wednesday, November 4, 2015 at 6:16:31 PM UTC-5, Malcolm McLean wrote: > These are the ones Microsoft considers insecure > https://msdn.microsoft.com/en-us/library/bb288454.aspx "The classic C runtime, "n" functions (such as strncpy and strncat) are banned because they are so hard to call correctly." This is along the same reason why Oracle deprecated stopping threads in Java. "People could do it badly, so we're going to remove the ability for them to do it." In Oracle's case by deprecating the feature. In Microsoft's case by banning the function (though it is still available, which is an effective deprecation only). Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-04 16:25 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <6eca206e-b38c-49ee-8488-3165d0f80d71@googlegroups.com> |
| In reply to | #74887 |
On Wednesday, November 4, 2015 at 5:29:10 PM UTC-6, Rick C. Hodgin wrote:
> On Wednesday, November 4, 2015 at 6:16:31 PM UTC-5, Malcolm McLean wrote:
> > These are the ones Microsoft considers insecure
> > https://msdn.microsoft.com/en-us/library/bb288454.aspx
>
> "The classic C runtime, "n" functions (such as strncpy and strncat)
> are banned because they are so hard to call correctly."
The "strncat" function is pretty much pointless, since the only situation
where it could sensibly by used would be in cases where one didn't know the
length of the source string but could somehow guarantee that a certain amount
of space would remain in its buffer. Variations of "strcpy" which could
accept a limit pointer for the destination buffer, and returned the location
just past the last character written, and either padded the result with null
or not depending upon which variation was invoked would have been nice, but
C doesn't provide those. If it did:
char myBuff[1024];
char * const buffEnd = myBuff + sizeof myBuff;
char *p = myBuff;
p= strapp(p, buffEnd, firstString);
p= strapp(p, buffEnd, secondString);
p= stnapp(p, buffEnd, thirdString, thirdStringMaxLength);
The "strncpy" method is perfectly fine if one knows how to use it, but is
perhaps poorly named since it's designed for working with a different kind
of data from the other "str"... methods. On the other hand, if there were
a function for zero-padding a string which fit the above pattern, that would
largely obviate the need for strncpy.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-05 00:47 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1e8q2$nrp$1@dont-email.me> |
| In reply to | #74886 |
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. -- 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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-04 19:24 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <kfn37wl6sd0.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #74905 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-11-05 16:34 +1300 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <da011rFj370U3@mid.individual.net> |
| In reply to | #74917 |
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? Do you disagree with Richard's argument above? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-05 09:39 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1f80m$82u$1@dont-email.me> |
| In reply to | #74918 |
On 05/11/15 03:34, Ian Collins wrote: > 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? > > Do you disagree with Richard's argument above? Whether one agrees or disagrees with me, Ian, the important thing is to think it through thoroughly for oneself. These so-called "safe" functions very often achieve their "safety" by refusing the fence, so to speak. Whilst it is indeed better to refuse the fence than to end up in the ditch, better still would be to clear the fence, land safely, and continue racing. I don't want a safe function that's safe because it throws away my data. If the answer doesn't have to be *right*, I can get the program to run in 0 seconds and be 100% safe. No, I don't want a "safe" (so-called) function. I want a safe *program* that's safe because it finds enough space for my data, legally of course, so that I get not only a safe result but also a correct one. The strcpy function can certainly be used as part of a safe program. The strcpy_s function can, too, of course, but it has no advantages to compensate for its disadvantages and make it a plausible alternative to strcpy. I am not particularly interested, by the way, in the "security chops" of someone who can come up with a routine as badly thought-out as strcpy_s, so the argument by supposed authority falls on deaf ears. -+-+-+-+-+-+- [I suppose I had better point out that I won't see, and thus won't be be replying to, any response of Tim Rentsch's such as the one Ian quotes above, since I killfiled him some weeks ago. And *then* I have to point out that I didn't do so for the usual reason (because he's obviously /not/ an idiot), but simply because I found that debating with him was time-consuming without being enjoyable - no doubt a failing on my part rather than his. Sorry, Tim, but there it is.] -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-05 13:45 +0100 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1fitv$eo9$1@dont-email.me> |
| In reply to | #74938 |
On 05/11/15 10:39, Richard Heathfield wrote: > I am not particularly interested, by the way, in the "security chops" of > someone who can come up with a routine as badly thought-out as strcpy_s, > so the argument by supposed authority falls on deaf ears. > How can you say that? Are you insinuating that Microsoft does not have a good reputation for security?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-05 13:30 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1flgl$nvj$2@dont-email.me> |
| In reply to | #74953 |
On 05/11/15 12:45, David Brown wrote: > On 05/11/15 10:39, Richard Heathfield wrote: > >> I am not particularly interested, by the way, in the "security chops" of >> someone who can come up with a routine as badly thought-out as strcpy_s, >> so the argument by supposed authority falls on deaf ears. >> > > How can you say that? Are you insinuating that Microsoft does not have > a good reputation for security? *You* might say that. I couldn't possibly comment. -- 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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-05 08:14 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <kfn4mh05spb.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #74918 |
Ian Collins <ian-news@hotmail.com> writes: > 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? > > Do you disagree with Richard's argument above? I don't think his argument is wrong as much as it is incomplete. First there are other circumstances that strcpy_s() protects against, besides exceeding the given length argument. Second, in the case that a length argument is exceeded, it may mean that the size of the destination is too small, or it may mean something else entirely, as for example an input string not being properly vetted, or a stray pointer being used as a source. So I think that part of his analysis falls a little bit short. More important though is the presumption that there is an "afterwards", that is, that any offending cases have been found, and so could be corrected. If you know about a bug then of course you can do something to fix it. The whole point of interfaces like strcpy_s() is to mitigate damage in the eventuality of running into a bug you did /not/ know about. His comments pretty much assume that such situations don't exist. I think there is plenty of evidence that they do, even for people who are careful to write safe and correct code.
[toc] | [prev] | [next] | [standalone]
| From | G G <gdotone@gmail.com> |
|---|---|
| Date | 2015-11-05 08:25 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <69d66e0c-4b66-4921-842d-e7754b5f3c68@googlegroups.com> |
| In reply to | #74978 |
Could someone please post the code for strcpy_s?
As most know I'm learning, and this seems to be
a function which many seem to be discussing.
I found this on freebsd.org while trying to find
source code for strcpy_s:
https://www.freebsd.org/doc/en/books/developers-handbook/secure-bufferov.html
The C programming language does not perform automatic
bounds checking on arrays or pointers as many other
languages do. In addition, the standard C library is
filled with a handful of very dangerous functions.
strcpy(char *dest, const char *src)
May overflow the dest buffer
strcat(char *dest, const char *src)
May overflow the dest buffer
getwd(char *buf) May overflow the buf buffer
gets(char *s) May overflow the s buffer
[vf]scanf(const char *format, ...) May overflow its arguments.
realpath(char *path, char resolved_path[])
May overflow the path buffer
[v]sprintf(char *str, const char *format, ...)
May overflow the str buffer.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-11-05 12:00 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1g1rl$cpj$1@dont-email.me> |
| In reply to | #74979 |
On 11/5/2015 11:25 AM, G G wrote:
> Could someone please post the code for strcpy_s?
> As most know I'm learning, and this seems to be
> a function which many seem to be discussing.
>
> I found this on freebsd.org while trying to find
> source code for strcpy_s:
>
> https://www.freebsd.org/doc/en/books/developers-handbook/secure-bufferov.html
>
> The C programming language does not perform automatic
> bounds checking on arrays or pointers as many other
> languages do. In addition, the standard C library is
> filled with a handful of very dangerous functions.
Nearly any tool can be dangerous if misused. It's not the
hammer's fault if you swing it at your head.
> strcpy(char *dest, const char *src)
> May overflow the dest buffer
... if misused.
> strcat(char *dest, const char *src)
> May overflow the dest buffer
... if misused.
> getwd(char *buf) May overflow the buf buffer
Not a Standard C function.
> gets(char *s) May overflow the s buffer
No longer a Standard C function.
> [vf]scanf(const char *format, ...) May overflow its arguments.
Not quite sure what they're talking about here: Using the
"%s" and "%[" without a field width (the gets() problem), or
providing too few arguments to match the format. Either way,
I'd say it's a case of danger arising from misuse.
> realpath(char *path, char resolved_path[])
> May overflow the path buffer
Not a Standard C function.
> [v]sprintf(char *str, const char *format, ...)
> May overflow the str buffer.
... if misused.
Could C and its library functions have more safeguards? Sure.
Would they improve things? It's debatable (proof: This thread is
just such a debate). Will strewing "safety dust" like a high-tech
Peter Pan let us all fly to Never-Bug-Land? Bosh.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | G G <gdotone@gmail.com> |
|---|---|
| Date | 2015-11-05 09:09 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <1b92bfc6-6e68-4d2c-a10d-399139247783@googlegroups.com> |
| In reply to | #74982 |
On Thursday, November 5, 2015 at 12:00:54 PM UTC-5, Eric Sosman wrote: > Nearly any tool can be dangerous if misused. It's not the > hammer's fault if you swing it at your head. This truly deserves comment. Comment: Eric that was funny. Great sense of humor. Thanks for the smiles.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-11-05 11:02 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <451d6830-abbe-4922-bf7d-fe3ea811f655@googlegroups.com> |
| In reply to | #74986 |
On Thursday, November 5, 2015 at 12:09:38 PM UTC-5, G G wrote: > On Thursday, November 5, 2015 at 12:00:54 PM UTC-5, Eric Sosman wrote: > > > Nearly any tool can be dangerous if misused. It's not the > > hammer's fault if you swing it at your head. > > This truly deserves comment. > > Comment: Eric that was funny. Great sense of humor. Thanks for the smiles. Are you ready with that hammer? Good. I've got the nail right here. Okay, when I nod my head, you hit it. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-05 09:28 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <8fc22658-70f7-4607-942b-620fc9bd182e@googlegroups.com> |
| In reply to | #74982 |
On Thursday, November 5, 2015 at 11:00:54 AM UTC-6, Eric Sosman wrote: > > strcpy(char *dest, const char *src) > > May overflow the dest buffer > > ... if misused. A problem with something like strcpy is that it is not amenable to many forms of static analysis which are applicable to methods which specify size limits. > > strcat(char *dest, const char *src) > > May overflow the dest buffer > > ... if misused. Most all uses of strcat would be better written using strlen+memcpy, though a copy-and-locate-end function might be better yet. > > [v]sprintf(char *str, const char *format, ...) > > May overflow the str buffer. > > ... if misused. I wish the C Standard had, at some point along the line, defined a better means of invoking variadic functions. Even though the present method is simple, it generates bulkier code than could approaches designed for size; given that variadic methods are usually used when speed is not critical, a small variadic-argument-parsing library could have allowed methods to receive variadic arguments in type-safe fashion with less calling code than is necessary with the present approach [since most arguments will be variables of either static or automatic duration, or objects directly pointed to be pointers of such types, creating new automatic variables for those things which don't fit that pattern, and then passing a static constant list of types and either stack offsets (for automatic variables) or pointers (for static/global ones) would not only provide type safety, but would in most cases result in smaller code than having to use separate instructions to set up each argument.]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-05 12:50 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <ln37wk5fy6.fsf@kst-u.example.com> |
| In reply to | #74982 |
Eric Sosman <esosman@comcast-dot-net.invalid> writes:
> On 11/5/2015 11:25 AM, G G wrote:
[...]
>> [vf]scanf(const char *format, ...) May overflow its arguments.
>
> Not quite sure what they're talking about here: Using the
> "%s" and "%[" without a field width (the gets() problem), or
> providing too few arguments to match the format. Either way,
> I'd say it's a case of danger arising from misuse.
If you read a number (either integer or floating-point) and the input
has the expected form but represents a value outside the range of
the type, the behavior is undefined. This makes it impossible
to use any of the *scanf functions safely for numeric input.
I believe that's the case even for unsigned integers.
N1570 7.21.6.2p10: "If this object does not have an appropriate type,
or if the result of the conversion cannot be represented in the object,
the behavior is undefined.".
[...]
--
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]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web