Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #90018 > unrolled thread
| Started by | G G <gdotone@gmail.com> |
|---|---|
| First post | 2016-07-05 02:38 -0700 |
| Last post | 2016-11-27 10:05 -0800 |
| Articles | 20 on this page of 354 — 37 participants |
Back to article view | Back to comp.lang.c
double free G G <gdotone@gmail.com> - 2016-07-05 02:38 -0700
Re: double free Ian Collins <ian-news@hotmail.com> - 2016-07-05 21:45 +1200
Re: double free Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-05 07:08 -0400
Re: double free G G <gdotone@gmail.com> - 2016-07-05 16:41 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-05 10:50 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-05 11:06 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-05 19:07 +0100
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-05 12:16 +0000
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-05 13:57 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-05 08:43 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-05 14:57 +0100
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-10 18:49 +0000
Re: double free G G <gdotone@gmail.com> - 2016-07-05 17:03 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-05 17:25 -0700
Re: double free Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-07-06 19:09 +0000
Re: double free "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-06 15:22 -0400
Re: double free Nobody <nobody@nowhere.invalid> - 2016-07-09 06:13 +0100
Re: double free "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-09 10:16 -0400
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-09 08:58 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-09 13:28 -0700
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-11 10:41 +0000
Re: double free David Brown <david.brown@hesbynett.no> - 2016-07-09 20:27 +0200
Re: double free "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-07-09 11:31 -0700
Re: double free Gareth Owen <gwowen@gmail.com> - 2016-07-09 20:14 +0100
Re: double free Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-09 15:34 -0400
Re: double free jameskuyper@verizon.net - 2016-07-09 14:02 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-09 14:10 -0700
Re: double free "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-09 17:14 -0400
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-09 14:24 -0700
Re: double free "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-09 17:31 -0400
Re: double free Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-09 20:50 -0400
Re: double free "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-09 15:50 -0400
Re: double free David Brown <david.brown@hesbynett.no> - 2016-07-10 11:32 +0200
Re: double free James Kuyper <jameskuyper@verizon.net> - 2016-07-10 16:01 -0400
Re: double free David Brown <david.brown@hesbynett.no> - 2016-07-11 10:07 +0200
Re: double free James Kuyper <jameskuyper@verizon.net> - 2016-07-11 08:15 -0400
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-11 06:53 -0700
Re: double free Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-11 10:35 -0600
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-11 09:48 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-11 11:02 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-11 11:01 -0700
Re: double free Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-11 13:03 -0600
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-11 10:57 -0700
Re: double free albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-27 13:29 +0100
Re: double free Melzzzzz <mel@zzzzz.com> - 2016-11-27 14:07 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-10 13:05 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-10 05:31 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-10 13:42 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-11 01:07 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-09 13:39 -0700
Re: double free David Brown <david.brown@hesbynett.no> - 2016-07-10 11:53 +0200
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-10 04:11 -0700
Re: double free Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-10 08:47 -0400
Re: double free James Kuyper <jameskuyper@verizon.net> - 2016-07-10 16:05 -0400
Re: double free Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-09 17:43 -0600
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-09 17:32 -0700
Re: double free Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-09 20:34 -0600
Re: double free Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-07-10 06:25 +0000
Re: double free supercat@casperkitty.com - 2016-07-11 08:02 -0700
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-11 11:01 +0000
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-11 04:07 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-11 12:17 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-11 04:59 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-11 13:07 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-11 13:38 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-11 14:11 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-11 18:54 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-11 11:09 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-11 19:47 +0100
Re: double free Ike Naar <ike@iceland.freeshell.org> - 2016-07-11 19:08 +0000
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-11 21:19 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-11 21:34 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-11 13:48 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-11 22:49 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-11 23:20 +0100
Re: double free Udyant Wig <udyant.wig@gmail.com> - 2016-07-12 10:26 +0530
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-11 22:34 -0700
Re: double free Ike Naar <ike@iceland.freeshell.org> - 2016-07-12 06:39 +0000
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-12 00:41 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-12 08:57 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-12 01:16 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-12 09:27 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-12 11:48 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-12 08:46 +0100
Re: double free David Brown <david.brown@hesbynett.no> - 2016-07-12 10:42 +0200
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-12 09:59 +0100
Re: double free David Brown <david.brown@hesbynett.no> - 2016-07-12 12:46 +0200
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 09:08 -0700
Re: double free David Brown <david.brown@hesbynett.no> - 2016-07-12 18:51 +0200
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 11:28 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-12 19:53 +0100
Re: double free supercat@casperkitty.com - 2016-07-12 12:19 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 14:26 -0700
Re: double free Ken Brody <kenbrody@spamcop.net> - 2016-07-12 11:00 -0400
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-12 16:18 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 08:44 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-12 09:24 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-12 17:34 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-12 09:52 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 09:40 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-12 18:22 +0100
Re: double free Gareth Owen <gwowen@gmail.com> - 2016-07-13 18:33 +0100
Re: double free "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-13 14:00 -0400
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 19:16 +0100
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-18 09:15 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-18 09:04 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-18 11:10 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-20 08:52 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-20 09:36 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-21 18:23 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-12 08:42 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-12 11:24 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-12 11:52 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-12 13:18 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-12 16:42 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-12 17:21 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 09:35 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-12 18:08 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-12 18:14 +0100
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-18 10:01 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-18 18:20 +0100
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-21 09:26 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-21 18:57 +0100
Re: double free Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 23:41 +0530
Re: double free BartC <bc@freeuk.com> - 2016-07-22 19:47 +0100
Re: double free supercat@casperkitty.com - 2016-07-22 11:58 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-22 12:03 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-22 20:26 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-22 13:12 -0700
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-23 08:57 +0000
Re: double free BartC <bc@freeuk.com> - 2016-07-23 10:21 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-23 11:08 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-23 12:36 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-23 07:14 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-23 16:41 +0100
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:17 +0000
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-23 20:42 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-23 12:51 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-23 21:50 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-23 14:17 -0700
Re: double free luser droog <luser.droog@gmail.com> - 2016-07-23 15:53 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-23 20:55 -0700
Re: double free luser droog <luser.droog@gmail.com> - 2016-07-23 22:21 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-24 10:35 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-24 02:55 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-24 04:05 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-24 14:03 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-24 14:24 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-24 15:15 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-24 16:01 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-24 11:36 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-24 19:52 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-24 12:14 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-24 11:13 -0700
Re: double free Martin Shobe <mashobe9@gmail.com> - 2016-07-24 14:52 -0500
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-25 09:59 -0700
Re: double free Martin Shobe <mashobe9@gmail.com> - 2016-07-25 19:32 -0500
Re: double free supercat@casperkitty.com - 2016-07-25 07:39 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-24 10:55 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-24 08:30 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-23 11:11 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-23 12:39 -0700
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-23 20:25 +0000
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 12:51 -0700
Re: double free supercat@casperkitty.com - 2016-07-22 13:18 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-24 08:23 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-24 19:36 +0100
Re: double free albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-02 10:21 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 10:57 +0000
Re: double free BartC <bc@freeuk.com> - 2016-12-02 12:33 +0000
Re: double free David Brown <david.brown@hesbynett.no> - 2016-12-02 14:07 +0100
Re: double free "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-02 10:19 -0500
Re: double free Keith Thompson <kst-u@mib.org> - 2016-12-02 08:56 -0800
Re: double free "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-02 12:31 -0500
Re: double free Keith Thompson <kst-u@mib.org> - 2016-12-02 11:42 -0800
Re: double free supercat@casperkitty.com - 2016-07-12 08:46 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 09:16 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-12 09:27 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 08:20 -0700
Re: double free James Kuyper <jameskuyper@verizon.net> - 2016-07-12 12:47 -0400
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-12 22:21 +0000
Re: double free BartC <bc@freeuk.com> - 2016-07-12 23:27 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 16:28 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-13 00:23 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 08:43 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-13 11:21 +0100
Re: double free Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-13 12:56 +0200
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 12:35 +0100
Re: double free Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-13 10:34 -0400
Re: double free Cal Dershowitz <cal@example.invalid> - 2016-07-15 05:57 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-13 11:17 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-13 04:30 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 12:33 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-13 13:41 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 13:57 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-13 06:10 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-13 20:08 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-13 15:11 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 18:14 +0100
Re: double free Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-13 19:20 +0200
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 18:24 +0100
Re: double free Robert Wessel <robertwessel2@yahoo.com> - 2016-07-15 00:51 -0500
Re: double free luser droog <luser.droog@gmail.com> - 2016-07-15 02:18 -0700
Re: double free "Osmium" <r124c4u102@comcast.net> - 2016-07-15 07:12 -0500
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-15 13:14 +0100
Re: double free Rosario19 <Ros@invalid.invalid> - 2016-07-18 09:28 +0200
Re: double free BartC <bc@freeuk.com> - 2016-07-13 18:43 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-13 20:15 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-13 21:14 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-13 13:24 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-13 21:50 +0100
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:21 +0000
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-13 13:02 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 21:34 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-13 13:51 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 22:22 +0100
Re: double free Robert Wessel <robertwessel2@yahoo.com> - 2016-07-15 01:08 -0500
Re: double free Reinhardt Behm <rbehm@hushmail.com> - 2016-07-15 17:33 +0800
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-15 05:02 -0700
Re: double free Reinhardt Behm <rbehm@hushmail.com> - 2016-07-15 21:15 +0800
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 14:48 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-15 08:02 -0700
Re: double free Cal Dershowitz <cal@example.invalid> - 2016-07-18 01:42 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 03:07 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-13 22:01 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-13 22:14 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-13 14:31 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-13 23:03 +0100
Re: double free "Osmium" <r124c4u102@comcast.net> - 2016-07-13 17:53 -0500
Re: double free supercat@casperkitty.com - 2016-07-13 16:18 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-13 16:19 -0700
Re: double free Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-13 22:44 -0400
Re: double free Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-14 09:44 +0200
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-13 17:07 -0700
Re: double free supercat@casperkitty.com - 2016-07-14 07:13 -0700
Re: double free Robert Wessel <robertwessel2@yahoo.com> - 2016-07-15 01:18 -0500
Re: double free Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-13 10:46 -0400
Re: double free Robert Wessel <robertwessel2@yahoo.com> - 2016-07-15 00:59 -0500
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-14 23:47 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-15 11:22 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-15 11:35 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 14:33 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-15 15:16 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-15 16:19 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-15 08:39 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-15 16:54 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 21:20 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 16:45 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-15 17:15 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-15 17:42 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 21:18 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 21:06 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-15 21:46 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 23:08 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-16 01:26 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-15 18:22 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-15 18:48 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-15 18:40 -0700
Re: double free supercat@casperkitty.com - 2016-07-15 10:09 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-15 11:07 -0700
Re: double free supercat@casperkitty.com - 2016-07-15 12:11 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-15 12:30 -0700
Re: double free supercat@casperkitty.com - 2016-07-15 12:41 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-15 13:04 -0700
Re: double free supercat@casperkitty.com - 2016-07-15 14:26 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-19 10:00 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-13 12:46 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-13 13:19 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-13 13:30 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-13 20:53 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-13 21:37 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-13 05:22 -0700
Re: double free supercat@casperkitty.com - 2016-07-13 07:07 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-14 19:31 +0100
Re: double free supercat@casperkitty.com - 2016-07-14 12:10 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-14 23:16 +0100
Re: double free supercat@casperkitty.com - 2016-07-14 16:00 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-14 12:34 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-14 20:57 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-14 13:15 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-14 21:27 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-14 21:31 +0100
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-18 09:46 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-19 13:32 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-19 13:46 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 06:00 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-19 09:23 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 09:38 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-19 17:51 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-19 18:22 +0100
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-23 09:02 +0000
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-19 11:42 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 12:27 -0700
Re: double free Philip Lantz <prl@canterey.us> - 2016-07-21 10:02 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-21 10:25 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-21 18:27 +0100
Re: double free Cal Dershowitz <cal@example.invalid> - 2016-07-29 00:42 -0700
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-23 08:59 +0000
Re: double free BartC <bc@freeuk.com> - 2016-07-19 15:22 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-19 15:59 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-19 16:39 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-19 16:55 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-19 17:49 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-19 18:20 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-19 19:03 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-19 19:22 +0100
sizeof (was Re: double free) Ken Brody <kenbrody@spamcop.net> - 2016-07-19 14:44 -0400
Re: sizeof (was Re: double free) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 12:31 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-19 22:46 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-19 15:19 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 00:21 +0100
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:21 +0000
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-19 12:08 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-19 09:41 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-21 18:10 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-22 11:23 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 03:40 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-22 10:33 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 12:47 -0700
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-12 22:18 +0000
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-11 10:53 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-11 21:20 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-11 13:56 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-11 22:39 +0100
Re: double free David Brown <david.brown@hesbynett.no> - 2016-07-12 10:57 +0200
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-11 21:58 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-11 13:23 +0100
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-11 13:00 +0000
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-11 10:44 -0700
Re: double free Gareth Owen <gwowen@gmail.com> - 2016-07-11 19:10 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-11 20:22 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-11 21:11 +0100
Re: double free Gareth Owen <gwowen@gmail.com> - 2016-07-11 21:49 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-11 22:01 +0100
Re: double free James Kuyper <jameskuyper@verizon.net> - 2016-07-11 09:09 -0400
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-11 14:16 +0100
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-15 13:51 +0000
Re: double free James Kuyper <jameskuyper@verizon.net> - 2016-07-15 12:04 -0400
Re: double free Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-11 17:51 +0200
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-11 10:19 +0000
Re: double free Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-05 08:57 -0600
Re: double free James Kuyper <jameskuyper@verizon.net> - 2016-07-05 11:13 -0400
Re: double free supercat@casperkitty.com - 2016-07-05 09:05 -0700
Re: double free G G <gdotone@gmail.com> - 2016-07-05 16:38 -0700
Re: double free G G <gdotone@gmail.com> - 2016-07-05 16:34 -0700
Re: double free Nobody <nobody@nowhere.invalid> - 2016-07-06 04:10 +0100
Re: double free Siri Cruise <chine.bleu@yahoo.com> - 2016-07-05 21:27 -0700
Re: double free supercat@casperkitty.com - 2016-07-06 02:53 -0700
Re: double free Siri Cruise <chine.bleu@yahoo.com> - 2016-07-06 06:09 -0700
Re: double free supercat@casperkitty.com - 2016-07-06 07:53 -0700
Re: double free "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-07-06 01:25 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-06 11:12 +0100
Re: double free Thiago Adams <thiago.adams@gmail.com> - 2016-11-27 09:52 -0800
Re: double free supercat@casperkitty.com - 2016-11-27 10:05 -0800
Page 13 of 18 — ← Prev page 1 … 11 12 [13] 14 15 … 18 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-15 11:35 +0100 |
| Message-ID | <nmae92$hlv$1@dont-email.me> |
| In reply to | #90386 |
On 15/07/2016 11:22, BartC wrote:
> I'm not new to C but I thought I'd try this as I have trouble with this
> stuff. I knew that the two declarations were:
>
> FooStruct *Array1[100]; // (this is the array of pointers)
> FooStruct (*Array2)[100]; // (and this is pointer to array)
>
> but wasn't sure which was which (I later used cdecl to establish this as
> I noted in the comments). I was going to use trial and error to find
> which they were by trying to access an element and using the success or
> failure of compilation to tell me whether I was on the right track.
>
> The problem was, the access code worked exactly the same for each!
>
> FooStruct F;
> int i;
>
> F=*Array1[i];
> F=*Array2[i];
>
> F=(*Array1)[i];
> F=(*Array2)[i];
> Your comments suggest that it /wouldn't/ be enough of an improvement to
> have a new language where type declarations are totally straightforward
> and transparent. Well, I would be the first customer for such a language!
Of course I already have a language that does that, which I secretly
used to help me with the C too. The above bit of code is written as:
[100]ref FooStruct Array1 # array of pointers
ref[100] FooStruct Array2 # pointer to array
int i
FooStruct F
F:=Array1[i]^ # index element than deref
F:=Array2^[i] # deref first then index element
Access to Array1 and Array2 needs to be different as they /are/
different. My compiler tells me that the corresponding C (adjusted for
0-based arrays) is:
FooStruct (*Array1[100]);
FooStruct (*Array2)[100];
int i;
FooStruct F;
F=(*Array1[i]);
F=(*Array2)[i];
This is based on logic as far as possible, and ignores the, IMO, rather
alarming laxity that C allows.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-15 14:33 +0100 |
| Message-ID | <87eg6vqb4y.fsf@bsb.me.uk> |
| In reply to | #90386 |
BartC <bc@freeuk.com> writes: <snip> > Elsewhere I posed this problem: > > [supercat giving examples in Pascal:] >>> If one wants an array of pointers to instances of FooStruct: >>> Var arr: Array[0..99] of ^FooStruct; > >>> If one wants a pointer to an array of instances of FooStruct: >>> Var arr: ^Array[0..99] of FooStruct; > >> (Exercise for those new to C: convert the last two examples into C >> equivalents.) > > I'm not new to C but I thought I'd try this as I have trouble with > this stuff. I knew that the two declarations were: > > FooStruct *Array1[100]; // (this is the array of pointers) > FooStruct (*Array2)[100]; // (and this is pointer to array) > > but wasn't sure which was which As a fan of brackets why don't you write FooStruct *(Array1[100]); // (this is the array of pointers) Would that not make it clear? C has declarations whose syntax mirror's the use and most C programmers know that *a[1] is a dereference of an array element -- i.e. it means *(a[1]). > (I later used cdecl to establish this > as I noted in the comments). I was going to use trial and error to > find which they were by trying to access an element and using the > success or failure of compilation to tell me whether I was on the > right track. > > The problem was, the access code worked exactly the same for each! Something is wrong with your compiler then. These two accesses: > FooStruct F; > int i; > > F=*Array1[i]; > F=*Array2[i]; are very different. If you've set up Array1 and Array2 so that they are both valid, they will generate different code and access different locations. > F=(*Array1)[i]; > F=(*Array2)[i]; Likewise. These two don't work the same way either. > So not only is there no obvious, easy way to remember how to write a > pointer to array or array of pointers, I find it easy (postfix operators bind more strongly the prefix ones) but I may be part of some elite few who can remember this sort of thing. I suppose those not so blessed could keen an operator precedence table on their (real or virtual) desktop. > but the language apparently > allows either to be used interchangeably. They are not interchangeable -- they mean different things. You've stated that you don't want to learn anything more about C so I won't explain what they mean, but anyone else who is baffled can just ask and I (or others) will try to explain it. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-15 15:16 +0100 |
| Message-ID | <nmar7q$tm1$1@dont-email.me> |
| In reply to | #90393 |
On 15/07/2016 14:33, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> The problem was, the access code worked exactly the same for each!
>
> Something is wrong with your compiler then. These two accesses:
>
>> FooStruct F;
>> int i;
>>
>> F=*Array1[i];
>> F=*Array2[i];
>
> are very different. If you've set up Array1 and Array2 so that they are
> both valid, they will generate different code and access different
> locations.
I'm not talking about the generated code. If A1 actually is a pointer to
array and A2 is an array of pointers, then you would expect the
generated code to access a FooStruct element to be different.
My issue is that you can access these very different structures using
the identical C expression.
>> F=(*Array1)[i];
>> F=(*Array2)[i];
>
> Likewise. These two don't work the same way either.
And here, that you can use a /different/ C expression (I assume *A[i]
means *(A[i]) not (*A)[i]) and it STILL works! Furthermore, that
different expression also works, unchanged, for either A1 or A1.
>> but the language apparently
>> allows either to be used interchangeably.
>
> They are not interchangeable -- they mean different things.
So why are they written the same? Suppose someone is under the
misapprehension that A1 is a pointer to array, not an array of pointers,
and the write indexing code under that assumption. The compiler will not
tell them they're doing it wrong. And the reader who's trying to
understand the data structures by looking at the code can't tell either.
> You've stated that you don't want to learn anything more about C so I
> won't explain what they mean, but anyone else who is baffled can just
> ask and I (or others) will try to explain it.
You can explain what's going on but that won't throw any light on why C,
a low-level supposedly very transparent language, allows it to happen.
It gets even more confusing:
FooStruct (*(*Array3)[100]); // pointer to ARRAY of pointers
FooStruct (*(*Array4))[100]; // pointer to pointer to ARRAY
FooStruct (*(*Array5[100])); // ARRAY of pointers to pointer
F=*(*Array3)[i];
F=(*(*Array4))[i];
F=*(*Array5[i]);
As far as I'm concerned, these are all just a maze of twisty passages,
all alike. Naturally I had to get my compiler to convert these from my
language where it is child's play of a few seconds to write this stuff,
and generate the C. And the C works so at this point my interest in its
idiosyncrasies ought to cease.
However C is so weird, that it turns from a bad language to a
fascinating one. The three objects A3, A4 and A5 are obviously of very
different types. But look here:
F=*(*Array3)[i];
F=*(*Array4)[i];
F=*(*Array5)[i];
F=(*(*Array4))[i];
F=(*(*Array3))[i];
F=(*(*Array5))[i];
F=*(*Array5[i]);
F=*(*Array4[i]);
F=*(*Array3[i]);
I'm using exactly the same expression on each of the objects in turn.
Yet it still compiles!
That is absolutely extraordinary. And quite brilliant. Because I
wouldn't have a clue how to get my own language to do that, short of
abandoning type checking completely, but then it would go wrong for
other reasons.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-15 16:19 +0100 |
| Message-ID | <nmauu3$bpu$1@dont-email.me> |
| In reply to | #90397 |
On 15/07/2016 15:16, BartC wrote:
> It gets even more confusing:
>
> FooStruct (*(*Array3)[100]); // pointer to ARRAY of pointers
> FooStruct (*(*Array4))[100]; // pointer to pointer to ARRAY
> FooStruct (*(*Array5[100])); // ARRAY of pointers to pointer
>
> However C is so weird, that it turns from a bad language to a
> fascinating one. The three objects A3, A4 and A5 are obviously of very
> different types.
The types are related in that they have the same number of pointer and
array elements, but in a different order.
Experiments using two array types and one pointer gave similar results.
Take this example:
FooStruct (*(*(*(*Array6))))[100][100];
FooStruct (*(*(*(*Array7[100][100]))));
Here, Array6 is a pointer to pointer to pointer to pointer to array 100
of array 100.
While Array7 is array 100 of array 100 of pointer to pointer to pointer
to pointer.
Yet again, the code need to access an element is interchangeable:
F=(*(*(*(*Array6))))[i][j];
F=(*(*(*(*Array7))))[i][j];
F=(*(*(*(*Array6[i][j]))));
F=(*(*(*(*Array7[i][j]))));
The code to access a 'terminal' element (ie. index all arrays and
dereference all pointers) doesn't care if the type starts with arrays
first, pointers first, or all mixed up! The indices and deferences can
apparently be done in any order.
It's magic.
Good luck trying to explain that to students.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-15 08:39 -0700 |
| Message-ID | <lnlh12x641.fsf@kst-u.example.com> |
| In reply to | #90397 |
BartC <bc@freeuk.com> writes:
> On 15/07/2016 14:33, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>> The problem was, the access code worked exactly the same for each!
>> Something is wrong with your compiler then. These two accesses:
>>
>>> FooStruct F;
>>> int i;
>>>
>>> F=*Array1[i];
>>> F=*Array2[i];
>>
>> are very different. If you've set up Array1 and Array2 so that they are
>> both valid, they will generate different code and access different
>> locations.
>
> I'm not talking about the generated code. If A1 actually is a pointer to
> array and A2 is an array of pointers, then you would expect the
> generated code to access a FooStruct element to be different.
>
> My issue is that you can access these very different structures using
> the identical C expression.
[...]
One more time. An array expression is, in most but not all contexts,
implicitly converted to a pointer to the array's initial element.
Because of that, an expression `a[i]` is valid, but has a different
meaning, whether `a` is a pointer or an array. You can of course
construct more complicated examples of this.
I am not trying to say that this language feature was a good idea.
In fact, I don't think it was. I am simply describing how it works.
You seem to be astonished and appalled every time you encounter this.
Most of the rest of us accept it and move on with our lives.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-15 16:54 +0100 |
| Message-ID | <nmb0v1$jer$1@dont-email.me> |
| In reply to | #90401 |
On 15/07/2016 16:39, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> My issue is that you can access these very different structures using >> the identical C expression. > [...] > > One more time. An array expression is, in most but not all contexts, > implicitly converted to a pointer to the array's initial element. > Because of that, an expression `a[i]` is valid, but has a different > meaning, whether `a` is a pointer or an array. You can of course > construct more complicated examples of this. > > I am not trying to say that this language feature was a good idea. > In fact, I don't think it was. I am simply describing how it works. I'm aware of the fact that with A[i], A can be a normal array, or it can be a pointer to the first element of an array. You can't tell just by looking. That itself is not that big a deal, and means the same source - A[i] - can be used for both kinds of arrays, potentially an advantage. What I didn't know until today, is that more elaborate types that consist of a sequence of pointer and array denotations, can apparently be dealt with in an expression without regards to the order of those pointers and arrays! See my last posts for examples. But wasn't the purpose of C's complicated type declarations that the code used to access the variable mirrors the type? It seems now that that isn't the case - the elements of the type, or the access expression, can all be mixed up, and it still works, provided there are the right number of deref and index ops. I also very strongly suspect that quite a few people who thought they knew C would be surprised too. I don't know how C manages that. > You seem to be astonished and appalled every time you encounter this. > Most of the rest of us accept it and move on with our lives. It really doesn't worry you that when you define a pointer to array, you can access an element by *either* dereferencing the pointer first, then doing the array (which is after all how its defined and how it *must* work internally), *or* by indexing the array first and *then* dereferencing the pointer? That doesn't seem to you just a little bit crazy? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-15 21:20 +0100 |
| Message-ID | <877fcmpsaa.fsf@bsb.me.uk> |
| In reply to | #90403 |
BartC <bc@freeuk.com> writes: <snip> > What I didn't know until today, is that more elaborate types that > consist of a sequence of pointer and array denotations, can apparently > be dealt with in an expression without regards to the order of those > pointers and arrays! Nonsense. You must deal with them correctly which means taking care to write the declarations and the accesses correctly. That two identical expressions mean different things depending on the types involved is one thing (and you've said you don't like it -- fine), but don't suggest that the order does not matter. (I say "suggest" because you are being vague -- deliberately I suspect -- with phrases like "dealt with".) <snip> > It really doesn't worry you that when you define a pointer to array, > you can access an element by *either* dereferencing the pointer first, > then doing the array (which is after all how its defined and how it > *must* work internally), *or* by indexing the array first and *then* > dereferencing the pointer? > > That doesn't seem to you just a little bit crazy? It would if that were true, but it isn't. (*a)[i] and *(a[i]) are, in general (i.e. when i is not zero), quite different. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-15 16:45 +0100 |
| Message-ID | <87oa5yq4zz.fsf@bsb.me.uk> |
| In reply to | #90397 |
BartC <bc@freeuk.com> writes: > On 15/07/2016 14:33, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> The problem was, the access code worked exactly the same for each! >> >> Something is wrong with your compiler then. These two accesses: >> >>> FooStruct F; >>> int i; >>> >>> F=*Array1[i]; >>> F=*Array2[i]; >> >> are very different. If you've set up Array1 and Array2 so that they are >> both valid, they will generate different code and access different >> locations. > > I'm not talking about the generated code. "worked exactly the same for each" made it sound as if you thought the two expressions mean the same thing. You do know they mean very different things? <snip> > My issue is that you can access these very different structures using > the identical C expression. Yes, but that should not be news to you. A much simpler example is the classic 2D "array" that you can make using pointers (int **mat1) or by direct declaration (int mat2[3][3]) and yet access both using mat?[i][j]. > >>> F=(*Array1)[i]; >>> F=(*Array2)[i]; >> >> Likewise. These two don't work the same way either. > > And here, that you can use a /different/ C expression (I assume *A[i] > means *(A[i]) not (*A)[i]) and it STILL works! Furthermore, that > different expression also works, unchanged, for either A1 or A1. > >>> but the language apparently >>> allows either to be used interchangeably. >> >> They are not interchangeable -- they mean different things. > > So why are they written the same? What they mean depends on the types. Since you have two different types the meaning of the expressions are different. This should have been your point all along -- that the same expression means different things depending on the type of the objects involved. The same simple rules can be used to explain what each expression does, but you are not keen on learning them. > Suppose someone is under the > misapprehension that A1 is a pointer to array, not an array of > pointers, and the write indexing code under that assumption. The > compiler will not tell them they're doing it wrong. And the reader > who's trying to understand the data structures by looking at the code > can't tell either. *I* can tell, because I'd look at the declaration. But you are right -- people who don't know C (or who don't take the declaration into account) will be baffled. <snip> > It gets even more confusing: > > FooStruct (*(*Array3)[100]); // pointer to ARRAY of pointers > FooStruct (*(*Array4))[100]; // pointer to pointer to ARRAY > FooStruct (*(*Array5[100])); // ARRAY of pointers to pointer <snip> > ... The three objects A3, A4 and A5 are obviously of very > different types. But look here: > > F=*(*Array3)[i]; > F=*(*Array4)[i]; > F=*(*Array5)[i]; > > F=(*(*Array4))[i]; > F=(*(*Array3))[i]; > F=(*(*Array5))[i]; > > F=*(*Array5[i]); > F=*(*Array4[i]); > F=*(*Array3[i]); > > I'm using exactly the same expression on each of the objects in > turn. Yet it still compiles! > > That is absolutely extraordinary. And quite brilliant. Because I > wouldn't have a clue how to get my own language to do that, short of > abandoning type checking completely, but then it would go wrong for > other reasons. It's very simple to do -- just make array values decay to pointer values and define E1[E2] in terms of pointer arithmetic. Then pretty much any pattern of three *s or []s will give you a FooStruct. Which one, of course, depends on what is being indexed and what is being derferenced. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-15 17:15 +0100 |
| Message-ID | <nmb26n$o84$1@dont-email.me> |
| In reply to | #90402 |
On 15/07/2016 16:45, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> So why are they written the same? > > What they mean depends on the types. Since you have two different types > the meaning of the expressions are different. This should have been > your point all along -- that the same expression means different things > depending on the type of the objects involved. I concentrated only on the type system and whether the compiler would report an error when an expression uses the wrong mix of array and pointer ops. It didn't, despite the difference between expression and declaration being quite dramatic in some examples. I've now done a test to see whether using the wrong expression gives the right result anyway, and it doesn't. Or at least, with two object types, two ways of accessing the element, and four different results, one of those was wrong (I expected two to be wrong). (I tested pointer/array and array/pointer as being simplest to set up.) It means that if someone had a pointer to array (etc), but thought it was an array of pointers, they can write the wrong expression and the compiler will not pick up their error. If this is a consequence of pointers and arrays being interchangeable, that is not a good state of affairs. I think I feel better about my own language now as that works much more strictly and exactly as you expect. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-15 17:42 +0100 |
| Message-ID | <nmb3pt$u5f$1@dont-email.me> |
| In reply to | #90405 |
On 15/07/2016 17:15, BartC wrote: > If this is a consequence of pointers and arrays being interchangeable, > that is not a good state of affairs. This must be it. Start with a chain of type denotations consisting of a mix of pointers and arrays, say N pointers and arrays in total. Since *A and A[] ops are interchangeable, all the compiler is interested in is whether *any* mix of *A and A[] ops add up to N. It doesn't matter that you mistakenly provide an index A[i] to part of the type that is actually a pointer, or use *A (effectively using an index of 0) to a part that was an array. It'll probably give the wrong results and might crash, but hey, you need to know what you're doing in C. So that is perfectly acceptable. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-15 21:18 +0100 |
| Message-ID | <87a8hipsdg.fsf@bsb.me.uk> |
| In reply to | #90406 |
BartC <bc@freeuk.com> writes: > On 15/07/2016 17:15, BartC wrote: > >> If this is a consequence of pointers and arrays being interchangeable, >> that is not a good state of affairs. > > This must be it. <sigh> No, that's not it. There's even a FAQ entry about it. > Start with a chain of type denotations consisting of a mix of pointers > and arrays, say N pointers and arrays in total. > > Since *A and A[] ops are interchangeable, all the compiler is > interested in is whether *any* mix of *A and A[] ops add up to N. The compiler is also interested in generating the right code, so it takes the type into account as it goes. > It doesn't matter that you mistakenly provide an index A[i] to part of > the type that is actually a pointer, or use *A (effectively using an > index of 0) to a part that was an array. It matters a lot if you want to access the right element. (It also matters if one of the array types is incomplete but that is very much a technicality.) > It'll probably give the wrong results and might crash, but hey, you > need to know what you're doing in C. So that is perfectly acceptable. You see -- you do know that it matters! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-15 21:06 +0100 |
| Message-ID | <87furapsy5.fsf@bsb.me.uk> |
| In reply to | #90405 |
BartC <bc@freeuk.com> writes: > On 15/07/2016 16:45, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> So why are they written the same? >> >> What they mean depends on the types. Since you have two different types >> the meaning of the expressions are different. This should have been >> your point all along -- that the same expression means different things >> depending on the type of the objects involved. > > I concentrated only on the type system and whether the compiler would > report an error when an expression uses the wrong mix of array and > pointer ops. > > It didn't, despite the difference between expression and declaration > being quite dramatic in some examples. How could it? What you call an array op is a pointer operation, and array values decay to pointer values so there is no "mix" to be wrong -- it's pointers all the way down. I can't shake the feeling you are putting on a show of being shocked here since these two facts (that E1[E2] is defined as a pointer operation, and that array values decay to pointer values) are amongst the best know facts about C. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-15 21:46 +0100 |
| Message-ID | <nmbi3a$jlq$1@dont-email.me> |
| In reply to | #90414 |
On 15/07/2016 21:06, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 15/07/2016 16:45, Ben Bacarisse wrote: >>> BartC <bc@freeuk.com> writes: >> >>>> So why are they written the same? >>> >>> What they mean depends on the types. Since you have two different types >>> the meaning of the expressions are different. This should have been >>> your point all along -- that the same expression means different things >>> depending on the type of the objects involved. >> >> I concentrated only on the type system and whether the compiler would >> report an error when an expression uses the wrong mix of array and >> pointer ops. >> >> It didn't, despite the difference between expression and declaration >> being quite dramatic in some examples. > > How could it? What you call an array op is a pointer operation, and > array values decay to pointer values so there is no "mix" to be wrong -- > it's pointers all the way down. No. You can have a pointer type T* that is known (by the programmer) to point to one instance of T. Or a type T* that points to multiple instances (a dynamic array for example). Or a T[] that also points to or comprises multiple instances. Using A[i] on the first kind of T* is likely to be an error, but the compiler can't tell you that. While using exclusively *A (with no offset) on the second kind of T*, or T[], is probably not quite right either. And that is your mix: A[i] with the first T*, or *A with the second T* or with T[]. With any other language such errors will be picked up immediately as you can't use A[i] with pointers, and you can't use *A with arrays. > I can't shake the feeling you are putting on a show of being shocked > here since these two facts (that E1[E2] is defined as a pointer > operation, and that array values decay to pointer values) are amongst > the best know facts about C. The shock was genuine. You don't fully appreciate the implications of mixing arrays and pointers until you have more complicated types. Such as the array of pointers/pointer to array that supercat posted examples of in Pascal. I was relying on the compiler to tell me I'd gone wrong in trying to determine which of *(A[i]) or (*A)[i] to use for each object type. But it was decidedly unhelpful as everything apparently worked! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-15 23:08 +0100 |
| Message-ID | <87shvamu5p.fsf@bsb.me.uk> |
| In reply to | #90417 |
BartC <bc@freeuk.com> writes: > On 15/07/2016 21:06, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 15/07/2016 16:45, Ben Bacarisse wrote: >>>> BartC <bc@freeuk.com> writes: >>> >>>>> So why are they written the same? >>>> >>>> What they mean depends on the types. Since you have two different types >>>> the meaning of the expressions are different. This should have been >>>> your point all along -- that the same expression means different things >>>> depending on the type of the objects involved. >>> >>> I concentrated only on the type system and whether the compiler would >>> report an error when an expression uses the wrong mix of array and >>> pointer ops. >>> >>> It didn't, despite the difference between expression and declaration >>> being quite dramatic in some examples. >> >> How could it? What you call an array op is a pointer operation, and >> array values decay to pointer values so there is no "mix" to be wrong -- >> it's pointers all the way down. > > No. You can have a pointer type T* that is known (by the programmer) > to point to one instance of T. Or a type T* that points to multiple > instances (a dynamic array for example). Or a T[] that also points to > or comprises multiple instances. You say "no" but you appear to be agreeing. All the "ops" as you call them are pointer ops so there is nothing for a C compiler to complain about (unless it can do some bounds checking at compiler time). > Using A[i] on the first kind of T* is likely to be an error, but the > compiler can't tell you that. > > While using exclusively *A (with no offset) on the second kind of T*, > or T[], is probably not quite right either. > > And that is your mix: A[i] with the first T*, or *A with the second T* > or with T[]. They are all pointer operations, so you should not be surprised that the compiler can't complain about them (from a type point of view). > With any other language such errors will be picked up immediately as > you can't use A[i] with pointers, and you can't use *A with arrays. Of course, but you were surprised that a *C* compiler did not complain about what I would have thought you knew was a pointer operation being applied to a pointer. Maybe all the *s and [] made you think the compiler would know more about the complex type than it does about the simplest ones, though I don't see how. >> I can't shake the feeling you are putting on a show of being shocked >> here since these two facts (that E1[E2] is defined as a pointer >> operation, and that array values decay to pointer values) are amongst >> the best know facts about C. > > The shock was genuine. You don't fully appreciate the implications of > mixing arrays and pointers until you have more complicated types. > > Such as the array of pointers/pointer to array that supercat posted > examples of in Pascal. > > I was relying on the compiler to tell me I'd gone wrong in trying to > determine which of *(A[i]) or (*A)[i] to use for each object type. But > it was decidedly unhelpful as everything apparently worked! Well I'll have to take your surprise as genuine then, but why you would think the compiler could tell you more about this complex case than it can in the simple ones is still a mystery to me. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-16 01:26 +0100 |
| Message-ID | <nmbuvp$tj9$1@dont-email.me> |
| In reply to | #90420 |
On 15/07/2016 23:08, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> With any other language such errors will be picked up immediately as >> you can't use A[i] with pointers, and you can't use *A with arrays. > > Of course, but you were surprised that a *C* compiler did not complain > about what I would have thought you knew was a pointer operation being > applied to a pointer. Maybe all the *s and [] made you think the > compiler would know more about the complex type than it does about the > simplest ones, though I don't see how. Well, I simply forgot that the array/pointer conflation that lets you write A[i] or *(A+i), or A[0] or *A, has these other implications when the data structure is more elaborate. I declare a pointer to an array, and I intend it to be a pointer to a single array, which I expect to access as a dereference followed by an index op. Yet C allows me to index this pointer with an offset i, which is already wrong before I do anything else. But I don't find out until I run the program, and then, if I'm lucky, it will be obviously wrong or crash. I think this is a flaw in the language where you can't distinguish one type of T* from another, ie. pointing to a single T or to the first of multiple Ts. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-15 18:22 -0700 |
| Message-ID | <lnwpkmv0ku.fsf@kst-u.example.com> |
| In reply to | #90426 |
BartC <bc@freeuk.com> writes:
[...]
> I think this is a flaw in the language where you can't distinguish one
> type of T* from another, ie. pointing to a single T or to the first of
> multiple Ts.
The language makes no such distinction. For purposes of pointer
arithmetic, an object of type T is treated as an array of type T[1].
I'm neither disputing nor agreeing with your statement that this
is a flaw in the language, merely explaining how it's defined.
I can see the benefit of a different kind of pointer that can point
to an object but that isn't subject to arithmetic, but I'm not sure
it's practical to add such a feature to C.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-15 18:48 -0700 |
| Message-ID | <a0bada71-ce4a-4895-b43b-79cd3b82cf93@googlegroups.com> |
| In reply to | #90427 |
On Saturday, July 16, 2016 at 2:22:43 AM UTC+1, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > [...] > > I think this is a flaw in the language where you can't distinguish one > > type of T* from another, ie. pointing to a single T or to the first of > > multiple Ts. > > The language makes no such distinction. For purposes of pointer > arithmetic, an object of type T is treated as an array of type T[1]. > > I'm neither disputing nor agreeing with your statement that this > is a flaw in the language, merely explaining how it's defined. > I can see the benefit of a different kind of pointer that can point > to an object but that isn't subject to arithmetic, but I'm not sure > it's practical to add such a feature to C. > Though it's traditional to use *ptr to dereference a pointer to a single object, ptr[0] to access the first element of an array.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-15 18:40 -0700 |
| Message-ID | <b7d32272-634d-4467-882d-48e27a64ad13@googlegroups.com> |
| In reply to | #90426 |
On Saturday, July 16, 2016 at 1:26:41 AM UTC+1, Bart wrote: > > Well, I simply forgot that the array/pointer conflation that lets you > write A[i] or *(A+i), or A[0] or *A, has these other implications when > the data structure is more elaborate. > > I declare a pointer to an array, and I intend it to be a pointer to a > single array, which I expect to access as a dereference followed by an > index op. > > Yet C allows me to index this pointer with an offset i, which is already > wrong before I do anything else. But I don't find out until I run the > program, and then, if I'm lucky, it will be obviously wrong or crash. > > I think this is a flaw in the language where you can't distinguish one > type of T* from another, ie. pointing to a single T or to the first of > multiple Ts. > Yes, C's rules for multi-dimensional arrays leave a lot to be desired. You need to be able to toggle between buffers on the heap and buffers on the stack, it's quite common to need to tweak that for performance, scaling, and constrained memory scenarios. And C allows you to do that easily with one dimensional arrays, much less easily with multi- dimensional arrays. Then whilst some 2D arrays have dimensions known at compile time, it's not the usual situation. You tend to get 2D arrays in two situations. The first is when the array covers physical space, e.g. an image, or a grid of cells in a video game world. Those dimensions are usually naturally variable. The second is where you have a table of "samples" and "properties". Whilst the "properties" dimension is often fixed, often it's still essentially arbitrary (e.g. we follow a hundred subjects for a year, taking weight measurements every month. So we've got 12 "properties" and the number of subjects will vary as we filter them by various criteria. However we could just as easily follow them for 16 months.)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-15 10:09 -0700 |
| Message-ID | <e265d355-8c96-4590-b40a-f76c4f01ece7@googlegroups.com> |
| In reply to | #90402 |
On Friday, July 15, 2016 at 10:46:07 AM UTC-5, Ben Bacarisse wrote: > It's very simple to do -- just make array values decay to pointer values > and define E1[E2] in terms of pointer arithmetic. Then pretty much any > pattern of three *s or []s will give you a FooStruct. Which one, of > course, depends on what is being indexed and what is being derferenced. It's sometimes unclear, however, what forms of pointer arithmetic will or will not give defined results. The Standard is quite clear that arrays are required to be stored consecutively with no padding. Given "char arr[10][10]" that would imply that adding 1 to the address of arr[1][9] will yield the address of arr[2][0]. The Standard is also quite clear, however, that an expression like arr[1][x] cannot be used to access arr[2][0] even if x happens to be 10. It would seem that at least when a second subscript is applied, the expression "arr[1]" doesn't decay into a "real" char*, but instead into a range-restricted pointer to a character. I see nothing in the Standard, however, that really defines what operations yield an unrestricted char* and what operations yield a restricted one.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-15 11:07 -0700 |
| Message-ID | <lnh9bqwz9r.fsf@kst-u.example.com> |
| In reply to | #90407 |
supercat@casperkitty.com writes:
> On Friday, July 15, 2016 at 10:46:07 AM UTC-5, Ben Bacarisse wrote:
>> It's very simple to do -- just make array values decay to pointer values
>> and define E1[E2] in terms of pointer arithmetic. Then pretty much any
>> pattern of three *s or []s will give you a FooStruct. Which one, of
>> course, depends on what is being indexed and what is being derferenced.
>
> It's sometimes unclear, however, what forms of pointer arithmetic will or
> will not give defined results.
>
> The Standard is quite clear that arrays are required to be stored
> consecutively with no padding. Given "char arr[10][10]" that would
> imply that adding 1 to the address of arr[1][9] will yield the address
> of arr[2][0]. The Standard is also quite clear, however, that an
> expression like arr[1][x] cannot be used to access arr[2][0] even if
> x happens to be 10.
What the standard makes clear is that the behavior is undefined.
Evaluating `arr[1][10]`, for example, might very well have the
effect of accessing the same object denoted by `arr[2][0]`.
> It would seem that at least when a second subscript is applied, the
> expression "arr[1]" doesn't decay into a "real" char*, but instead
> into a range-restricted pointer to a character. I see nothing in the
> Standard, however, that really defines what operations yield an
> unrestricted char* and what operations yield a restricted one.
Probably because the standard doesn't define this in terms of
"unrestricted" vs. "restricted" pointers. What it defines is which
operations have defined behavior (and what that behavior is), and
which do not. Given a value of type char* pointing to the initial
element of an object of type char[10], adding 11 to that pointer
value has undefined behavior. The fact that that char[10] object
happens to be an element of an array object of type char[10][10]
doesn't change that.
--
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 13 of 18 — ← Prev page 1 … 11 12 [13] 14 15 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web