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 14 of 18 — ← Prev page 1 … 12 13 [14] 15 16 … 18 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-15 12:11 -0700 |
| Message-ID | <20b352c3-5b7a-4c33-8e80-76e654896af8@googlegroups.com> |
| In reply to | #90408 |
On Friday, July 15, 2016 at 1:07:52 PM UTC-5, Keith Thompson wrote:
> 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.
Consider:
union uu {
unsigned char a[10][10];
unsigned char b[100];
} u;
If x and y are in the range 0..9, I see no way that a write of u.a[x][y]
followed by a read of u.b[x*10+y] could do anything other than yield the
value just written.
In the expression u.a[0][i], to what type does u.a[0] decay?
In the expression u.b[i], to what type does u.b decay?
It would seem that (union uu*)(u.a[0])->b[i] should be defined for all
i in the range 0..99. I'm unclear, however, which of the following
lines would not be equivalent to the previous one.
(union uu*)(u.a[0])->b[i]
( (unsigned char*)(union uu*)(u.a[0]) )[i]
( (unsigned char*)(u.a[0]) )[i]
( (u.a[0]) )[i]
Since the first is defined for i=0..99 and the last only for i=0..9, it
would seem there must be some difference; I think the most logical
explanation for the difference would be that while a[0] nominally decays
to a some kind of character pointer, it won't be usable as a full-fledged
"unsigned char*" unless one performs some kind of cast upon it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-15 12:30 -0700 |
| Message-ID | <lnd1mewvgb.fsf@kst-u.example.com> |
| In reply to | #90410 |
supercat@casperkitty.com writes:
> On Friday, July 15, 2016 at 1:07:52 PM UTC-5, Keith Thompson wrote:
>> 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.
>
> Consider:
>
> union uu {
> unsigned char a[10][10];
> unsigned char b[100];
> } u;
>
> If x and y are in the range 0..9, I see no way that a write of u.a[x][y]
> followed by a read of u.b[x*10+y] could do anything other than yield the
> value just written.
Nor do I. N1570 6.5.2.3, footnote 95:
If the member used to read the contents of a union object is
not the same as the member last used to store a value in the
object, the appropriate part of the object representation of
the value is reinterpreted as an object representation in the
new type as described in 6.2.6 (a process sometimes called
"type punning"). This might be a trap representation.
The standard says enough about array representation to indicate that,
unless I'm missing something, it should reliably work as you describe.
> In the expression u.a[0][i], to what type does u.a[0] decay?
unsigned char*
> In the expression u.b[i], to what type does u.b decay?
unsigned char*
> It would seem that (union uu*)(u.a[0])->b[i] should be defined for all
> i in the range 0..99.
Now you're casting an unsigned char* pointer to type `union uu*`. N1570
6.7.2.1 guarantees that
A pointer to a union object, suitably converted, points to each
of its members (or if a member is a bitfield, then to the unit
in which it resides), and vice versa.
but that's not *quite* what you're doing here. The pointer value being
converted is to the 0th element of one of the union's members, not to
the member itself. I'm not confident that this is defined. On the
other hand, you're treating objects as arrays of unsigned char, and
there are some special guarantees for that. Using arrays of int or some
other non-character type might make the examples clearer.
> I'm unclear, however, which of the following
> lines would not be equivalent to the previous one.
>
> (union uu*)(u.a[0])->b[i]
> ( (unsigned char*)(union uu*)(u.a[0]) )[i]
> ( (unsigned char*)(u.a[0]) )[i]
> ( (u.a[0]) )[i]
>
> Since the first is defined for i=0..99 and the last only for i=0..9, it
> would seem there must be some difference; I think the most logical
> explanation for the difference would be that while a[0] nominally decays
> to a some kind of character pointer, it won't be usable as a full-fledged
> "unsigned char*" unless one performs some kind of cast upon it.
I'm not sure what a "full-fledged unsigned char*" is supposed to be.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-15 12:41 -0700 |
| Message-ID | <29e420f3-061b-4803-bb66-dcad76f9938c@googlegroups.com> |
| In reply to | #90411 |
On Friday, July 15, 2016 at 2:30:23 PM UTC-5, Keith Thompson wrote: > supercat writes: > The standard says enough about array representation to indicate that, > unless I'm missing something, it should reliably work as you describe. > > > In the expression u.a[0][i], to what type does u.a[0] decay? > > unsigned char* > > > In the expression u.b[i], to what type does u.b decay? > > unsigned char* > > > It would seem that (union uu*)(u.a[0])->b[i] should be defined for all > > i in the range 0..99. > > Now you're casting an unsigned char* pointer to type `union uu*`. N1570 > 6.7.2.1 guarantees that > > A pointer to a union object, suitably converted, points to each > of its members (or if a member is a bitfield, then to the unit > in which it resides), and vice versa. > > but that's not *quite* what you're doing here. The pointer value being > converted is to the 0th element of one of the union's members, not to > the member itself. I'm not confident that this is defined. On the > other hand, you're treating objects as arrays of unsigned char, and > there are some special guarantees for that. Using arrays of int or some > other non-character type might make the examples clearer. Even with non-character types, the address of an array is the address of its first element, is it not? > > I'm unclear, however, which of the following > > lines would not be equivalent to the previous one. > > > > (union uu*)(u.a[0])->b[i] > > ( (unsigned char*)(union uu*)(u.a[0]) )[i] > > ( (unsigned char*)(u.a[0]) )[i] > > ( (u.a[0]) )[i] > > > > Since the first is defined for i=0..99 and the last only for i=0..9, it > > would seem there must be some difference; I think the most logical > > explanation for the difference would be that while a[0] nominally decays > > to a some kind of character pointer, it won't be usable as a full-fledged > > "unsigned char*" unless one performs some kind of cast upon it. > > I'm not sure what a "full-fledged unsigned char*" is supposed to be. The expression u.a[0][i] is defined for a smaller range of types than u.b[i]; that would seem to imply that there is something different from u.a[0] and u.b, but I'm not clear what kinds of pointer expressions a compiler could treat like the former, and what kinds of pointer expressions a compiler could treat like the latter.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-15 13:04 -0700 |
| Message-ID | <ln8tx2wtvb.fsf@kst-u.example.com> |
| In reply to | #90412 |
supercat@casperkitty.com writes:
> On Friday, July 15, 2016 at 2:30:23 PM UTC-5, Keith Thompson wrote:
>> supercat writes:
>> The standard says enough about array representation to indicate that,
>> unless I'm missing something, it should reliably work as you describe.
>>
>> > In the expression u.a[0][i], to what type does u.a[0] decay?
>>
>> unsigned char*
>>
>> > In the expression u.b[i], to what type does u.b decay?
>>
>> unsigned char*
>>
>> > It would seem that (union uu*)(u.a[0])->b[i] should be defined for all
>> > i in the range 0..99.
>>
>> Now you're casting an unsigned char* pointer to type `union uu*`. N1570
>> 6.7.2.1 guarantees that
>>
>> A pointer to a union object, suitably converted, points to each
>> of its members (or if a member is a bitfield, then to the unit
>> in which it resides), and vice versa.
>>
>> but that's not *quite* what you're doing here. The pointer value being
>> converted is to the 0th element of one of the union's members, not to
>> the member itself. I'm not confident that this is defined. On the
>> other hand, you're treating objects as arrays of unsigned char, and
>> there are some special guarantees for that. Using arrays of int or some
>> other non-character type might make the examples clearer.
>
> Even with non-character types, the address of an array is the address of
> its first element, is it not?
No, they're of different types. They should yield the same value when
suitable converted to the same pointer type (I don't have the chapter
and verse that guarantees that).
>> > I'm unclear, however, which of the following
>> > lines would not be equivalent to the previous one.
>> >
>> > (union uu*)(u.a[0])->b[i]
>> > ( (unsigned char*)(union uu*)(u.a[0]) )[i]
>> > ( (unsigned char*)(u.a[0]) )[i]
>> > ( (u.a[0]) )[i]
>> >
>> > Since the first is defined for i=0..99 and the last only for i=0..9, it
>> > would seem there must be some difference; I think the most logical
>> > explanation for the difference would be that while a[0] nominally decays
>> > to a some kind of character pointer, it won't be usable as a full-fledged
>> > "unsigned char*" unless one performs some kind of cast upon it.
>>
>> I'm not sure what a "full-fledged unsigned char*" is supposed to be.
>
> The expression u.a[0][i] is defined for a smaller range of types than
> u.b[i]; that would seem to imply that there is something different from
> u.a[0] and u.b, but I'm not clear what kinds of pointer expressions a
> compiler could treat like the former, and what kinds of pointer expressions
> a compiler could treat like the latter.
Do you mean a smaller range of *values*?
Here's the relevent code again:
union uu {
unsigned char a[10][10];
unsigned char b[100];
} u;
The difference is that `u.a[0]` is of type `unsigned char[10]`, and
`u.b` is of type `unsigned char[100]`. Both decay to `unsigned char*`,
but the range of integer values you can add to that pointer value
differs, for reasons explained in N1570 6.5.6p8.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-15 14:26 -0700 |
| Message-ID | <f7dd8766-d610-44b1-b35a-a41bc3154a00@googlegroups.com> |
| In reply to | #90413 |
On Friday, July 15, 2016 at 3:04:32 PM UTC-5, Keith Thompson wrote:
> supercat writes:
> > The expression u.a[0][i] is defined for a smaller range of types than
> > u.b[i]; that would seem to imply that there is something different from
> > u.a[0] and u.b, but I'm not clear what kinds of pointer expressions a
> > compiler could treat like the former, and what kinds of pointer expressions
> > a compiler could treat like the latter.
>
> Do you mean a smaller range of *values*?
Yes.
> Here's the relevent code again:
>
> union uu {
> unsigned char a[10][10];
> unsigned char b[100];
> } u;
>
> The difference is that `u.a[0]` is of type `unsigned char[10]`, and
> `u.b` is of type `unsigned char[100]`. Both decay to `unsigned char*`,
> but the range of integer values you can add to that pointer value
> differs, for reasons explained in N1570 6.5.6p8.
If the Standard specified that arrays which are arguments to
address-arithmetic or subscripting operators do not decay, but instead
have semantics defined specifically for those types, that would clearly
establish that u.a[0][i] can only access the first ten elements of the
array, but (int*)(u.a[0])[i] would be able to access any element of the
array, since the former operation would be using address arithmetic
operator on an array type, while the latter would be using it on a pointer.
I don't think the Standard actually says anything like that, though, which
raises a question of what one must do to convert the address of u.a[0][0]
into an int* which can be used in a fashion equivalent to the address of
u.b[0].
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-19 10:00 -0700 |
| Message-ID | <kfn7fchwok4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90412 |
supercat@casperkitty.com writes: > On Friday, July 15, 2016 at 2:30:23 PM UTC-5, Keith Thompson wrote: >> supercat writes: >> The standard says enough about array representation to indicate that, >> unless I'm missing something, it should reliably work as you describe. >> >>> In the expression u.a[0][i], to what type does u.a[0] decay? >> >> unsigned char* >> >>> In the expression u.b[i], to what type does u.b decay? >> >> unsigned char* >> >>> It would seem that (union uu*)(u.a[0])->b[i] should be defined for all >>> i in the range 0..99. >> >> Now you're casting an unsigned char* pointer to type `union uu*`. N1570 >> 6.7.2.1 guarantees that >> >> A pointer to a union object, suitably converted, points to each >> of its members (or if a member is a bitfield, then to the unit >> in which it resides), and vice versa. >> >> but that's not *quite* what you're doing here. The pointer value being >> converted is to the 0th element of one of the union's members, not to >> the member itself. I'm not confident that this is defined. On the >> other hand, you're treating objects as arrays of unsigned char, and >> there are some special guarantees for that. Using arrays of int or some >> other non-character type might make the examples clearer. > > Even with non-character types, the address of an array is the address of > its first element, is it not? > >>> I'm unclear, however, which of the following >>> lines would not be equivalent to the previous one. >>> >>> (union uu*)(u.a[0])->b[i] >>> ( (unsigned char*)(union uu*)(u.a[0]) )[i] >>> ( (unsigned char*)(u.a[0]) )[i] >>> ( (u.a[0]) )[i] >>> >>> Since the first is defined for i=0..99 and the last only for i=0..9, it >>> would seem there must be some difference; I think the most logical >>> explanation for the difference would be that while a[0] nominally decays >>> to a some kind of character pointer, it won't be usable as a full-fledged >>> "unsigned char*" unless one performs some kind of cast upon it. >> >> I'm not sure what a "full-fledged unsigned char*" is supposed to be. > > The expression u.a[0][i] is defined for a smaller range of types than > u.b[i]; that would seem to imply that there is something different from > u.a[0] and u.b, but I'm not clear what kinds of pointer expressions a > compiler could treat like the former, and what kinds of pointer expressions > a compiler could treat like the latter. Nor will you be, because your goal is not to understand how the behavior /is/ defined, but to convince other people how the behavior /should be/ defined. As long as you confuse these two concerns, I think you should expect that you won't make much progress on either one.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-13 12:46 +0100 |
| Message-ID | <87wpkpsqug.fsf@bsb.me.uk> |
| In reply to | #90314 |
BartC <bc@freeuk.com> writes: > On 13/07/2016 08:23, Malcolm McLean wrote: <snip> >> Bart makes the point too strongly. <snip> > It's exaggerating to make the point that /you/ brought up: > >>> int *array = malloc(10 * sizeof *array); > >>Gibberish. >>malloc ten times sizeof times array? Ten times the size of the array? > > The sizeof*array bit has exactly the same syntactic shape as any > identifier*array. The extra space they've put in doesn't help as you > learn to ignore odd spacing in C especially inside expressions. If you are in the position of seeing code with erratic and unhelpful spacing, you will have to do that, but I don't let that stick with me. I try to write code using helpful layout and I enjoy reading code written by people who use layout in a helpful way. > (And the fact that some people think an extra space might be necessary > suggests that there /could/ be a problem.) > > Perhaps I should have used a simpler example: > > size * sizeof * array * depth > > The brain can't help seeing patterns and the dominant one here is of > four things multiplied together (before the deeper understanding kicks > in when it recognises that sizeof is special). I suppose brains differ. Mine sees a sizeof operator there and a badly placed *. I see the words not the pattern, so 'array' is either a terrible name for a numeric quantity or that * is a dereference. Obviously this is, in part, because I've seen a lot of C, so sizeof is like while and switch to me. Equally, I would not be baffled by a language that had expressions like sqrt *p * sin *q because the words carry a strong meaning. I'd still use the spacing to stress the relationship between the operations but even without it I would not think that sqrt is being multiplied by p. > All I'm saying is that it was a lousy design choice in C to have a > dereference operator "*" that can't always be cleanly distinguished > (ie. at first glance) from the identical "*" multiply > operator. sizeof*p being one example, another is a**b (and yet another > is t*u when t is a type and "*" is now a pointer-to indicator.) I hope you can see that all I am saying is that this is a micro-problem that vanishes into then noise compared with the real problems program have. This is largely because it is so easy to make the code much clearer: size * depth * sizeof array[0] would be my preference. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-13 13:19 +0100 |
| Message-ID | <nm5bjt$8cs$1@dont-email.me> |
| In reply to | #90320 |
On 13/07/2016 12:46, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> size * sizeof * array * depth
>>
>> The brain can't help seeing patterns and the dominant one here is of
>> four things multiplied together
> I suppose brains differ. Mine sees a sizeof operator there and a badly
> placed *. I see the words not the pattern, so 'array' is either a
> terrible name for a numeric quantity or that * is a dereference.
>
> Obviously this is, in part, because I've seen a lot of C, so sizeof is
> like while and switch to me. Equally, I would not be baffled by a
> language that had expressions like
>
> sqrt *p * sin *q
>
> because the words carry a strong meaning. I'd still use the spacing to
> stress the relationship between the operations but even without it I
> would not think that sqrt is being multiplied by p.
I could cope with your example but in my hands it would be written as:
sqrt(*p) * sin(*q)
just to emphasise its proper structure (and so that it takes 200msec
less to grok it).
(This is not just about the dual purpose of the * making it potentially
most confusing; I would also write:
sqrt(p) * sin(q)
rather than
sqrt p * sin q
as I think using "()" is a visually stronger way of highlighting
structure along a line than just using white space which after all has
little significance.)
>> All I'm saying is that ...
> I hope you can see that all I am saying is that this is a micro-problem
> that vanishes into then noise compared with the real problems program
> have.
These micro-problems can all add up to become a significant distraction
when trying to get actual work done.
Yes you can get around them, when you have control of the code, by
sticking to particular styles and guidelines. Except other people may
not use the same guidelines.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-13 13:30 +0100 |
| Message-ID | <nm5ca5$adk$1@dont-email.me> |
| In reply to | #90321 |
On 13/07/2016 13:19, BartC wrote: > (This is not just about the dual purpose of the * making it potentially > most confusing 'more' confusing not 'most'. (Or perhaps I subconsciously thought differently!)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-13 20:53 +0100 |
| Message-ID | <87furds4ae.fsf@bsb.me.uk> |
| In reply to | #90321 |
BartC <bc@freeuk.com> writes: > On 13/07/2016 12:46, Ben Bacarisse wrote: <snip> >> I hope you can see that all I am saying is that this is a micro-problem >> that vanishes into then noise compared with the real problems program >> have. > > These micro-problems can all add up to become a significant > distraction when trying to get actual work done. (Malcolm makes the same point somewhere else as well but this thread is long enough already so I'll answer once...) I find this really baffling. I've never felt that this sort of issue has any significant effect on getting work done, even when a thousand of these tiny wrinkles get piled up together. The vast majority of programming effort goes in design and planning, and, when programming in C, designing ways round C's real semantic limitations. I wonder how many million programmer hours have been sunk into re-implementing things like strings, lists, trees, arrays and so on. And then there are the missing larger structural issues that have to be worked round -- name spaces, modules, higher-order functions, exceptions (or error signalling in general). The list goes on and on. (I'm not suggesting you always need all of these, or that they are all universally "good things", but solutions to the problems for which these things have been proposed as solutions do need to be found.) You complain about the two meanings of *, yet in C you can't even return two values from a function without some absurdly heavyweight machinery. It just seems completely off-kilter. My use of micro-problem was intended to mean insignificant even in quantity, which might, I suppose, reflect some unusual facility I have in reading syntax. Or maybe other people are so much better at solving what I see as the big problems in programming that these matters, small as they are to me, loom large. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-13 21:37 +0100 |
| Message-ID | <nm68pu$mci$1@dont-email.me> |
| In reply to | #90344 |
On 13/07/2016 20:53, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> These micro-problems can all add up to become a significant
>> distraction when trying to get actual work done.
>
> (Malcolm makes the same point somewhere else as well but this thread is
> long enough already so I'll answer once...)
>
> I find this really baffling. I've never felt that this sort of issue
> has any significant effect on getting work done, even when a thousand of
> these tiny wrinkles get piled up together. The vast majority of
> programming effort goes in design and planning, and, when programming in
> C, designing ways round C's real semantic limitations. I wonder how
> many million programmer hours have been sunk into re-implementing things
> like strings, lists, trees, arrays and so on. And then there are the
> missing larger structural issues that have to be worked round -- name
> spaces, modules, higher-order functions, exceptions (or error signalling
> in general). The list goes on and on. (I'm not suggesting you always
> need all of these, or that they are all universally "good things", but
> solutions to the problems for which these things have been proposed as
> solutions do need to be found.)
> You complain about the two meanings of *, yet in C you can't even return
> two values from a function without some absurdly heavyweight machinery.
> It just seems completely off-kilter. My use of micro-problem was
> intended to mean insignificant even in quantity, which might, I suppose,
> reflect some unusual facility I have in reading syntax. Or maybe other
> people are so much better at solving what I see as the big problems in
> programming that these matters, small as they are to me, loom large.
I'm not concerned with those higher level concerns. Only with using a
language at the same level as C is, then those mechanical details of
syntax and so on become important.
You seem to be saying there's no point in complaining about the
crudeness of a bicycle because we should all be driving cars whenever
possible.
But there's a lot that could be done - and has been done - to make bikes
much easier and more comfortable to ride!
Taking a leaf of your book however, how much time is wasted, by those
not quite as expert as you, by trying to figure out the exact form of a
'pointer to function taking two ints returning a pointer to int' type in
C, when I can just write:
ref function (int,int)=>ref int
Or the amount of times you have to do something like extracting bit 4 of
an int by writing:
(a>>4)&1 // or !!(a & (1<<4)) etc etc
when I can just write:
a.[4]
(and without having to create my own customised version of a language
via macros either).
Etc.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-13 05:22 -0700 |
| Message-ID | <2723388b-9561-428b-860c-3720dee3d59a@googlegroups.com> |
| In reply to | #90320 |
On Wednesday, July 13, 2016 at 12:46:41 PM UTC+1, Ben Bacarisse wrote: > > I hope you can see that all I am saying is that this is a micro-problem > that vanishes into then noise compared with the real problems program > have. This is largely because it is so easy to make the code much > clearer: > > size * depth * sizeof array[0] > array is probably an uninitialised pointer, and you are taking the first element. Confusing. There's also the C quirk that. size * depth * (sizeof array)["size"] is actually compileable and well defined, assuming pointers to be 4 bytes. This is all micro-problem stuff. However these sorts of micro-problems have cumulative effects.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-13 07:07 -0700 |
| Message-ID | <c12f846d-c679-4534-95d6-689491d322de@googlegroups.com> |
| In reply to | #90314 |
On Wednesday, July 13, 2016 at 5:17:56 AM UTC-5, Bart wrote: > All I'm saying is that it was a lousy design choice in C to have a > dereference operator "*" that can't always be cleanly distinguished (ie. > at first glance) from the identical "*" multiply operator. sizeof*p > being one example, another is a**b (and yet another is t*u when t is a > type and "*" is now a pointer-to indicator.) My objection to C's design is that the dereferencing operator acts as a prefix rather than a suffix, which can lead to ambiguity with associativity. In Pascal, the expression Foo^^.Bar dereferences Foo twice and then accesses member `.Bar` of the resulting structure. In C, the corresponding expression would need to be either (**Foo).Bar or (*Foo)->Bar. Note that Pascal uses a reserved word for the xor operator, leaving ^ as a symbol for indirection separate from the symbol for multiplication [since a dereferencing suffix which overloaded that operator could lead to syntactic ambiguity in expressions like x*+1 unless the parser knew that x was a pointer type]. BTW, Pascal also uses a reserved word for integer division, so an expression like Int1/Int2 uses a floating-point division while Int1 div Int2 uses integer division.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-14 19:31 +0100 |
| Message-ID | <nm8lq2$6kc$1@dont-email.me> |
| In reply to | #90327 |
On 14/07/2016 18:48, Stefan Ram wrote: > supercat@casperkitty.com writes: >> My objection to C's design is that the dereferencing operator acts >> as a prefix rather than a suffix > > No, it's a suffix. > > For example, given that > > p > > is the address of an object, then > > p[0] > > is the object itself with the dereferencing > operator »[0]«, where the »0« stands for »0bject«. > >> associativity. In Pascal, the expression Foo^^.Bar dereferences Foo >> twice and then accesses member `.Bar` of the resulting structure. > > p[0][0].m Interesting. But it doesn't work here: int (*array)[]; int a,i; a=array[0][i]; unless array is declared as int (*array)[0]. However, here you now have a pointer to array (which needs to be incorrectly given a length of zero instead of unspecified), but the access apparently involves two index operations instead of a pointer operation followed by an indexing one. Very confusing to the reader. (A language with a 'proper' postfix dereference op would do it like this: ref[]int array int a,i a := array^[i] Now the declaration and the access code coincide. And the array stays unbounded.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-14 12:10 -0700 |
| Message-ID | <661e5552-6dc1-4928-953b-d9ff3b6216ec@googlegroups.com> |
| In reply to | #90369 |
On Thursday, July 14, 2016 at 1:31:39 PM UTC-5, Bart wrote:
> (A language with a 'proper' postfix dereference op would do it like this:
>
> ref[]int array
> int a,i
>
> a := array^[i]
>
> Now the declaration and the access code coincide. And the array stays
> unbounded.)
In 1980s Pascal dialects, if one wants an array of integers:
Var arr: Array[0..99] of Integer;
If one wants an array of instances of structure FooStruct:
Var arr: Array[0..99] of FooStruct;
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;
I'm not positive, but I think some dialects of Pascal allowed the array
dimension to be omitted when declaring pointers to array types (in which
case there would be no range checking) but if would use the specified
dimensions for range checking when they were supplied and range checking
was enabled.
A strict Pascal compiler given
Var arr1: Array[0..9] of Integer;
Var arr2: Array[0..9] of Integer;
would not regard arr1 and arr2 has having compatible types, but would
require that the code be written as:
type ArrayOfInt = Array[0..9] of Integer;
Var arr1: ArrayOfInt;
Var arr2: ArrayOfInt;
but 1980s dialects would regard types as compatible of they were
structurally equivalent without requiring an explicit type declaration.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-14 23:16 +0100 |
| Message-ID | <nm92vl$s53$1@dont-email.me> |
| In reply to | #90371 |
On 14/07/2016 20:10, supercat@casperkitty.com wrote: > On Thursday, July 14, 2016 at 1:31:39 PM UTC-5, Bart wrote: >> (A language with a 'proper' postfix dereference op would do it like this: >> >> ref[]int array >> int a,i >> >> a := array^[i] >> >> Now the declaration and the access code coincide. And the array stays >> unbounded.) > > In 1980s Pascal dialects, if one wants an array of integers: > > Var arr: Array[0..99] of Integer; > > If one wants an array of instances of structure FooStruct: > > Var arr: Array[0..99] of FooStruct; > > 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; Yes, it's a delight having a sane type declaration syntax! (Exercise for those new to C: convert the last two examples into C equivalents.) > I'm not positive, but I think some dialects of Pascal allowed the array > dimension to be omitted when declaring pointers to array types With the only dialect I used, an array's bounds were intimately tied to the type. You couldn't have a pointer to an unbounded array, which severely restricted Pascal's usefulness for real code. (So a function taking an Array of Int would need separate versions for each possible array length. And all possible lengths would need to be known at compile-time. The same with strings.) Obviously someone must have had the sense to produce tweaked versions for real-world use rather than education. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-14 16:00 -0700 |
| Message-ID | <abfe0e4c-a816-452c-89af-51fd947f1d17@googlegroups.com> |
| In reply to | #90377 |
On Thursday, July 14, 2016 at 5:16:29 PM UTC-5, Bart wrote:
> On 14/07/2016 20:10, supercat wrote:
> > I'm not positive, but I think some dialects of Pascal allowed the array
> > dimension to be omitted when declaring pointers to array types
>
> With the only dialect I used, an array's bounds were intimately tied to
> the type. You couldn't have a pointer to an unbounded array, which
> severely restricted Pascal's usefulness for real code.
>
> (So a function taking an Array of Int would need separate versions for
> each possible array length. And all possible lengths would need to be
> known at compile-time. The same with strings.)
Turbo Pascal on the PC or CP/M systems, and both Think Pascal and MPW
Pascal on the Macintosh both made it possible to allocate a block of
memory of arbitrary size and cast the resulting pointer to an arbitrary
pointer type. Thus, at minimum, one would be able to do things like (I
forget the exact syntax)
Type
CountedArray = Structure
Length : Word;
Dat : Array[0..32767] of Byte;
End;
CountedArrayPtr = ^CountedArray;
Procedure PrintCountedArray(TheArray: CountedArrayPtr)
Var
I: Word;
P: CountedArrayPtr;
Begin
P := @TheArray;
For I:=0 to P^.Length-1 do
WriteLn(P^.dat[i]);
End;
All of the aforementioned Pascal dialects would allow pointers to structures
that were like CountedArray but differed in size to be handled by the above
function if they were cast to CountedArray. Array bounds checking wouldn't
be useful, of course, but the code would work if it didn't need to go beyond
the declared bounds of CountedArray. Of course, nearly all C microcomputer
C dialects of that era (I know of no exceptions) also made it possible to do
such things, but such an extension of the Common Initial Sequence rule is no
longer fashionable; indeed, modern compilers' treatment of the rule renders
it essentially useless.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-14 12:34 -0700 |
| Message-ID | <lntwfsvws4.fsf@kst-u.example.com> |
| In reply to | #90369 |
BartC <bc@freeuk.com> writes:
> On 14/07/2016 18:48, Stefan Ram wrote:
>> supercat@casperkitty.com writes:
>>> My objection to C's design is that the dereferencing operator acts
>>> as a prefix rather than a suffix
>>
>> No, it's a suffix.
>>
>> For example, given that
>>
>> p
>>
>> is the address of an object, then
>>
>> p[0]
>>
>> is the object itself with the dereferencing
>> operator »[0]«, where the »0« stands for »0bject«.
>>
>>> associativity. In Pascal, the expression Foo^^.Bar dereferences Foo
>>> twice and then accesses member `.Bar` of the resulting structure.
>>
>> p[0][0].m
Yes, `p[0]` is equivalent to `*p` -- but it's hardly idiomatic to use
postfix `[0]` as a dereference operator, at least for pointers that
don't necessily point to the initial element of an array object. It
might not be a bad idea, but I don't think I'd use it myself.
> Interesting. But it doesn't work here:
>
> int (*array)[];
> int a,i;
>
> a=array[0][i];
So you defined a pointer to an incomplete array type. You can't
use the prefix `*` dereference operator on it either.
> unless array is declared as int (*array)[0].
That's invalid. C doesn't permit zero-length arrays. (Some compilers,
for example gcc, may permit them as an extension).
[...]
--
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-14 20:57 +0100 |
| Message-ID | <nm8qqs$qdp$1@dont-email.me> |
| In reply to | #90372 |
On 14/07/2016 20:34, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> Interesting. But it doesn't work here: >> >> int (*array)[]; >> int a,i; >> >> a=array[0][i]; > > So you defined a pointer to an incomplete array type. You can't > use the prefix `*` dereference operator on it either. It seems to work (with *) on the six compilers I tried (with warnings and extra warnings shown). Why shouldn't it work? And how /should/ I index such an array? (Ie. pointer to an array of unknown length as might be used for a dynamic array or passed to a function.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-14 13:15 -0700 |
| Message-ID | <lnpoqgvuvs.fsf@kst-u.example.com> |
| In reply to | #90373 |
BartC <bc@freeuk.com> writes:
> On 14/07/2016 20:34, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> Interesting. But it doesn't work here:
>>>
>>> int (*array)[];
>>> int a,i;
>>>
>>> a=array[0][i];
>>
>> So you defined a pointer to an incomplete array type. You can't
>> use the prefix `*` dereference operator on it either.
>
> It seems to work (with *) on the six compilers I tried (with warnings
> and extra warnings shown).
>
> Why shouldn't it work? And how /should/ I index such an array? (Ie.
> pointer to an array of unknown length as might be used for a dynamic
> array or passed to a function.)
I was mistaken. (I rarely use incomplete array types.)
Here's a complete example:
#include <stdio.h>
int main(void) {
int (*array_ptr)[];
int arr[5] = { 10, 20, 30, 40, 50 };
array_ptr = &arr;
int elem = (*array_ptr)[0];
printf("elem = %d\n", elem);
}
The output:
elem = 10
array_ptr is of type "array of int", where the array has unspecified
bounds. It decays to "pointer to array of int". We don't need the
bounds to be able to index it.
But if we change:
int elem = (*array_ptr)[0];
to:
int elem = (array_ptr[0])[0];
it fails to compile; gcc says:
c.c: In function ‘main’:
c.c:7:9: error: invalid use of array with unspecified bounds
int elem = (array_ptr[0])[0];
^~~
`array_ptr[0]` is by definition equivalent to `(*array_ptr + 0)`.
Since we don't know the size of the pointed-to object, we can't
perform arithmetic on the pointer (not even adding 0).
So `*p` and `p[0]` are not equivalent in all cases.
--
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 14 of 18 — ← Prev page 1 … 12 13 [14] 15 16 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web