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 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-25 14:02 -0700 |
| Message-ID | <lnzjs5mqkt.fsf@nuthaus.mib.org> |
| In reply to | #35767 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 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.
I'm glad you realize that.
> That has to be balanced against the disadvantage of writing
> code which is difficult for a human to read.
No, it doesn't. Learn the idiom once, understand it forever.
Do *you* find it difficult, or do you merely assume that everyone
else does? (I've asked you this, in different words, several times;
you have yet to answer.)
If your goal is to write code that can be understood by
non-programmers, or by programmers unfamiliar with the language
it's written in, I suggest C is not the language for you. Cobol was
meant to achieve that goal (no comment on whether it succeeded).
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2013-08-25 22:43 -0700 |
| Message-ID | <85172825-b233-4bb7-985e-076542338605@googlegroups.com> |
| In reply to | #35781 |
On Sunday, August 25, 2013 10:02:42 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > That has to be balanced against the disadvantage of writing > > code which is difficult for a human to read. > > No, it doesn't. Learn the idiom once, understand it forever. > > Do *you* find it difficult, or do you merely assume that everyone > else does? (I've asked you this, in different words, several times; > you have yet to answer.) > Hard to read. Not difficult intellectually of course. one issue is ptr = malloc(N * sizeof *ptr); uses the same operator glyph in different contexts which aren't lexically distinguished, except by an optional whitespace convention.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-08-25 02:21 +0100 |
| Message-ID | <0.c612b18408a4e51294a2.20130825022142BST.87k3jah8ex.fsf@bsb.me.uk> |
| In reply to | #35736 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > 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); No. My remark followed this (no snipped): | At least put in parentheses so we can have visual fix on what sizeof | applies to. I meant what are the options for what sizeof may apply to? I can see only three, and the wrong ones are so daft I would bother to address them. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-24 19:41 -0700 |
| Message-ID | <lnhaeeo5kk.fsf@nuthaus.mib.org> |
| In reply to | #35736 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 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.
You understand it perfectly well, don't you?
sizeof is unusual in that it's the only operator named by a keyword
rather than by a punctuation symbol. (C11 adds _Alignof, but that
doesn't take a subexpression operand.) There are other languages that
have multiple operators whose names are keywords. Even C has "and",
"or", "xor" and so on if you have #include <iso646.h>. It's really not
a difficult concept.
> 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.
A programmer who thinks sizeof is a function needs to learn that sizeof
isn't a function. Once. You might try telling people that yourself,
rather than suggesting elaborate workarounds to avoid the burden of
learning it.
I have no great objection to extraneous parentheses on sizeof; they're
mostly harmless. But I dislike using them myself, because I prefer to
keep in mind that sizeof is an operator, not a function. (Same thing
for "return" and "case".)
> The best option is
>
> buff = malloc(N * sizeof(int));
>
> it's very easy to see what the intention is.
No, because I declared "int32_t *buff", and if I write it that way I'll
never notice the error until I try it on a 64-bit system.
(And someone with the level of expertise you assume will probably think
that sizeof is a function, and wonder what it means to evaluate "int" as
an argument.)
--
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-24 15:15 -0700 |
| Message-ID | <lny57qd9bo.fsf@nuthaus.mib.org> |
| 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.
It's perfectly easy to read once you've learned it, and you only have to
learn it once. Don't try to prevent other people from learning the
language.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2013-08-24 02:48 -0700 |
| Message-ID | <f3a2ba58-0251-4105-927b-268581aaef4a@googlegroups.com> |
| In reply to | #35642 |
On Friday, August 23, 2013 6:15:42 PM UTC+1, Sharwan Joram wrote: > Often when you get an error on calling free, the problem is that there's been memory corruption in the preceding or following block, which could be in a very different part of the program in code space. But you are calling strtok() on a wild pointer. That will rewrite some random point in memory with a character zero. If that's not your problem, you're allocating a wild amount of parameters. Assuming you've just posted a fragement and these variables are correct, your loop condition stops when strtok() returns NULL. Tha't asking for trouble, as you might have more than parametercount tokens in the string. You also say that allocating *parameters (* *parametercount?) breaks. That's a bit worrying, it shouldn't, nad indicates something wrong somewhere. Then as James pointed out, you're setting the string to a constant. You say this is commented out. Are you sure?
[toc] | [prev] | [next] | [standalone]
| From | Sven Köhler <remove-sven.koehler@gmail.com> |
|---|---|
| Date | 2013-08-24 17:02 +0300 |
| Message-ID | <b7rsoeF4vr7U1@mid.dfncis.de> |
| In reply to | #35642 |
Hi,
here are some comments on your code.
Am 23.08.2013 20:15, schrieb Sharwan Joram:
> 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.
I can't tell how much memory you allocate. What's the value of
parametercount?
> for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
> parameters[parametercount] = (char *)malloc(30 * sizeof (char *));
Clearly this line is wrong. You cast to (char*), yet you use
sizeof(char*). What you really meant is
parameters[parametercount] = (char *)malloc(30 * sizeof (char));
> memset(parameters[parametercount], '\0', 30);
> memcpy(parameters[parametercount], token, strlen(token));
I hope you make sure, each token is no longer than 29 characters.
Also instead of using memset, memcpy, and strlen, you could use strncpy:
strncpy(parameters[parametercount], token, 29);
parameters[parametercount][29]=0;
> parameters[parametercount] = token;
You just allocated some memory with malloc. You will never be able to
free that memory again, since you overwrite the pointer here. Also, you
just memcpy'ed the string - so why copy the pointer? Delete this line.
Also, a few lines below you free all pointers in the array. Actually,
you won't free what you allocated here, but you will free the memory
pointed to by the token variable! And from the looks of it, the token
variable contains to the middle of a string. Such pointers cannot be free'd.
> }
>
> /* idx contains the number of tokens */
> if (parameters != NULL){
> for (parametercount = idx; parametercount >= 0; ++parametercount)
> free(parameters[parametercount]);
> free(parameters);
> }
I can't tell what the value of idx is. Also, it seems to me like you
want to count backwards but instead you have ++parametercount in the for
loop.
Please post a snippet that is somewhat more complete.
Regards,
Sven
[toc] | [prev] | [next] | [standalone]
| From | Sharwan Joram <sharwan.joram@gmail.com> |
|---|---|
| Date | 2013-08-24 12:05 -0700 |
| Message-ID | <eb9eb063-9006-4727-bd48-d568ae150d37@googlegroups.com> |
| In reply to | #35687 |
On Saturday, August 24, 2013 7:32:52 PM UTC+5:30, Sven Köhler wrote:
> Hi,
>
>
>
> here are some comments on your code.
>
>
>
> Am 23.08.2013 20:15, schrieb Sharwan Joram:
>
> > 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.
>
>
>
> I can't tell how much memory you allocate. What's the value of
>
> parametercount?
>
>
>
> > for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
>
> > parameters[parametercount] = (char *)malloc(30 * sizeof (char *));
>
>
>
> Clearly this line is wrong. You cast to (char*), yet you use
>
> sizeof(char*). What you really meant is
>
>
>
> parameters[parametercount] = (char *)malloc(30 * sizeof (char));
>
>
>
> > memset(parameters[parametercount], '\0', 30);
>
> > memcpy(parameters[parametercount], token, strlen(token));
>
>
>
> I hope you make sure, each token is no longer than 29 characters.
>
> Also instead of using memset, memcpy, and strlen, you could use strncpy:
>
>
>
> strncpy(parameters[parametercount], token, 29);
>
> parameters[parametercount][29]=0;
>
>
>
> > parameters[parametercount] = token;
>
>
>
> You just allocated some memory with malloc. You will never be able to
>
> free that memory again, since you overwrite the pointer here. Also, you
>
> just memcpy'ed the string - so why copy the pointer? Delete this line.
>
>
>
> Also, a few lines below you free all pointers in the array. Actually,
>
> you won't free what you allocated here, but you will free the memory
>
> pointed to by the token variable! And from the looks of it, the token
>
> variable contains to the middle of a string. Such pointers cannot be free'd.
>
>
>
> > }
>
> >
>
> > /* idx contains the number of tokens */
>
> > if (parameters != NULL){
>
> > for (parametercount = idx; parametercount >= 0; ++parametercount)
>
> > free(parameters[parametercount]);
>
> > free(parameters);
>
> > }
>
>
>
> I can't tell what the value of idx is. Also, it seems to me like you
>
> want to count backwards but instead you have ++parametercount in the for
>
> loop.
>
>
>
> Please post a snippet that is somewhat more complete.
>
>
>
>
>
> Regards,
>
> Sven
I've modified the code with the guidelines given by James and other mentors in the list, mentioned below. But it's still failing.
-----------Code Snippet -------------
/*-----------------------------------------*/
if(token != NULL){
char *temp_token = (char *) malloc (strlen(saved_token) + 1);
memcpy(temp_token, saved_token, strlen(saved_token));
idx = parametercount = detect_delim_count(temp_token, delimiters);
if (temp_token)
free(temp_token);
parameters = malloc(parametercount * sizeof(char *));
if ( NULL == parameters){
fprintf(stdout, "CLI: Couldn't allocate sufficient memory . Exiting \n");
exit(1);
}
for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
parameters[parametercount] = calloc(30 , strlen(token) + 1);
if ( NULL == parameters[parametercount]){
fprintf(stdout,"CLI: Couldn't allocate sufficient memory. Exiting \n");
exit(1);
}
strncpy(parameters[parametercount], token, strlen(token));
}
shutdown = (currentcommand->command_handler)(client_fd, parameters, parametercount);
}
}else{
/* some more code here */
}
if (parameters != NULL){
for (parametercount = idx ; parametercount >= 0; --parametercount)
free(parameters[parametercount]);
free(parameters);
}
int detect_delim_count(char *i_str, char *delim)
{
char *itr_str = NULL;
char *parser = NULL;
int count = 0;
itr_str = i_str;
for (parser = strtok(itr_str, delim); parser && *parser ; parser = strtok(NULL, delim))
count++;
return (count-1);
}
---------------DEBUG TRACE-----------
Breakpoint 1, execute_commands (client_fd=10, command_name=0xb27fef54 "show parameters param1 param2 param3 param4", d_len=44) at opennopd/subsystems/clicommands.c:158
158 if(token != NULL){
Missing separate debuginfos, use: debuginfo-install glibc-2.15-59.fc17.i686 libmnl-1.0.3-4.fc17.i686 libnetfilter_queue-1.0.2-1.fc17.i686 libnfnetlink-1.0.1-1.fc17.i686 nss-softokn-freebl-3.14.3-1.fc17.i686
(gdb) n
159 char *temp_token = (char *) malloc (strlen(saved_token) + 1);
(gdb)
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) p idx
$1 = 3
(gdb) n
164 parameters = malloc(parametercount * sizeof(char *));
(gdb)
165 if ( NULL == parameters){
(gdb)
169 for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
(gdb)
170 parameters[parametercount] = calloc(30 , strlen(token) + 1);
(gdb)
171 if ( NULL == parameters[parametercount]){
(gdb)
175 strncpy(parameters[parametercount], token, strlen(token));
(gdb)
169 for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
(gdb)
170 parameters[parametercount] = calloc(30 , strlen(token) + 1);
(gdb)
171 if ( NULL == parameters[parametercount]){
(gdb)
169 for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
(gdb)
170 parameters[parametercount] = calloc(30 , strlen(token) + 1);
(gdb)
171 if ( NULL == parameters[parametercount]){
(gdb)
175 strncpy(parameters[parametercount], token, strlen(token));
(gdb)
169 for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
(gdb)
170 parameters[parametercount] = calloc(30 , strlen(token) + 1);
(gdb)
171 if ( NULL == parameters[parametercount]){
(gdb)
175 strncpy(parameters[parametercount], token, strlen(token));
(gdb)
169 for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
(gdb)
177 shutdown = (currentcommand->command_handler)(client_fd, parameters, parametercount);
(gdb)
188 executedcommand = currentcommand;
(gdb) p parameters[0]
$2 = 0xb6e0a040 "param1"
(gdb) p parameters[1]
$3 = 0xb6e0a118 "param2"
(gdb) p parameters[2]
$4 = 0xb6e0a1f0 "param3"
(gdb) p parameters[3]
$5 = 0xb6e0a2c8 "param4"
(gdb) p parameters[4]
$6 = 0x61726170 <Address 0x61726170 out of bounds>
(gdb) p *parameters
$7 = 0xb6e0a040 "param1"
(gdb) n
193 currentcommand = currentcommand->next;
(gdb)
127 while((executedcommand == NULL) && (currentcommand != NULL)){
(gdb)
198 if (parameters != NULL){
(gdb)
199 for (parametercount = idx ; parametercount >= 0; --parametercount)
(gdb)
200 free(parameters[parametercount]);
(gdb) p idx
$8 = 3
(gdb) n
*** glibc detected *** /home/sources/opennop-daemon/opennopd/opennopd: corrupted double-linked list: 0xb6e0a028 ***
======= Backtrace: =========
/lib/libc.so.6[0x4441a1d1]
/lib/libc.so.6[0x4441a7bd]
/home/sources/opennop-daemon/opennopd/opennopd[0x80529e2]
/home/sources/opennop-daemon/opennopd/opennopd[0x80520f5]
/lib/libpthread.so.0[0x4455fadf]
/lib/libc.so.6(clone+0x5e)[0x4449944e]
======= Memory map: ========
08048000-08056000 r-xp 00000000 fd:01 397491 /home/sources/opennop-daemon/opennopd/opennopd
08056000-08057000 rw-p 0000d000 fd:01 397491 /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
b1fff000-b2000000 ---p 00000000 00:00 0
b2000000-b2800000 rw-p 00000000 00:00 0 [stack:4641]
b2800000-b2821000 rw-p 00000000 00:00 0
b2821000-b2900000 ---p 00000000 00:00 0
b2a00000-b2b00000 rw-p 00000000 00:00 0
b2bf9000-b2bfa000 ---p 00000000 00:00 0
b2bfa000-b33fa000 rw-p 00000000 00:00 0 [stack:4637]
b33fa000-b33fb000 ---p 00000000 00:00 0
b33fb000-b3bfb000 rw-p 00000000 00:00 0 [stack:4636]
b3bfb000-b3bfc000 ---p 00000000 00:00 0
b3bfc000-b43fc000 rw-p 00000000 00:00 0 [stack:4635]
b43fc000-b43fd000 ---p 00000000 00:00 0
b43fd000-b4bfd000 rw-p 00000000 00:00 0 [stack:4634]
b4bfd000-b4bfe000 ---p 00000000 00:00 0
b4bfe000-b53fe000 rw-p 00000000 00:00 0 [stack:4633]
b53fe000-b53ff000 ---p 00000000 00:00 0
b53ff000-b5bff000 rw-p 00000000 00:00 0 [stack:4632]
b5bff000-b5c00000 ---p 00000000 00:00 0
b5c00000-b6400000 rw-p 00000000 00:00 0 [stack:4631]
b6400000-b6500000 rw-p 00000000 00:00 0
b65ff000-b6600000 ---p 00000000 00:00 0
b6600000-b6e00000 rw-p 00000000 00:00 0 [stack:4630]
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:4629]
b77d3000-b77d4000 ---p 00000000 00:00 0
b77d4000-b7fd6000 rw-p 00000000 00:00 0 [stack:4628]
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]
Program received signal SIGABRT, Aborted.
0xb7fff424 in __kernel_vsyscall ()
Missing separate debuginfos, use: debuginfo-install libgcc-4.7.2-2.fc17.i686
(gdb)
Input is : param1 param2 param3 param4
Thanks
Sharwan
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2013-08-24 15:14 -0700 |
| Message-ID | <u0bi199eadnt0f1u5ht6bscu99ql9cqur0@4ax.com> |
| In reply to | #35697 |
On Sat, 24 Aug 2013 12:05:02 -0700 (PDT), Sharwan Joram
<sharwan.joram@gmail.com> wrote:
>On Saturday, August 24, 2013 7:32:52 PM UTC+5:30, Sven Köhler wrote:
<snip a lot of irrelevant previous messages>
>I've modified the code with the guidelines given by James and other mentors in the list, mentioned below. But it's still failing.
>
>-----------Code Snippet -------------
>
>
>
>
> /*-----------------------------------------*/
> if(token != NULL){
> char *temp_token = (char *) malloc (strlen(saved_token) + 1);
> memcpy(temp_token, saved_token, strlen(saved_token));
At this point, temp_token does not point to a string. You forgot to
copy the terminal \0. Once again, I suggest you use the appropriate
function (strcpy in this case) rather than trying to use one that you
have to force to be suitable.
> idx = parametercount = detect_delim_count(temp_token, delimiters);
> if (temp_token)
This test is too late. If temp_token is NULL, the call to memcpy and
the processing in detect_delim_count both invoke undefined behavior.
> free(temp_token);
> parameters = malloc(parametercount * sizeof(char *));
> if ( NULL == parameters){
> fprintf(stdout, "CLI: Couldn't allocate sufficient memory . Exiting \n");
> exit(1);
1 is not a portable return code from main. I suggest you use
EXIT_FAILURE.
> }
> for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
The test on *token is still completely superfluous.
Why do you assign a value to parameter count above only to reset the
value here?
> parameters[parametercount] = calloc(30 , strlen(token) + 1);
> if ( NULL == parameters[parametercount]){
> fprintf(stdout,"CLI: Couldn't allocate sufficient memory. Exiting \n");
> exit(1);
> }
> strncpy(parameters[parametercount], token, strlen(token));
I'm confused. I token points to a string of len 5, you allocate and
zero 180 bytes and then copy the 5 char string into the allocated
space. What is the extra 174 bytes for?
strcpy would be more efficient than strncpy for copying the string
unless you change the third argument to something useful.
> }
> shutdown = (currentcommand->command_handler)(client_fd, parameters, parametercount);
> }
> }else{
> /* some more code here */
>
>}
> if (parameters != NULL){
This test is too late. If parameters is NULL at this point, you have
already invoked undefined behavior multiple times.
> for (parametercount = idx ; parametercount >= 0; --parametercount)
> free(parameters[parametercount]);
> free(parameters);
> }
>
>
>
>
> int detect_delim_count(char *i_str, char *delim)
> {
> char *itr_str = NULL;
> char *parser = NULL;
> int count = 0;
>
> itr_str = i_str;
> for (parser = strtok(itr_str, delim); parser && *parser ; parser = strtok(NULL, delim))
> count++;
>
> return (count-1);
Why -1? Is it your intent to never process the last tokenized string?
> }
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-24 15:38 -0700 |
| Message-ID | <lnli3qd8ab.fsf@nuthaus.mib.org> |
| In reply to | #35721 |
Barry Schwarz <schwarzb@dqel.com> writes:
> On Sat, 24 Aug 2013 12:05:02 -0700 (PDT), Sharwan Joram
> <sharwan.joram@gmail.com> wrote:
[...]
>> strncpy(parameters[parametercount], token, strlen(token));
>
[...]
>
> strcpy would be more efficient than strncpy for copying the string
> unless you change the third argument to something useful.
And strncpy is *not* just a "safer" strcpy; it can leave the target
array without a terminating '\0' character (i.e., not a string).
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-08-25 02:10 +0100 |
| Message-ID | <0.9e962e2bfe3a36f29810.20130825021045BST.87y57qh8x6.fsf@bsb.me.uk> |
| In reply to | #35697 |
Sharwan Joram <sharwan.joram@gmail.com> writes:
<snip>
> I've modified the code with the guidelines given by James and other
> mentors in the list, mentioned below. But it's still failing.
Some things not yet mentioned...
> -----------Code Snippet -------------
>
>
>
>
> /*-----------------------------------------*/
> if(token != NULL){
> char *temp_token = (char *) malloc (strlen(saved_token) + 1);
> memcpy(temp_token, saved_token, strlen(saved_token));
> idx = parametercount = detect_delim_count(temp_token, delimiters);
> if (temp_token)
> free(temp_token);
> parameters = malloc(parametercount * sizeof(char *));
> if ( NULL == parameters){
> fprintf(stdout, "CLI: Couldn't allocate sufficient memory . Exiting \n");
> exit(1);
> }
> for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
This loop can run off the end of the allocated array. You need to stop
before parameterCount == idx.
> parameters[parametercount] = calloc(30 , strlen(token) + 1);
> if ( NULL == parameters[parametercount]){
> fprintf(stdout,"CLI: Couldn't allocate sufficient memory. Exiting \n");
> exit(1);
> }
> strncpy(parameters[parametercount], token, strlen(token));
> }
> shutdown = (currentcommand->command_handler)(client_fd, parameters, parametercount);
> }
> }else{
> /* some more code here */
>
> }
> if (parameters != NULL){
> for (parametercount = idx ; parametercount >= 0; --parametercount)
> free(parameters[parametercount]);
Here you free elements that you never set. Even if you used every
available element, the very first free call accesses memory outside the
array.
> free(parameters);
> }
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Sharwan Joram <sharwan.joram@gmail.com> |
|---|---|
| Date | 2013-08-25 00:30 -0700 |
| Message-ID | <966c674d-fc38-47a5-b6e0-55f6679d6111@googlegroups.com> |
| In reply to | #35744 |
On Sunday, August 25, 2013 6:40:45 AM UTC+5:30, Ben Bacarisse wrote:
> Sharwan Joram <sharwan.joram@gmail.com> writes:
>
> <snip>
>
> > I've modified the code with the guidelines given by James and other
>
> > mentors in the list, mentioned below. But it's still failing.
>
>
>
> Some things not yet mentioned...
>
>
>
> > -----------Code Snippet -------------
>
> >
>
> >
>
> >
>
> >
>
> > /*-----------------------------------------*/
>
> > if(token != NULL){
>
> > char *temp_token = (char *) malloc (strlen(saved_token) + 1);
>
> > memcpy(temp_token, saved_token, strlen(saved_token));
>
> > idx = parametercount = detect_delim_count(temp_token, delimiters);
>
> > if (temp_token)
>
> > free(temp_token);
>
> > parameters = malloc(parametercount * sizeof(char *));
>
> > if ( NULL == parameters){
>
> > fprintf(stdout, "CLI: Couldn't allocate sufficient memory . Exiting \n");
>
> > exit(1);
>
> > }
>
> > for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
>
>
>
> This loop can run off the end of the allocated array. You need to stop
>
> before parameterCount == idx.
>
idx contains the number of delimiters available in the string. For example if the string contains 2 delimiters then the sub-strings are 3. The idx decremented by -1 while returning because of the increment in it's value by 1 in last iteration of for loop. This loop works well as expected.
>
>
> > parameters[parametercount] = calloc(30 , strlen(token) + 1);
>
> > if ( NULL == parameters[parametercount]){
>
> > fprintf(stdout,"CLI: Couldn't allocate sufficient memory. Exiting \n");
>
> > exit(1);
>
> > }
>
> > strncpy(parameters[parametercount], token, strlen(token));
>
> > }
>
> > shutdown = (currentcommand->command_handler)(client_fd, parameters, parametercount);
>
> > }
>
> > }else{
>
> > /* some more code here */
>
> >
>
> > }
>
> > if (parameters != NULL){
>
> > for (parametercount = idx ; parametercount >= 0; --parametercount)
>
> > free(parameters[parametercount]);
>
>
>
> Here you free elements that you never set. Even if you used every
>
> available element, the very first free call accesses memory outside the
>
> array.
The elements are assigned above in the code. In for loop.
>
>
>
> > free(parameters);
>
> > }
>
> <snip>
>
>
>
> --
>
> Ben.
Let me know if you find anything else suspicious which can resolve this problem.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-08-25 21:13 +0100 |
| Message-ID | <0.da4727889c670b15fa07.20130825211332BST.8761uth6kz.fsf@bsb.me.uk> |
| In reply to | #35756 |
Sharwan Joram <sharwan.joram@gmail.com> writes:
> On Sunday, August 25, 2013 6:40:45 AM UTC+5:30, Ben Bacarisse wrote:
>> Sharwan Joram <sharwan.joram@gmail.com> writes:
>> <snip>
>>
>> > I've modified the code with the guidelines given by James and other
>> > mentors in the list, mentioned below. But it's still failing.
>>
>> Some things not yet mentioned...
<snip>
>> > if(token != NULL){
>> > char *temp_token = (char *) malloc (strlen(saved_token) + 1);
>> > memcpy(temp_token, saved_token, strlen(saved_token));
You need to copy one more byte to ensure the string is null-terminated,
though, in fact, a simple strcpy(temp_token, saved_token); call is
better here.
>> > if (temp_token)
>> > free(temp_token);
This test is a bit late. I'd put it here:
char *temp_token = malloc(strlen(saved_token) + 1);
if (temp_token) {
strcpy(temp_token, saved_token);
idx = parametercount = detect_delim_count(temp_token, delimiters);
free(temp_token);
}
else { /* complain and exit */ }
>> > parameters = malloc(parametercount * sizeof(char *));
>> > if ( NULL == parameters){
>> > fprintf(stdout, "CLI: Couldn't allocate sufficient memory . Exiting \n");
>> > exit(1);
>> > }
>> > for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
You count delimiters using a variable "delimiters", but here you use
" ". This may be fine for you test case but it's not right in general
and could do all kinds of damage.
>> This loop can run off the end of the allocated array. You need to stop
>> before parameterCount == idx.
>
> idx contains the number of delimiters available in the string. For
> example if the string contains 2 delimiters then the sub-strings are
> 3. The idx decremented by -1 while returning because of the increment
> in it's value by 1 in last iteration of for loop. This loop works well
> as expected.
The one in detect_delim_count works but this one doesn't.
I'd missed the counting, but it still does not work. When there are no
delimiters, idx is set to 0 and you call malloc(0). That's wrong, but
you then make matters worse by assigning to parameters[0]. In the
general case, you count the delimiters but then store a string for every
token (that's one more than the number of delimiters). You always
overrun this array.
I suspect you've got confused as to whether you choose to count
delimiters of parameters. Personally, I'd count parameters.
Given that you've already counted either delimiters (or parameters), I
would suggest you make it clear by making this loop a simple counting
one:
for (int i = 0; i < idx; i++) {
const char *tok = strtok(i == 0 ? saved_token : NULL, " ");
cont int size_t = strlen(tok);
parameters[i] = malloc(len + 1);
// Failure test removed to reduce my typing.
strcpy(parameters[i], tok);
}
I've also removed the odd call to calloc that allocates 30 times the
storage that's needed. Instead, I allocate only what's needed for each
string and so the copy with a plain strcpy.
<snip>
>> > if (parameters != NULL){
>> > for (parametercount = idx ; parametercount >= 0; --parametercount)
>> > free(parameters[parametercount]);
>>
>> Here you free elements that you never set. Even if you used every
>> available element, the very first free call accesses memory outside the
>> array.
>
> The elements are assigned above in the code. In for loop.
Not parameters[idx]. Well, maybe I should be more explicit. You
allocate room for idx pointers indexed from 0 to idx-1, so either the
first loop will overrun the array (by assigning to parameters[idx]), or,
when that's fixed, this loop frees a pointer that was never set.
>> > free(parameters);
>> > }
>>
>> <snip>
>>
>>
>>
>> --
>>
>> Ben.
>
> Let me know if you find anything else suspicious which can resolve
> this problem.
If you worked on making the code clearer, i.e. writing just what you
mean, I think you'd have been able to find most of these yourself.
A tip: can you run the code under a memory checker like valgrind? It's
found more bugs in my code than any other debug tool. I use it whenever
I can.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Sven Köhler <remove-sven.koehler@gmail.com> |
|---|---|
| Date | 2013-08-25 11:13 +0300 |
| Message-ID | <b7tslkFhkb7U1@mid.dfncis.de> |
| In reply to | #35697 |
Dear Sharwan,
The code below doesn't crash and is tested with valgrind.
Learn from it.
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
int detect_delim_count(char *i_str, const char *delim) {
char *token;
int count = 0;
for (token = strtok(i_str, delim); token && *token; token =
strtok(NULL, delim))
count++;
return count;
}
int main() {
char **parameters;
char *token;
int idx, parametercount;
const char* saved_token = "d e f";
const char* delimiters = " ";
char *temp_token = (char *) malloc (strlen(saved_token) + 1);
if ( NULL == temp_token){
fprintf(stdout, "CLI: Couldn't allocate sufficient memory . Exiting \n");
exit(1);
}
strcpy(temp_token, saved_token);
parametercount = detect_delim_count(temp_token, delimiters);
strcpy(temp_token, saved_token);
parameters = malloc(parametercount * sizeof(char *));
if ( NULL == parameters){
fprintf(stdout, "CLI: Couldn't allocate sufficient memory . Exiting \n");
exit(1);
}
for( idx = 0 , token = strtok(temp_token, " "); token && *token ; ++idx
, token = strtok(NULL, " ")){
parameters[idx] = malloc(strlen(token) + 1);
if ( NULL == parameters[idx]){
fprintf(stdout,"CLI: Couldn't allocate sufficient memory. Exiting \n");
exit(1);
}
fprintf(stdout, "found token %s\n", token);
strcpy(parameters[idx], token);
}
free(temp_token);
//shutdown = (currentcommand->command_handler)(client_fd, parameters,
parametercount);
while (parametercount > 0)
free(parameters[--parametercount]);
free(parameters);
}
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-25 10:03 -0400 |
| Message-ID | <kvd2qq$1nk$1@dont-email.me> |
| In reply to | #35697 |
On 08/24/2013 03:05 PM, Sharwan Joram wrote:
...
> I've modified the code with the guidelines given by James and other mentors in the list, mentioned below. But it's still failing.
Not quite. As I and other have said, for best results you need to give
us a complete, compilable program. All you've given us is a:
> -----------Code Snippet -------------
While the code you have given us contains defects severe enough to be
the cause of the symptoms you've observed, you had no way of being sure
that would be the case. It could very well have been that the actual
problem was in some other part of your program.
> if(token != NULL){
> char *temp_token = (char *) malloc (strlen(saved_token) + 1);
> memcpy(temp_token, saved_token, strlen(saved_token));
Once again, you're using the value returned by malloc() before bothering
to check whether malloc() has succeeded. If malloc() failed, temp_token
would be null, and the call to memcpy() would render the behavior of
your program undefined.
> idx = parametercount = detect_delim_count(temp_token, delimiters);
> if (temp_token)
Now you've finally bothered checking whether the allocation succeeded.
That's ironic, because you wait until after it is used twice in ways
that would be dangerous if temp_token is null. The only code you protect
is the call to free(), and free()ing a null pointer is actually
perfectly safe.
detect_delim_count() returns the number of delimiters. The number of
parameters is inherently one more than the number of delimiters. I see
from a later message that you're well aware of that fact. Therefore, I
find it puzzling that you would store the value returned by
detect_delim_count(), in a variable named parametercount. You should
either have named the variable delimitercount, or you should have added
1 to the value returned by detect_delim_count() before storing it in
parametercount.
> free(temp_token);
> parameters = malloc(parametercount * sizeof(char *));
Here you allocate enough room in the parameters array to store one
pointer for each delimiter. However, what you need is enough room to
store one pointer for each parameter, which is one more than the value
currently stored in parametercount.
> if ( NULL == parameters){
> fprintf(stdout, "CLI: Couldn't allocate sufficient memory . Exiting \n");
> exit(1);
> }
> for( parametercount = 0 , token = strtok(saved_token, " "); token && *token ; ++parametercount , token = strtok(NULL, " ")){
> parameters[parametercount] = calloc(30 , strlen(token) + 1);
You're now allocating enough space for 30 copies of the token. I think
you should change 30 to 1, unless there's some reason, not obvious in
the code you've shown, for setting aside that much space.
The last successful call to strtok() will result in the above code
attempting to store the value returned by malloc() into parameters[idx],
but you only allocated enough memory to store idx pointers:
parameters[0] through parameters[idx-1]. You haven't allocated enough
space to store anything in parameters[idx]. Attempting to do so renders
the behavior of your program undefined. Under certain circumstances,
your program might fail immediately because of this defect. However,
judging from the symptoms you've reported, what you did was corrupt some
memory being used by some other part of the program, almost certainly
memory being used by the malloc() family to manage the heap. That's why
the subsequent call to free() failed.
> if ( NULL == parameters[parametercount]){
> fprintf(stdout,"CLI: Couldn't allocate sufficient memory. Exiting \n");
> exit(1);
> }
> strncpy(parameters[parametercount], token, strlen(token));
strlen() has to examine every character in the string, to look for the
terminating null character. strncpy() needs to retrieve the value of
every character in the string. If you'd simply called strcpy() instead,
then it would only have gone through the string once.
In some contexts, strncpy(dest, src, count) can be safer than
strcpy(dest,src). That's true only when "count" is less than strlen(src)
and also less than the length of the array pointed at by dest.
strncpy(dest, src, strlen(src)) stops at exactly the same place that
strcpy() would stop - you don't get any protection at all. If
strlen(src) is bigger than the size of the array pointed at by dest,
strncpy(dest,src,strlen(src)) will still overwrite then end of that
array, just like strcpy().
> }
> shutdown = (currentcommand->command_handler)(client_fd, parameters, parametercount);
> }
> }else{
> /* some more code here */
>
> }
> if (parameters != NULL){
> for (parametercount = idx ; parametercount >= 0; --parametercount)
> free(parameters[parametercount]);
You set parametercount initially to the same value as idx, and used
parametercount to determine how many parameters to allocate space for.
Unless code that you haven't shown has changed the value of idx since
that time, space was therefore only allocated for idx different
pointers, starting with parameters[0] and ending with parameters[idx-1].
However, the above loop starts by trying to retrieve the value of
parameters[idx] and passing it to free(). This would still be a separate
problem even if you corrected parametercount earlier to contain the
count of the parameters, rather than the count of delimiters. In that
case, parameters[idx] would refer to memory that had never been
allocated for use by your program, and which had never been written. to.
As a result, it might contain a trap representation, in which case even
retrieving the value of parameters[idx] would render the behavior of
your program undefined. Even it if were not a trap representation, it
almost certainly would not contain a value returned by a call to
malloc(). Therefore, passing that value to free() would also render the
behavior of your code undefined.
You should correct the for() loop to either of the following forms:
for(parametercount=idx-1; parametercount >=0; --parametercount)
or
for(parametercount=0; parametercount<idx; parametercount++)
The second form is slightly shorter and more idiomatic. I'd also
recommend exchanging the variable names idx and parametercount, since
you're using parameter count more like an index into the parameters
array, and less like a fixed count of parameters.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-25 14:07 -0700 |
| Message-ID | <lnvc2tmqde.fsf@nuthaus.mib.org> |
| In reply to | #35766 |
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) {
>> fprintf(stdout,"CLI: Couldn't allocate sufficient memory. Exiting \n");
>> exit(1);
>> }
>> strncpy(parameters[parametercount], token, strlen(token));
>
> strlen() has to examine every character in the string, to look for the
> terminating null character. strncpy() needs to retrieve the value of
> every character in the string. If you'd simply called strcpy() instead,
> then it would only have gone through the string once.
>
> In some contexts, strncpy(dest, src, count) can be safer than
> strcpy(dest,src). That's true only when "count" is less than strlen(src)
> and also less than the length of the array pointed at by dest.
> strncpy(dest, src, strlen(src)) stops at exactly the same place that
> strcpy() would stop - you don't get any protection at all. If
> strlen(src) is bigger than the size of the array pointed at by dest,
> strncpy(dest,src,strlen(src)) will still overwrite then end of that
> array, just like strcpy().
[...]
You missed the most dangerous thing about strncpy(): it doesn't
necessarily null-terminate the target array (and in this case it won't).
It's *not* just a safer strcpy().
http://the-flat-trantor-society.blogspot.com/2012/03/no-strncpy-is-not-safer-strcpy.html
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-25 18:47 -0400 |
| Message-ID | <kve1hu$lmh$1@dont-email.me> |
| In reply to | #35783 |
On 08/25/2013 05:07 PM, Keith Thompson 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) {
>
>>> fprintf(stdout,"CLI: Couldn't allocate sufficient memory. Exiting \n");
>>> exit(1);
>>> }
>>> strncpy(parameters[parametercount], token, strlen(token));
>>
>> strlen() has to examine every character in the string, to look for the
>> terminating null character. strncpy() needs to retrieve the value of
>> every character in the string. If you'd simply called strcpy() instead,
>> then it would only have gone through the string once.
>>
>> In some contexts, strncpy(dest, src, count) can be safer than
>> strcpy(dest,src). That's true only when "count" is less than strlen(src)
>> and also less than the length of the array pointed at by dest.
>> strncpy(dest, src, strlen(src)) stops at exactly the same place that
>> strcpy() would stop - you don't get any protection at all. If
>> strlen(src) is bigger than the size of the array pointed at by dest,
>> strncpy(dest,src,strlen(src)) will still overwrite then end of that
>> array, just like strcpy().
> [...]
>
> You missed the most dangerous thing about strncpy(): it doesn't
> necessarily null-terminate the target array (and in this case it won't).
> It's *not* just a safer strcpy().
You're right - I deliberately didn't comment on that issue in his
original code, which always memset() the first 30 bytes. As a result, if
code which used those parameters was always careful to read either until
the 30th byte had been read, or until a null character was read,
whichever comes first, the failure to null-terminate the parameters
could have been correct (though I think it unlikely, particularly in the
context of the other errors in his code).
However, when he followed my suggestion to remove the memset(), but
failed to follow my suggestion to change strncpy() to strcpy(), that
removed any possibility that the rest of his code could deal with
parameters stored in this fashion. I should have reconsidered the issue.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2013-08-26 06:40 +0000 |
| Message-ID | <slrn3vfsl1lu2l.n1v.ike@iceland.freeshell.org> |
| In reply to | #35783 |
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.
"It is allowed on all hands, that the primitive way of breaking
eggs, before we eat them, was upon the larger end; but his present
majesty's grandfather, while he was a boy, going to eat an egg,
and breaking it according to the ancient practice, happened to cut
one of his fingers. Whereupon the emperor his father published an
edict, commanding all his subjects, upon great penalties, to break
the smaller end of their eggs. The people so highly resented this
law, that our histories tell us, there have been six rebellions
raised on that account; wherein one emperor lost his life, and
another his crown. These civil commotions were constantly fomented
by the monarchs of Blefuscu; and when they were quelled, the exiles
always fled for refuge to that empire. It is computed that eleven
thousand persons have at several times suffered death, rather than
submit to break their eggs at the smaller end"
(Jonathan Swift, Gulliver's Travels, part 1: A Voyage to Lilliput)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-26 06:31 -0400 |
| Message-ID | <kvfapl$p7$1@dont-email.me> |
| In reply to | #35821 |
On 08/26/2013 02:40 AM, Ike Naar wrote:
> On 2013-08-25, Keith Thompson <kst-u@mib.org> wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>>> On 08/24/2013 03:05 PM, Sharwan Joram wrote:
>> [...]
>>>> if ( NULL == parameters[parametercount]){
>>
>> This is what's known as a "Yoda conndition"
>> <http://en.wikipedia.org/wiki/Yoda_Conditions>. I know that a lot of
>> programmers like them, and for somewhat valid reasons, but personally I
>> find them jarring and unnecessary. Personally, I'd write that as:
>>
>> if (parameters[parametercount] == NULL) {
>
> Does it matter? The == operator is symmetric, (X==Y) == (Y==X).
>
> If (X==Y) is jarring and unnecessary, then, for symmetry reasons
> (Y==X) is unnecessary and jarring.
If jarring and unnecessary is (X==Y), then for symmetry reasons,
unnecessary and jarring is (Y==X).
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2013-08-26 07:44 -0400 |
| Message-ID | <ZcHSt.7102$nK2.6716@en-nntp-11.dc1.easynews.com> |
| In reply to | #35825 |
On 8/26/13 6:31 AM, James Kuyper wrote:
> On 08/26/2013 02:40 AM, Ike Naar wrote:
>> On 2013-08-25, Keith Thompson <kst-u@mib.org> wrote:
>>> James Kuyper <jameskuyper@verizon.net> writes:
>>>> On 08/24/2013 03:05 PM, Sharwan Joram wrote:
>>> [...]
>>>>> if ( NULL == parameters[parametercount]){
>>>
>>> This is what's known as a "Yoda conndition"
>>> <http://en.wikipedia.org/wiki/Yoda_Conditions>. I know that a lot of
>>> programmers like them, and for somewhat valid reasons, but personally I
>>> find them jarring and unnecessary. Personally, I'd write that as:
>>>
>>> if (parameters[parametercount] == NULL) {
>>
>> Does it matter? The == operator is symmetric, (X==Y) == (Y==X).
>>
>> If (X==Y) is jarring and unnecessary, then, for symmetry reasons
>> (Y==X) is unnecessary and jarring.
>
> If jarring and unnecessary is (X==Y), then for symmetry reasons,
> unnecessary and jarring is (Y==X).
>
Only if the jarring is based on pure C language semantics. I think the
previous person was referring to the fact that for English speakers, the
sentence X equals Y, has a different grammatical implications than Y
equals X, as the first variable is the subject of the verb equals and
the second is the object of the verb, and linguistically, the subject of
the verb is more important and should naturally be the variable, not the
constant, as the subject is what is being tested and the object the
value being tested for. It is just the fact that equals has this funny
transitive property that makes swapping make sense programatically, even
if it doesn't really change what makes sense linguistically.
The order NULL == var is jarring because we have no need to test for the
properties of NULL, we know everything possible about it.
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web