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 1 of 10 [1] 2 3 … 10 Next page →
| From | Sharwan Joram <sharwan.joram@gmail.com> |
|---|---|
| Date | 2013-08-23 10:15 -0700 |
| Subject | Memory corruption on freeing a pointer to pointer |
| Message-ID | <ea56f6e9-efbe-4456-aa56-d3b9bfc6720f@googlegroups.com> |
Hi,
I have a strange problem here in my code. I'am getting memory corruption while trying to free the first element of list. Code snippet and GDB debugging trace below :
---------------------------------- code
char **parameters;
int idx;
int parametercount;
char *saved_token, token;
parameters = (char **)malloc(parametercount * sizeof(char *)); // Don't use *parameters it breaks.
for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
parameters[parametercount] = (char *)malloc(30 * sizeof (char *));
memset(parameters[parametercount], '\0', 30);
memcpy(parameters[parametercount], token, strlen(token));
parameters[parametercount] = token;
}
/* idx contains the number of tokens */
if (parameters != NULL){
for (parametercount = idx; parametercount >= 0; ++parametercount)
free(parameters[parametercount]);
free(parameters);
}
---------- Debugging session trace ----
160 memcpy(temp_token, saved_token, strlen(saved_token));
(gdb)
161 idx = parametercount = detect_delim_count(temp_token, delimiters);
(gdb)
162 if (temp_token)
(gdb)
163 free(temp_token);
(gdb) n
171 parameters = (char **)malloc(parametercount * sizeof(char *)); // Don't use *parameters it breaks.
(gdb)
172 for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
(gdb)
173 parameters[parametercount] = (char *)malloc(30 * sizeof (char *));
(gdb) p parameters
$1 = (char **) 0xb6e0f828
(gdb) n
174 memset(parameters[parametercount], '\0', 30);
(gdb)
175 memcpy(parameters[parametercount], token, strlen(token));
(gdb)
172 for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
(gdb)
173 parameters[parametercount] = (char *)malloc(30 * sizeof (char *));
(gdb) p parameters
$2 = (char **) 0xb6e0f828
(gdb) n
174 memset(parameters[parametercount], '\0', 30);
(gdb) p parameters[parametercount]
$3 = 0xb6e0f8b8 ""
(gdb) n
175 memcpy(parameters[parametercount], token, strlen(token));
(gdb)
172 for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
(gdb) p parameters[parametercount]
$4 = 0xb6e0f8b8 "param2"
(gdb) n
173 parameters[parametercount] = (char *)malloc(30 * sizeof (char *));
(gdb)
174 memset(parameters[parametercount], '\0', 30);
(gdb) p parameters[parametercount]
$5 = 0xb6e0f938 ""
(gdb)
$6 = 0xb6e0f938 ""
(gdb) n
175 memcpy(parameters[parametercount], token, strlen(token));
(gdb) p parameters[parametercount]
$7 = 0xb6e0f938 ""
(gdb) n
172 for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
(gdb) p parameters[parametercount]
$8 = 0xb6e0f938 "param3"
(gdb) n
173 parameters[parametercount] = (char *)malloc(30 * sizeof (char *));
(gdb)
174 memset(parameters[parametercount], '\0', 30);
(gdb)
175 memcpy(parameters[parametercount], token, strlen(token));
(gdb)
172 for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
(gdb) p parameters[parametercount]
$9 = 0xb6e0f9b8 "param4"
(gdb) n
201 shutdown = (currentcommand->command_handler)(client_fd, parameters, parametercount);
(gdb)
211 executedcommand = currentcommand;
(gdb)
216 currentcommand = currentcommand->next;
(gdb)
127 while((executedcommand == NULL) && (currentcommand != NULL)){
(gdb)
221 if (parameters != NULL){
(gdb)
222 for (parametercount = idx; parametercount >= 0; ++parametercount)
(gdb) p parameters
$10 = (char **) 0xb6e0f828
(gdb) p parameters[parametercount]
$11 = 0x61726170 <Address 0x61726170 out of bounds>
(gdb) n
223 free(parameters[parametercount]);
(gdb) p parameters[parametercount]
$12 = 0xb6e0f9b8 "param4"
(gdb) n
*** glibc detected *** /home/sources/opennop-daemon/opennopd/opennopd: corrupted double-linked list: 0xb6e0f820 ***
======= Backtrace: =========
/lib/libc.so.6[0x4441a1d1]
/lib/libc.so.6[0x4441a7bd]
/home/sources/opennop-daemon/opennopd/opennopd[0x805294c]
/home/sources/opennop-daemon/opennopd/opennopd[0x80520c5]
/lib/libpthread.so.0[0x4455fadf]
/lib/libc.so.6(clone+0x5e)[0x4449944e]
======= Memory map: ========
08048000-08056000 r-xp 00000000 fd:01 397476 /home/sources/opennop-daemon/opennopd/opennopd
08056000-08057000 rw-p 0000d000 fd:01 397476 /home/sources/opennop-daemon/opennopd/opennopd
08057000-082ce000 rw-p 00000000 00:00 0 [heap]
44382000-443a1000 r-xp 00000000 fd:01 148916 /usr/lib/ld-2.15.so
443a1000-443a2000 r--p 0001e000 fd:01 148916 /usr/lib/ld-2.15.so
443a2000-443a3000 rw-p 0001f000 fd:01 148916 /usr/lib/ld-2.15.so
443a5000-44550000 r-xp 00000000 fd:01 148917 /usr/lib/libc-2.15.so
44550000-44551000 ---p 001ab000 fd:01 148917 /usr/lib/libc-2.15.so
44551000-44553000 r--p 001ab000 fd:01 148917 /usr/lib/libc-2.15.so
44553000-44554000 rw-p 001ad000 fd:01 148917 /usr/lib/libc-2.15.so
44554000-44557000 rw-p 00000000 00:00 0
44559000-4456f000 r-xp 00000000 fd:01 148918 /usr/lib/libpthread-2.15.so
4456f000-44570000 r--p 00015000 fd:01 148918 /usr/lib/libpthread-2.15.so
44570000-44571000 rw-p 00016000 fd:01 148918 /usr/lib/libpthread-2.15.so
44571000-44573000 rw-p 00000000 00:00 0
44575000-44578000 r-xp 00000000 fd:01 148924 /usr/lib/libdl-2.15.so
44578000-44579000 r--p 00002000 fd:01 148924 /usr/lib/libdl-2.15.so
44579000-4457a000 rw-p 00003000 fd:01 148924 /usr/lib/libdl-2.15.so
448f5000-44911000 r-xp 00000000 fd:01 148934 /usr/lib/libgcc_s-4.7.2-20120921.so.1
44911000-44912000 rw-p 0001b000 fd:01 148934 /usr/lib/libgcc_s-4.7.2-20120921.so.1
45642000-45692000 r-xp 00000000 fd:01 148937 /usr/lib/libfreebl3.so
45692000-45693000 rw-p 00050000 fd:01 148937 /usr/lib/libfreebl3.so
45693000-45697000 rw-p 00000000 00:00 0
456a8000-456b0000 r-xp 00000000 fd:01 148938 /usr/lib/libcrypt-2.15.so
456b0000-456b1000 r--p 00007000 fd:01 148938 /usr/lib/libcrypt-2.15.so
456b1000-456b2000 rw-p 00008000 fd:01 148938 /usr/lib/libcrypt-2.15.so
456b2000-456d9000 rw-p 00000000 00:00 0
b21ff000-b2200000 ---p 00000000 00:00 0
b2200000-b2a00000 rw-p 00000000 00:00 0 [stack:846]
b2a00000-b2b00000 rw-p 00000000 00:00 0
b2bf9000-b2bfa000 ---p 00000000 00:00 0
b2bfa000-b33fa000 rw-p 00000000 00:00 0 [stack:844]
b33fa000-b33fb000 ---p 00000000 00:00 0
b33fb000-b3bfb000 rw-p 00000000 00:00 0 [stack:843]
b3bfb000-b3bfc000 ---p 00000000 00:00 0
b3bfc000-b43fc000 rw-p 00000000 00:00 0 [stack:842]
b43fc000-b43fd000 ---p 00000000 00:00 0
b43fd000-b4bfd000 rw-p 00000000 00:00 0 [stack:840]
b4bfd000-b4bfe000 ---p 00000000 00:00 0
b4bfe000-b53fe000 rw-p 00000000 00:00 0 [stack:836]
b53fe000-b53ff000 ---p 00000000 00:00 0
b53ff000-b5bff000 rw-p 00000000 00:00 0 [stack:835]
b5bff000-b5c00000 ---p 00000000 00:00 0
b5c00000-b6400000 rw-p 00000000 00:00 0 [stack:834]
b6400000-b6500000 rw-p 00000000 00:00 0
b65ff000-b6600000 ---p 00000000 00:00 0
b6600000-b6e00000 rw-p 00000000 00:00 0 [stack:833]
b6e00000-b6e2a000 rw-p 00000000 00:00 0
b6e2a000-b6f00000 ---p 00000000 00:00 0
b6fd2000-b6fd3000 ---p 00000000 00:00 0
b6fd3000-b77d3000 rw-p 00000000 00:00 0 [stack:832]
b77d3000-b77d4000 ---p 00000000 00:00 0
b77d4000-b7fd6000 rw-p 00000000 00:00 0 [stack:831]
b7fd6000-b7fda000 r-xp 00000000 fd:01 165010 /usr/lib/libmnl.so.0.1.0
b7fda000-b7fdb000 r--p 00003000 fd:01 165010 /usr/lib/libmnl.so.0.1.0
b7fdb000-b7fdc000 rw-p 00004000 fd:01 165010 /usr/lib/libmnl.so.0.1.0
b7fdc000-b7fe2000 r-xp 00000000 fd:01 165001 /usr/lib/libnfnetlink.so.0.2.0
b7fe2000-b7fe3000 r--p 00005000 fd:01 165001 /usr/lib/libnfnetlink.so.0.2.0
b7fe3000-b7fe4000 rw-p 00006000 fd:01 165001 /usr/lib/libnfnetlink.so.0.2.0
b7fe4000-b7fe5000 rw-p 00000000 00:00 0
b7fe5000-b7feb000 r-xp 00000000 fd:01 148876 /usr/lib/libnetfilter_queue.so.1.3.0
b7feb000-b7fec000 r--p 00005000 fd:01 148876 /usr/lib/libnetfilter_queue.so.1.3.0
b7fec000-b7fed000 rw-p 00006000 fd:01 148876 /usr/lib/libnetfilter_queue.so.1.3.0
b7ffc000-b7fff000 rw-p 00000000 00:00 0
b7fff000-b8000000 r-xp 00000000 00:00 0 [vdso]
bffdf000-c0000000 rw-p 00000000 00:00 0 [stack]
I am unable to understand the reason of this behaviour.
--Regards,
Sharwan Joram
[toc] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-23 14:05 -0400 |
| Message-ID | <5217A463.8030302@verizon.net> |
| In reply to | #35642 |
On 08/23/2013 01:15 PM, Sharwan Joram wrote:
> Hi,
> I have a strange problem here in my code. I'am getting memory corruption while trying to free the first element of list. Code snippet and GDB debugging trace below :
>
> ---------------------------------- code
> char **parameters;
> int idx;
> int parametercount;
> char *saved_token, token;
>
> parameters = (char **)malloc(parametercount * sizeof(char *)); // Don't use *parameters it breaks.
Using (char**) is unnecessary; and if this code gets compiled using C90,
could mask a defect.
sizeof *parameters should be exactly equivalent to sizeof(char *),
except for being safer in the even that the type of 'paremeters' ever
gets changed.. If you've seen something break when you used *parameters,
that needs investigation.
You make no attempt, neither above nor below, to confirm whether your
calls to malloc() were successful. They might not have been. If any
malloc() call failed, the fact that your code tries to write to the
allocated memory would render the behavior of your program undefined.
Memory corruption is a very plausible result if that happens.
> for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
> parameters[parametercount] = (char *)malloc(30 * sizeof (char *));
> memset(parameters[parametercount], '\0', 30);
It's simpler, and on some systems, faster, to call calloc() rather than
malloc() followed by memset().
> memcpy(parameters[parametercount], token, strlen(token));
Why not just strcpy()?
Are you certain that strlen(token)<31? If not, the memcpy() will
overwrite memory beyond that which is allocated, rendering the behavior
of your program undefined.
Will your code ever change the parameter strings? If not, you might save
some memory (and remove the need to check whether strlen(token) > 31) by
always allocating strlen(token)+1 bytes, and you can drop the call to
memset(). However, if you do this, you need to make sure that everything
done with these parameter strings stops at the terminating null
character, rather than just assuming there will always be 30 safely
accessible bytes.
> parameters[parametercount] = token;
That's the cause of your problem. I can't figure you why you wrote that
code - but it almost certainly doesn't do what what you think it does.
You've just replaced the only pointer you have to memory that was
allocated by malloc(), with a pointer to memory within the array pointed
at by saved_token. Therefore, you will never be able to free that
allocated memory, which creates a memory leak. Also, you'll never again
be able to access the string that you copied into that memory.
> }
>
> /* idx contains the number of tokens */
> if (parameters != NULL){
> for (parametercount = idx; parametercount >= 0; ++parametercount)
> free(parameters[parametercount]);
This is where the defect above actually causes your program to fail.
Since parameters[parametercount] no longer contains a pointer to memory
that was allocated by malloc(), passing it's value to free() means that
the behavior of your program is undefined. Memory corruption is a very
likely consequences of doing something like that.
[toc] | [prev] | [next] | [standalone]
| From | Sharwan Joram <sharwan.joram@gmail.com> |
|---|---|
| Date | 2013-08-23 11:17 -0700 |
| Message-ID | <003911c8-23c9-4f86-955b-74c7b3f1fef7@googlegroups.com> |
| In reply to | #35650 |
On Friday, August 23, 2013 11:35:23 PM UTC+5:30, James Kuyper wrote:
> On 08/23/2013 01:15 PM, Sharwan Joram wrote:
>
> > Hi,
>
> > I have a strange problem here in my code. I'am getting memory corruption while trying to free the first element of list. Code snippet and GDB debugging trace below :
>
> >
>
> > ---------------------------------- code
>
> > char **parameters;
>
> > int idx;
>
> > int parametercount;
>
> > char *saved_token, token;
>
> >
>
> > parameters = (char **)malloc(parametercount * sizeof(char *)); // Don't use *parameters it breaks.
>
>
>
> Using (char**) is unnecessary; and if this code gets compiled using C90,
>
> could mask a defect.
>
>
>
> sizeof *parameters should be exactly equivalent to sizeof(char *),
>
> except for being safer in the even that the type of 'paremeters' ever
>
> gets changed.. If you've seen something break when you used *parameters,
>
> that needs investigation.
>
>
>
> You make no attempt, neither above nor below, to confirm whether your
>
> calls to malloc() were successful. They might not have been. If any
>
> malloc() call failed, the fact that your code tries to write to the
>
> allocated memory would render the behavior of your program undefined.
>
> Memory corruption is a very plausible result if that happens.
>
>
>
> > for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
>
> > parameters[parametercount] = (char *)malloc(30 * sizeof (char *));
>
> > memset(parameters[parametercount], '\0', 30);
>
>
>
> It's simpler, and on some systems, faster, to call calloc() rather than
>
> malloc() followed by memset().
>
>
>
> > memcpy(parameters[parametercount], token, strlen(token));
>
>
>
> Why not just strcpy()?
>
> Are you certain that strlen(token)<31? If not, the memcpy() will
>
> overwrite memory beyond that which is allocated, rendering the behavior
>
> of your program undefined.
>
>
>
> Will your code ever change the parameter strings? If not, you might save
>
> some memory (and remove the need to check whether strlen(token) > 31) by
>
> always allocating strlen(token)+1 bytes, and you can drop the call to
>
> memset(). However, if you do this, you need to make sure that everything
>
> done with these parameter strings stops at the terminating null
>
> character, rather than just assuming there will always be 30 safely
>
> accessible bytes.
>
>
>
> > parameters[parametercount] = token;
>
>
>
> That's the cause of your problem. I can't figure you why you wrote that
>
> code - but it almost certainly doesn't do what what you think it does.
>
>
>
> You've just replaced the only pointer you have to memory that was
>
> allocated by malloc(), with a pointer to memory within the array pointed
>
> at by saved_token. Therefore, you will never be able to free that
>
> allocated memory, which creates a memory leak. Also, you'll never again
>
> be able to access the string that you copied into that memory.
>
>
>
> > }
>
> >
>
> > /* idx contains the number of tokens */
>
> > if (parameters != NULL){
>
> > for (parametercount = idx; parametercount >= 0; ++parametercount)
>
> > free(parameters[parametercount]);
>
>
>
> This is where the defect above actually causes your program to fail.
>
> Since parameters[parametercount] no longer contains a pointer to memory
>
> that was allocated by malloc(), passing it's value to free() means that
>
> the behavior of your program is undefined. Memory corruption is a very
>
> likely consequences of doing something like that.
Hi James,
One error in the snippet above : This line is commented
parameters[parametercount] = token;
1. The parameters never go beyond 30 characters.
As the aim of the code above is to quickly check the functionality so didn't care the suggestions you mentioned above.
--Sharwan
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-23 14:51 -0400 |
| Message-ID | <5217AF49.4030509@verizon.net> |
| In reply to | #35651 |
On 08/23/2013 02:17 PM, Sharwan Joram wrote:
> On Friday, August 23, 2013 11:35:23 PM UTC+5:30, James Kuyper wrote:
>> On 08/23/2013 01:15 PM, Sharwan Joram wrote:
...
>>> parameters[parametercount] = token;
>>
>> That's the cause of your problem. I can't figure you why you wrote that
>> code - but it almost certainly doesn't do what what you think it does.
>>
>> You've just replaced the only pointer you have to memory that was
>> allocated by malloc(), with a pointer to memory within the array pointed
>> at by saved_token. Therefore, you will never be able to free that
>> allocated memory, which creates a memory leak. Also, you'll never again
>> be able to access the string that you copied into that memory.
>>
>>> }
>>>
>>> /* idx contains the number of tokens */
>>> if (parameters != NULL){
>>> for (parametercount = idx; parametercount >= 0; ++parametercount)
>>> free(parameters[parametercount]);
>>
>> This is where the defect above actually causes your program to fail.
>> Since parameters[parametercount] no longer contains a pointer to memory
>> that was allocated by malloc(), passing it's value to free() means that
>> the behavior of your program is undefined. Memory corruption is a very
>> likely consequences of doing something like that.
>
> Hi James,
> One error in the snippet above : This line is commented
> parameters[parametercount] = token;
It's not commented out in the code you displayed. If it is commented out
in the code that you're actually running, you just wasted a fair amount
of both my time and yours by not showing me the actual code that failed.
It's generally a bad idea, when asking for help identifying a code
defect, to show the person who's helping you anything other than a
complete program that will, as shown, demonstrate the defect. By
definition, you don't know what the defect is, or you wouldn't need
help. It follows that you don't know which part of the program actually
causes the defect. Anything less than a complete program may be a waste
of time.
You may think that your complete program is too big to show me - and
you're probably right. Which means that what you should do is cut the
program down to be as small as possible, while still demonstrating the
problem. Remove one piece at a time (preferably a really big piece, such
as every line of code that was supposed to execute after the line where
something failed), and check to see if the problem still occurs. If it
doesn't, put that piece back in, and choose a different piece to remove.
If you can't find any remaining pieces that can be removed, that's when
the program is ready for you to ask for someone's help.
Note: it is very common for people who are following this process, to
figure out what the problem is, without even having to ask for help.
> 1. The parameters never go beyond 30 characters.
>
> As the aim of the code above is to quickly check the functionality so didn't care the suggestions you mentioned above.
Well, one of the short-cuts you took for in order "to quickly check the
functionality" may be the cause of the problem you're seeing. Those
shortcuts are easy, simple things to fix, and I'd recommend doing so
before doing anything else to investigate this problem.
[toc] | [prev] | [next] | [standalone]
| From | blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> |
|---|---|
| Date | 2013-08-24 21:50 +0000 |
| Message-ID | <b7so56FaphdU1@mid.individual.net> |
| In reply to | #35654 |
In article <5217AF49.4030509@verizon.net>, James Kuyper <jameskuyper@verizon.net> wrote: > On 08/23/2013 02:17 PM, Sharwan Joram wrote: > > On Friday, August 23, 2013 11:35:23 PM UTC+5:30, James Kuyper wrote: > >> On 08/23/2013 01:15 PM, Sharwan Joram wrote: [ snip ] > > Hi James, > > One error in the snippet above : This line is commented > > parameters[parametercount] = token; > > It's not commented out in the code you displayed. If it is commented out > in the code that you're actually running, you just wasted a fair amount > of both my time and yours by not showing me the actual code that failed. > > It's generally a bad idea, when asking for help identifying a code > defect, to show the person who's helping you anything other than a > complete program that will, as shown, demonstrate the defect. By > definition, you don't know what the defect is, or you wouldn't need > help. It follows that you don't know which part of the program actually > causes the defect. Anything less than a complete program may be a waste > of time. > You may think that your complete program is too big to show me - and > you're probably right. Which means that what you should do is cut the > program down to be as small as possible, while still demonstrating the > problem. Remove one piece at a time (preferably a really big piece, such > as every line of code that was supposed to execute after the line where > something failed), and check to see if the problem still occurs. If it > doesn't, put that piece back in, and choose a different piece to remove. > If you can't find any remaining pieces that can be removed, that's when > the program is ready for you to ask for someone's help. > Note: it is very common for people who are following this process, to > figure out what the problem is, without even having to ask for help. I'll second this recommendation to the OP!! It seems that much of the difficulty in solving the problem has to do with variables whose values readers can't be sure about. And as you say, sometimes just trying to pull out a short self-contained program that demonstrates the problem helps in identifying it. OP: Is there some reason you can't do that?? [ snip ] -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-24 15:36 -0700 |
| Message-ID | <lnppt2d8d5.fsf@nuthaus.mib.org> |
| In reply to | #35654 |
James Kuyper <jameskuyper@verizon.net> writes:
[...]
> It's generally a bad idea, when asking for help identifying a code
> defect, to show the person who's helping you anything other than a
> complete program that will, as shown, demonstrate the defect. By
> definition, you don't know what the defect is, or you wouldn't need
> help. It follows that you don't know which part of the program actually
> causes the defect. Anything less than a complete program may be a waste
> of time.
> You may think that your complete program is too big to show me - and
> you're probably right. Which means that what you should do is cut the
> program down to be as small as possible, while still demonstrating the
> problem. Remove one piece at a time (preferably a really big piece, such
> as every line of code that was supposed to execute after the line where
> something failed), and check to see if the problem still occurs. If it
> doesn't, put that piece back in, and choose a different piece to remove.
> If you can't find any remaining pieces that can be removed, that's when
> the program is ready for you to ask for someone's help.
> Note: it is very common for people who are following this process, to
> figure out what the problem is, without even having to ask for help.
[...]
See also http://sscce.org/ ("Short, Self Contained, Correct
(Compilable), Example").
--
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 | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2013-08-23 13:18 -0500 |
| Message-ID | <kv891a$1kg$1@dont-email.me> |
| In reply to | #35642 |
On 8/23/2013 12:15 PM, Sharwan Joram wrote:
> Hi,
> I have a strange problem here in my code. I'am getting memory corruption while trying to free the first element of list. Code snippet and GDB debugging trace below :
>
> ---------------------------------- code
> char **parameters;
> int idx;
> int parametercount;
> char *saved_token, token;
>
> parameters = (char **)malloc(parametercount * sizeof(char *)); // Don't use *parameters it breaks.
What do you think it breaks?
> for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
I'll assume you left out the code that initialized saved_token.
> parameters[parametercount] = (char *)malloc(30 * sizeof (char *));
> memset(parameters[parametercount], '\0', 30);
> memcpy(parameters[parametercount], token, strlen(token));
If you're going to use strlen(token), why not go ahead and use strcpy?
> parameters[parametercount] = token;
One of your main problems is here. token is a pointer into the memory
pointed to by saved_token. After the first call to strtok(), it's not
going to be a pointer you can pass to free(). Even the first call to
strtok() might not result in a pointer that can be passed to free().
More importantly, it overwrites the value already there, leaking that
memory.
> }
>
> /* idx contains the number of tokens */
> if (parameters != NULL){
> for (parametercount = idx; parametercount >= 0; ++parametercount)
> free(parameters[parametercount]);
> free(parameters);
> }
The for loop is the other main problem. If your comment is correct, then
idx indexes to first free slot in the parameters array. Since you don't
appear to have initialized that slot with anything, the call to free is
problematic. On top of that, you increment parametercount, so the second
time through (if it gets that far) idx points to the second free slot in
parameters. This will continue until the undefined behavor from
attempting to derefence past the end of the array, attempting to free
garbage, or overflowing idx puts an end to your process. From the
message below, it appears that attempting to free garbage is what was
finally caught.
[snip]
Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2013-08-23 20:00 +0000 |
| Message-ID | <slrn3vfsl1ffrc.p8d.ike@iceland.freeshell.org> |
| In reply to | #35642 |
On 2013-08-23, Sharwan Joram <sharwan.joram@gmail.com> wrote: > char **parameters; > int idx; > int parametercount; > char *saved_token, token; > > parameters = (char **)malloc(parametercount * sizeof(char *)); > // Don't use *parameters it breaks. What is the value of parametercount?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-08-23 21:37 +0100 |
| Message-ID | <0.a2b503684b479248fead.20130823213737BST.87k3jcnnxq.fsf@bsb.me.uk> |
| In reply to | #35658 |
Ike Naar <ike@iceland.freeshell.org> writes: > On 2013-08-23, Sharwan Joram <sharwan.joram@gmail.com> wrote: >> char **parameters; >> int idx; >> int parametercount; >> char *saved_token, token; >> >> parameters = (char **)malloc(parametercount * sizeof(char *)); >> // Don't use *parameters it breaks. > > What is the value of parametercount? I was going to post that, and then I saw that the debug output showed that code is executed between the declaration and the use. The OP has not made the code being executed at all clear. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2013-08-23 14:16 -0700 |
| Message-ID | <efjf19pg8vm7hb5ji87l6c9hlls59e2ie0@4ax.com> |
| In reply to | #35642 |
On Fri, 23 Aug 2013 10:15:42 -0700 (PDT), Sharwan Joram
<sharwan.joram@gmail.com> wrote:
>Hi,
> I have a strange problem here in my code. I'am getting memory corruption while trying to free the first element of list. Code snippet and GDB debugging trace below :
>
>---------------------------------- code
>char **parameters;
>int idx;
>int parametercount;
>char *saved_token, token;
>
>parameters = (char **)malloc(parametercount * sizeof(char *)); // Don't use *parameters it breaks.
The value of parametercount is indeterminant. The next block of code
implies it is not known at this time.
> for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
What does saved_token point to? Under what condition can token be
non-NULL and *token be '\0'?
> parameters[parametercount] = (char *)malloc(30 * sizeof (char *));
This allocates too much memory.
> memset(parameters[parametercount], '\0', 30);
What purpose does this serve since you immediately replace the zeroed
out values in the next statement?
> memcpy(parameters[parametercount], token, strlen(token));
Why not use strcpy and save at least one function call?
> parameters[parametercount] = token;
You have now caused a memory leak. parameters[parametercount] used to
point to the allocated memory. Now it point to somewhere inside
saved_token.
>}
>
>/* idx contains the number of tokens */
> if (parameters != NULL){
If parameters is NULL, all the previous code invokes undefined
behavior. Essentially, this is if statement must evaluate to true.
> for (parametercount = idx; parametercount >= 0; ++parametercount)
If idx is positive, this loop will never terminate.
> free(parameters[parametercount]);
Since parameters[parametercount] no longer contains a value returned
by malloc, this call to free invokes undefined behavior and frequently
causes programs to crash.
> free(parameters);
> }
>
>---------- Debugging session trace ----
This trace does not match the code you have shown us.
>
>160 memcpy(temp_token, saved_token, strlen(saved_token));
>(gdb)
>161 idx = parametercount = detect_delim_count(temp_token, delimiters);
>(gdb)
>162 if (temp_token)
>(gdb)
>163 free(temp_token);
>(gdb) n
>171 parameters = (char **)malloc(parametercount * sizeof(char *)); // Don't use *parameters it breaks.
>(gdb)
>172 for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
>(gdb)
>173 parameters[parametercount] = (char *)malloc(30 * sizeof (char *));
>(gdb) p parameters
>$1 = (char **) 0xb6e0f828
>(gdb) n
>174 memset(parameters[parametercount], '\0', 30);
>(gdb)
>175 memcpy(parameters[parametercount], token, strlen(token));
>(gdb)
An assignment statement should have been traced here.
>172 for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
>(gdb)
<snip>
Show us your real code.
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-23 17:50 -0400 |
| Message-ID | <5217D920.6010201@verizon.net> |
| In reply to | #35666 |
On 08/23/2013 05:16 PM, Barry Schwarz wrote:
> On Fri, 23 Aug 2013 10:15:42 -0700 (PDT), Sharwan Joram
> <sharwan.joram@gmail.com> wrote:
>
>> Hi,
>> I have a strange problem here in my code. I'am getting memory corruption while trying to free the first element of list. Code snippet and GDB debugging trace below :
...
It's clear that Sharwan only presented us with part of his program, and
as I found out the hard way, even some of the lines he did give us
weren't actually part of the program.
>> parameters[parametercount] = (char *)malloc(30 * sizeof (char *));
>
> This allocates too much memory.
That's probably correct (though it might be the case that some of the
parameters are large enough to need that much space). However, your
comment isn't very helpful without further explanation.
Sharwan: what Barry is referring to is the fact that you wrote
30*sizeof(char*), when context suggests that you should have written
30*sizeof(char), or better yet, 30*sizeof **parameters. sizeof(char*) is
almost certainly larger than sizeof(char); on many modern systems it
will be 4; other likely values include 2 and 8.
>> for (parametercount = idx; parametercount >= 0; ++parametercount)
>
> If idx is positive, this loop will never terminate.
Assuming that the above line is more "real" than the
parameters[parametercount] = token;
turned out to be, this looks like the best candidate for the main problem.
It will access memory beyond the end of the parameters array, interpret
uninitialized memory or memory that's serving some other purpose as if
it contained a pointer value, and pass that value to free(). That will
render the behavior of the code undefined for at least two different
reasons (three if char* can have trap values) almost simultaneously.
It probably should have been written:
for (parametercount = idx-1; parametercount >= 0; --parametercount)
Alternatively, it would have worked just as well going through the array
in the opposite direction, with less danger of getting the loop
conditions wrong:
for(parametercount = 0; parametercount < idx; ++parametercount)
[toc] | [prev] | [next] | [standalone]
| From | gdotone@gmail.com |
|---|---|
| Date | 2013-08-23 22:56 -0700 |
| Message-ID | <e48aa375-01ee-4994-82cb-5922b7041ed3@googlegroups.com> |
| In reply to | #35642 |
this is Sharwan Joram code with comments and questions from me as i try to learn C
this is only a partial bit of the code
thanks for helpng me learn
char **parameter; /* parameter is a pointer that points to a character pointer */
int idx;
int parameterCount; /* the number of parameters counted */
char *saved_token, token;
/*
get sizeof char pointer
allocate a memory block the size of parameterCount times the sizeof character pointer
so, an array is being created, cast the array of memory to be a char **, a pointer to a
pointer of type char.
parameterCount has not been initialized.
*/
parameters = (char **) malloc( parameterCount * sizeof( char * ) );
/*
test to see if malloc was able to find memory space.
*/
if ( parameter != NULL )
{
/*
loop until token && *token (what! token is a char, so what is *token)
parameter is initialized to 0
token is initialized to whatever *saved_token first token is.
( but *saved_token is not initialized at this point )
++parameterCount is increment by 1
token is assigned the value of next token from the *save_token pointer
( but token is declared as a char, strtok() returns a pointer to a char )
( so, maybe token should be declared as a char *, a pointer to a char )
*/
for( parameterCount = 0, token = strtok( saved_token, " ";
token && *token;
++parameterCount, token = strtok( NULL," ") );
{
/*
question: Do you want the size a char or do you want the size of the pointer
to type char? they may not be the same size, right?
find the sizeof a char pointer
multiply that value by 30 and calloc malloc to get a block of memory the size
of 30 character pointers
cast that block to be of type char pointer (char *)
have parameter[parameterCount] point to that block of memory.
*/
parameters[parametercount] = (char *)malloc(30 * sizeof (char *));
/*
void *memset( void *s, int c, size_t n );
copies c ( converted to unsigned char ) into the first n characters of
the object pointed to by s. A pointer to the result is returned.
(referenced from a textbook)
parameters[ parameterCount ] is being treated as array of pointers to an array
of chars?
so, in the 30 position of the array of characters place a '\0' character
*/
memset(parameters[parameterCount], '\0', 30);
....
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-08-24 13:45 +0100 |
| Message-ID | <0.f26f8ddb8b60f2239108.20130824134545BST.87k3jbl0jq.fsf@bsb.me.uk> |
| In reply to | #35677 |
gdotone@gmail.com writes:
> this is Sharwan Joram code with comments and questions from me as i
> try to learn C this is only a partial bit of the code
>
> thanks for helpng me learn
> char **parameter; /* parameter is a pointer that points to a character pointer */
>
> int idx;
>
> int parameterCount; /* the number of parameters counted */
>
> char *saved_token, token;
>
> /*
>
> get sizeof char pointer
> allocate a memory block the size of parameterCount times the sizeof character pointer
> so, an array is being created, cast the array of memory to be a char **, a pointer to a
> pointer of type char.
>
> parameterCount has not been initialized.
>
> */
>
> parameters = (char **) malloc( parameterCount * sizeof( char * ) );
Two things: you say that parameterCount has not been initialised, but
has it been set in the "real" code bu this time? If not what do you
expect this like to do? Without having set parameterCount, you have no
idea.
Second thing: please switch to this pattern:
parameters = malloc( parameterCount * sizeof *parameters );
It's shorter, and you don't have to check any types. Provided the type
of "parameters" is correct (and it looks fine to me) it is guaranteed to
allocate the right space for parameterCount objects.
> /*
> test to see if malloc was able to find memory space.
> */
>
> if ( parameter != NULL )
> {
>
> /*
> loop until token && *token (what! token is a char, so
> what is *token)
You have the wrong type for token. It, too, should be a char *.
> parameter is initialized to 0
No it isn't. Did you mean parameterCount? You need to take a lot of
care in programming. Little details make all the difference.
> token is initialized to whatever *saved_token
> first token is.
> ( but *saved_token is not initialized at
> this point )
Do you mean this? If *saved_token is uninitialised (and I assume the
same is true of saved_token) you are no longer in control of what
happens. You must only operate with data you've set.
> ++parameterCount is increment by 1
> token is assigned the value of next token from the *save_token pointer
> ( but token is declared as a char, strtok() returns a pointer to a char )
> ( so, maybe token should be declared as a char *, a pointer to a char )
> */
>
> for( parameterCount = 0, token = strtok( saved_token, " ";
> token && *token;
> ++parameterCount, token = strtok(
> NULL," ") );
I there some prize for cramming as much as possible into one for
statement? You have at least one syntax error there, and please note
that last semi-colon. Do you know what effect it has?
I would write this in the following way:
char *token = strtok(saved_token, " ");
int p_count = 0;
while (token && *token) {
/* do the processing of the token */
token = strtok(NULL, " ");
p_count += 1;
}
Note that (a) I've broken it up intosimpler pieces; (b) I've moved some
of the declarations closer to the point of use; and (c) I've not re-used
paramerterCount. It's quite likely that whatever value paramerterCount
had before will be useful again so lets use a new int for this loop.
In fact, I think you want something called "maxParameterCount" in the
original allocation, in which case using paramerterCount here is fine.
The point is that the number plays different roles in the two places and
that deserves having two variables.
> {
>
> /*
> question: Do you want the size a char or do you want the size of the pointer
> to type char? they may not be the same size, right?
>
> find the sizeof a char pointer
> multiply that value by 30 and calloc malloc to get a block of memory the size
> of 30 character pointers
> cast that block to be of type char pointer (char *)
> have parameter[parameterCount] point to that block of memory.
> */
>
> parameters[parametercount] = (char *)malloc(30 * sizeof (char *));
If you write
parameters[parametercount] = malloc(30 * sizeof *parameters[parametercount]);
you know you are getting space for 30 of the things that can be pointed
to by parameters[X]. There are, as it happens, char objects, so your
sizeof expression above is wrong.
> /*
> void *memset( void *s, int c, size_t n );
The header files are there for a purpose! It's rarely a good idea to
manually declare C library functions like this.
> copies c ( converted to unsigned char ) into the first n characters of
> the object pointed to by s. A pointer to the result is returned.
> (referenced from a textbook)
>
> parameters[ parameterCount ] is being treated as array of pointers to an array
> of chars?
No. parameters[parameterCount] is just a pointer to a character.
> so, in the 30 position of the array of characters place a '\0' character
>
> */
>
> memset(parameters[parameterCount], '\0', 30);
I suggest you try to write a cut-down version of this program and post
it whole.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2013-08-24 06:20 -0700 |
| Message-ID | <0547d27d-351d-41c4-9e0f-620383a393e4@googlegroups.com> |
| In reply to | #35683 |
On Saturday, August 24, 2013 1:45:45 PM UTC+1, Ben Bacarisse wrote: > gdotone@gmail.com writes: > > > > parameters = (char **) malloc( parameterCount * sizeof( char * ) ); > > > Second thing: please switch to this pattern: > > parameters = malloc( parameterCount * sizeof *parameters ); > > It's shorter, and you don't have to check any types. Provided the type > of "parameters" is correct (and it looks fine to me) it is guaranteed to > allocate the right space for parameterCount objects. > But it's hard to read. At least put in parentheses so we can have visual fix on what sizeof applies to.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-08-24 20:16 +0100 |
| Message-ID | <0.a4bb097e980238d2f6ad.20130824201600BST.874naekihb.fsf@bsb.me.uk> |
| In reply to | #35686 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, August 24, 2013 1:45:45 PM UTC+1, Ben Bacarisse wrote: >> gdotone@gmail.com writes: >> > >> >> > parameters = (char **) malloc( parameterCount * sizeof( char * ) ); >> >> >> Second thing: please switch to this pattern: >> >> parameters = malloc( parameterCount * sizeof *parameters ); >> >> It's shorter, and you don't have to check any types. Provided the type >> of "parameters" is correct (and it looks fine to me) it is guaranteed to >> allocate the right space for parameterCount objects. >> > But it's hard to read. At least put in parentheses so we can have visual fix > on what sizeof applies to. What are the options? Are you assuming a reader who thinks sizeof might be a variable? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2013-08-24 16:51 -0700 |
| Message-ID | <1d844afd-ffe0-4c4a-85d6-b05a39122fcd@googlegroups.com> |
| In reply to | #35699 |
On Saturday, August 24, 2013 8:16:00 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > What are the options? Are you assuming a reader who thinks sizeof might > be a variable? > A bad option is buff = malloc( N * sizeof *buff); it's got two C quirks - an operator which looks like an identifier, and a sort of pointer dereference which isn't really a dereference. It also uses the asterisk in two contexts, which aren't visually distinguishable. It's asking for trouble, difficulty in understanding, adding cost to the maintenance of programs. buff = malloc( N * sizeof(*buff)); is a bit less bad. At least we can see that sizeof applies to *buff, and that * is unary. A novice or an experience programmer unused to C might assume that sizeof() is a fucntion, but that's unlikely to do any real harm. The best option is buff = malloc(N * sizeof(int)); it's very easy to see what the intention is.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2013-08-25 12:27 +1200 |
| Message-ID | <b7t1bdFc2s0U1@mid.individual.net> |
| In reply to | #35736 |
Malcolm McLean wrote: > On Saturday, August 24, 2013 8:16:00 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> >> What are the options? Are you assuming a reader who thinks sizeof might >> be a variable? >> > > A bad option is > > buff = malloc( N * sizeof *buff); > > it's got two C quirks - an operator which looks like an identifier, and a > sort of pointer dereference which isn't really a dereference. It also uses the > asterisk in two contexts, which aren't visually distinguishable. It's asking > for trouble, difficulty in understanding, adding cost to the maintenance of > programs. If a so called programmer doesn't understand this idiomatic construct, they shouldn't be working on C code. > buff = malloc( N * sizeof(*buff)); Most programmers would be happy with and probably use this form. > is a bit less bad. At least we can see that sizeof applies to *buff, and that > * is unary. A novice or an experience programmer unused to C might assume > that sizeof() is a fucntion, but that's unlikely to do any real harm. > > The best option is > > buff = malloc(N * sizeof(int)); > > it's very easy to see what the intention is. Until the type of buff changes, which does happen. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2013-08-24 18:02 -0700 |
| Message-ID | <8db9d45b-3ab3-433e-92f5-c8060abb9299@googlegroups.com> |
| In reply to | #35739 |
On Sunday, August 25, 2013 1:27:25 AM UTC+1, Ian Collins wrote: > Malcolm McLean wrote: > > If a so called programmer doesn't understand this idiomatic construct, > they shouldn't be working on C code. > A programmer can be a very experienced programmer, but not so familiar with C. That's happening more and more with the explosion of high-level languages. But even an experienced C programmer thinks in English (assuming him to be an anglophone). "size of int" is prounceable in English, and has the correct meaning. size of star peeteear doesn't have a meaning. In programming the trivial is important. Little difficulties have a way of accumulating, and combining to make major headaches. > > > buff = malloc(N * sizeof(int)); > > it's very easy to see what the intention is. > > Until the type of buff changes, which does happen. > Automatic variables shouldn't have a large scope, so you should be able to check the entire function when making a modification. The real danger is when buff is a member of a structure, which has many functions which operate on it. But you can easily have other problems.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2013-08-25 15:03 +1200 |
| Message-ID | <b7tafbFc2s0U2@mid.individual.net> |
| In reply to | #35743 |
Malcolm McLean wrote: > On Sunday, August 25, 2013 1:27:25 AM UTC+1, Ian Collins wrote: >> Malcolm McLean wrote: >> >> If a so called programmer doesn't understand this idiomatic construct, >> they shouldn't be working on C code. >> > A programmer can be a very experienced programmer, but not so familiar with C. > That's happening more and more with the explosion of high-level languages. While true, that doesn't detract from my comment. programmers coming from a scripting language probably aren't familiar with low level memory management at all, so they have quite a bit to learn. The include C's idioms. Suggesting experienced programmers avoid C idioms that may be unfamiliar to others is a step too far. > But even an experienced C programmer thinks in English (assuming him to be > an anglophone). "size of int" is prounceable in English, and has the correct > meaning. size of star peeteear doesn't have a meaning. > In programming the trivial is important. Little difficulties have a way of > accumulating, and combining to make major headaches. Such as the types of variables changing? >>> buff = malloc(N * sizeof(int)); >>> it's very easy to see what the intention is. >> >> Until the type of buff changes, which does happen. >> > Automatic variables shouldn't have a large scope, so you should be able to > check the entire function when making a modification. The real danger is > when buff is a member of a structure, which has many functions which operate > on it. But you can easily have other problems. I'd wager more dynamic allocations *are* used to initialise members of structures (which are more likely to changer their type) than are used for automatic variables. The only real use for dynamic allocations to automatic variables is for objects that are too large for the (mythical) stack. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2013-08-25 08:09 -0700 |
| Message-ID | <fb464a65-465d-4992-a5ab-d52ccd88a3ab@googlegroups.com> |
| In reply to | #35751 |
On Sunday, August 25, 2013 4:03:07 AM UTC+1, Ian Collins wrote: > Malcolm McLean wrote: > > > In programming the trivial is important. Little difficulties have a way of > > accumulating, and combining to make major headaches. > > Such as the types of variables changing? > The fact that the sizeof *ptr method is robust to the type of ptr changing is a real advantage. That has to be balanced against the disadvantage of writing code which is difficult for a human to read. > > I'd wager more dynamic allocations *are* used to initialise members of > structures (which are more likely to changer their type) than are used > for automatic variables. The only real use for dynamic allocations to > automatic variables is for objects that are too large for the (mythical) > stack. > Stacks are getting very big now. I wouldn't have considered declaring a buffer of 1000 ints on the stack when I started with C, now I routinely do so.
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web