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 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-08-26 16:54 +0000 |
| Message-ID | <kvg17p$pbq$1@speranza.aioe.org> |
| In reply to | #35828 |
James Kuyper <jameskuyper@verizon.net> wrote: > On 08/26/2013 02:40 AM, Ike Naar wrote: (snip) >> Does it matter? The == operator is symmetric, (X==Y) == (Y==X). > Yes, it matters - because it's intended to protect against the typo > which replaces == with =, by ensuring that it would cause a constraint > violation. The assignment operator is very definitely not symmetric. Well, don't do that. There are an infinite number of ways you can code C incorrectly, and this is one. There is a general rule that you should write for readability, and as common mathematical English phrasing normally doesn't work that way, it is more difficult to read. Now, Java came up with another solution to this problem. The expression in if must have type boolean, and, except in the case of assignment to a boolean variable, and assignment won't be boolean, the assignment won't compile. It isn't possible to change C now, but to me readability is important, and in many cases it sounds wrong backwards. -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-26 13:26 -0400 |
| Message-ID | <521B8FE3.1000005@verizon.net> |
| In reply to | #35850 |
On 08/26/2013 12:54 PM, glen herrmannsfeldt wrote:
> James Kuyper <jameskuyper@verizon.net> wrote:
>> On 08/26/2013 02:40 AM, Ike Naar wrote:
>
> (snip)
>
>>> Does it matter? The == operator is symmetric, (X==Y) == (Y==X).
>
>> Yes, it matters - because it's intended to protect against the typo
>> which replaces == with =, by ensuring that it would cause a constraint
>> violation. The assignment operator is very definitely not symmetric.
>
> Well, don't do that.
If you know how to eliminate (not just reduce) errors created when
writing C (or anything else, for that matter), I'd appreciate hearing
about how it was done. If you have time for that - the secret to doing
something like that could make you very rich, if handled properly.
I don't know any such secret - so instead I use methods designed to
minimize the number of mistakes I make (which don't work very well). The
single most effective such method I've developed is to always write
bookend code (for instance, '(' and ')', or '{' and '}', or 'fopen()'
and 'fclose()') first, and then fill in what happens between the
bookends second. I almost never make "missing bookend" errors anymore.
I also use methods to ensure that most of mistakes I actually make get
caught (which works significantly better, though not as well as I'd
like). Yoda conditionals are one such method, though not one I've
decided to adopt. I agree that I find it uncomfortable - but I'd not
criticize anyone for feeling differently about that.
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2013-08-28 22:27 -0400 |
| Message-ID | <khbt19p58b88193bkteg3opr0ebhehrrgo@4ax.com> |
| In reply to | #35850 |
On Mon, 26 Aug 2013 16:54:17 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > James Kuyper <jameskuyper@verizon.net> wrote: > > On 08/26/2013 02:40 AM, Ike Naar wrote: <snip: Yoda conditions> > Now, Java came up with another solution to this problem. > The expression in if must have type boolean, and, except in > the case of assignment to a boolean variable, and assignment > won't be boolean, the assignment won't compile. > Java didn't invent this; algol68 has a distinct boolean type (although I don't recall if this case is coercible) and does have nestable assignment, but (canonically) using := which is harder to mistake. Fortran>=77 also has boolean, as do Pascal and Ada, but they have (as you noted) assignment as a statement not a (sub)expression, plus the latter two use := . I don't know about the other Wirth languages. The only non-C-family language I know to use integer 1/0 for boolean is APL. FORTH uses integer nonzero/0 with a preference for -1 as the nonzero, but FORTH is almost as typeless as BCPL, plus the syntax for both assignment and if are radically different from C. > It isn't possible to change C now, but to me readability is > important, and in many cases it sounds wrong backwards. > > -- glen
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-08-29 05:18 +0000 |
| Message-ID | <kvmljv$2qm$1@speranza.aioe.org> |
| In reply to | #36057 |
David Thompson <dave.thompson2@verizon.net> wrote: (snip, I wrote) >> Now, Java came up with another solution to this problem. >> The expression in if must have type boolean, and, except in >> the case of assignment to a boolean variable, and assignment >> won't be boolean, the assignment won't compile. > Java didn't invent this; algol68 has a distinct boolean type (although > I don't recall if this case is coercible) and does have nestable > assignment, but (canonically) using := which is harder to mistake. It has been a long time since I wrote ALGOL. Does it allow assignment in places, such as inside and IF, where it might be confused for a relational expression? One that I do remember for ALGOL is that it uses IF THEN ELSE for the conditional operator. I := IF J>1 THEN 3 ELSE 4; > Fortran>=77 also has boolean, as do Pascal and Ada, but they have (as > you noted) assignment as a statement not a (sub)expression, plus the > latter two use := . I don't know about the other Wirth languages. > The only non-C-family language I know to use integer 1/0 for boolean > is APL. FORTH uses integer nonzero/0 with a preference for -1 as the > nonzero, but FORTH is almost as typeless as BCPL, plus the syntax for > both assignment and if are radically different from C. PL/I uses '0'B and '1'B, bit strings of length one. It allows conversion beteen bit (or character) strings and numeric types, though. But also PL/I, like Fortran, has an assignment statement. The = in assignment has a differnet meaning from = as a relational operator. Multiple assignment is done with , not =. -- glen
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2013-09-04 00:01 -0400 |
| Message-ID | <6oib29hu0d9i62adbdu5feb10diu5j3123@4ax.com> |
| In reply to | #36064 |
On Thu, 29 Aug 2013 05:18:55 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > David Thompson <dave.thompson2@verizon.net> wrote: > > (snip, I wrote) > > >> Now, Java came up with another solution to this problem. > >> The expression in if must have type boolean, and, except in > >> the case of assignment to a boolean variable, and assignment > >> won't be boolean, the assignment won't compile. > > > Java didn't invent this; algol68 has a distinct boolean type (although > > I don't recall if this case is coercible) and does have nestable > > assignment, but (canonically) using := which is harder to mistake. > > It has been a long time since I wrote ALGOL. Does it allow assignment > in places, such as inside and IF, where it might be confused for > a relational expression? > There were two algols, rather different. algol 60 could be thought of, very roughly, as a nicer syntax for nearly Fortran semantics plus call-by-name (which proved a pretty spectacular dead-end). algol 68 was an attempt, partly successful, to combine nearly all known semantics into one rather minimalist syntax, philosophically a bit like LISP. Except for declarations, pretty much everything functioned as an expression (although not always called that) and (unless my memory is playing tricks again) that includes using at least a boolean assignment -- as I hinted, I don't recall for sure about other types -- as a value and thus a predicate. > One that I do remember for ALGOL is that it uses IF THEN ELSE > for the conditional operator. > > I := IF J>1 THEN 3 ELSE 4; > Either keywords IF THEN ... FI *or* symbols ( | |: ). Similarly for loops and most other things. The keywords are more readable (if you know English) but the symbols are more math-y and international. > > Fortran>=77 also has boolean, as do Pascal and Ada, but they have (as > > you noted) assignment as a statement not a (sub)expression, plus the > > latter two use := . I don't know about the other Wirth languages. > > > The only non-C-family language I know to use integer 1/0 for boolean > > is APL. FORTH uses integer nonzero/0 with a preference for -1 as the > > nonzero, but FORTH is almost as typeless as BCPL, plus the syntax for > > both assignment and if are radically different from C. > > PL/I uses '0'B and '1'B, bit strings of length one. It allows > conversion beteen bit (or character) strings and numeric types, > though. > > But also PL/I, like Fortran, has an assignment statement. > The = in assignment has a differnet meaning from = as a relational > operator. Multiple assignment is done with , not =. > > -- glen
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-09-04 05:40 +0000 |
| Message-ID | <l06h52$lfd$1@speranza.aioe.org> |
| In reply to | #36265 |
David Thompson <dave.thompson2@verizon.net> wrote: (snip, I wrote) >> It has been a long time since I wrote ALGOL. Does it allow assignment >> in places, such as inside and IF, where it might be confused for >> a relational expression? > There were two algols, rather different. algol 60 could be thought of, > very roughly, as a nicer syntax for nearly Fortran semantics plus > call-by-name (which proved a pretty spectacular dead-end). algol 68 > was an attempt, partly successful, to combine nearly all known > semantics into one rather minimalist syntax, philosophically a bit > like LISP. Except for declarations, pretty much everything functioned > as an expression (although not always called that) and (unless my > memory is playing tricks again) that includes using at least a boolean > assignment -- as I hinted, I don't recall for sure about other types > -- as a value and thus a predicate. I used to have an Algol 58 book near my computer, but not now. >> One that I do remember for ALGOL is that it uses IF THEN ELSE >> for the conditional operator. >> I := IF J>1 THEN 3 ELSE 4; > Either keywords IF THEN ... FI *or* symbols ( | |: ). Similarly for > loops and most other things. The keywords are more readable (if you > know English) but the symbols are more math-y and international. Some years ago, I used ALGOL-10 on the PDP-10. I don' t know that I had a manual for it, though, so I might not have known all the features. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2013-08-27 08:54 +1200 |
| Message-ID | <b81tkeF3oitU1@mid.individual.net> |
| In reply to | #35828 |
James Kuyper wrote:
> On 08/26/2013 02:40 AM, Ike Naar wrote:
>> 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).
>
> Yes, it matters - because it's intended to protect against the typo
> which replaces == with =, by ensuring that it would cause a constraint
> violation. The assignment operator is very definitely not symmetric.
The best way to protect against that particular typo is decent unit tests.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2013-08-26 21:09 +0000 |
| Message-ID | <slrn3vfsl1ngvd.atm.ike@iceland.freeshell.org> |
| In reply to | #35876 |
On 2013-08-26, Ian Collins <ian-news@hotmail.com> wrote:
> James Kuyper wrote:
>> On 08/26/2013 02:40 AM, Ike Naar wrote:
>>> 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).
>>
>> Yes, it matters - because it's intended to protect against the typo
>> which replaces == with =, by ensuring that it would cause a constraint
>> violation. The assignment operator is very definitely not symmetric.
>
> The best way to protect against that particular typo is decent unit tests.
Do not overestimate the value of unit tests.
Let's take, for example, a piece of code that multiplies two
32-bit numbers to obtain a 64-bit result.
A decent test (that covers all cases) would require 2^64 test cases
which is at least impractical.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2013-08-27 09:16 +1200 |
| Message-ID | <b81ut8F3oitU2@mid.individual.net> |
| In reply to | #35878 |
Ike Naar wrote:
> On 2013-08-26, Ian Collins <ian-news@hotmail.com> wrote:
>> James Kuyper wrote:
>>> On 08/26/2013 02:40 AM, Ike Naar wrote:
>>>> 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).
>>>
>>> Yes, it matters - because it's intended to protect against the typo
>>> which replaces == with =, by ensuring that it would cause a constraint
>>> violation. The assignment operator is very definitely not symmetric.
>>
>> The best way to protect against that particular typo is decent unit tests.
>
> Do not overestimate the value of unit tests.
> Let's take, for example, a piece of code that multiplies two
> 32-bit numbers to obtain a 64-bit result.
What has that got to do with this particular typo?
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2013-08-26 21:39 +0000 |
| Message-ID | <slrn3vfsl1nion.9qo.ike@iceland.freeshell.org> |
| In reply to | #35881 |
On 2013-08-26, Ian Collins <ian-news@hotmail.com> wrote:
> Ike Naar wrote:
>> On 2013-08-26, Ian Collins <ian-news@hotmail.com> wrote:
>>> James Kuyper wrote:
>>>> On 08/26/2013 02:40 AM, Ike Naar wrote:
>>>>> 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).
>>>>
>>>> Yes, it matters - because it's intended to protect against the typo
>>>> which replaces == with =, by ensuring that it would cause a constraint
>>>> violation. The assignment operator is very definitely not symmetric.
>>>
>>> The best way to protect against that particular typo is decent unit tests.
>>
>> Do not overestimate the value of unit tests.
>> Let's take, for example, a piece of code that multiplies two
>> 32-bit numbers to obtain a 64-bit result.
>
> What has that got to do with this particular typo?
Everything. If you know the typo in your progam, you
don't need tests to find it, you just fix the typo.
If you don't know there's a typo, the only way to be sure you
find one is to test all possible cases.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2013-08-27 09:42 +1200 |
| Message-ID | <b820euF3oitU5@mid.individual.net> |
| In reply to | #35887 |
Ike Naar wrote:
> On 2013-08-26, Ian Collins <ian-news@hotmail.com> wrote:
>> Ike Naar wrote:
>>> On 2013-08-26, Ian Collins <ian-news@hotmail.com> wrote:
>>>> James Kuyper wrote:
>>>>> On 08/26/2013 02:40 AM, Ike Naar wrote:
>>>>>> 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).
>>>>>
>>>>> Yes, it matters - because it's intended to protect against the typo
>>>>> which replaces == with =, by ensuring that it would cause a constraint
>>>>> violation. The assignment operator is very definitely not symmetric.
>>>>
>>>> The best way to protect against that particular typo is decent unit tests.
>>>
>>> Do not overestimate the value of unit tests.
>>> Let's take, for example, a piece of code that multiplies two
>>> 32-bit numbers to obtain a 64-bit result.
>>
>> What has that got to do with this particular typo?
>
> Everything. If you know the typo in your progam, you
> don't need tests to find it, you just fix the typo.
> If you don't know there's a typo, the only way to be sure you
> find one is to test all possible cases.
But you will know as soon as you add the code and it fails its test.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2013-08-26 21:52 +0000 |
| Message-ID | <slrn3vfsl1njhd.gs2.ike@iceland.freeshell.org> |
| In reply to | #35888 |
On 2013-08-26, Ian Collins <ian-news@hotmail.com> wrote:
> Ike Naar wrote:
>> On 2013-08-26, Ian Collins <ian-news@hotmail.com> wrote:
>>> Ike Naar wrote:
>>>> On 2013-08-26, Ian Collins <ian-news@hotmail.com> wrote:
>>>>> James Kuyper wrote:
>>>>>> On 08/26/2013 02:40 AM, Ike Naar wrote:
>>>>>>> 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).
>>>>>>
>>>>>> Yes, it matters - because it's intended to protect against the typo
>>>>>> which replaces == with =, by ensuring that it would cause a constraint
>>>>>> violation. The assignment operator is very definitely not symmetric.
>>>>>
>>>>> The best way to protect against that particular typo is decent unit tests.
>>>>
>>>> Do not overestimate the value of unit tests.
>>>> Let's take, for example, a piece of code that multiplies two
>>>> 32-bit numbers to obtain a 64-bit result.
>>>
>>> What has that got to do with this particular typo?
>>
>> Everything. If you know the typo in your progam, you
>> don't need tests to find it, you just fix the typo.
>> If you don't know there's a typo, the only way to be sure you
>> find one is to test all possible cases.
>
> But you will know as soon as you add the code and it fails its test.
That depends. If you're lucky, bad code will fail the tests. If
you're not lucky (i.e. if the test subset did not cover all possible
failures) bad code may pass the tests. As long as the tests don't
cover all possible failures, passing the tests does not guarantee
the code is okay.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2013-08-26 17:46 -0500 |
| Message-ID | <kvglo5$sdj$1@dont-email.me> |
| In reply to | #35878 |
Ike Naar wrote:
> On 2013-08-26, Ian Collins <ian-news@hotmail.com> wrote:
>> James Kuyper wrote:
>>> On 08/26/2013 02:40 AM, Ike Naar wrote:
>>>> 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).
>>>
>>> Yes, it matters - because it's intended to protect against the typo
>>> which replaces == with =, by ensuring that it would cause a constraint
>>> violation. The assignment operator is very definitely not symmetric.
>>
>> The best way to protect against that particular typo is decent unit tests.
>
> Do not overestimate the value of unit tests.
> Let's take, for example, a piece of code that multiplies two
> 32-bit numbers to obtain a 64-bit result.
> A decent test (that covers all cases) would require 2^64 test cases
> which is at least impractical.
>
No point in that - use the symmetries of the situation
to make it faster. Walk a one through both operands, for example,
then add some reinforcement about zero and in
the overflow cases if they're signed.
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-26 17:12 -0400 |
| Message-ID | <521BC4BD.30309@verizon.net> |
| In reply to | #35876 |
On 08/26/2013 04:54 PM, Ian Collins wrote: > James Kuyper wrote: ... >> Yes, it matters - because it's intended to protect against the typo >> which replaces == with =, by ensuring that it would cause a constraint >> violation. The assignment operator is very definitely not symmetric. > > The best way to protect against that particular typo is decent unit tests. I greatly prefer catching problems during compilation rather than testing.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2013-08-27 09:17 +1200 |
| Message-ID | <b81uvkF3oitU3@mid.individual.net> |
| In reply to | #35879 |
James Kuyper wrote: > On 08/26/2013 04:54 PM, Ian Collins wrote: >> James Kuyper wrote: > .... >>> Yes, it matters - because it's intended to protect against the typo >>> which replaces == with =, by ensuring that it would cause a constraint >>> violation. The assignment operator is very definitely not symmetric. >> >> The best way to protect against that particular typo is decent unit tests. > > I greatly prefer catching problems during compilation rather than testing. So do I. For my projects make == make test. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-26 18:45 -0400 |
| Message-ID | <521BDA77.4060905@verizon.net> |
| In reply to | #35882 |
On 08/26/2013 05:17 PM, Ian Collins wrote: > James Kuyper wrote: >> On 08/26/2013 04:54 PM, Ian Collins wrote: >>> James Kuyper wrote: >> .... >>>> Yes, it matters - because it's intended to protect against the typo >>>> which replaces == with =, by ensuring that it would cause a constraint >>>> violation. The assignment operator is very definitely not symmetric. >>> >>> The best way to protect against that particular typo is decent unit tests. >> >> I greatly prefer catching problems during compilation rather than testing. > > So do I. For my projects make == make test. Building my code takes only seconds per module. A comprehensive test of one module would take anything from minutes up to days to run, depending upon what precisely that module does. A test that is not comprehensive would not be an adequate substitute for good warning messages from the compiler. A test that is comprehensive requires a lot more work than writing the code that it is testing.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2013-08-27 11:03 +1200 |
| Message-ID | <b8255dFf8m0U2@mid.individual.net> |
| In reply to | #35898 |
James Kuyper wrote: > On 08/26/2013 05:17 PM, Ian Collins wrote: >> James Kuyper wrote: >>> On 08/26/2013 04:54 PM, Ian Collins wrote: >>>> James Kuyper wrote: >>> .... >>>>> Yes, it matters - because it's intended to protect against the typo >>>>> which replaces == with =, by ensuring that it would cause a constraint >>>>> violation. The assignment operator is very definitely not symmetric. >>>> >>>> The best way to protect against that particular typo is decent unit tests. >>> >>> I greatly prefer catching problems during compilation rather than testing. >> >> So do I. For my projects make == make test. > > Building my code takes only seconds per module. A comprehensive test of > one module would take anything from minutes up to days to run, > depending upon what precisely that module does. It sounds like your tests aren't unit tests, more like module acceptance tests. > A test that is not > comprehensive would not be an adequate substitute for good warning > messages from the compiler. I didn't say it was, but there are plenty of logic errors a compiler can't spot that can quickly and easily be caught by unit tests (especially if the code is written to pass the tests). One test for the quality of unit tests is whether lint spots anything in the code the tests missed! > A test that is comprehensive requires a lot > more work than writing the code that it is testing. I agree and that is why I always advocate more than one level of testing. One mission (not life) critical product I used to manage had three layers of testing: unit, acceptance and release. The respective testing cycles were seconds, hours and days. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-26 08:52 -0700 |
| Message-ID | <lnsixwla9n.fsf@nuthaus.mib.org> |
| In reply to | #35821 |
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. 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.
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], or between
if (foo) {
/* ... */
}
and
if (!foo); else {
/* ... */
}
but I know which I'd rather see.
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?
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-08-26 17:20 +0000 |
| Message-ID | <kvg2o1$tql$1@speranza.aioe.org> |
| In reply to | #35841 |
Keith Thompson <kst-u@mib.org> wrote:
(big 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?
No, I would write
if( ! strcmp(s1, s2))
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.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-26 10:59 -0700 |
| Message-ID | <lnbo4kl4ds.fsf@nuthaus.mib.org> |
| In reply to | #35852 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>
> (big 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?
>
> 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.
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)".
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.
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.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web