Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #35642 > unrolled thread
| Started by | Sharwan Joram <sharwan.joram@gmail.com> |
|---|---|
| First post | 2013-08-23 10:15 -0700 |
| Last post | 2013-08-26 09:23 -0700 |
| Articles | 20 on this page of 187 — 23 participants |
Back to article view | Back to comp.lang.c
Memory corruption on freeing a pointer to pointer Sharwan Joram <sharwan.joram@gmail.com> - 2013-08-23 10:15 -0700
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-23 14:05 -0400
Re: Memory corruption on freeing a pointer to pointer Sharwan Joram <sharwan.joram@gmail.com> - 2013-08-23 11:17 -0700
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-23 14:51 -0400
Re: Memory corruption on freeing a pointer to pointer blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2013-08-24 21:50 +0000
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-24 15:36 -0700
Re: Memory corruption on freeing a pointer to pointer Martin Shobe <martin.shobe@yahoo.com> - 2013-08-23 13:18 -0500
Re: Memory corruption on freeing a pointer to pointer Ike Naar <ike@iceland.freeshell.org> - 2013-08-23 20:00 +0000
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-23 21:37 +0100
Re: Memory corruption on freeing a pointer to pointer Barry Schwarz <schwarzb@dqel.com> - 2013-08-23 14:16 -0700
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-23 17:50 -0400
Re: Memory corruption on freeing a pointer to pointer gdotone@gmail.com - 2013-08-23 22:56 -0700
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-24 13:45 +0100
Re: Memory corruption on freeing a pointer to pointer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-24 06:20 -0700
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-24 20:16 +0100
Re: Memory corruption on freeing a pointer to pointer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-24 16:51 -0700
Re: Memory corruption on freeing a pointer to pointer Ian Collins <ian-news@hotmail.com> - 2013-08-25 12:27 +1200
Re: Memory corruption on freeing a pointer to pointer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-24 18:02 -0700
Re: Memory corruption on freeing a pointer to pointer Ian Collins <ian-news@hotmail.com> - 2013-08-25 15:03 +1200
Re: Memory corruption on freeing a pointer to pointer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-25 08:09 -0700
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-25 14:02 -0700
Re: Memory corruption on freeing a pointer to pointer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-25 22:43 -0700
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-25 02:21 +0100
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-24 19:41 -0700
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-24 15:15 -0700
Re: Memory corruption on freeing a pointer to pointer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-24 02:48 -0700
Re: Memory corruption on freeing a pointer to pointer Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-24 17:02 +0300
Re: Memory corruption on freeing a pointer to pointer Sharwan Joram <sharwan.joram@gmail.com> - 2013-08-24 12:05 -0700
Re: Memory corruption on freeing a pointer to pointer Barry Schwarz <schwarzb@dqel.com> - 2013-08-24 15:14 -0700
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-24 15:38 -0700
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-25 02:10 +0100
Re: Memory corruption on freeing a pointer to pointer Sharwan Joram <sharwan.joram@gmail.com> - 2013-08-25 00:30 -0700
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-25 21:13 +0100
Re: Memory corruption on freeing a pointer to pointer Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-25 11:13 +0300
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-25 10:03 -0400
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-25 14:07 -0700
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-25 18:47 -0400
Re: Memory corruption on freeing a pointer to pointer Ike Naar <ike@iceland.freeshell.org> - 2013-08-26 06:40 +0000
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-26 06:31 -0400
Re: Memory corruption on freeing a pointer to pointer Richard Damon <Richard@Damon-Family.org> - 2013-08-26 07:44 -0400
Re: Memory corruption on freeing a pointer to pointer Ike Naar <ike@iceland.freeshell.org> - 2013-08-26 15:15 +0000
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-26 07:50 -0400
Re: Memory corruption on freeing a pointer to pointer David Brown <david@westcontrol.removethisbit.com> - 2013-08-26 16:08 +0200
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-26 11:42 -0400
Re: Memory corruption on freeing a pointer to pointer David Brown <david@westcontrol.removethisbit.com> - 2013-08-26 18:16 +0200
Re: Memory corruption on freeing a pointer to pointer glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-26 17:10 +0000
Re: Memory corruption on freeing a pointer to pointer David Brown <david@westcontrol.removethisbit.com> - 2013-08-27 09:27 +0200
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-27 07:42 -0400
Re: Memory corruption on freeing a pointer to pointer glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-27 18:38 +0000
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-27 15:14 -0400
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-27 14:23 -0700
Re: Memory corruption on freeing a pointer to pointer Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-08-27 16:06 -0600
Re: Memory corruption on freeing a pointer to pointer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-27 15:14 -0700
Re: Memory corruption on freeing a pointer to pointer glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-27 23:17 +0000
Re: Memory corruption on freeing a pointer to pointer Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-28 20:34 +0300
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-28 11:06 -0700
Re: Memory corruption on freeing a pointer to pointer Robert Wessel <robertwessel2@yahoo.com> - 2013-08-28 22:31 -0500
[OT] significant digits James Kuyper <jameskuyper@verizon.net> - 2013-08-29 06:53 -0400
Re: [OT] significant digits Robert Wessel <robertwessel2@yahoo.com> - 2013-08-29 16:51 -0500
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-28 15:05 -0400
Re: Memory corruption on freeing a pointer to pointer David Brown <david@westcontrol.removethisbit.com> - 2013-08-28 00:05 +0200
Re: Memory corruption on freeing a pointer to pointer Ian Collins <ian-news@hotmail.com> - 2013-08-28 10:08 +1200
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-27 18:30 -0400
Re: Memory corruption on freeing a pointer to pointer David Brown <david@westcontrol.removethisbit.com> - 2013-08-28 09:39 +0200
Re: Memory corruption on freeing a pointer to pointer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-28 04:04 -0700
Re: Memory corruption on freeing a pointer to pointer Robert Wessel <robertwessel2@yahoo.com> - 2013-08-28 22:35 -0500
[OT] English [was: Memory corruption on freeing a pointer to pointer] James Kuyper <jameskuyper@verizon.net> - 2013-08-28 07:10 -0400
Re: [OT] English [was: Memory corruption on freeing a pointer to pointer] David Brown <david@westcontrol.removethisbit.com> - 2013-08-28 14:50 +0200
Re: [OT] English [was: Memory corruption on freeing a pointer to pointer] ralph <nt_consulting@yahoo.com> - 2013-08-28 12:29 -0500
Re: [OT] English [was: Memory corruption on freeing a pointer to pointer] Philip Lantz <prl@canterey.us> - 2013-08-30 00:57 -0700
Re: [OT] English [was: Memory corruption on freeing a pointer to pointer] David Brown <david@westcontrol.removethisbit.com> - 2013-08-30 10:07 +0200
Re: [OT] English [was: Memory corruption on freeing a pointer to pointer] Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-28 20:46 +0300
Re: [OT] English [was: Memory corruption on freeing a pointer to pointer] James Kuyper <jameskuyper@verizon.net> - 2013-08-28 15:13 -0400
Re: [OT] English [was: Memory corruption on freeing a pointer to pointer] Ian Collins <ian-news@hotmail.com> - 2013-08-29 08:40 +1200
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-28 03:58 +0100
Re: Memory corruption on freeing a pointer to pointer David Brown <david@westcontrol.removethisbit.com> - 2013-08-28 09:58 +0200
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-27 11:45 -0700
Re: Memory corruption on freeing a pointer to pointer glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-27 23:23 +0000
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-27 16:47 -0700
Re: Memory corruption on freeing a pointer to pointer glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-28 03:29 +0000
Re: Memory corruption on freeing a pointer to pointer glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-26 16:54 +0000
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-26 13:26 -0400
Re: Memory corruption on freeing a pointer to pointer David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
Re: Memory corruption on freeing a pointer to pointer glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-29 05:18 +0000
Re: Memory corruption on freeing a pointer to pointer David Thompson <dave.thompson2@verizon.net> - 2013-09-04 00:01 -0400
Re: Memory corruption on freeing a pointer to pointer glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-04 05:40 +0000
Re: Memory corruption on freeing a pointer to pointer Ian Collins <ian-news@hotmail.com> - 2013-08-27 08:54 +1200
Re: Memory corruption on freeing a pointer to pointer Ike Naar <ike@iceland.freeshell.org> - 2013-08-26 21:09 +0000
Re: Memory corruption on freeing a pointer to pointer Ian Collins <ian-news@hotmail.com> - 2013-08-27 09:16 +1200
Re: Memory corruption on freeing a pointer to pointer Ike Naar <ike@iceland.freeshell.org> - 2013-08-26 21:39 +0000
Re: Memory corruption on freeing a pointer to pointer Ian Collins <ian-news@hotmail.com> - 2013-08-27 09:42 +1200
Re: Memory corruption on freeing a pointer to pointer Ike Naar <ike@iceland.freeshell.org> - 2013-08-26 21:52 +0000
Re: Memory corruption on freeing a pointer to pointer Les Cargill <lcargill99@comcast.com> - 2013-08-26 17:46 -0500
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-26 17:12 -0400
Re: Memory corruption on freeing a pointer to pointer Ian Collins <ian-news@hotmail.com> - 2013-08-27 09:17 +1200
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-26 18:45 -0400
Re: Memory corruption on freeing a pointer to pointer Ian Collins <ian-news@hotmail.com> - 2013-08-27 11:03 +1200
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-26 08:52 -0700
Re: Memory corruption on freeing a pointer to pointer glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-26 17:20 +0000
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-26 10:59 -0700
Re: Memory corruption on freeing a pointer to pointer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-26 11:31 -0700
Re: Memory corruption on freeing a pointer to pointer glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-26 19:30 +0000
Re: Memory corruption on freeing a pointer to pointer glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-26 19:26 +0000
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-26 13:37 -0700
Re: Memory corruption on freeing a pointer to pointer Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-26 22:20 -0700
Re: Memory corruption on freeing a pointer to pointer Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-27 16:42 +0300
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-27 10:28 -0700
Re: Memory corruption on freeing a pointer to pointer Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-28 20:29 +0300
Re: Memory corruption on freeing a pointer to pointer David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
Re: Memory corruption on freeing a pointer to pointer Ike Naar <ike@iceland.freeshell.org> - 2013-08-26 19:18 +0000
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-26 15:41 -0400
Re: Memory corruption on freeing a pointer to pointer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-26 12:58 -0700
Re: Memory corruption on freeing a pointer to pointer glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-26 20:52 +0000
Re: Memory corruption on freeing a pointer to pointer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-26 14:35 -0700
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-27 00:48 +0100
Re: Memory corruption on freeing a pointer to pointer David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-29 03:40 +0100
Re: Memory corruption on freeing a pointer to pointer David Thompson <dave.thompson2@verizon.net> - 2013-09-04 00:01 -0400
Re: Memory corruption on freeing a pointer to pointer glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-29 05:27 +0000
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-30 01:40 +0100
Re: Memory corruption on freeing a pointer to pointer Les Cargill <lcargill99@comcast.com> - 2013-08-26 17:51 -0500
Re: Memory corruption on freeing a pointer to pointer Ike Naar <ike@iceland.freeshell.org> - 2013-08-27 08:24 +0000
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-27 08:12 -0400
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-27 11:48 -0700
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-26 13:28 -0700
Re: Memory corruption on freeing a pointer to pointer Ike Naar <ike@iceland.freeshell.org> - 2013-08-26 20:40 +0000
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-26 14:36 -0700
Re: Memory corruption on freeing a pointer to pointer Ike Naar <ike@iceland.freeshell.org> - 2013-08-26 21:43 +0000
Re: Memory corruption on freeing a pointer to pointer glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-26 21:59 +0000
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-26 15:26 -0700
Re: Memory corruption on freeing a pointer to pointer Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-27 16:52 +0300
Re: Memory corruption on freeing a pointer to pointer Ike Naar <ike@iceland.freeshell.org> - 2013-08-28 16:16 +0000
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-28 10:54 -0700
Re: Memory corruption on freeing a pointer to pointer Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-28 20:56 +0300
Re: Memory corruption on freeing a pointer to pointer glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-28 19:23 +0000
Re: Memory corruption on freeing a pointer to pointer Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-28 23:31 -0700
Re: Memory corruption on freeing a pointer to pointer Ike Naar <ike@iceland.freeshell.org> - 2013-08-27 07:00 +0000
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-27 11:41 -0700
Re: Memory corruption on freeing a pointer to pointer Ike Naar <ike@iceland.freeshell.org> - 2013-08-28 16:21 +0000
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-28 10:57 -0700
Re: Memory corruption on freeing a pointer to pointer Ike Naar <ike@iceland.freeshell.org> - 2013-08-28 21:27 +0000
Re: Memory corruption on freeing a pointer to pointer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-28 14:53 -0700
Re: Memory corruption on freeing a pointer to pointer Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-27 16:37 +0300
Re: Memory corruption on freeing a pointer to pointer Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-27 16:29 +0300
Re: Memory corruption on freeing a pointer to pointer Ike Naar <ike@iceland.freeshell.org> - 2013-08-28 16:11 +0000
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-28 02:45 +0100
Re: Memory corruption on freeing a pointer to pointer Ike Naar <ike@iceland.freeshell.org> - 2013-08-28 20:47 +0000
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-28 16:22 -0700
Re: Memory corruption on freeing a pointer to pointer Martin Shobe <martin.shobe@yahoo.com> - 2013-08-29 13:36 -0500
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-29 20:06 +0100
Re: Memory corruption on freeing a pointer to pointer Martin Shobe <martin.shobe@yahoo.com> - 2013-08-30 10:48 -0500
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-30 18:34 +0100
Re: Memory corruption on freeing a pointer to pointer Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-27 16:25 +0300
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-27 10:06 -0400
Re: Memory corruption on freeing a pointer to pointer Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-27 18:21 +0300
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-27 12:16 -0400
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-28 02:25 +0100
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-27 11:51 -0700
Re: Memory corruption on freeing a pointer to pointer gdotone@gmail.com - 2013-08-26 02:55 -0700
Re: Memory corruption on freeing a pointer to pointer gdotone@gmail.com - 2013-08-26 03:04 -0700
Re: Memory corruption on freeing a pointer to pointer gdotone@gmail.com - 2013-08-25 19:02 -0700
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-25 20:01 -0700
Re: Memory corruption on freeing a pointer to pointer gdotone@gmail.com - 2013-08-25 22:49 -0700
Re: Memory corruption on freeing a pointer to pointer gdotone@gmail.com - 2013-08-25 23:07 -0700
Re: Memory corruption on freeing a pointer to pointer gdotone@gmail.com - 2013-08-25 23:20 -0700
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-26 13:03 +0100
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-26 07:02 -0400
Re: Memory corruption on freeing a pointer to pointer gdotone@gmail.com - 2013-08-26 08:27 -0700
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-26 11:52 -0400
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-26 08:57 -0700
Re: Memory corruption on freeing a pointer to pointer Barry Schwarz <schwarzb@dqel.com> - 2013-08-26 04:53 -0700
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-26 12:58 +0100
Re: Memory corruption on freeing a pointer to pointer Sharwan Joram <sharwan.joram@gmail.com> - 2013-08-26 06:40 -0700
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-26 15:28 +0100
Re: Memory corruption on freeing a pointer to pointer gdotone@gmail.com - 2013-08-26 14:54 -0700
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-26 18:22 -0400
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-26 15:31 -0700
Re: Memory corruption on freeing a pointer to pointer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-27 01:08 +0100
Re: Memory corruption on freeing a pointer to pointer gdotone@gmail.com - 2013-08-26 22:02 -0700
Re: Memory corruption on freeing a pointer to pointer Barry Schwarz <schwarzb@dqel.com> - 2013-08-26 21:07 -0700
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-26 08:29 -0700
Re: Memory corruption on freeing a pointer to pointer gdotone@gmail.com - 2013-08-26 08:46 -0700
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-26 08:59 -0700
Re: Memory corruption on freeing a pointer to pointer gdotone@gmail.com - 2013-08-26 09:19 -0700
Re: Memory corruption on freeing a pointer to pointer Keith Thompson <kst-u@mib.org> - 2013-08-26 10:47 -0700
Re: Memory corruption on freeing a pointer to pointer James Kuyper <jameskuyper@verizon.net> - 2013-08-26 12:18 -0400
Re: Memory corruption on freeing a pointer to pointer gdotone@gmail.com - 2013-08-26 09:23 -0700
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2013-08-26 11:31 -0700 |
| Message-ID | <4b8326bb-060a-466f-b4dd-4d22885129f5@googlegroups.com> |
| In reply to | #35858 |
On Monday, August 26, 2013 6:59:43 PM UTC+1, Keith Thompson wrote: > glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > > > Talking about symmetry in operations, it still bothers me to write > > > if(s1.equals(s2)) > > > in Java, which seems to make s1 and s2 very unequal. The symmetry > > of the == operator is lost. > > > I haven't done enough Java to comment on that, but at first glance I > agree that (s1.equals(s2)) isn't very pretty. > > Virtually all object languages have that problems. The syntax makes it look like the functions operate on one object, taking the other as an argument. Often that doesn't express very well what the code is doing. In C++ you can overload the == operator, but operator overloadign creates its own issues.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-08-26 19:30 +0000 |
| Message-ID | <kvgac0$kf4$1@speranza.aioe.org> |
| In reply to | #35859 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: (snip, I wrote) >> > Talking about symmetry in operations, it still bothers me to write >> > if(s1.equals(s2)) >> > in Java, which seems to make s1 and s2 very unequal. The symmetry >> > of the == operator is lost. > Virtually all object languages have that problems. The syntax > makes it look like the functions operate on one object, > taking the other as an argument. Often that doesn't express > very well what the code is doing. > In C++ you can overload the == operator, but operator > overloadign creates its own issues. I don't know C++ quite as well, but in Java you use == to compare the reference, .equals() to compare the object. As Java doesn't have operator overload, you couldn't do that, but you wouldn't want to do it anyway. Among others, you couldn't test for null. -- glen
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-08-26 19:26 +0000 |
| Message-ID | <kvga5h$jod$1@speranza.aioe.org> |
| In reply to | #35858 |
Keith Thompson <kst-u@mib.org> wrote:
(snip)
>>> I know why Yoda conditions are used, and it's a valid reason.
>>> But would you even consider writing
>>> if (0 == strcmp(s1, s2))
>>> if it weren't for the "==" vs. "=" issue?
(snip, then I wrote)
>> No, I would write
>> if( ! strcmp(s1, s2))
> Again, this is a matter of personal taste.
> I know what !strcmp(s1, s2) means, but I dislike it.
I suppose I don't especially like it, but I usually do it anyway.
> Many functions return a logically Boolean result, even if the result
> isn't of type bool or _Bool. By "logically Boolean", I mean that
> the result answers a yes/no question without adding more information.
Yes, but == and != don't help all that much. The relation is still
backwards, but you get used to it. About as easy to get used to
with ! as with !=.
> strcmp is not one of those functions, so I dislike using its result
> either as a condition or as the operand of "!". For much the same
> reason, I dislike writing "if (ptr)" and strongly prefer
> "if (ptr != NULL)".
In this case, I think of the pointer as pointing to something, or not,
and so, to me, it makes some sense as a boolean.
> But of course that wasn't the point of the question. Using
> a different example, would you even consider writing
> if (5 == strlen(s))
> rather than
> if (strlen(s) == 5)
> if it weren't for the "==" vs. "=" issue?
> My point is that, as far as I can see, there is no reason to put a
> constant expression on the LHS of an "==" comparison and a non-constant
> expression on the RHS other than the attempt to avoid a potential "=="
> vs. "=" error. And *in my opinion* that's not a good enough reason to
> do it.
Yes, I don't like the
if (5 == strlen(s))
form. It looks ugly, and distracts me from reading the code.
But also I rarely do assignments in if statements.
> And if both forms are equally clear to you, that's great -- but be aware
> that not everyone sees it that way.
>> Talking about symmetry in operations, it still bothers me to write
>> if(s1.equals(s2))
>> in Java, which seems to make s1 and s2 very unequal. The symmetry
>> of the == operator is lost.
> I haven't done enough Java to comment on that, but at
> first glance I agree that (s1.equals(s2)) isn't very pretty.
There is also:
if("abc".equals(s1))
instead of
if(s1.equals("abc"))
which I never do, but supposedly has some advantage if s1
might be null.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-26 13:37 -0700 |
| Message-ID | <ln38pwkx31.fsf@nuthaus.mib.org> |
| In reply to | #35862 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
> (snip)
>>>> I know why Yoda conditions are used, and it's a valid reason.
>>>> But would you even consider writing
>
>>>> if (0 == strcmp(s1, s2))
>
>>>> if it weren't for the "==" vs. "=" issue?
>
> (snip, then I wrote)
>>> No, I would write
>
>>> if( ! strcmp(s1, s2))
>
>> Again, this is a matter of personal taste.
>
>> I know what !strcmp(s1, s2) means, but I dislike it.
>
> I suppose I don't especially like it, but I usually do it anyway.
>
>> Many functions return a logically Boolean result, even if the result
>> isn't of type bool or _Bool. By "logically Boolean", I mean that
>> the result answers a yes/no question without adding more information.
>
> Yes, but == and != don't help all that much. The relation is still
> backwards, but you get used to it. About as easy to get used to
> with ! as with !=.
It helps me.
if (strcmp(s1, s2) < 0) /* s1 is less than s2 */
if (strcmp(s1, s2) == 0) /* s1 is equal to s2 */
if (strcmp(s1, s2) > 0) /* s1 is greater than s2 */
if (strcmp(s1, s2) != 0) /* s1 is not equal to s2 */
if (strcmp(s1, s2) <= 0) /* s1 is less than or equal to s2 */
...
The result returned my strcmp is not (in my head, at least)
a Boolean; it's a tri-state comparison (with all negative values
logically equivalent to each other, and all positive values logically
equivalent to each other). Which is why the only thing I'm entirely
comfortable doing with strcmp() is explicitly comparing its result
to 0.
>> strcmp is not one of those functions, so I dislike using its result
>> either as a condition or as the operand of "!". For much the same
>> reason, I dislike writing "if (ptr)" and strongly prefer
>> "if (ptr != NULL)".
>
> In this case, I think of the pointer as pointing to something, or not,
> and so, to me, it makes some sense as a boolean.
And the language definition agrees with you -- but it's not *just* a
Boolean. A pure Boolean value does not have multiple distinct true
values; it's true or false, nothing else.
I'm sure part of it is that I learned Pascal before I learned C.
But when I see "if (ptr)", I have to mentally translate it to
"if (ptr != NULL)".
[...]
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2013-08-26 22:20 -0700 |
| Message-ID | <kfny57ng15n.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #35870 |
Keith Thompson <kst-u@mib.org> writes: > I'm sure part of it is that I learned Pascal before I learned C. > But when I see "if (ptr)", I have to mentally translate it to > "if (ptr != NULL)". I find this interesting and also rather astonishing. (Not unbelievable, just astonishing.) To offer a point of comparison, I also learned Pascal before I learned C, but immediately took to the C-isms 'if(ptr)' and 'if(!ptr)' without any difficulty. When I see something like 'if (ptr != NULL)' it almost always looks awkward or somewhat contrived. Not meaning to imply anyone else should have this reaction, just that it is the reaction I have myself.
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2013-08-27 16:42 +0300 |
| Message-ID | <87bo4jz1ve.fsf@bazspaz.fatphil.org> |
| In reply to | #35918 |
Tim Rentsch <txr@alumni.caltech.edu> writes: > Keith Thompson <kst-u@mib.org> writes: > > I'm sure part of it is that I learned Pascal before I learned C. > > But when I see "if (ptr)", I have to mentally translate it to > > "if (ptr != NULL)". > > I find this interesting and also rather astonishing. > (Not unbelievable, just astonishing.) > > To offer a point of comparison, I also learned Pascal > before I learned C, but immediately took to the C-isms > 'if(ptr)' and 'if(!ptr)' without any difficulty. When > I see something like 'if (ptr != NULL)' it almost always > looks awkward or somewhat contrived. Not meaning to > imply anyone else should have this reaction, just that it > is the reaction I have myself. Tally one more for that point of view here. However, I don't physically wince when I see (ptr != NULL), unlike some other jarring and unnecessary constructs. Phil -- If "law-abiding citizens have nothing to fear" from privacy-invading technologies and policies, then law-abiding governments should have nothing to fear from whistleblowers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-27 10:28 -0700 |
| Message-ID | <lnk3j7hwl1.fsf@nuthaus.mib.org> |
| In reply to | #35943 |
Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>> > I'm sure part of it is that I learned Pascal before I learned C.
>> > But when I see "if (ptr)", I have to mentally translate it to
>> > "if (ptr != NULL)".
>>
>> I find this interesting and also rather astonishing.
>> (Not unbelievable, just astonishing.)
>>
>> To offer a point of comparison, I also learned Pascal
>> before I learned C, but immediately took to the C-isms
>> 'if(ptr)' and 'if(!ptr)' without any difficulty. When
>> I see something like 'if (ptr != NULL)' it almost always
>> looks awkward or somewhat contrived. Not meaning to
>> imply anyone else should have this reaction, just that it
>> is the reaction I have myself.
>
> Tally one more for that point of view here. However, I don't
> physically wince when I see (ptr != NULL), unlike some other
> jarring and unnecessary constructs.
If all our pointers we called "ptr", I'd probably have less problem
with "if (ptr)".
What I do find jarring (and often incorrect) is "if (cond == true)".
--
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 | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2013-08-28 20:29 +0300 |
| Message-ID | <878uzlyb8y.fsf@bazspaz.fatphil.org> |
| In reply to | #35965 |
Keith Thompson <kst-u@mib.org> writes:
> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> > Tim Rentsch <txr@alumni.caltech.edu> writes:
...
> >> 'if(ptr)' and 'if(!ptr)' without any difficulty. When
> >> I see something like 'if (ptr != NULL)' it almost always
> >> looks awkward or somewhat contrived. Not meaning to
> >> imply anyone else should have this reaction, just that it
> >> is the reaction I have myself.
> >
> > Tally one more for that point of view here. However, I don't
> > physically wince when I see (ptr != NULL), unlike some other
> > jarring and unnecessary constructs.
>
> If all our pointers we called "ptr", I'd probably have less problem
> with "if (ptr)".
>
> What I do find jarring (and often incorrect) is "if (cond == true)".
That's a subtle one. It doesn't look disgusting (so doesn't "jar",
/per se/), but it definitely stands out as another one of those
tell-tale signs that foretell /hic erunt plures dracones/.
Next time I'm at my work machine, I'll check the file I was
looking at the other day, to see if they do that or similar.
Phil
--
If "law-abiding citizens have nothing to fear" from privacy-invading
technologies and policies, then law-abiding governments should have
nothing to fear from whistleblowers.
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2013-08-28 22:27 -0400 |
| Message-ID | <tnbt199f6992lrs14d16tnd3kmnngk5uqs@4ax.com> |
| In reply to | #35858 |
On Mon, 26 Aug 2013 10:59:43 -0700, Keith Thompson <kst-u@mib.org> wrote: <snip> > I know what !strcmp(s1, s2) means, but I dislike it. > > Many functions return a logically Boolean result, even if the result > isn't of type bool or _Bool. By "logically Boolean", I mean that > the result answers a yes/no question without adding more information. > > strcmp is not one of those functions, so I dislike using its result > either as a condition or as the operand of "!". For much the same > reason, I dislike writing "if (ptr)" and strongly prefer "if (ptr != NULL)". > I agree on strcmp, partly because it's ternary (as you note downthread) but I think mostly because 'compare' doesn't connote to me which case is true. If it had been named strunequal or strdifferent -- still returning 0 for equal and >0 or <0 for the two different types of unequal -- I would be happy to write it as a pseudo-boolean in the cases where I only care about equal/unequal, which I estimate is well over half, and write the >0 or <0 only when I care about direction. But those names would have been too long in PDP-11 days; strdiff works for me about as well as memcpy, but struneq just looks silly. OTOH I disagree about pointers. Maybe it's a fair bit of LISPing, but the first attribute I think of about almost any pointer, regardless of target type, is possible nullness. I find ptr or !ptr natural, but I'm also fine with !=NULL and ==NULL if the style uses that. > But of course that wasn't the point of the question. Using a different > example, would you even consider writing > > if (5 == strlen(s)) > > rather than > > if (strlen(s) == 5) > > if it weren't for the "==" vs. "=" issue? > Probably not for a simple case like that, and the first 2 or 3 times I read such it did slow me up a bit before I got used to it. But if s is more complicated -- maybe if enough to put the ==5 way to the right and definitely if enough to put it on a subsequent line -- I would be much more likely to keep the 5 'up front'. OTOH in those cases I might consider doing the complicated part in a separate assignment and reducing it to the simple case -- at least for if; comparable cases in while and for are harder.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2013-08-26 19:18 +0000 |
| Message-ID | <slrn3vfsl1nagj.atm.ike@iceland.freeshell.org> |
| In reply to | #35841 |
On 2013-08-26, Keith Thompson <kst-u@mib.org> wrote:
> Ike Naar <ike@iceland.freeshell.org> writes:
>> On 2013-08-25, Keith Thompson <kst-u@mib.org> wrote:
>>> James Kuyper <jameskuyper@verizon.net> writes:
>>>> On 08/24/2013 03:05 PM, Sharwan Joram wrote:
>>> [...]
>>>>> if ( NULL == parameters[parametercount]){
>>>
>>> This is what's known as a "Yoda conndition"
>>><http://en.wikipedia.org/wiki/Yoda_Conditions>. I know that a lot of
>>> programmers like them, and for somewhat valid reasons, but personally I
>>> find them jarring and unnecessary. Personally, I'd write that as:
>>>
>>> if (parameters[parametercount] == NULL) {
>>
>> Does it matter? The == operator is symmetric, (X==Y) == (Y==X).
>>
>> If (X==Y) is jarring and unnecessary, then, for symmetry reasons
>> (Y==X) is unnecessary and jarring.
> [...]
>
> Yes, it matters *to me* (and to plenty of other people). "==" is
> commutative as far as the language is concerned, but code should be
> written both for the compiler and for the human reader.
>
> X==Y is a poor example for this, since X==Y and Y==X are pretty much
> equally readable.
X and Y were meant to be placeholders for arbitrary subexpressions.
I prefer to treat (X==Y) as a mathematical formula (stating that
subjects X and Y have equal values), rather than shoehorn it into
an English sentence that has X, but not Y, as its subject.
How about Yodaness when both operands are non-constant, as in
(sin(alpha) == cos(beta)) ?.
Would it now matter which operand goes on the left side?
What if it's unknown which of the operands is constant?
Consider the expression (pNeedle == pHaystack).
If we assume that pNeedle is variable and pHaystack is
constant, this expression is, supposedly, perfectly readable.
But if it turns out that pNeedle is constant and pHaystack is
variable, the same expression suddenly becomes Yoda? So Yodaness
is not a syntactic property of the expression itself, but also
depends on additional knowledge that may or may not be obvious from
looking at the expression and its context, and that even may change
at runtime?
I think the main purpose of the == operator is to test whether
two values are equal. For that purpose it does not really matter
whether operands are constant or not: it's equality we're
interested in, not constness. Taking constness into consideration
just complicates things unnecessarily; so let that not influence
the way equalities are notated.
By the way, does Yodaness apply to other commutative operators as
well? Which one of (2 * f(x)) and (f(x) * 2) is Yoda, and why?
> The problem (for me) is when programmers write things
> like:
> if (0 == strcmp(s1, s2))
> rather than
> if (strcmp(s1, s2) == 0)
>
> When comparing a computed value to a constant, I'm asking a question
> about the computed value: (Is it equal to this constant?) You can
> ask a question about a constant: (Is it equal to this computed
> value?), but I personally find that to be an awkward way to ask
> the same question.
It might help to re-phrase the question to one that is more symmetric
in its operands, e.g. "are ... and ... equal?".
> If you find (strcmp(s1, s2) == 0) just as readable and natural as
> (0 == strcmp(s1, s2)), that's great for you; apparently your brain
> works just a little bit differently than mine.
>
> If your only criterion for choosing between two different ways
> of writing something is that they have the same language-level
> semantics, that should mean you have no preference between arr[i]
> and i[arr],
In this case I'd prefer arr[i]. There is a longstanding tradition
in programming languages to write arr[i]. C allows i[arr], but other
programming languages don't. In mathematics notation one sometimes
writes 'arr' with a subscripted 'i' to the right, but I've never
seen that the other way around.
In contrast, the equality operator is symmetric both in mathematics
and in most (every?) programming language that I know of.
> or between
> if (foo) {
> /* ... */
> }
>
> and
>
> if (!foo); else {
> /* ... */
> }
>
> but I know which I'd rather see.
I'd prefer the first form because it's simpler.
> I know why Yoda conditions are used, and it's a valid reason.
> But would you even consider writing
>
> if (0 == strcmp(s1, s2))
>
> if it weren't for the "==" vs. "=" issue?
Actually the Yoda form can be slightly more readable when the
function call has a long argument list, as in
if (3 == scanf("%g %g %g", &latitude, &longitude, &elevation))
one can immediately see that the returnvalue of scanf is compared to 3,
because the 3 is close to the scanf, whereas in
if (scanf("%g %g %g", &latitude, &longitude, &elevation) == 3)
the 3 and the scanf are far apart.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-26 15:41 -0400 |
| Message-ID | <521BAF83.6040600@verizon.net> |
| In reply to | #35861 |
On 08/26/2013 03:18 PM, Ike Naar wrote: ... > How about Yodaness when both operands are non-constant, as in > (sin(alpha) == cos(beta)) ?. > Would it now matter which operand goes on the left side? Of course not - the only argument ever presented for Yoda Conditions is protection against the possibility of mistyping = instead of ==. Such protection is only needed when one of the operands is an lvalue; such protection is only possible if the other is not an lvalue. It is neither needed nor possible in this case. > What if it's unknown which of the operands is constant? > Consider the expression (pNeedle == pHaystack). > If we assume that pNeedle is variable and pHaystack is > constant, this expression is, supposedly, perfectly readable. > But if it turns out that pNeedle is constant and pHaystack is > variable, the same expression suddenly becomes Yoda? So Yodaness > is not a syntactic property of the expression itself, ... The relevant property is lvalueness. > ... but also > depends on additional knowledge that may or may not be obvious from > looking at the expression and its context, ... If you're writing code so obfuscated that it leaves you uncertain which expressions are lvalues, you've got bigger problems than can be dealt with by using Yoda conditions. > ... and that even may change > at runtime? Nothing that occurs at runtime can change whether or not a given expression is an lvalue. > I think the main purpose of the == operator is to test whether > two values are equal. For that purpose it does not really matter > whether operands are constant or not: it's equality we're > interested in, not constness. Taking constness into consideration > just complicates things unnecessarily; so let that not influence > the way equalities are notated. > > By the way, does Yodaness apply to other commutative operators as > well? Which one of (2 * f(x)) and (f(x) * 2) is Yoda, and why? Do you know of any other commutative operators for which a common typo converts them into a different operator for which one order is a constraint violation, and the other is perfectly legal code that does something quite different from what it would have done without the typo? The other operator is, of course, necessarily not commutative. There might be some other such pair of operators - I don't claim any certainty about that. However, but I think the ==/= typo is overwhelmingly the most common such pair.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2013-08-26 12:58 -0700 |
| Message-ID | <fc9f9e14-8b31-4dc5-a9e8-168d4e1e3690@googlegroups.com> |
| In reply to | #35864 |
On Monday, August 26, 2013 8:41:55 PM UTC+1, James Kuyper wrote: > On 08/26/2013 03:18 PM, Ike Naar wrote: > > Do you know of any other commutative operators for which a common > typo converts them into a different operator for which one order > is a constraint violation, and the other is perfectly legal code > that does something quite different from what it would have done > without the typo? > > The other operator is, of course, necessarily not commutative. > The +/= pair. They're generally on the same key, so drawpixel(x + 2, y = 2); is a common typo, and it's irritating that it compiles. However unlike == / =, the difference applies to every language. Even if you know C very well, often you don't see == / = mistakes, whilst +/= leaps out.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-08-26 20:52 +0000 |
| Message-ID | <kvgf68$1p3$1@speranza.aioe.org> |
| In reply to | #35867 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: (snip) >> The other operator is, of course, necessarily >> not commutative. > The +/= pair. They're generally on the same key, so > drawpixel(x + 2, y = 2); > is a common typo, and it's irritating that it compiles. However > unlike == / =, the difference applies to every language. Even > if you know C very well, often you don't see == / = mistakes, > whilst +/= leaps out. Not every language. Many don't allow assignment in the middle of expressions. In Fortran, assignment is a statement, not an operator. In PL/I, assignment is also a statement, and = is the relational operator. x,y=1; /* multiple assignment */ x=y=1; /* relational operator */ -- glen
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2013-08-26 14:35 -0700 |
| Message-ID | <d3e8349e-3cbb-40d8-8a47-d063dcc37090@googlegroups.com> |
| In reply to | #35875 |
On Monday, August 26, 2013 9:52:24 PM UTC+1, glen herrmannsfeldt wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > > is a common typo, and it's irritating that it compiles. However > > unlike == / =, the difference applies to every language. Even > > if you know C very well, often you don't see == / = mistakes, > > whilst +/= leaps out. > > Not every language. Many don't allow assignment in the middle > of expressions. In Fortran, assignment is a statement, not an > operator. > Every language except brainf**k and ilk uses + for addition, and virtually every one uses =, which is never used for addition. (OK, go on, post some C++ which overloads the assignment operator). So the +/= typo applies to every language. It will always generate an expression which is wrong, in every language known to the programmer. It leaps out. OTOH if(Nstates = 52) is correct Fortran with the obvious meaning. In C, the logic will break when Texas secedes, but it will appear to work until then. So the error doesn't leap out.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-08-27 00:48 +0100 |
| Message-ID | <0.8291df93d9c560ee63e8.20130827004825BST.87eh9g9fp2.fsf@bsb.me.uk> |
| In reply to | #35885 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> > OTOH if(Nstates = 52) is correct Fortran with the obvious meaning. Since when? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2013-08-28 22:27 -0400 |
| Message-ID | <ecbt19tgk5gt0mh413j3f3n2h6komct4t9@4ax.com> |
| In reply to | #35902 |
On Tue, 27 Aug 2013 00:48:25 +0100, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > <snip> > > OTOH if(Nstates = 52) is correct Fortran with the obvious meaning. > > Since when? F90. But .EQ. and friends remain also available (and fill the dusty decks off to the horizon, or something like that). As I believe glen noted elsethread, there's no ambiguity in Fortran because it allows assignment only as a (top-level) statement not a (nestable) expression.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-08-29 03:40 +0100 |
| Message-ID | <0.7e1f0add86d4a6463b0a.20130829034054BST.87hae95idl.fsf@bsb.me.uk> |
| In reply to | #36055 |
David Thompson <dave.thompson2@verizon.net> writes: > On Tue, 27 Aug 2013 00:48:25 +0100, Ben Bacarisse > <ben.usenet@bsb.me.uk> wrote: > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> <snip> >> > OTOH if(Nstates = 52) is correct Fortran with the obvious meaning. >> >> Since when? > > F90. But .EQ. and friends remain also available (and fill the dusty > decks off to the horizon, or something like that). > > As I believe glen noted elsethread, there's no ambiguity in Fortran > because it allows assignment only as a (top-level) statement not a > (nestable) expression. I can't get gfortran to accept it, and I can't find it in the 2008 draft standard (the first one I could find for no money). == yes, that's been around for some time. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2013-09-04 00:01 -0400 |
| Message-ID | <hnib29lnbiud9fqe3133e4dm21p3ui9bj1@4ax.com> |
| In reply to | #36059 |
On Thu, 29 Aug 2013 03:40:54 +0100, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > David Thompson <dave.thompson2@verizon.net> writes: > > > On Tue, 27 Aug 2013 00:48:25 +0100, Ben Bacarisse > > <ben.usenet@bsb.me.uk> wrote: > > > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> <snip> > >> > OTOH if(Nstates = 52) is correct Fortran with the obvious meaning. > >> > >> Since when? > > > > F90. <snip> > I can't get gfortran to accept it, and I can't find it in the 2008 draft > standard (the first one I could find for no money). == yes, that's been > around for some time. (Confirmed elsethread) you're right. Sorry, brainslip.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-08-29 05:27 +0000 |
| Message-ID | <kvmm3i$3vi$1@speranza.aioe.org> |
| In reply to | #36055 |
David Thompson <dave.thompson2@verizon.net> wrote: (snip on Fortran = operator) > F90. But .EQ. and friends remain also available (and fill the dusty > decks off to the horizon, or something like that). > As I believe glen noted elsethread, there's no ambiguity in Fortran > because it allows assignment only as a (top-level) statement not a > (nestable) expression. Even more, unlike C, subscript and substring are not operators in Fortran. You can't subscript a function returning an array without assigning the value to an array first. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-08-30 01:40 +0100 |
| Message-ID | <0.e2f03ff0b280feca1ce1.20130830014021BST.87eh9c2eq2.fsf@bsb.me.uk> |
| In reply to | #36065 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > David Thompson <dave.thompson2@verizon.net> wrote: > > (snip on Fortran = operator) The folks over in comp.lang.fortran have confirmed that Fortran does not have a = operator. (I'm not saying you said there was one, but this snip comment could be read as not disagreeing with David Thompson). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web