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 9 of 18 — ← Prev page 1 … 7 8 [9] 10 11 … 18 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-23 11:11 +0100 |
| Message-ID | <87a8h8acl8.fsf@bsb.me.uk> |
| In reply to | #90835 |
BartC <bc@freeuk.com> writes: <snip> > ... And, while there might be a reason why &, ^ and | need to > be all different (which I can't think of), there /isn't/ a good one > why they all have to be lower than == and <=. (Which means that if > (a&b != 0x800) doesn't do what you think.) By the way, I hope you know *why* this is the case in C and that the language designers agree with you on this point. Oddly, it is, in part, in honour of your notion of "cut and paste" portability between languages. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-23 12:39 -0700 |
| Message-ID | <ln1t2kgn3l.fsf@kst-u.example.com> |
| In reply to | #90831 |
raltbos@xs4all.nl (Richard Bos) writes:
> Keith Thompson <kst-u@mib.org> wrote:
[...]
>> Do you know of a language that has a "<<" operator similar to C's, in
>> which the relative precedence of "<<" and "+" differs from C's?
>
> No, but I know of at least one in which << has a different meaning from
> C's.
I'm curious what language you're referring to. (If you mean C++'s
use of << as an output operator, that's an overload implemented in
the library; the built-in << and >> operators still have the same
meaning as in C.)
I remember the first time I opened my new copy of K&R1 and saw
that it had << and >> operators. I had seen similar notation
in mathematics, and I wondered about the semantics of C's
"much-less-than" and "much-greater-than" operators.
--
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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-07-23 20:25 +0000 |
| Message-ID | <5793d0ca.4963453@news.xs4all.nl> |
| In reply to | #90862 |
Keith Thompson <kst-u@mib.org> wrote: > raltbos@xs4all.nl (Richard Bos) writes: > > Keith Thompson <kst-u@mib.org> wrote: > [...] > >> Do you know of a language that has a "<<" operator similar to C's, in > >> which the relative precedence of "<<" and "+" differs from C's? > > > > No, but I know of at least one in which << has a different meaning from > > C's. > > I'm curious what language you're referring to. Icon. << means lexical comparison of strings. There is no shift operator. > I remember the first time I opened my new copy of K&R1 and saw > that it had << and >> operators. I had seen similar notation > in mathematics, and I wondered about the semantics of C's > "much-less-than" and "much-greater-than" operators. I'm sure it would be possible to create a mathematically-inclined language in which << means a more strict kind of inequality than < for, e.g., complex numbers or Hamiltonians, or even sets. Richard
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-22 12:51 -0700 |
| Message-ID | <73518d2c-8b0c-4c15-a9ec-bbbd54f47abd@googlegroups.com> |
| In reply to | #90805 |
On Friday, July 22, 2016 at 7:48:12 PM UTC+1, Bart wrote: > > If you lift a fragment of code, or transcribe it to a different > language, then you will have an easier time if it's like this: > > a << (b + c) > > than like this: > > a << b + c // which means the same as above in C > > because outside of C, '<<' may have a different precedence. > Exactly. Twenty years ago you could say "C is the only high level language of any significance in common use, and every programmer can be assumed to know it perfectly". But that's no longer true.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-22 13:18 -0700 |
| Message-ID | <aa907b9f-cc57-4234-ad5d-e148f5f93102@googlegroups.com> |
| In reply to | #90814 |
On Friday, July 22, 2016 at 2:51:08 PM UTC-5, Malcolm McLean wrote: > Twenty years ago you could say "C is the only high level language of > any significance in common use, and every programmer can be assumed > to know it perfectly". But that's no longer true. Pascal was on the way out by 1996, but throughout the 1980s and into the 1990s it had a really good run on both the PC and the Macintosh. It's ironic that it was displaced largely because C compilers of the day could better support pointer-related techniques that some people claim were never defined, and for which support has become unfashionable in some circles.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-24 08:23 -0700 |
| Message-ID | <kfnpoq3rret.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90733 |
BartC <bc@freeuk.com> writes: > On 21/07/2016 17:26, Tim Rentsch wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 18/07/2016 18:01, Tim Rentsch wrote: >>>> BartC <bc@freeuk.com> writes: >>>> >>>>> Are you suggesting that every C programmer ought to know the >>>>> precedence levels of all ten binary operators? >>>> >>>> I would. And do. And happy to do it. If you can't take >>>> the heat, stay out of the kitchen. >>> >>> So you don't care that other people may have trouble reading or >>> maintaining your code? >> >> Broadly speaking there are two kinds of questions asked in >> usenet newgroups: those looking for an answer, and those >> looking for an argument. This question is a good example >> of the second kind. > > So you don't care. I didn't say that. You said that. My comment didn't say anything about how to write expressions, only that C programmers should know the precedence rules. Obviously you are determined to pick a fight despite my efforts to avoid one, and put words in my mouth to do so. That makes you, well, kind of an asshole.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-24 19:36 +0100 |
| Message-ID | <nn31ql$1e0$1@dont-email.me> |
| In reply to | #90902 |
On 24/07/2016 16:23, Tim Rentsch wrote: > BartC <bc@freeuk.com> writes: >> So you don't care. > > I didn't say that. You said that. My comment didn't say > anything about how to write expressions, only that C programmers > should know the precedence rules. And yet you still refuse to clarify a simple point. You say (about precedence levels): "Only that they ought to know them, and by implication that they should learn if they don't." Does that mean that extraneous parentheses should be used to make code more obvious, or not? It sounds to me that 'Not' follows logically from your comment. But I don't actually know whether you care about the readability of your code, or whether you recommend parentheses to make code clearer. I suspect you won't comment because it means conceding a point. Or admitting that your attitude is elitist. Meanwhile /I/ will continue to write (a|b)^c or a|(b^c) and be sure that everyone knows which operation is done first whether or not they've done their homework on obscure C precedence levels. > Obviously you are determined > to pick a fight despite my efforts to avoid one, and put words > in my mouth to do so. You've had plenty of opportunity to put words into your own mouth! > That makes you, well, kind of an asshole. OK, well, I can revise my own opinion of you too... -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-12-02 10:21 +0100 |
| Message-ID | <o1ree2$7sk$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #90266 |
In article <87shvfyrq6.fsf@bsb.me.uk>, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >BartC <bc@freeuk.com> writes: > >> On 12/07/2016 11:24, Ben Bacarisse wrote: >>> Udyant Wig <udyant.wig@gmail.com> writes: >> >>>> But "sizeof()" really *is* a function. It acts exactly like a function >>>> of it's argument. There is no reason to not treat it that way. Sure, the >>>> C standard *allows* you to not have parenthesis around an expression >>>> argument, but you should treat that as the parsing oddity it is, nothing >>>> more. There is zero reason not to have the parenthesis there. >>> >>> No one ever made a splash by being moderate! >>> >>> It's true that sizeof acts like a mathematical function -- albeit one >>> with a very peculiar domain (pieces of C syntax) -- but it does not act >>> like a C function. Adding ()s will make it look like a C function and >>> that is as likely to look as odd to some as leaving it looking like an >>> operator will look odd to others. >> >> It will also look like a C macro invocation, which are used >> everywhere. > >I don't see what your point is. Just writing an identifier can look like >a macro invocation. That's why is usual to recommend that macros be >named in ALL_CAPS. > >> It can also look like a variable declaration: >> >> typedef int F; >> >> F(a); > >What's that got to do with ()s in uses of sizeof? It bolsters the case >for not using redundant parentheses, but both sizeof(a); and sizeof a; >can look like a declaration to someone who does not know what sizeof is. > >> sizeof needs parentheses anyway when applied to a type, so necessarily >> have to look like a function call. > >Not like a C function call of course. That's why I'd always add a space >before the ()s just to help avoid it being confused with one. > >> (And I suspect most don't even know >> whether it is types or expressions that don't require the parentheses, >> so add them just in case!) > >Yes, a lot of people do that. Surely the question though is what's the >clearest way to show what's going on? I my view, if you like extra ()s >then use them by try to show that sizeof is not a function. A space >helps to do that and I'd use one where the () are required round a type >name even when I don't used extra ()s round an expression. Functions plus their parenthesis are a syntactically coupled in C, so much so that we have things like typedef *f(); for pointers to functions. Now imagine that to avoid ambuigity C where such that those brackets for functions where underlined. Normal parenthesis are to be used for forcing the evaluation order in complicated expressions, lets call this grouping. Now you can choose normal parenthesis or underlined parentesis for ``sizeof'' , and both would feel wrong. The choice is impossible. So lets face it, "sizeof something" is just an irregular hack that is added to c to accomplish something useful. One of the things that it accomplishes is that malloc() can be defined in assembler in a separate library and used for everything. There is nothing to be done except being jealous of languages like algol 68 that are precise from the ground up, or adding ever more features (like C++ and newer c- standards) to arrive at the elusive perfection. In the C++ it means using new and making sizeof obsolescent because, basically, it can't be fixed. If you're into stack languages you want to do remember something (Put it on the stack) now apply sizeof (to the top of the stack) The "something" is something that doesn't really exist in c. so this is impossible. "sizeof (int)" is like "flying dogs" , they are not dogs but bats. It is just an expression, get over it. > >-- >Ben. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-02 10:57 +0000 |
| Message-ID | <87eg1qy4xf.fsf@bsb.me.uk> |
| In reply to | #97866 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: > In article <87shvfyrq6.fsf@bsb.me.uk>, > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >>BartC <bc@freeuk.com> writes: <snip> >>> (And I suspect most don't even know >>> whether it is types or expressions that don't require the parentheses, >>> so add them just in case!) >> >>Yes, a lot of people do that. Surely the question though is what's the >>clearest way to show what's going on? I my view, if you like extra ()s >>then use them by try to show that sizeof is not a function. A space >>helps to do that and I'd use one where the () are required round a type >>name even when I don't used extra ()s round an expression. > > Functions plus their parenthesis are a syntactically coupled > in C, so much so that we have things like > typedef *f(); > for pointers to functions. (You meant typedef <sometype> (*f)(); here, I think) > Now imagine that to avoid ambuigity C where such that those brackets for > functions where underlined. > Normal parenthesis are to be used for forcing the evaluation order > in complicated expressions, lets call this grouping. > > Now you can choose normal parenthesis or underlined parentesis for > ``sizeof'' , and both would feel wrong. The choice is impossible. That's an interesting way to think about these things -- imagine different kind of ()s for the various uses that they have. Doing that, though, I find I disagree. C's syntax has two forms of sizeof expression. One, the form where the operand is an expression should clearly use the grouping parentheses. They are optional and come about because expressions can be bracketed if you so choose. The other for, where the operand is a type name has ( and ) written explicitly in syntax. Here you are right -- these are not grouping parentheses nor are they function call parentheses. I'm you imagined syntax, they would be a third form. For consistency, I'd use this third form everywhere where the syntax calls for a type in parentheses -- casts, compound literals and so on. > So lets face it, "sizeof something" is just an irregular hack that > is added to c to accomplish something useful. Sure. <snip> > "sizeof (int)" is like "flying dogs" , they are not dogs but bats. > It is just an expression, get over it. That phrase, "get over it", suggests I have a problem with. I don't! The "other" more unusual syntax is just special case designed for a particular purpose. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-02 12:33 +0000 |
| Message-ID | <o1rpkv$718$1@dont-email.me> |
| In reply to | #97866 |
On 02/12/2016 09:21, Albert van der Horst wrote:
> In article <87shvfyrq6.fsf@bsb.me.uk>,
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 12/07/2016 11:24, Ben Bacarisse wrote:
>>>> Udyant Wig <udyant.wig@gmail.com> writes:
>>>
>>>>> But "sizeof()" really *is* a function. It acts exactly like a function
>>>>> of it's argument. There is no reason to not treat it that way. Sure, the
>>>>> C standard *allows* you to not have parenthesis around an expression
>>>>> argument, but you should treat that as the parsing oddity it is, nothing
>>>>> more. There is zero reason not to have the parenthesis there.
>>>>
>>>> No one ever made a splash by being moderate!
>>>>
>>>> It's true that sizeof acts like a mathematical function -- albeit one
>>>> with a very peculiar domain (pieces of C syntax) -- but it does not act
>>>> like a C function. Adding ()s will make it look like a C function and
>>>> that is as likely to look as odd to some as leaving it looking like an
>>>> operator will look odd to others.
>>>
>>> It will also look like a C macro invocation, which are used
>>> everywhere.
>>
>> I don't see what your point is. Just writing an identifier can look like
>> a macro invocation. That's why is usual to recommend that macros be
>> named in ALL_CAPS.
>>
>>> It can also look like a variable declaration:
>>>
>>> typedef int F;
>>>
>>> F(a);
>>
>> What's that got to do with ()s in uses of sizeof? It bolsters the case
>> for not using redundant parentheses, but both sizeof(a); and sizeof a;
>> can look like a declaration to someone who does not know what sizeof is.
>>
>>> sizeof needs parentheses anyway when applied to a type, so necessarily
>>> have to look like a function call.
>>
>> Not like a C function call of course. That's why I'd always add a space
>> before the ()s just to help avoid it being confused with one.
>>
>>> (And I suspect most don't even know
>>> whether it is types or expressions that don't require the parentheses,
>>> so add them just in case!)
>>
>> Yes, a lot of people do that. Surely the question though is what's the
>> clearest way to show what's going on? I my view, if you like extra ()s
>> then use them by try to show that sizeof is not a function. A space
>> helps to do that and I'd use one where the () are required round a type
>> name even when I don't used extra ()s round an expression.
>
> Functions plus their parenthesis are a syntactically coupled
> in C, so much so that we have things like
> typedef *f();
> for pointers to functions.
> Now imagine that to avoid ambuigity C where such that those brackets for
> functions where underlined.
> Normal parenthesis are to be used for forcing the evaluation order
> in complicated expressions, lets call this grouping.
>
> Now you can choose normal parenthesis or underlined parentesis for
> ``sizeof'' , and both would feel wrong. The choice is impossible.
If you see the pattern:
identifier(identifier)
then A(B) this can mean a number of things:
- Call function A with parameter B
- Declare variable B with type A
- Invoke macro A with parameter B
- The start of an if statement when A is "if"
- The start of a while statement when A is "while"
- A sizeof term when A is "sizeof"
So while the first three can result in ambiguity which must be resolved
by looking at previous declarations of A, the last three can be resolved
immediately** because A is a keyword.
So there isn't really much of a conflict between a function call and
sizeof(). They both fit the more general pattern of mapping something B
to something else according to A.
(** unless someone does '#define sizeof puts' for example. But if people
start redefining keywords, then we might as well give up.)
> So lets face it, "sizeof something" is just an irregular hack that
> is added to c to accomplish something useful.
In what way, the syntax? Many languages have a means of accessing
various compile-time properties. I don't know if function-like syntax
should be limited only to calling actual C functions.
(Elsewhere, I might use B.bytes instead of sizeof(B), but then '.bytes'
impinges on member-selection syntax. So you have to think up a dedicated
syntax that is /only/ used for these attributes.)
(My objection, if this was the same thread, was to do with:
A*sizeof*C
without parentheses around '*C', fitting the visual pattern A*B*C.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-02 14:07 +0100 |
| Message-ID | <o1rrko$enu$1@dont-email.me> |
| In reply to | #97870 |
On 02/12/16 13:33, BartC wrote: > On 02/12/2016 09:21, Albert van der Horst wrote: >> In article <87shvfyrq6.fsf@bsb.me.uk>, >> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >>> BartC <bc@freeuk.com> writes: >>> >>>> On 12/07/2016 11:24, Ben Bacarisse wrote: >>>>> Udyant Wig <udyant.wig@gmail.com> writes: >>>> >>>>>> But "sizeof()" really *is* a function. It acts exactly like a >>>>>> function >>>>>> of it's argument. There is no reason to not treat it that way. >>>>>> Sure, the >>>>>> C standard *allows* you to not have parenthesis around an expression >>>>>> argument, but you should treat that as the parsing oddity it is, >>>>>> nothing >>>>>> more. There is zero reason not to have the parenthesis there. >>>>> >>>>> No one ever made a splash by being moderate! >>>>> >>>>> It's true that sizeof acts like a mathematical function -- albeit one >>>>> with a very peculiar domain (pieces of C syntax) -- but it does not >>>>> act >>>>> like a C function. Adding ()s will make it look like a C function and >>>>> that is as likely to look as odd to some as leaving it looking like an >>>>> operator will look odd to others. >>>> >>>> It will also look like a C macro invocation, which are used >>>> everywhere. >>> >>> I don't see what your point is. Just writing an identifier can look >>> like >>> a macro invocation. That's why is usual to recommend that macros be >>> named in ALL_CAPS. >>> >>>> It can also look like a variable declaration: >>>> >>>> typedef int F; >>>> >>>> F(a); >>> >>> What's that got to do with ()s in uses of sizeof? It bolsters the case >>> for not using redundant parentheses, but both sizeof(a); and sizeof a; >>> can look like a declaration to someone who does not know what sizeof is. >>> >>>> sizeof needs parentheses anyway when applied to a type, so necessarily >>>> have to look like a function call. >>> >>> Not like a C function call of course. That's why I'd always add a space >>> before the ()s just to help avoid it being confused with one. >>> >>>> (And I suspect most don't even know >>>> whether it is types or expressions that don't require the parentheses, >>>> so add them just in case!) >>> >>> Yes, a lot of people do that. Surely the question though is what's the >>> clearest way to show what's going on? I my view, if you like extra ()s >>> then use them by try to show that sizeof is not a function. A space >>> helps to do that and I'd use one where the () are required round a type >>> name even when I don't used extra ()s round an expression. >> >> Functions plus their parenthesis are a syntactically coupled >> in C, so much so that we have things like >> typedef *f(); >> for pointers to functions. >> Now imagine that to avoid ambuigity C where such that those brackets for >> functions where underlined. >> Normal parenthesis are to be used for forcing the evaluation order >> in complicated expressions, lets call this grouping. >> >> Now you can choose normal parenthesis or underlined parentesis for >> ``sizeof'' , and both would feel wrong. The choice is impossible. > > If you see the pattern: > > identifier(identifier) > > then A(B) this can mean a number of things: > > - Call function A with parameter B > - Declare variable B with type A I never realised that was legal. It is right there in 6.7.6, but I can't ever recall having seen it in use. I am sure it is possible to construct complicated declarations where the parenthesis might be useful (that is why the option exists), but then you don't have the simple form A(B). Certainly if you see "foo(x);", then it is very unlikely to be declaring an object "x" of type "foo". > - Invoke macro A with parameter B > > - The start of an if statement when A is "if" > - The start of a while statement when A is "while" > - A sizeof term when A is "sizeof" > > So while the first three can result in ambiguity which must be resolved > by looking at previous declarations of A, the last three can be resolved > immediately** because A is a keyword. > > So there isn't really much of a conflict between a function call and > sizeof(). They both fit the more general pattern of mapping something B > to something else according to A. A key difference with "sizeof" is that it does not evaluate its argument, and therefore will lose any side-effects. "sizeof(i++)" does not increment i, whereas both function calls and macros /will/ increment i. In my own programming, I don't normally have side-effects on function or macro arguments - thus sizeof works like a function in /my/ code. But many programmers are quite happy to write "foo(i++)", and this is significantly different from "sizeof(i++)".
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-12-02 10:19 -0500 |
| Message-ID | <5c2dd4b1-c566-92a0-265c-7a7659e9bfeb@verizon.net> |
| In reply to | #97866 |
On 12/02/2016 04:21 AM, Albert van der Horst wrote:
...
> Now imagine that to avoid ambuigity C where such that those brackets for
> functions where underlined.
> Normal parenthesis are to be used for forcing the evaluation order
> in complicated expressions, lets call this grouping.
>
> Now you can choose normal parenthesis or underlined parentesis for
> ``sizeof'' , and both would feel wrong. The choice is impossible.
True - if we're going to completely semantically distinguish all of the
different uses for parentheses in the C standard, the parentheses in
sizeof(int) (which are part of the sizeof syntax), should not only be
distinguished from the parentheses in puts("Hello, World!") (which are
part of the function call syntax), but also from the parentheses in
sizeof(a+b) (which are solely for grouping purposes).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-02 08:56 -0800 |
| Message-ID | <lnh96m5kxf.fsf@kst-u.example.com> |
| In reply to | #97880 |
"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 12/02/2016 04:21 AM, Albert van der Horst wrote:
> ...
>> Now imagine that to avoid ambuigity C where such that those brackets for
>> functions where underlined.
>> Normal parenthesis are to be used for forcing the evaluation order
>> in complicated expressions, lets call this grouping.
>>
>> Now you can choose normal parenthesis or underlined parentesis for
>> ``sizeof'' , and both would feel wrong. The choice is impossible.
>
> True - if we're going to completely semantically distinguish all of the
> different uses for parentheses in the C standard, the parentheses in
> sizeof(int) (which are part of the sizeof syntax), should not only be
> distinguished from the parentheses in puts("Hello, World!") (which are
> part of the function call syntax), but also from the parentheses in
> sizeof(a+b) (which are solely for grouping purposes).
In fact there are, if I've counted correctly, 24 distinct uses of
parentheses in the grammar, any of which could in principle have
been defined to use some other symbol. The following is extracted
from N1570 Annex A.
primary-expression:
( expression )
generic-selection:
_Generic ( assignment-expression , generic-assoc-list )
postfix-expression:
postfix-expression ( argument-expression-list[opt] )
( type-name ) { initializer-list }
( type-name ) { initializer-list , }
unary-expression:
sizeof ( type-name )
_Alignof ( type-name )
cast-expression:
( type-name ) cast-expression
atomic-type-specifier:
_Atomic ( type-name )
alignment-specifier:
_Alignas ( type-name )
_Alignas ( constant-expression )
direct-declarator:
identifier
( declarator )
direct-abstract-declarator:
( abstract-declarator )
static_assert-declaration:
_Static_assert ( constant-expression , string-literal ) ;
selection-statement:
if ( expression ) statement
if ( expression ) statement else statement
iteration-statement:
while ( expression ) statement
do statement while ( expression ) ;
for ( expression[opt] ; expression[opt] ; expression[opt] ) statement
for ( declaration expression[opt] ; expression[opt] ) statement
control-line:
# define identifier lparen identifier-listopt )
# define identifier lparen ... ) replacement-list new-line
# define identifier lparen identifier-list , ... )
(For the control-line productions, "lparen" is a ( character not
immediately preceded by white-space.)
The fact that a function call
postfix-expression ( argument-expression-list[opt] )
and a sizeof expression
sizeof ( type-name )
can be superficially similar *if* you ignore the fact that sizeof
is a keyword is not particularly significant.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-12-02 12:31 -0500 |
| Message-ID | <47154296-b427-0c0e-7d73-fb3a1bbbd908@verizon.net> |
| In reply to | #97888 |
On 12/02/2016 11:56 AM, Keith Thompson wrote:
> "James R. Kuyper" <jameskuyper@verizon.net> writes:
...
>> True - if we're going to completely semantically distinguish all of the
>> different uses for parentheses in the C standard, the parentheses in
>> sizeof(int) (which are part of the sizeof syntax), should not only be
>> distinguished from the parentheses in puts("Hello, World!") (which are
>> part of the function call syntax), but also from the parentheses in
>> sizeof(a+b) (which are solely for grouping purposes).
Just to be clear, I wasn't actually suggesting that this should be done,
only pointing out that it could be done.
> In fact there are, if I've counted correctly, 24 distinct uses of
> parentheses in the grammar, any of which could in principle have
> been defined to use some other symbol.
Agreed - with a couple of exceptions. C declarations ideally mirror one
valid way of using the declared identifier. Therefore, whichever symbols
are used to surround the arguments in a function call, should also be
used to declare that something is a function. This also applies to the
#definition and invocation of function-like macros. And, if we want to
retain the ability that currently exists to seamlessly replace a
function call with the invocation of a function-like macro, then
function calls and function-like macro invocations should also use the
same symbols to surround their arguments.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-02 11:42 -0800 |
| Message-ID | <lnd1ha5d93.fsf@kst-u.example.com> |
| In reply to | #97890 |
"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 12/02/2016 11:56 AM, Keith Thompson wrote:
>> "James R. Kuyper" <jameskuyper@verizon.net> writes:
> ...
>>> True - if we're going to completely semantically distinguish all of the
>>> different uses for parentheses in the C standard, the parentheses in
>>> sizeof(int) (which are part of the sizeof syntax), should not only be
>>> distinguished from the parentheses in puts("Hello, World!") (which are
>>> part of the function call syntax), but also from the parentheses in
>>> sizeof(a+b) (which are solely for grouping purposes).
>
> Just to be clear, I wasn't actually suggesting that this should be done,
> only pointing out that it could be done.
>
>> In fact there are, if I've counted correctly, 24 distinct uses of
>> parentheses in the grammar, any of which could in principle have
>> been defined to use some other symbol.
>
> Agreed - with a couple of exceptions. C declarations ideally mirror one
> valid way of using the declared identifier. Therefore, whichever symbols
> are used to surround the arguments in a function call, should also be
> used to declare that something is a function. This also applies to the
> #definition and invocation of function-like macros. And, if we want to
> retain the ability that currently exists to seamlessly replace a
> function call with the invocation of a function-like macro, then
> function calls and function-like macro invocations should also use the
> same symbols to surround their arguments.
Sure. A C-like language that used 24 distinct pairs of symbols (or
keywords) in place of parentheses would be syntactically consistent, but
very confusing. *Some* of those 24 usages are closely related to each
other -- for example the two forms of compound literal, with and without
a trailing comma.
I have no particular problem with the fact that C uses parentheses for
*all* 24 cases. I'm just pointing out that the use of the same symbol
does not imply logical similarity, particularly for function calls
vs. sizeof expressions.
--
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-12 08:46 -0700 |
| Message-ID | <ce2eb43a-afde-4e1b-ab45-33b1b8601569@googlegroups.com> |
| In reply to | #90264 |
On Tuesday, July 12, 2016 at 5:52:47 AM UTC-5, Bart wrote: > It will also look like a C macro invocation, which are used everywhere. > It can also look like a variable declaration: If written as "sizeof(int)", then it will look like a macro invocation. If written as "sizeof (int)", then it won't. A similar thing can happen with return. Writing it as "return(x+y)*z;" will make it look like a function call whose return is multiplied by z and otherwise ignored. Writing it as "return (x+y)*z;" will make it look like a statement.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-12 09:16 -0700 |
| Message-ID | <lnoa62j0hd.fsf@kst-u.example.com> |
| In reply to | #90264 |
BartC <bc@freeuk.com> writes:
[...]
> sizeof needs parentheses anyway when applied to a type, so necessarily
> have to look like a function call. (And I suspect most don't even know
> whether it is types or expressions that don't require the parentheses,
> so add them just in case!)
When I write C code, I don't cater to an audience that doesn't know
C. Someone who doesn't understand what `sizeof n` or `sizeof *p`
means is likely to have a hard time reading my code. The solution
(which you seem to object to) is to learn the language.
When I apply sizeof to a parenthesized type name, I leave a space
between the keyword and the "(":
sizeof (int)
(I do the same if the operand happens to be a parenthesized
expression, though that's fairly rare.)
When I write a function call, the function name and the "(" are
adjacent:
func(arg)
You can argue that `sizeof (int)` looks like a function call (*if* you
pretend that "sizeof" is an ordinary identifier rather than a keyword
and that "int" is an expression), but a reasonable coding style can (and
IMHO should) make them visually distinct.
--
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-12 09:27 -0700 |
| Message-ID | <ce32745e-e7b1-4a18-96ed-7bbaace37ada@googlegroups.com> |
| In reply to | #90277 |
On Tuesday, July 12, 2016 at 5:16:24 PM UTC+1, Keith Thompson wrote: > > You can argue that `sizeof (int)` looks like a function call (*if* you > pretend that "sizeof" is an ordinary identifier rather than a keyword > and that "int" is an expression), but a reasonable coding style can (and > IMHO should) make them visually distinct. > But doesn't matter too much whether sizeof(int) is a subroutine call or a macro call or not, if you're just reading the code quickly to understand it. It matters if you want to micro-optimise, but then you'll be reading the code closely and you won't be confused.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-12 08:20 -0700 |
| Message-ID | <ln1t2ykhlx.fsf@kst-u.example.com> |
| In reply to | #90246 |
Udyant Wig <udyant.wig@gmail.com> writes:
[...]
> If you are saying that sizeof should be thought of as a function,
> then Linus Torvalds would agree with you:
>
> <URL:https://lkml.org/lkml/2012/7/11/103>
>
> The mail is quite short, but I produce an excerpt here:
>
> But "sizeof()" really *is* a function. It acts exactly like a function
> of it's argument. There is no reason to not treat it that way. Sure, the
> C standard *allows* you to not have parenthesis around an expression
> argument, but you should treat that as the parsing oddity it is, nothing
> more. There is zero reason not to have the parenthesis there.
Linus Torvalds is wrong on this point.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-07-12 12:47 -0400 |
| Message-ID | <nm36vm$j8a$1@dont-email.me> |
| In reply to | #90246 |
On 07/12/2016 12:56 AM, Udyant Wig wrote: > On 07/12/2016 03:50 AM, BartC wrote: >> However it's not just about how compilers cope with this (obviously >> they do). It's the 'tokenising' that takes place in the mind of the >> human reader of the code that is also relevant. Using ...(*C) instead >> of ...*C makes it less likely that the * might be, however briefly, >> mistaken for a multiply. > > If you are saying that sizeof should be thought of as a function, > then Linus Torvalds would agree with you: > > <URL:https://lkml.org/lkml/2012/7/11/103> > > The mail is quite short, but I produce an excerpt here: > > But "sizeof()" really *is* a function. It acts exactly like a function > of it's argument. There is no reason to not treat it that way. Sure, the > C standard *allows* you to not have parenthesis around an expression > argument, but you should treat that as the parsing oddity it is, nothing > more. There is zero reason not to have the parenthesis there. Interpreting sizeof() as a function makes it difficult to correctly interpret expressions such as sizeof(5)[array], and can lead you to incorrectly interpret sizeof(sin)(0) as a constraint violation.
[toc] | [prev] | [next] | [standalone]
Page 9 of 18 — ← Prev page 1 … 7 8 [9] 10 11 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web