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 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-13 03:43 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <kfn6116ruop.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #75225 |
Philip Lantz <prl@canterey.us> writes:
> 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?
I think we are talking about two different things. What I'm
talking about is the interface definitions given in Annex K.
I'm not talking about some possibly earlier set of definitions
that may have provided a starting point for what is in Annex K.
It may be that the work on strcpy_s(), etc, started at Microsoft
and was initially largely carried out by them, but I don't have
any way of talking about that since there isn't anything I can
point to that says what it is. Certainly if work on strcpy_s()
etc started at Microsoft then they brought other people into the
loop fairly early, as evidenced by this 2005 ISO document and
its accompanying rationale document -
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1146.pdf
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1147.pdf
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-07 20:03 +0100 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1lhp3$ru4$1@dont-email.me> |
| In reply to | #74977 |
On 05/11/15 16:50, 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: >>>> 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. > Sorry, I can't provide any solid evince (I assume that you have already looked at Wikipedia and dismissed that as "independent evidence"?). <https://en.wikipedia.org/wiki/C_string_handling#strcpy_.2F_strcat> All I have heard of strcpy_s was that it came from Microsoft, and was implemented in MSVC, long before C11 was standardised. But it would not surprise me unduly if it were influenced by others than MS - no one works on these sort of things entirely alone. (If I were cynical, I could note that MS is infamous for stealing ideas from others...)
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-10 16:42 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <56421e39.7037921@news.xs4all.nl> |
| In reply to | #75283 |
David Brown <david.brown@hesbynett.no> wrote: > All I have heard of strcpy_s was that it came from Microsoft, and was > implemented in MSVC, long before C11 was standardised. But it would not > surprise me unduly if it were influenced by others than MS - no one > works on these sort of things entirely alone. > > (If I were cynical, I could note that MS is infamous for stealing ideas > from others...) You're not cynical enough. They steal good ideas of others, and then mangle them badly. Ideas which are bad in the first place, those they're quite capable of coming up with on their own. Much like GNU. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-13 04:03 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <kfn1tburts4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #75283 |
David Brown <david.brown@hesbynett.no> writes: > On 05/11/15 16:50, 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: >>>> >>>>> 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. > > Sorry, I can't provide any solid evince (I assume that you have > already looked at Wikipedia and dismissed that as "independent > evidence"?). > > <https://en.wikipedia.org/wiki/C_string_handling#strcpy_.2F_strcat> > > All I have heard of strcpy_s was that it came from Microsoft, and was > implemented in MSVC, long before C11 was standardised. And that appears to be the case (although WG14 got involved much earlier, as mentioned in my reply to Philip Lantz). However that is still consistent with my earlier comments. > But it would not surprise me unduly if it were influenced by > others than MS - no one works on these sort of things entirely > alone. Right. I think there isn't much question that the interface definitions given in Annex K, which is what I've been talking about, included consultation with people outside of Microsoft. So I think what you're saying is still compatible with what I'm saying.
[toc] | [prev] | [next] | [standalone]
| From | G G <gdotone@gmail.com> |
|---|---|
| Date | 2015-11-04 19:42 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <ea075387-c4d5-449c-99ce-7853c36196c6@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 WoW! ok, Thanks Malcolm.
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2015-11-05 12:54 +0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1enad$p3s$1@dont-email.me> |
| In reply to | #74920 |
G G 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 > > WoW! These banned functions should be banned alone because of their disgusting names. -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-05 10:36 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1fbb9$jba$1@dont-email.me> |
| In reply to | #74925 |
On 05/11/2015 04:54, Reinhardt Behm wrote: > G G 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 >> >> WoW! > > These banned functions should be banned alone because of their disgusting > names. > I didn't realise there were so many of them. 34 variations on strcat() for example. The safe version looks simpler, but I suspect the "*" in the name represents all the 34 variations, so there are still loads of them, but now with longer names! Something wrong I think when a language library starts to grow in that manner. (And with the safe versions, there are now 68 variations; no wonder some libraries are so large.) (I don't think I've ever used anything other than plain strcat.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2015-11-05 20:46 +0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1fiv7$ddr$2@dont-email.me> |
| In reply to | #74945 |
Bartc wrote: > On 05/11/2015 04:54, Reinhardt Behm wrote: >> G G 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 >>> >>> WoW! >> >> These banned functions should be banned alone because of their disgusting >> names. >> > > I didn't realise there were so many of them. > > 34 variations on strcat() for example. The safe version looks simpler, > but I suspect the "*" in the name represents all the 34 variations, so > there are still loads of them, but now with longer names! > > Something wrong I think when a language library starts to grow in that > manner. (And with the safe versions, there are now 68 variations; no > wonder some libraries are so large.) > > (I don't think I've ever used anything other than plain strcat.) Inventing such names is the best method to stop people from using them. With so many ugly names, nobody can remember which one to use. -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-05 09:02 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <9b994fb4-067b-4603-b46e-b8620fd2e2be@googlegroups.com> |
| In reply to | #74945 |
On Thursday, November 5, 2015 at 4:36:40 AM UTC-6, Bart wrote: > I didn't realise there were so many of them. > > 34 variations on strcat() for example. The safe version looks simpler, > but I suspect the "*" in the name represents all the 34 variations, so > there are still loads of them, but now with longer names! Having a large number of things which are named in consistent fashion is a good thing, since it may allow programmers to indicate which aspects of the function are or are not important in a given context. Even if most implementations would end up mapping most of the names to a tiny number of different things, the choice of which names map to which things might vary from one implementation to the next. As a simple example, there are many cases where code will use memmove and a compiler wouldn't be able to tell anything about its arguments, but a programmer would know... 1. Which combinations of source and destination alignments are likely, which (if any) will never occur, and whether the data length will be a whole number of words or half-words. 2. Whether the programmer knows that bottom-up copying would be safe, or that top-down copying would be safe. 3. Whether the function is likely to be used for any significant number of "large" copy operations. If a programmer could specify that a memmove would be used to copy whole numbers of full words of data that will be half-word aligned 100% of the time, may be copied in bottom-up order, and very seldom be used on large moves, a compiler could sensibly generate in-line code which fits those requirements. A compiler for a platform which supports unaligned reads and writes might generate the same code to copy small multiples of 4 bytes of known-to-be aligned data as for eight bytes of arbitrarily-aligned data, but a compiler for a platform which doesn't support unaligned reads may very much appreciate the distinction. The number of names would get to be very large, but by my understanding LISP programmers never complain about the huge number of [IIRC] car, cdr, cadr, caddaddadddddaaaar, etc. functions. What's important is not that the number of names be small, but rather that the names fit a consistent pattern.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-06 11:07 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <563c88f5.9413421@news.xs4all.nl> |
| In reply to | #74886 |
Malcolm McLean <malcolm.mclean5@btinternet.com> 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. > These are the ones Microsoft considers insecure > > https://msdn.microsoft.com/en-us/library/bb288454.aspx Yeah, because Mickey$oft have a stellar record when it comes to buffer overflows! Predictably, most of that page is bollocks. Richard
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-06 11:26 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1i2le$u09$1@dont-email.me> |
| In reply to | #75066 |
On 06/11/15 11:07, Richard Bos wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> 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. > >> These are the ones Microsoft considers insecure >> >> https://msdn.microsoft.com/en-us/library/bb288454.aspx > > Yeah, because Mickey$oft have a stellar record when it comes to buffer > overflows! > > Predictably, most of that page is bollocks. Richard, I stand in awe of your superlative and highly detailed technical summary. :-) I think the biggest problem with MS's so-called "safe" functions is that they work on the assumption that it's better to get the wrong answer than to expose the system to the risk of damage. You know, you want to go to the cinema, but that involves crossing a busy road, so you cross the quieter road instead and end up at the supermarket. Did you get run over? No. But did you get to the cinema? No. This whole debate shouldn't be about safe functions, but about safe programming techniques. If you want a call to strcpy to be safe, you have to make sure that your destination is big enough to store *all* the data you want to copy. The strcpy_s function cannot do this for you. All it can do is ensure that no more data is copied to the destination than the programmer says can be stored there. That is *not* the same thing, not by a long way. -- 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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-06 15:58 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <563ccd17.26854781@news.xs4all.nl> |
| In reply to | #75072 |
Richard Heathfield <rjh@cpax.org.uk> wrote: > On 06/11/15 11:07, Richard Bos wrote: > > Malcolm McLean <malcolm.mclean5@btinternet.com> 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. > > > >> These are the ones Microsoft considers insecure > >> > >> https://msdn.microsoft.com/en-us/library/bb288454.aspx > > > > Yeah, because Mickey$oft have a stellar record when it comes to buffer > > overflows! > > > > Predictably, most of that page is bollocks. > > Richard, I stand in awe of your superlative and highly detailed > technical summary. :-) Sometimes, a more specific explanation would be wasted. > I think the biggest problem with MS's so-called "safe" functions is that > they work on the assumption that it's better to get the wrong answer > than to expose the system to the risk of damage. You know, you want to > go to the cinema, but that involves crossing a busy road, so you cross > the quieter road instead and end up at the supermarket. Did you get run > over? No. But did you get to the cinema? No. Oh, it's worse than that. They send you across the quieter road - but they _still_ don't teach you to look left - then right - then left*. The road may be quieter, but it's still not closed off, and walking across it with your eyes closed may kill you _later_ than on the busier road, but your injuries are still going to be pretty horrific. > This whole debate shouldn't be about safe functions, but about safe > programming techniques. Quite. (Not quiet.) Richard * People from countries where they drive not on the right, but the wrong side of the road may need to reverse these.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2015-11-06 11:10 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <9i4%x.14351$zj3.3970@fx05.iad> |
| In reply to | #75108 |
Off-topic aside... On Friday November 6 2015 10:58, in comp.lang.c, "Richard Bos" <raltbos@xs4all.nl> wrote: > Richard Heathfield <rjh@cpax.org.uk> wrote: [snip] >> You know, you want to >> go to the cinema, but that involves crossing a busy road, so you cross >> the quieter road instead and end up at the supermarket. Did you get run >> over? No. But did you get to the cinema? No. > > Oh, it's worse than that. They send you across the quieter road - but > they _still_ don't teach you to look left - then right - then left*. [snip] > * People from countries where they drive not on the right, but the wrong > side of the road may need to reverse these. Long ago, travelled from my home in Canada to London, England, and stayed in a "downtown" hotel. While wandering about the city, in a (literally) pedestrian way, I noted that, by the curb, printed on the pavement of the major streets, was an admonition to "Look Right". This statement appeared regularly along the roadway, on both sides. I guess that London, being the cosmopolitan place it is, had enough unfortunate accidents with people "looking left" that it became worthwile to remind them to look right as well. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-11-07 01:13 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <MPG.30a760ada4cf267186@news.eternal-september.org> |
| In reply to | #75111 |
Lew Pitcher wrote: > Richard Bos wrote: > > Oh, it's worse than that. They send you across the quieter road - but > > they _still_ don't teach you to look left - then right - then left*. > > > > * People from countries where they drive not on the right, but the wrong > > side of the road may need to reverse these. > > Long ago, travelled from my home in Canada to London, England, and stayed in > a "downtown" hotel. > > While wandering about the city, in a (literally) pedestrian way, I noted that, > by the curb, printed on the pavement of the major streets, was an admonition > to "Look Right". This statement appeared regularly along the roadway, on both > sides. > > I guess that London, being the cosmopolitan place it is, had enough > unfortunate accidents with people "looking left" that it became worthwile to > remind them to look right as well. I don't think those markings are for the benefit of us left-pondians. I think they are due to one-way streets.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2015-11-07 11:11 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <Jop%x.2658$lL.1208@fx28.iad> |
| In reply to | #75234 |
On Saturday November 7 2015 04:13, in comp.lang.c, "Philip Lantz" <prl@canterey.us> wrote: > Lew Pitcher wrote: >> Richard Bos wrote: >> > Oh, it's worse than that. They send you across the quieter road - but >> > they _still_ don't teach you to look left - then right - then left*. >> > >> > * People from countries where they drive not on the right, but the wrong >> > side of the road may need to reverse these. >> >> Long ago, travelled from my home in Canada to London, England, and stayed >> in a "downtown" hotel. >> >> While wandering about the city, in a (literally) pedestrian way, I noted >> that, by the curb, printed on the pavement of the major streets, was an >> admonition to "Look Right". This statement appeared regularly along the >> roadway, on both sides. >> >> I guess that London, being the cosmopolitan place it is, had enough >> unfortunate accidents with people "looking left" that it became worthwile >> to remind them to look right as well. > > I don't think those markings are for the benefit of us left-pondians. I agree. > I think they are due to one-way streets. Not entirely. While they *do* occupy a prominent role in one-way streets, the "Look Right" markings also appear on two-way streets. Take a look at the photo at http://1.bp.blogspot.com/-AEbGnibnvAM/UxOkmkj9Z6I/AAAAAAAAA1k/sPE6MPkWURs/s1600/IMG_6986.jpg to see an example. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-10 16:47 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <56421eba.7167187@news.xs4all.nl> |
| In reply to | #75234 |
Philip Lantz <prl@canterey.us> wrote: > Lew Pitcher wrote: > > Richard Bos wrote: > > > Oh, it's worse than that. They send you across the quieter road - but > > > they _still_ don't teach you to look left - then right - then left*. > > > > > > * People from countries where they drive not on the right, but the wrong > > > side of the road may need to reverse these. > > > > Long ago, travelled from my home in Canada to London, England, and stayed in > > a "downtown" hotel. > > > > While wandering about the city, in a (literally) pedestrian way, I noted that, > > by the curb, printed on the pavement of the major streets, was an admonition > > to "Look Right". This statement appeared regularly along the roadway, on both > > sides. > > > > I guess that London, being the cosmopolitan place it is, had enough > > unfortunate accidents with people "looking left" that it became worthwile to > > remind them to look right as well. > > I don't think those markings are for the benefit of us left-pondians. I think > they are due to one-way streets. No, they're not. They're all over the place. And they're quite helpful. I don't know whether they appear in other, less furriner-infected parts of the country; what I do know is that after the third time or so, I found myself turning that way automatically upon emerging from a tube station without having looked at the print. Habituation is funny. Fuck, I need to get back to the Great Wen one of these days. Richard
[toc] | [prev] | [next] | [standalone]
| From | Siri Cruz <chine.bleu@yahoo.com> |
|---|---|
| Date | 2015-11-04 06:49 -0800 |
| Message-ID | <chine.bleu-0F9C2C.06491404112015@88-209-239-213.giganet.hu> |
| In reply to | #74838 |
In article <cbf00349-353f-4490-bc03-ad637a470e05@googlegroups.com>, G G <gdotone@gmail.com> wrote: > (*structp).component structp->component > > Is there an advantage of choosing one over the other. (equivalent > expressions) Which makes your meaning clearer? -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. 'I desire mercy, not sacrifice.' God exists since mathematics is consistent, and the devil exists since we cannot prove the consistency. ~~ Morris Kline
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-04 09:55 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1d65p$9lb$1@dont-email.me> |
| In reply to | #74838 |
On 11/04/2015 09:22 AM, G G wrote: > (*structp).component structp->component > > Is there an advantage of choosing one over the other. (equivalent expressions) Yes - the second one involves typing one less character. > That comes from p. 577, Problem Solving and Program Design, by Elliot B. Koffman. > > Also, how would you read those? > > like: > > bad attempt follows... > (*structp).component : > structp is a pointer of type (whatever structp is a structure type of) of component, > with component, ??? > structp is a pointer to an object of struct or union type containing a member named component. This expression refers to that member of the pointed-at object. It can be used to either retrieve the value of that member, or to write a new value to that member. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | G G <gdotone@gmail.com> |
|---|---|
| Date | 2015-11-04 07:00 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <f3b45623-7ff8-4553-bcd7-9a5b72102f10@googlegroups.com> |
| In reply to | #74844 |
On Wednesday, November 4, 2015 at 9:56:13 AM UTC-5, James Kuyper wrote: > On 11/04/2015 09:22 AM, G G wrote: > structp is a pointer to an object of struct or union type containing a > member named component. This expression refers to that member of the > pointed-at object. It can be used to either retrieve the value of that > member, or to write a new value to that member. > -- > James Kuyper Thanks James.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-04 13:19 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1di3r$rpb$1@dont-email.me> |
| In reply to | #74844 |
On 11/04/2015 09:55 AM, James Kuyper wrote: > On 11/04/2015 09:22 AM, G G wrote: >> (*structp).component structp->component >> >> Is there an advantage of choosing one over the other. (equivalent expressions) > > Yes - the second one involves typing one less character. Apologies - I'm usually able to count correctly, but this is clearly not supporting evidence for that claim. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web