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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2013-08-26 17:51 -0500 |
| Message-ID | <kvgm16$sdj$2@dont-email.me> |
| In reply to | #35867 |
Malcolm McLean wrote: > 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. > So find . -name "*.[ch]" | xargs grep if | grep -v "==" That doesn't get 'em all. but it's close. And yes, I have these things on my Windows machines, too. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2013-08-27 08:24 +0000 |
| Message-ID | <slrn3vfsl1ooi0.4va.ike@iceland.freeshell.org> |
| In reply to | #35864 |
On 2013-08-26, James Kuyper <jameskuyper@verizon.net> wrote: > [...] 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. The Wikipedia page, mentioned in Keith's post that started this discussion about Yoda conditions, presents two arguments (although the second argument applies to Java code and not to C). The Wikipedia article (as I understand it) defines a Yoda condition as a condition in which the left operand is a constant and the right operand is a variable; lvalueness is not mentioned - at least not explicitly. >> [...] > The relevant property is lvalueness. >> [...] > 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. >> [...] > Nothing that occurs at runtime can change whether or not a given > expression is an lvalue. All agreed, if the relevant property is lvalueness instead of constness. Although I'd expect that "lvalue" should actually be "modifiable lvalue". Let me see if I understand your definition of Yoda condition correctly: A Yoda condition (X==Y) is a condition that is protected against accidental assignment, while the reverse condition (Y==X) is unprotected. That means: - X is an expression that is not a modifiable lvalue; so that (X=Y) violates 6.5.16, constraint 2. - Y is a modifiable lvalue; so that (Y=X) is an accidental but valid assignment. Examples: int var; int const con; char *s1, *s2; (42 == var); /* Yoda condition */ (con == var); /* Yoda condition */ (42 == var+1); /* not Yoda condition */ (42 == con); /* not Yoda condition */ (0 == strcmp(s1, s2)); /* not Yoda condition */ Right?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-27 08:12 -0400 |
| Message-ID | <kvi53k$a72$1@dont-email.me> |
| In reply to | #35933 |
On 08/27/2013 04:24 AM, Ike Naar wrote: ... > Let me see if I understand your definition of Yoda condition correctly: I'd never heard of that term before this thread started, so I really have no definition for it. However, I know of a closely related concept that applies to every example I've seen of a Yoda condition. > A Yoda condition (X==Y) is a condition that is protected against > accidental assignment, while the reverse condition (Y==X) is unprotected. > That means: > - X is an expression that is not a modifiable lvalue; > so that (X=Y) violates 6.5.16, constraint 2. > - Y is a modifiable lvalue; > so that (Y=X) is an accidental but valid assignment. > > Examples: > > int var; > int const con; > char *s1, *s2; > > (42 == var); /* Yoda condition */ > (con == var); /* Yoda condition */ > (42 == var+1); /* not Yoda condition */ > (42 == con); /* not Yoda condition */ > (0 == strcmp(s1, s2)); /* not Yoda condition */ > > Right? All of the above correctly describes the concept that I'm thinking of. The use of the phrase "modifiable lvalue" marks this as specific to C, C++ and related languages. More generally, a Yoda condition is the use X==Y rather than Y==X, despite the equivalence of those expressions, to protect against the typo == > =, because X=Y would be invalid, but Y=X would not be. The details of what makes X=Y invalid could vary from one language to another, and of course the concept is meaningless for languages which don't have both = and ==. If the people who actually use the term "Yoda condition" want to use it in a more restricted sense, such as the one you mentioned from Wikipedia, I'm certainly in no position to stop them; but I would recommend adopting this definition. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-27 11:48 -0700 |
| Message-ID | <ln7gf7hsv9.fsf@nuthaus.mib.org> |
| In reply to | #35939 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 08/27/2013 04:24 AM, Ike Naar wrote:
[...]
>> Examples:
>>
>> int var;
>> int const con;
>> char *s1, *s2;
>>
>> (42 == var); /* Yoda condition */
>> (con == var); /* Yoda condition */
>> (42 == var+1); /* not Yoda condition */
>> (42 == con); /* not Yoda condition */
>> (0 == strcmp(s1, s2)); /* not Yoda condition */
>>
>> Right?
>
> All of the above correctly describes the concept that I'm thinking of.
> The use of the phrase "modifiable lvalue" marks this as specific to C,
> C++ and related languages. More generally, a Yoda condition is the use
> X==Y rather than Y==X, despite the equivalence of those expressions, to
> protect against the typo == > =, because X=Y would be invalid, but Y=X
> would not be. The details of what makes X=Y invalid could vary from one
> language to another, and of course the concept is meaningless for
> languages which don't have both = and ==.
>
> If the people who actually use the term "Yoda condition" want to use it
> in a more restricted sense, such as the one you mentioned from
> Wikipedia, I'm certainly in no position to stop them; but I would
> recommend adopting this definition.
I still think of (0 == strcmp(s1, s2)) as a Yoda condition; that
particular case doesn't guard against "==" vs. "=" errors, but the
cultivated habit of putting the constant on the left does.
http://hegeekshegeek.files.wordpress.com/2012/06/yoda-beatles.jpg
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-26 13:28 -0700 |
| Message-ID | <ln7gf8kxhr.fsf@nuthaus.mib.org> |
| In reply to | #35861 |
Ike Naar <ike@iceland.freeshell.org> writes:
> 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.
Sure, but my argument (whether you agree with it or not) doesn't apply
to 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?
The names "alpha" and "beta" might suggest that "alpha" goes first, but
in general it probably doesn't matter -- though it might depend on the
circumstances.
> 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?
Strictly speaking, constness *is* a syntactic, or at least compile-time,
property of an expression, though it's going to depend on contact
outside the expression.
I'm not sure what to make of (pNeedle == pHaystack); normally one search
for a needle *in* a haystack.
Certainly you can construct a continuum of cases, with comparing a
computed value to a literal constant on one end, and comparing the
results of two clearly symmetric expressions on the other. I admit this
is rather vague, and I don't have a well-defined rule for when the order
is important to me.
> 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.
But *why* do you want to know whether they're equal? What if, in the
problem domain, what you're really doing is asking a question about the
value of some expression (is it equal to 42?), and not asking a question
about 42 (about which you already have complete knowledge)? Putting the
constant on the right can provide a useful clue to the reader.
> 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?
It matters far less for multiplication. I'm not sure I can clearly
articulate 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?".
Logically true, but that doesn't make the Yoda form any clearer to me.
I know "==" is commutative, but (0 == strcmp(s1, s2)) is still clumsy
*to me*.
[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?
>
> 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.
Ok, that's another valid reason for using Yoda conditions. I'd still put
the 3 on the right side myself; I might split it across two lines if I
thought the distance was a problem, or I might store the result in a
temporary.
But setting that aside for a moment (and avoiding the "!strcmp()"
variant):
It would never occur to me to write:
if (42 == x)
rather than
if (x == 42)
if it weren't for the possibility of confusing "==" and "=".
Would you write (42 == x) yourself? Do you really find it *just*
as natural as (x == 42)?
--
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 | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2013-08-26 20:40 +0000 |
| Message-ID | <slrn3vfsl1nf9l.atm.ike@iceland.freeshell.org> |
| In reply to | #35869 |
On 2013-08-26, Keith Thompson <kst-u@mib.org> wrote: > It would never occur to me to write: > if (42 == x) > rather than > if (x == 42) > if it weren't for the possibility of confusing "==" and "=". > Would you write (42 == x) yourself? Do you really find it *just* > as natural as (x == 42)? Yes. Equality is a boolean function operating on two operands, returning "the operands are equal". It does not matter which one of the operands is on the left side of the operator.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-26 14:36 -0700 |
| Message-ID | <lntxicjfsn.fsf@nuthaus.mib.org> |
| In reply to | #35871 |
Ike Naar <ike@iceland.freeshell.org> writes:
> On 2013-08-26, Keith Thompson <kst-u@mib.org> wrote:
>> It would never occur to me to write:
>> if (42 == x)
>> rather than
>> if (x == 42)
>> if it weren't for the possibility of confusing "==" and "=".
>> Would you write (42 == x) yourself? Do you really find it *just*
>> as natural as (x == 42)?
>
> Yes. Equality is a boolean function operating on two operands,
> returning "the operands are equal". It does not matter which
> one of the operands is on the left side of the operator.
Fascinating.
You are of course absolutely correct with respect to the semantics
of the "==" operator; nevertheless (as I've already said) I find
(42 == x) annoyingly awkward -- as do many other people. I take
your word for it that you don't, but I honestly find it surprising.
--
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 | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2013-08-26 21:43 +0000 |
| Message-ID | <slrn3vfsl1nj0q.9qo.ike@iceland.freeshell.org> |
| In reply to | #35886 |
On 2013-08-26, Keith Thompson <kst-u@mib.org> wrote: > Ike Naar <ike@iceland.freeshell.org> writes: >> On 2013-08-26, Keith Thompson <kst-u@mib.org> wrote: >>> It would never occur to me to write: >>> if (42 == x) >>> rather than >>> if (x == 42) >>> if it weren't for the possibility of confusing "==" and "=". >>> Would you write (42 == x) yourself? Do you really find it *just* >>> as natural as (x == 42)? >> >> Yes. Equality is a boolean function operating on two operands, >> returning "the operands are equal". It does not matter which >> one of the operands is on the left side of the operator. > > Fascinating. > > You are of course absolutely correct with respect to the semantics > of the "==" operator; nevertheless (as I've already said) I find > (42 == x) annoyingly awkward -- as do many other people. I take > your word for it that you don't, but I honestly find it surprising. Do you find (42 + x) more or less awkward than (x + 42), and why? If you don't care, then what's the fundamental difference between the + operator and the == operator?
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-08-26 21:59 +0000 |
| Message-ID | <kvgj47$amq$1@speranza.aioe.org> |
| In reply to | #35889 |
Ike Naar <ike@iceland.freeshell.org> wrote: (snip, someone wrote) >> You are of course absolutely correct with respect to the semantics >> of the "==" operator; nevertheless (as I've already said) I find >> (42 == x) annoyingly awkward -- as do many other people. I take >> your word for it that you don't, but I honestly find it surprising. > Do you find (42 + x) more or less awkward than (x + 42), and why? > If you don't care, then what's the fundamental difference between > the + operator and the == operator? Algebra commonly puts the coefficient before the variable, so 2x and not x2. Polynomials are commonly written in order of decreasing power of x, so x+42 instead if 42+x. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-26 15:26 -0700 |
| Message-ID | <lnppt0jdfw.fsf@nuthaus.mib.org> |
| In reply to | #35889 |
Ike Naar <ike@iceland.freeshell.org> writes:
> On 2013-08-26, Keith Thompson <kst-u@mib.org> wrote:
>> Ike Naar <ike@iceland.freeshell.org> writes:
>>> On 2013-08-26, Keith Thompson <kst-u@mib.org> wrote:
>>>> It would never occur to me to write:
>>>> if (42 == x)
>>>> rather than
>>>> if (x == 42)
>>>> if it weren't for the possibility of confusing "==" and "=".
>>>> Would you write (42 == x) yourself? Do you really find it *just*
>>>> as natural as (x == 42)?
>>>
>>> Yes. Equality is a boolean function operating on two operands,
>>> returning "the operands are equal". It does not matter which
>>> one of the operands is on the left side of the operator.
>>
>> Fascinating.
>>
>> You are of course absolutely correct with respect to the semantics
>> of the "==" operator; nevertheless (as I've already said) I find
>> (42 == x) annoyingly awkward -- as do many other people. I take
>> your word for it that you don't, but I honestly find it surprising.
>
> Do you find (42 + x) more or less awkward than (x + 42), and why?
No. Well, now that I think about it, I think I prefer (x + 42), for
reasons I can't necessarily articulate.
> If you don't care, then what's the fundamental difference between
> the + operator and the == operator?
The difference is that "==" is much more natural with the constant on
the right, and with "+" the difference is less striking.
I know that doesn't answer your question.
"Fred is 42 years old" vs. "42 years old is Fred" might shed *some*
light on it, but it's not a great example ("is" in that context does not
denote equality).
--
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-27 16:52 +0300 |
| Message-ID | <877gf7z1ev.fsf@bazspaz.fatphil.org> |
| In reply to | #35889 |
Ike Naar <ike@iceland.freeshell.org> writes: > On 2013-08-26, Keith Thompson <kst-u@mib.org> wrote: > > Ike Naar <ike@iceland.freeshell.org> writes: > >> On 2013-08-26, Keith Thompson <kst-u@mib.org> wrote: > >>> It would never occur to me to write: > >>> if (42 == x) > >>> rather than > >>> if (x == 42) > >>> if it weren't for the possibility of confusing "==" and "=". > >>> Would you write (42 == x) yourself? Do you really find it *just* > >>> as natural as (x == 42)? > >> > >> Yes. Equality is a boolean function operating on two operands, > >> returning "the operands are equal". It does not matter which > >> one of the operands is on the left side of the operator. > > > > Fascinating. > > > > You are of course absolutely correct with respect to the semantics > > of the "==" operator; nevertheless (as I've already said) I find > > (42 == x) annoyingly awkward -- as do many other people. I take > > your word for it that you don't, but I honestly find it surprising. > > Do you find (42 + x) more or less awkward than (x + 42), and why? > If you don't care, then what's the fundamental difference between > the + operator and the == operator? It depends entirely on context. Base plus offset would be my general preference. So: buffer_end = buffer_start + 0x4000; but: regs = 0x40008c00 + bank_offset; 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 | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2013-08-28 16:16 +0000 |
| Message-ID | <slrn3vfsl1s8iu.kka.ike@iceland.freeshell.org> |
| In reply to | #35945 |
On 2013-08-27, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote: > Ike Naar <ike@iceland.freeshell.org> writes: > >> On 2013-08-26, Keith Thompson <kst-u@mib.org> wrote: >> > Ike Naar <ike@iceland.freeshell.org> writes: >> >> On 2013-08-26, Keith Thompson <kst-u@mib.org> wrote: >> >>> It would never occur to me to write: >> >>> if (42 == x) >> >>> rather than >> >>> if (x == 42) >> >>> if it weren't for the possibility of confusing "==" and "=". >> >>> Would you write (42 == x) yourself? Do you really find it *just* >> >>> as natural as (x == 42)? >> >> >> >> Yes. Equality is a boolean function operating on two operands, >> >> returning "the operands are equal". It does not matter which >> >> one of the operands is on the left side of the operator. >> > >> > Fascinating. >> > >> > You are of course absolutely correct with respect to the semantics >> > of the "==" operator; nevertheless (as I've already said) I find >> > (42 == x) annoyingly awkward -- as do many other people. I take >> > your word for it that you don't, but I honestly find it surprising. >> >> Do you find (42 + x) more or less awkward than (x + 42), and why? >> If you don't care, then what's the fundamental difference between >> the + operator and the == operator? > > It depends entirely on context. Base plus offset would be my general > preference. So: > > buffer_end = buffer_start + 0x4000; > > but: > > regs = 0x40008c00 + bank_offset; So, for the '+' operator it may depend on context, but for the '==' operator it should depend on dogma?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-28 10:54 -0700 |
| Message-ID | <ln61uphf9p.fsf@nuthaus.mib.org> |
| In reply to | #36021 |
Ike Naar <ike@iceland.freeshell.org> writes:
> On 2013-08-27, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
>> Ike Naar <ike@iceland.freeshell.org> writes:
[...]
>>> Do you find (42 + x) more or less awkward than (x + 42), and why?
>>> If you don't care, then what's the fundamental difference between
>>> the + operator and the == operator?
>>
>> It depends entirely on context. Base plus offset would be my general
>> preference. So:
>>
>> buffer_end = buffer_start + 0x4000;
>>
>> but:
>>
>> regs = 0x40008c00 + bank_offset;
>
> So, for the '+' operator it may depend on context,
Yes.
> but for the '==' operator it should depend on dogma?
For me, it depends on which form I personally find less awkward,
which happens to be the form with the constant on the right.
--
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:56 +0300 |
| Message-ID | <87txi9wvgg.fsf@bazspaz.fatphil.org> |
| In reply to | #36021 |
Ike Naar <ike@iceland.freeshell.org> writes: > >> Do you find (42 + x) more or less awkward than (x + 42), and why? > >> If you don't care, then what's the fundamental difference between > >> the + operator and the == operator? > > > > It depends entirely on context. Base plus offset would be my general > > preference. So: > > > > buffer_end = buffer_start + 0x4000; > > > > but: > > > > regs = 0x40008c00 + bank_offset; > > So, for the '+' operator it may depend on context, > but for the '==' operator it should depend on dogma? It's not dogma, it's convention. I am familiar with the reasons why others adopt a different convention, and I find their reasons weak. What's 1 + 2 * 3? I adamantly support the convention that it is 7, but there are some who can quite justifiably claim it's 9. I find their convention inferior. I am in the majority. That doesn't make it dogma. 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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-08-28 19:23 +0000 |
| Message-ID | <kvlin8$jq2$1@speranza.aioe.org> |
| In reply to | #36030 |
Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote: (snip) >> So, for the '+' operator it may depend on context, >> but for the '==' operator it should depend on dogma? > It's not dogma, it's convention. I am familiar with > the reasons why others adopt a different convention, > and I find their reasons weak. > What's 1 + 2 * 3? Many characteristics of our favorite programming languages trace back to Fortran. (One of the biggest, multiple character variable names, still hasn't been adopted by mathematics.) It does make sense that the original FORmula TRANslation adopted the associativity and precedence rules used in algebra. (Though it was a long time before Fortran allowed for associativity in exponentiation.) > I adamantly support the convention that it is 7, but > there are some who can quite justifiably claim it's 9. > I find their convention inferior. I am in the majority. > That doesn't make it dogma. Some hand calculators don't have enough logic to keep track of such. A few programming languages also don't follow the usual conventions. One interesting one that doesn't is PL/360. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2013-08-28 23:31 -0700 |
| Message-ID | <kfnsixtdn4g.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #36030 |
Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes: > Ike Naar <ike@iceland.freeshell.org> writes: >> >> Do you find (42 + x) more or less awkward than (x + 42), and why? >> >> If you don't care, then what's the fundamental difference between >> >> the + operator and the == operator? >> > >> > It depends entirely on context. Base plus offset would be my general >> > preference. So: >> > >> > buffer_end = buffer_start + 0x4000; >> > >> > but: >> > >> > regs = 0x40008c00 + bank_offset; >> >> So, for the '+' operator it may depend on context, >> but for the '==' operator it should depend on dogma? > > It's not dogma, it's convention. I am familiar with > the reasons why others adopt a different convention, > and I find their reasons weak. > > What's 1 + 2 * 3? It's 7. Just ask Ken Iverson.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2013-08-27 07:00 +0000 |
| Message-ID | <slrn3vfsl1ojkk.4va.ike@iceland.freeshell.org> |
| In reply to | #35841 |
On 2013-08-26, Keith Thompson <kst-u@mib.org> wrote: > 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? There is no reason to write it that way for the "==" vs. "=" issue. if (strcmp(s1, s2) == 0) is already safe, because if (strcmp(s1, s2) = 0) /* oops, mistyped "==" */ is not valid C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-27 11:41 -0700 |
| Message-ID | <lnfvtvht7o.fsf@nuthaus.mib.org> |
| In reply to | #35925 |
Ike Naar <ike@iceland.freeshell.org> writes:
> On 2013-08-26, Keith Thompson <kst-u@mib.org> wrote:
>> 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?
>
> There is no reason to write it that way for the "==" vs. "=" issue.
>
> if (strcmp(s1, s2) == 0)
>
> is already safe, because
>
> if (strcmp(s1, s2) = 0) /* oops, mistyped "==" */
>
> is not valid C.
True -- but I've seen programmers who habitually use "Yoda
conditions" even in cases where they're not necessary. I suppose
cultivating the habit of putting the constant on the left, without
necessarily thinking each time about whether it's necessary, does
avoid "=" vs. "==" problems.
I appreciate the principle behind it (I have some habits I cultivate
myself for similar reasons); I just have a mental quirk that makes
me dislike it in this case.
--
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 | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2013-08-28 16:21 +0000 |
| Message-ID | <slrn3vfsl1s8t7.kka.ike@iceland.freeshell.org> |
| In reply to | #35970 |
On 2013-08-27, Keith Thompson <kst-u@mib.org> wrote: > Ike Naar <ike@iceland.freeshell.org> writes: >> On 2013-08-26, Keith Thompson <kst-u@mib.org> wrote: >>> 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? >> >> There is no reason to write it that way for the "==" vs. "=" issue. >> >> if (strcmp(s1, s2) == 0) >> >> is already safe, because >> >> if (strcmp(s1, s2) = 0) /* oops, mistyped "==" */ >> >> is not valid C. > > True -- but I've seen programmers who habitually use "Yoda > conditions" even in cases where they're not necessary. I suppose > cultivating the habit of putting the constant on the left, without > necessarily thinking each time about whether it's necessary, does > avoid "=" vs. "==" problems. There might be a non-habitual reason for putting the constant on the left. One can be non-dogmatic about the order of the operands for the == operator just as one can be non-dogmatic about their order in case of, say, the '+', the '*' or the '|' operators.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-28 10:57 -0700 |
| Message-ID | <ln1u5dhf55.fsf@nuthaus.mib.org> |
| In reply to | #36022 |
Ike Naar <ike@iceland.freeshell.org> writes:
> On 2013-08-27, Keith Thompson <kst-u@mib.org> wrote:
>> Ike Naar <ike@iceland.freeshell.org> writes:
>>> On 2013-08-26, Keith Thompson <kst-u@mib.org> wrote:
>>>> 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?
>>>
>>> There is no reason to write it that way for the "==" vs. "=" issue.
>>>
>>> if (strcmp(s1, s2) == 0)
>>>
>>> is already safe, because
>>>
>>> if (strcmp(s1, s2) = 0) /* oops, mistyped "==" */
>>>
>>> is not valid C.
>>
>> True -- but I've seen programmers who habitually use "Yoda
>> conditions" even in cases where they're not necessary. I suppose
>> cultivating the habit of putting the constant on the left, without
>> necessarily thinking each time about whether it's necessary, does
>> avoid "=" vs. "==" problems.
>
> There might be a non-habitual reason for putting the constant on
> the left. One can be non-dogmatic about the order of the operands
> for the == operator just as one can be non-dogmatic about their
> order in case of, say, the '+', the '*' or the '|' operators.
You keep using the word "dogma" when "preference" or "convention"
would IMHO be more accurate.
I see no reason to *prefer* putting the constant on the left other than
avoidance of "=" vs. "==" problems.
From your point of view, I would expect that consistently putting the
constant on the left would be no better or worse than consistently
putting it on the right.
--
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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web