Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #83511 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2016-03-09 00:52 -0800 |
| Last post | 2016-03-30 07:00 -0700 |
| Articles | 20 on this page of 330 — 24 participants |
Back to article view | Back to comp.lang.c
Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-09 00:52 -0800
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-09 10:13 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-09 02:19 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-09 02:23 -0800
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-09 13:00 +0000
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-09 02:38 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-09 02:59 -0800
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-09 10:35 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-10 00:20 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-09 02:56 -0800
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-09 13:11 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-09 06:37 -0800
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-09 15:50 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-09 08:19 -0800
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-09 17:18 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-10 00:11 -0800
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-10 08:48 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-10 04:17 -0800
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-10 11:12 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-10 04:16 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-10 04:20 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-09 08:41 -0800
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-09 17:27 +0000
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-09 22:41 -0600
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-10 10:38 +0000
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-10 09:37 -0600
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-10 15:51 +0000
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-10 18:42 -0600
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-11 04:17 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-10 00:18 -0800
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-10 08:51 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-09 08:50 -0800
Re: Testing nodes and lists for hashtable jadill33@gmail.com - 2016-03-09 07:16 -0800
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-09 09:27 -0600
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-09 07:46 -0800
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-09 10:56 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-10 00:25 -0800
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-10 08:55 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-11 01:14 -0800
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-11 01:53 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-11 02:25 -0800
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-11 12:31 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-12 00:03 -0800
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-12 09:04 -0800
Re: Testing nodes and lists for hashtable mark.bluemel@gmail.com - 2016-03-11 02:30 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-11 02:39 -0800
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-11 02:52 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-11 04:09 -0800
Re: Testing nodes and lists for hashtable mark.bluemel@gmail.com - 2016-03-14 08:41 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-11 02:34 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-11 02:41 -0800
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-11 12:14 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-11 04:20 -0800
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-11 12:33 +0000
Re: Testing nodes and lists for hashtable Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-03-11 12:12 -0600
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-11 10:24 -0800
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-11 19:04 +0000
Re: Testing nodes and lists for hashtable Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-03-11 14:20 -0600
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-11 23:55 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-11 04:23 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-11 04:25 -0800
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-11 12:36 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-11 05:56 -0800
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-11 14:55 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-11 07:22 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-11 07:29 -0800
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-11 16:01 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-11 23:41 -0800
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-13 13:48 +0000
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-11 20:20 +0000
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-13 13:06 +0000
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-12 17:41 -0600
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-13 05:03 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-13 13:50 +0000
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-13 10:32 -0500
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-13 09:18 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-13 16:31 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-13 10:17 -0700
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-13 10:17 -0500
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-13 09:06 -0700
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-13 09:51 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-13 10:31 -0700
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-13 12:41 -0500
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-11 08:41 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-11 23:54 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-12 08:10 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-12 08:17 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-12 08:19 -0800
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-12 09:16 -0800
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-13 04:17 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-12 19:37 +0000
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-13 11:20 -0500
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-13 21:37 +0000
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-12 09:48 -0800
Re: Testing nodes and lists for hashtable raltbos@xs4all.nl (Richard Bos) - 2016-03-12 20:31 +0000
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-12 21:18 +0000
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-12 17:54 -0600
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-13 04:25 -0700
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-13 04:44 -0700
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-13 12:31 -0500
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-13 11:14 -0700
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-13 16:17 -0500
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-13 14:37 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-13 11:43 -0700
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-13 12:08 -0700
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-13 16:31 -0500
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-14 01:12 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-14 01:21 -0700
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-14 13:48 -0500
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-15 01:43 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-14 01:35 -0700
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-14 13:44 -0500
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-15 01:39 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-13 23:04 +0000
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-13 16:09 -0700
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-13 17:54 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-14 01:58 -0700
Re: Testing nodes and lists for hashtable fir <profesor.fir@gmail.com> - 2016-03-14 03:08 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-14 10:59 +0000
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 04:59 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-14 13:15 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-14 11:09 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-14 03:18 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 11:03 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-14 11:17 -0700
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-14 15:16 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-15 01:59 -0700
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarz45@yahoo.com> - 2016-03-15 20:13 -0700
Re: Testing nodes and lists for hashtable supercat@casperkitty.com - 2016-03-15 22:09 -0700
Re: Testing nodes and lists for hashtable BartC <bc@freeuk.com> - 2016-03-16 11:53 +0000
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-16 09:39 -0500
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-16 07:57 -0700
Re: Testing nodes and lists for hashtable supercat@casperkitty.com - 2016-03-16 08:38 -0700
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-16 09:04 -0700
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-16 11:22 -0500
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-16 10:42 -0700
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-16 10:57 -0700
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-16 11:57 -0700
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-16 10:43 -0500
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-16 10:59 -0700
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-16 13:22 -0500
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-16 16:09 -0700
Re: Testing nodes and lists for hashtable supercat@casperkitty.com - 2016-03-16 17:03 -0700
Re: Testing nodes and lists for hashtable raltbos@xs4all.nl (Richard Bos) - 2016-03-20 13:04 +0000
Re: Testing nodes and lists for hashtable Tim Rentsch <txr@alumni.caltech.edu> - 2016-03-30 09:07 -0700
Re: Testing nodes and lists for hashtable luser droog <luser.droog@gmail.com> - 2016-03-31 20:34 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-14 14:04 +0000
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-14 11:07 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-14 03:49 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-14 13:03 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-14 11:24 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-14 11:41 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-14 19:35 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-15 01:53 -0700
Re: Testing nodes and lists for hashtable luser droog <luser.droog@gmail.com> - 2016-03-15 02:03 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-15 02:09 -0700
Re: Testing nodes and lists for hashtable luser droog <luser.droog@gmail.com> - 2016-03-15 02:13 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-15 02:22 -0700
Re: Testing nodes and lists for hashtable luser droog <luser.droog@gmail.com> - 2016-03-15 02:15 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-15 02:28 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-15 02:30 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-15 09:13 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-15 02:28 -0700
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-15 03:15 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-15 13:26 +0000
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-15 09:18 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-15 03:19 -0700
Re: Testing nodes and lists for hashtable David Brown <david.brown@hesbynett.no> - 2016-03-15 15:21 +0100
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-15 08:39 -0700
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-15 09:26 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 00:10 -0700
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-15 09:19 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 00:08 -0700
Re: Testing nodes and lists for hashtable David Brown <david.brown@hesbynett.no> - 2016-03-16 08:55 +0100
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-16 09:17 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 09:25 -0700
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 13:06 -0700
Re: Testing nodes and lists for hashtable Gareth Owen <gwowen@gmail.com> - 2016-03-14 20:29 +0000
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 21:03 +0000
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-14 14:57 -0700
Re: Testing nodes and lists for hashtable raltbos@xs4all.nl (Richard Bos) - 2016-03-14 22:35 +0000
Re: Testing nodes and lists for hashtable David Brown <david.brown@hesbynett.no> - 2016-03-16 19:47 +0100
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-14 14:26 -0700
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-14 11:37 -0700
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-14 11:37 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-15 08:58 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-15 16:12 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 00:04 -0700
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-15 10:48 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-15 18:00 +0000
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-15 19:20 +0000
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-15 21:24 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 00:50 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-16 11:19 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 04:37 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-16 11:51 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 05:20 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 07:13 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 09:05 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-16 11:45 +0000
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-16 13:46 +0000
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-16 14:00 +0000
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-16 07:05 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-16 16:42 +0000
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-16 10:21 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-16 17:33 +0000
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-16 10:44 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-16 18:00 +0000
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-16 11:08 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-16 18:19 +0000
Re: Testing nodes and lists for hashtable Gareth Owen <gwowen@gmail.com> - 2016-03-16 19:38 +0000
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-16 14:00 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-16 21:52 +0000
Re: Testing nodes and lists for hashtable Gareth Owen <gwowen@gmail.com> - 2016-03-16 22:12 +0000
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-16 13:39 -0500
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-16 15:39 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-17 02:59 +0000
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-17 04:20 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-17 23:46 +0000
Re: Testing nodes and lists for hashtable Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-17 20:04 -0400
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-18 01:05 +0000
Re: Testing nodes and lists for hashtable Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-17 22:35 -0400
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-17 17:19 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-18 01:39 +0000
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-18 02:54 -0700
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-18 09:08 -0500
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-18 11:20 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-18 21:29 +0000
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-18 17:48 -0700
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-16 22:09 -0500
Re: Testing nodes and lists for hashtable raltbos@xs4all.nl (Richard Bos) - 2016-03-17 11:49 +0000
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-17 08:45 -0700
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-17 12:11 -0500
Re: Testing nodes and lists for hashtable supercat@casperkitty.com - 2016-03-17 10:31 -0700
Re: Testing nodes and lists for hashtable Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-17 11:09 -0700
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-17 16:15 -0500
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-18 00:39 +0000
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-16 12:04 -0500
Re: Testing nodes and lists for hashtable Steve Thompson <stevet810@gmail.com> - 2016-03-17 14:21 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 00:53 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 01:00 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 01:24 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-16 11:08 +0000
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-16 11:25 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 00:41 -0700
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-16 08:27 -0500
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 06:43 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-16 14:07 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 08:16 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-16 15:25 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 08:30 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-16 20:32 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-17 03:26 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-17 16:15 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-17 11:07 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 08:47 -0700
Re: Testing nodes and lists for hashtable Stephen Sprunk <stephen@sprunk.org> - 2016-03-16 10:54 -0500
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 09:35 -0700
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-16 11:31 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-17 02:53 -0700
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-28 18:08 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-30 02:07 -0700
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-30 09:45 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-30 17:54 +0100
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-16 20:26 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-17 03:00 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-17 16:05 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-16 09:10 -0700
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-16 12:24 -0700
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-16 13:16 -0700
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-16 16:20 -0700
Re: Testing nodes and lists for hashtable supercat@casperkitty.com - 2016-03-16 16:54 -0700
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-16 17:27 -0700
Re: Testing nodes and lists for hashtable supercat@casperkitty.com - 2016-03-16 13:18 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-16 20:21 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-17 04:23 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-17 04:47 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-17 05:40 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-17 12:49 +0000
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-17 06:45 -0700
Re: Testing nodes and lists for hashtable mark.bluemel@gmail.com - 2016-03-17 10:00 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-17 12:40 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-28 12:00 -0700
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-28 12:37 -0700
Re: Testing nodes and lists for hashtable Geoff <geoff@invalid.invalid> - 2016-03-28 17:43 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-30 01:31 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-30 01:55 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-30 10:23 +0100
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-30 02:32 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-30 02:33 -0700
Re: Testing nodes and lists for hashtable Geoff <geoff@invalid.invalid> - 2016-03-30 07:04 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-30 15:17 +0100
Re: Testing nodes and lists for hashtable Geoff <geoff@invalid.invalid> - 2016-03-30 07:46 -0700
Re: Testing nodes and lists for hashtable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-30 16:41 +0100
Re: Testing nodes and lists for hashtable Geoff <geoff@invalid.invalid> - 2016-03-30 09:16 -0700
Re: Testing nodes and lists for hashtable Geoff <geoff@invalid.invalid> - 2016-03-30 09:18 -0700
Re: Testing nodes and lists for hashtable Geoff <geoff@invalid.invalid> - 2016-03-30 09:37 -0700
Re: Testing nodes and lists for hashtable Barry Schwarz <schwarzb@dqel.com> - 2016-03-30 10:32 -0700
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-30 12:10 -0700
Re: Testing nodes and lists for hashtable Geoff <geoff@invalid.invalid> - 2016-03-28 17:42 -0700
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-29 08:51 -0700
Re: Testing nodes and lists for hashtable Geoff <geoff@invalid.invalid> - 2016-03-29 09:56 -0700
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-29 12:09 -0700
Re: Testing nodes and lists for hashtable Geoff <geoff@invalid.invalid> - 2016-03-29 16:34 -0700
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-29 16:50 -0700
Re: Testing nodes and lists for hashtable Geoff <geoff@invalid.invalid> - 2016-03-29 17:17 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-30 02:30 -0700
Re: Testing nodes and lists for hashtable Richard Heathfield <rjh@cpax.org.uk> - 2016-03-30 00:52 +0100
Re: Testing nodes and lists for hashtable Geoff <geoff@invalid.invalid> - 2016-03-29 17:27 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-30 02:26 -0700
Re: Testing nodes and lists for hashtable mark.bluemel@gmail.com - 2016-03-30 07:09 -0700
Re: Testing nodes and lists for hashtable Geoff <geoff@invalid.invalid> - 2016-03-30 07:33 -0700
Re: Testing nodes and lists for hashtable Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-30 11:32 -0400
Re: Testing nodes and lists for hashtable mrs@kithrup.com (Mike Stump) - 2016-04-29 08:21 +0000
Re: Testing nodes and lists for hashtable Jerry Stuckle <jstucklex@attglobal.net> - 2016-04-29 10:35 -0400
Re: Testing nodes and lists for hashtable Ken Brody <kenbrody@spamcop.net> - 2016-04-29 11:29 -0400
Re: Testing nodes and lists for hashtable Jerry Stuckle <jstucklex@attglobal.net> - 2016-04-29 12:21 -0400
Re: Testing nodes and lists for hashtable Ken Brody <kenbrody@spamcop.net> - 2016-05-02 11:55 -0400
Re: Testing nodes and lists for hashtable Jerry Stuckle <jstucklex@attglobal.net> - 2016-05-02 13:13 -0400
Re: Testing nodes and lists for hashtable supercat@casperkitty.com - 2016-03-30 08:15 -0700
Re: Testing nodes and lists for hashtable Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-30 11:39 -0400
Re: Testing nodes and lists for hashtable supercat@casperkitty.com - 2016-03-30 09:47 -0700
Re: Testing nodes and lists for hashtable Geoff <geoff@invalid.invalid> - 2016-03-30 08:48 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-30 02:18 -0700
Re: Testing nodes and lists for hashtable Geoff <geoff@invalid.invalid> - 2016-03-30 06:56 -0700
Re: Testing nodes and lists for hashtable Keith Thompson <kst-u@mib.org> - 2016-03-30 09:04 -0700
Re: Testing nodes and lists for hashtable Geoff <geoff@invalid.invalid> - 2016-03-30 09:25 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-04-01 00:52 -0700
Re: Testing nodes and lists for hashtable Alla _ <modelling.data@gmail.com> - 2016-03-30 02:05 -0700
Re: Testing nodes and lists for hashtable Geoff <geoff@invalid.invalid> - 2016-03-30 07:00 -0700
Page 10 of 17 — ← Prev page 1 … 8 9 [10] 11 12 … 17 Next page →
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-03-14 22:35 +0000 |
| Message-ID | <56e73c59.3405546@news.xs4all.nl> |
| In reply to | #83937 |
Keith Thompson <kst-u@mib.org> wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > > On 14/03/16 20:06, Malcolm McLean wrote: > >> On Monday, March 14, 2016 at 6:41:51 PM UTC, Alla _ wrote: > >>> > >>> Unfortunately, I can't yet write the makefile myself, > >>> so I don't truly understand if I shall compile dictionary_test.c, or > >>> should I compile only speller.c. > >>> > >> No-one can understand makefiles. > > > > That's not true. > > > > Makefiles can be as simple or complicated as you like. I like to keep > > mine relatively simple, but I know plenty of people who write really > > scary makefiles that they can understand just fine. And there's always > > the documentation, if you're really desperate. > > And *some* Makefiles are generated automatically by other tools. Such > Makefiles tend not to be particularly legible. (Of course that doesn't > justify Malcolm's overly general statement.) In fact, it makes one wonder whether CMake itself creates makefiles as an interim step... and whether those makefiles are human-legible. As for me, I'll happily read my own makefiles, and keep them simple, but sometimes shake my head in exasperation at other people's. Richard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-03-16 19:47 +0100 |
| Message-ID | <ncc9ho$bu3$2@dont-email.me> |
| In reply to | #83923 |
On 14/03/16 22:03, Richard Heathfield wrote: > On 14/03/16 20:06, Malcolm McLean wrote: >> On Monday, March 14, 2016 at 6:41:51 PM UTC, Alla _ wrote: >>> >>> Unfortunately, I can't yet write the makefile myself, >>> so I don't truly understand if I shall compile dictionary_test.c, or >>> should I compile only speller.c. >>> >> No-one can understand makefiles. > > That's not true. > > Makefiles can be as simple or complicated as you like. I like to keep > mine relatively simple, but I know plenty of people who write really > scary makefiles that they can understand just fine. And there's always > the documentation, if you're really desperate. > You can also find a good compromise - I have written some really scary makefiles, and can't understand them :-) (Actually, I /can/ understand them, but it's not easy - the sed expressions in particular took a fair amount of trial and error. But once it works, it is reusable on many projects.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-03-14 14:26 -0700 |
| Message-ID | <lnk2l4kayz.fsf@kst-u.example.com> |
| In reply to | #83916 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, March 14, 2016 at 6:41:51 PM UTC, Alla _ wrote:
>> Unfortunately, I can't yet write the makefile myself,
>> so I don't truly understand if I shall compile dictionary_test.c, or
>> should I compile only speller.c.
>>
> No-one can understand makefiles.
> They're incomprehensible.
Wrong.
--
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 | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2016-03-14 11:37 -0700 |
| Message-ID | <g90eebdrtkqhjnpqhqem4mmqm51vhhtb4g@4ax.com> |
| In reply to | #83858 |
On Mon, 14 Mar 2016 03:49:29 -0700 (PDT), Alla _
<modelling.data@gmail.com> wrote:
>/**
> * Unloads dictionary from memory. Returns true if successful else false.
> */
>bool unload(void)
>{
> if (hashtable != NULL)
> {
> node *cursor = hashtable->list[0];
> for (int i = 0; i < HASHTABLE_SIZE && cursor != NULL; i++)
This loop appears broken for two reasons:
cursor will never be assigned the value of list[j] for any j
other than 0. Thus it will never free the allocation for words
beginning with any letter other than a.
Even if cursor were assigned each list[j], consider the case
where the dictionary consisted of words beginning with a and c. When
cursor is assigned list[1], it will be NULL. The loop will terminate
without ever checking list[2] which it must do to free the 'c' words.
You really need two nested loops:
An outer one to process list[i] where i runs from 0 to
HASHTABLE_SIZE-1.
An inner one to traverse the linked list from list[i] until
cursor->next is NULL.
> {
> node *temp = cursor;
> cursor = cursor->next;
> free(temp);
> }
> return true;
Shouldn't this function also release the allocations that were
performed for hashtable->list and hashtable itself in create_table?
> }
> return false;
This is supposed to indicate failure. But this statement is executed
only if the input is NULL. What is the failure? There was nothing to
release and it was done without error.
>}
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2016-03-14 11:37 -0700 |
| Message-ID | <2mvdeb9im8cjktkfhn873uo55bgiodm74j@4ax.com> |
| In reply to | #83858 |
On Mon, 14 Mar 2016 03:49:29 -0700 (PDT), Alla _ <modelling.data@gmail.com> wrote: >This is the first time I have to combine these two types of files, >and I don't understand how that works. It seems I am doing something >wrong, because my dictionary_test.c doesn't compile. >I have put typedef stucts in .h file, but initialize a global table >ht* in .c file. All the rest are copies of the functions we have discussed >here. >Here is what I get from compiler: >Undefined symbols for architecture x86_64: > "_main", referenced from: > start in crt1.10.6.o >ld: symbol(s) not found for architecture x86_64 >collect2: ld returned 1 exit status For your reference, those are link diagnostics, not compile diagnostics. I don't use gcc but I hope the output it produces provides some way to distinguish between the two. -- Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-03-15 08:58 -0700 |
| Message-ID | <4cd46c6f-2fee-49c7-a4e1-c3dcaa969efa@googlegroups.com> |
| In reply to | #83511 |
speller.c doesn't operate correctly; it generates strange output,
and there is no time values within this output.
I have installed valgrind to see what's going on in a hope to find
mistakes. What's strange, valgrind has showed the time summery, which
didn't appear at the terminal after I ran speller.c (I have changed names
back to original ones).
Please, take a look at the first part of valgrind report I am trying to
decipher; my comments are within it separated by //
Here are parts that valgrind refer to:
in dictionary.c
bool unload(void)
{
if (hashtable != NULL)
{
node *cursor = NULL;
for (int i = 0; i < HASHTABLE_SIZE; i++)
{
cursor = hashtable->list[i]; // this is dictionary.c:179
while(cursor != NULL)
{
node *temp = cursor;
cursor = cursor->next;
free(temp);
}
free(hashtable); // this is dictionary.c:186
}
return true;
}
return false;
}
in speller.c main()
bool unloaded = unload(); // this is speller.c:157
ht *create_table (void)
{
hashtable = malloc(sizeof *hashtable); // this is dictionary.c:56
if (hashtable != NULL)
{
hashtable->list = malloc(HASHTABLE_SIZE * sizeof *hashtable->list);
if (hashtable->list != NULL)
{
hashtable->size = HASHTABLE_SIZE;
for (int i = 0; i < HASHTABLE_SIZE; i++)
hashtable->list[i] = NULL;
}
else
{
free(hashtable);
hashtable = NULL;
}
}
return hashtable;
}
bool load(const char *dictionary)
{
FILE *open_dict;
node *new_node = NULL;
char new_word[LENGTH] = {0};
if ((open_dict = fopen(dictionary, "r")) != NULL)
{
if ((hashtable = create_table()) != NULL) // this is dictionary.c:86
{
while (fscanf(open_dict, "%44s", new_word) == 1 &&
(new_node = create_node(new_word)) != NULL)
{
//******dictionary_size += 1;
unsigned int hash_index = hash(new_word) % HASHTABLE_SIZE;
new_node->next = hashtable->list[hash_index];
hashtable->list[hash_index] = new_node;
}
return true;
}
else
{
printf("Couldn't create a table: out of memory\n");
return false;
}
fclose(open_dict);
}
bool loaded = load(dictionary); // this is in main() speller.c:45
==13760== Invalid read of size 8
==13760== at 0x100001970: unload (dictionary.c:179) //
==13760== by 0x100000FBF: main (speller.c:157)
==13760== Address 0x1000050c0 is 0 bytes inside a block of size 16 free'd
==13760== at 0xD9E8: free (vg_replace_malloc.c:534)
==13760== by 0x1000019BC: unload (dictionary.c:186)
==13760== by 0x100000FBF: main (speller.c:157)
==13760== Block was alloc'd at
==13760== at 0xC258: malloc (vg_replace_malloc.c:303)
==13760== by 0x100001546: create_table (dictionary.c:56)
==13760== by 0x100001674: load (dictionary.c:86)
==13760== by 0x100000B28: main (speller.c:45)
I understand from this the following (generally speaking it tells me
that I am free the space that's already somehow free):
the memory has been allocated for the hashtable within dictionary.c:56,
dictionary.c:86, speller.c:45, which is in fact "one action", because
speller.c calls load function, which in turn calls create_table function.
The report tells that I have invalidly used 8 bytes for
cursor = hashtable->list[i];
and that I free 0 bytes, which means nothing, by free(hashtable); why
does it have 0 bytes, if hashtable is a global variable, and memory
was allocated and never freed before this call to free()?
Thank you!
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-03-15 16:12 +0000 |
| Message-ID | <nc9c3m$vij$1@dont-email.me> |
| In reply to | #84027 |
On 15/03/16 15:58, Alla _ wrote:
> bool unload(void)
> {
> if (hashtable != NULL)
> {
> node *cursor = NULL;
>
> for (int i = 0; i < HASHTABLE_SIZE; i++)
> {
> cursor = hashtable->list[i]; // this is dictionary.c:179
Okay, we're taking i from 0 to some integer HASHTABLE_SIZE - 1, which I
presume is 25 or so.
First time through, we have cursor = hashtable->list[0], which is fine.
> while(cursor != NULL)
> {
> node *temp = cursor;
> cursor = cursor->next;
> free(temp);
> }
Okay, we've released all the nodes from hashtable[0]. Good.
> free(hashtable); // this is dictionary.c:186
Now we've destroyed hashtable, so we're not allowed to refer to that
memory any more. But next time round the loop, you set cursor to the
value of hashtable->list[1].
So you're freeing hashtable too soon. Move that free() call outside the
loop.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-03-16 00:04 -0700 |
| Message-ID | <1c18440b-9ddc-49b3-82c0-7a9bd21db2fa@googlegroups.com> |
| In reply to | #84029 |
On Tuesday, March 15, 2016 at 8:12:43 PM UTC+4, Richard Heathfield wrote:
> On 15/03/16 15:58, Alla _ wrote:
>
> > bool unload(void)
> > {
> > if (hashtable != NULL)
> > {
> > node *cursor = NULL;
> >
> > for (int i = 0; i < HASHTABLE_SIZE; i++)
> > {
> > cursor = hashtable->list[i]; // this is dictionary.c:179
>
> Okay, we're taking i from 0 to some integer HASHTABLE_SIZE - 1, which I
> presume is 25 or so.
>
> First time through, we have cursor = hashtable->list[0], which is fine.
>
> > while(cursor != NULL)
> > {
> > node *temp = cursor;
> > cursor = cursor->next;
> > free(temp);
> > }
>
> Okay, we've released all the nodes from hashtable[0]. Good.
>
> > free(hashtable); // this is dictionary.c:186
>
> Now we've destroyed hashtable, so we're not allowed to refer to that
> memory any more. But next time round the loop, you set cursor to the
> value of hashtable->list[1].
>
> So you're freeing hashtable too soon. Move that free() call outside the
> loop.
>
Ah, I see! Thank you!
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2016-03-15 10:48 -0700 |
| Message-ID | <jgigeb11kpt2pfdeafckrunv56auhrhk63@4ax.com> |
| In reply to | #84027 |
On Tue, 15 Mar 2016 08:58:02 -0700 (PDT), Alla _
<modelling.data@gmail.com> wrote:
>bool unload(void)
>{
> if (hashtable != NULL)
> {
> node *cursor = NULL;
>
> for (int i = 0; i < HASHTABLE_SIZE; i++)
> {
> cursor = hashtable->list[i]; // this is dictionary.c:179
> while(cursor != NULL)
> {
> node *temp = cursor;
> cursor = cursor->next;
> free(temp);
> }
> free(hashtable); // this is dictionary.c:186
You still have a memory leak. Your while loop frees all the
allocations from create_node. This statement frees one allocation
from create_table. Look at that function and determine how many
allocations it performs. There should be a free for each.
> }
> return true;
> }
> return false;
>}
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-03-15 18:00 +0000 |
| Message-ID | <nc9ide$j99$1@dont-email.me> |
| In reply to | #84037 |
On 15/03/16 17:48, Barry Schwarz wrote:
> On Tue, 15 Mar 2016 08:58:02 -0700 (PDT), Alla _
> <modelling.data@gmail.com> wrote:
>
>> bool unload(void)
>> {
>> if (hashtable != NULL)
>> {
>> node *cursor = NULL;
>>
>> for (int i = 0; i < HASHTABLE_SIZE; i++)
>> {
>> cursor = hashtable->list[i]; // this is dictionary.c:179
>> while(cursor != NULL)
>> {
>> node *temp = cursor;
>> cursor = cursor->next;
>> free(temp);
>> }
>> free(hashtable); // this is dictionary.c:186
>
> You still have a memory leak. Your while loop frees all the
> allocations from create_node. This statement frees one allocation
> from create_table. Look at that function and determine how many
> allocations it performs. There should be a free for each.
I think the problem stems from trying to do too much in a single
function. By separating out the task of destroying the nodes from the
task of destroying the table, we can make each task clearer:
static void unload_nodes(void)
{
if(hashtable != NULL)
{
for(int i = 0; i < HASHTABLE_SIZE; i++)
{
node *cursor = hashtable->list[i];
while(cursor != NULL)
{
node *temp = cursor;
cursor = cursor->next;
free(temp);
}
hashtable->list[i] = NULL; /* restore a consistent state */
}
}
}
bool unload(void)
{
bool had_to_unload = false;
if(hashtable != NULL)
{
unload_nodes();
free(hashtable);
hashtable = NULL; /* ensure that a second call to unload()
will stop at the test. */
had_to_unload = true;
}
return had_to_unload;
}
or, if you don't mind early returns:
bool unload(void)
{
if(hashtable == NULL)
{
return false;
}
unload_nodes();
free(hashtable);
hashtable = NULL;
return true;
}
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-03-15 19:20 +0000 |
| Message-ID | <87mvpz1rbk.fsf@bsb.me.uk> |
| In reply to | #84039 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 15/03/16 17:48, Barry Schwarz wrote:
>> On Tue, 15 Mar 2016 08:58:02 -0700 (PDT), Alla _
>> <modelling.data@gmail.com> wrote:
>>
>>> bool unload(void)
>>> {
>>> if (hashtable != NULL)
>>> {
>>> node *cursor = NULL;
>>>
>>> for (int i = 0; i < HASHTABLE_SIZE; i++)
>>> {
>>> cursor = hashtable->list[i]; // this is dictionary.c:179
>>> while(cursor != NULL)
>>> {
>>> node *temp = cursor;
>>> cursor = cursor->next;
>>> free(temp);
>>> }
>>> free(hashtable); // this is dictionary.c:186
>>
>> You still have a memory leak.
Yes, and the hashtable->link can't be used anymore yet the for loop will
ry to do so. I point this out because it's the source of valgrind's
complaint about the access on line 179. Once the hash table is freed
all access to it is illegal.
> Your while loop frees all the
>> allocations from create_node. This statement frees one allocation
>> from create_table. Look at that function and determine how many
>> allocations it performs. There should be a free for each.
>
> I think the problem stems from trying to do too much in a single
> function. By separating out the task of destroying the nodes from the
> task of destroying the table, we can make each task clearer:
I was think the same but then...
> static void unload_nodes(void)
> {
> if(hashtable != NULL)
> {
> for(int i = 0; i < HASHTABLE_SIZE; i++)
> {
> node *cursor = hashtable->list[i];
> while(cursor != NULL)
> {
> node *temp = cursor;
> cursor = cursor->next;
> free(temp);
> }
> hashtable->list[i] = NULL; /* restore a consistent state */
> }
> }
> }
>
> bool unload(void)
> {
> bool had_to_unload = false;
>
> if(hashtable != NULL)
> {
> unload_nodes();
> free(hashtable);
> hashtable = NULL; /* ensure that a second call to unload()
> will stop at the test. */
> had_to_unload = true;
> }
> return had_to_unload;
> }
I don't see what the bool return is for, but I may well have missed some
posts as the program developed.
But there are two more substantive points. One is that I think there is
still a leak -- you need to free hashtable->list. The second is that
this strikes me as an odd, rather uneaen, division of the work. There
are two data types here -- a list and an array -- so surely the
freeing-up should be done by one function that can free a list:
void free_node_list(node *list)
{
while (list != NULL) {
node *temp = list->next;
free(list);
list = temp;
}
}
and another one that runs through the table:
void unload(void) // should take a hash table but...
{
if (hashtable != NULL) {
for(int i = 0; i < HASHTABLE_SIZE; i++)
free_node_list(hashtable->list[i]);
free(hashtable->list);
free(hashtable); // and set to NULL if that is your preference
}
}
(Didn't have time to even show this to a compiler so I'm sure there will
be issues but you get the idea.)
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-03-15 21:24 +0000 |
| Message-ID | <nc9ubl$d5k$1@dont-email.me> |
| In reply to | #84044 |
On 15/03/16 19:20, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 15/03/16 17:48, Barry Schwarz wrote:
>>> On Tue, 15 Mar 2016 08:58:02 -0700 (PDT), Alla _
>>> <modelling.data@gmail.com> wrote:
>>>
>>>> bool unload(void)
>>>> {
>>>> if (hashtable != NULL)
>>>> {
>>>> node *cursor = NULL;
>>>>
>>>> for (int i = 0; i < HASHTABLE_SIZE; i++)
>>>> {
>>>> cursor = hashtable->list[i]; // this is dictionary.c:179
>>>> while(cursor != NULL)
>>>> {
>>>> node *temp = cursor;
>>>> cursor = cursor->next;
>>>> free(temp);
>>>> }
>>>> free(hashtable); // this is dictionary.c:186
>>>
>>> You still have a memory leak.
>
> Yes, and the hashtable->link can't be used anymore yet the for loop will
> ry to do so. I point this out because it's the source of valgrind's
> complaint about the access on line 179. Once the hash table is freed
> all access to it is illegal.
Yes, I pointed this out in an earlier reply.
>> Your while loop frees all the
>>> allocations from create_node. This statement frees one allocation
>>> from create_table. Look at that function and determine how many
>>> allocations it performs. There should be a free for each.
>>
>> I think the problem stems from trying to do too much in a single
>> function. By separating out the task of destroying the nodes from the
>> task of destroying the table, we can make each task clearer:
>
> I was think the same but then...
>
>> static void unload_nodes(void)
>> {
>> if(hashtable != NULL)
>> {
>> for(int i = 0; i < HASHTABLE_SIZE; i++)
>> {
>> node *cursor = hashtable->list[i];
>> while(cursor != NULL)
>> {
>> node *temp = cursor;
>> cursor = cursor->next;
>> free(temp);
>> }
>> hashtable->list[i] = NULL; /* restore a consistent state */
>> }
>> }
>> }
>>
>> bool unload(void)
>> {
>> bool had_to_unload = false;
>>
>> if(hashtable != NULL)
>> {
>> unload_nodes();
>> free(hashtable);
>> hashtable = NULL; /* ensure that a second call to unload()
>> will stop at the test. */
>> had_to_unload = true;
>> }
>> return had_to_unload;
>> }
>
> I don't see what the bool return is for, but I may well have missed some
> posts as the program developed.
I assumed (perhaps wrongly) that he wasn't allowed to change the
interface of this function. I don't see what it's for, either.
>
> But there are two more substantive points. One is that I think there is
> still a leak -- you need to free hashtable->list.
You're right. I thought the memory was allocated[N] in the struct, but
it isn't -- it's node **.
> The second is that
> this strikes me as an odd, rather uneven,
Uneven is odd, isn't it?
> division of the work. There
> are two data types here -- a list and an array -- so surely the
> freeing-up should be done by one function that can free a list:
>
> void free_node_list(node *list)
> {
> while (list != NULL) {
> node *temp = list->next;
> free(list);
> list = temp;
> }
> }
>
> and another one that runs through the table:
>
> void unload(void) // should take a hash table but...
> {
> if (hashtable != NULL) {
> for(int i = 0; i < HASHTABLE_SIZE; i++)
> free_node_list(hashtable->list[i]);
> free(hashtable->list);
> free(hashtable); // and set to NULL if that is your preference
> }
> }
>
> (Didn't have time to even show this to a compiler so I'm sure there will
> be issues but you get the idea.)
I do. I like the idea of free_node_list(), but I'd go a step further and
move the loop out:
void unload(void)
{
if(hashtable != NULL)
{
free_node_list_array(hashtable->list); /* will call
free_node_list() in a loop */
free(hashtable->list);
free(hashtable);
hashtable = NULL; /* I think this is an essential step, not an
optional one. If, later, unload() is called again by mistake, hashtable
having a null value will protect against an illegal free() call. Defence
in depth. */
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-03-16 00:50 -0700 |
| Message-ID | <cd2a6e60-2e9d-4787-a9c4-55d8c92ee41c@googlegroups.com> |
| In reply to | #84044 |
On Tuesday, March 15, 2016 at 11:20:27 PM UTC+4, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
> > On 15/03/16 17:48, Barry Schwarz wrote:
> >> On Tue, 15 Mar 2016 08:58:02 -0700 (PDT), Alla _
> >> <modelling.data@gmail.com> wrote:
> >>
> >>> bool unload(void)
> >>> {
> >>> if (hashtable != NULL)
> >>> {
> >>> node *cursor = NULL;
> >>>
> >>> for (int i = 0; i < HASHTABLE_SIZE; i++)
> >>> {
> >>> cursor = hashtable->list[i]; // this is dictionary.c:179
> >>> while(cursor != NULL)
> >>> {
> >>> node *temp = cursor;
> >>> cursor = cursor->next;
> >>> free(temp);
> >>> }
> >>> free(hashtable); // this is dictionary.c:186
> >>
> >> You still have a memory leak.
>
> Yes, and the hashtable->link can't be used anymore yet the for loop will
> ry to do so. I point this out because it's the source of valgrind's
> complaint about the access on line 179. Once the hash table is freed
> all access to it is illegal.
>
> > Your while loop frees all the
> >> allocations from create_node. This statement frees one allocation
> >> from create_table. Look at that function and determine how many
> >> allocations it performs. There should be a free for each.
> >
> > I think the problem stems from trying to do too much in a single
> > function. By separating out the task of destroying the nodes from the
> > task of destroying the table, we can make each task clearer:
>
> I was think the same but then...
>
> > static void unload_nodes(void)
> > {
> > if(hashtable != NULL)
> > {
> > for(int i = 0; i < HASHTABLE_SIZE; i++)
> > {
> > node *cursor = hashtable->list[i];
> > while(cursor != NULL)
> > {
> > node *temp = cursor;
> > cursor = cursor->next;
> > free(temp);
> > }
> > hashtable->list[i] = NULL; /* restore a consistent state */
> > }
> > }
> > }
> >
> > bool unload(void)
> > {
> > bool had_to_unload = false;
> >
> > if(hashtable != NULL)
> > {
> > unload_nodes();
> > free(hashtable);
> > hashtable = NULL; /* ensure that a second call to unload()
> > will stop at the test. */
> > had_to_unload = true;
> > }
> > return had_to_unload;
> > }
>
> I don't see what the bool return is for, but I may well have missed some
> posts as the program developed.
>
> But there are two more substantive points. One is that I think there is
> still a leak -- you need to free hashtable->list. The second is that
> this strikes me as an odd, rather uneaen, division of the work. There
> are two data types here -- a list and an array -- so surely the
> freeing-up should be done by one function that can free a list:
>
> void free_node_list(node *list)
> {
> while (list != NULL) {
> node *temp = list->next;
> free(list);
> list = temp;
> }
> }
>
Thank you! I am not sure I understand what's the difference between
the above version and the one Richard has suggested (apart from linguistics);
does the main difference lie in freeing the list not within free_node_list()
function but within this unload() function?:
static void unload_nodes(void)
{
if(hashtable != NULL)
{
for(int i = 0; i < HASHTABLE_SIZE; i++)
{
node *cursor = hashtable->list[i];
while(cursor != NULL)
{
node *temp = cursor;
cursor = cursor->next;
free(temp);
}
hashtable->list[i] = NULL; /* restore a consistent state */
}
}
}
> and another one that runs through the table:
>
> void unload(void) // should take a hash table but...
> {
> if (hashtable != NULL) {
> for(int i = 0; i < HASHTABLE_SIZE; i++)
> free_node_list(hashtable->list[i]);
> free(hashtable->list);
Is the main difference in the above statement - to free the list
not within free_node_list() function but within this unload() function?
> free(hashtable); // and set to NULL if that is your preference
> }
> }
>
> (Didn't have time to even show this to a compiler so I'm sure there will
> be issues but you get the idea.)
>
> <snip>
> --
> Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-03-16 11:19 +0000 |
| Message-ID | <874mc61xh0.fsf@bsb.me.uk> |
| In reply to | #84071 |
Alla _ <modelling.data@gmail.com> writes:
> On Tuesday, March 15, 2016 at 11:20:27 PM UTC+4, Ben Bacarisse wrote:
<snip>
>> But there are two more substantive points. One is that I think there is
>> still a leak -- you need to free hashtable->list. The second is that
>> this strikes me as an odd, rather uneaen, division of the work. There
>> are two data types here -- a list and an array -- so surely the
>> freeing-up should be done by one function that can free a list:
>>
>> void free_node_list(node *list)
>> {
>> while (list != NULL) {
>> node *temp = list->next;
>> free(list);
>> list = temp;
>> }
>> }
<snip>
>> and another one that runs through the table:
>>
>> void unload(void) // should take a hash table but...
>> {
>> if (hashtable != NULL) {
>> for(int i = 0; i < HASHTABLE_SIZE; i++)
>> free_node_list(hashtable->list[i]);
>> free(hashtable->list);
>
> Is the main difference in the above statement - to free the list
> not within free_node_list() function but within this unload()
> function?
I would not put it like that, but (if I understand you) that is the
difference. I'd say the list *is* freed within free_node_list -- this
is the purpose of the function.
If you'd come to this exercise via a few other that were about building
an using lists (a very common data structure in programming) you would
probably already have a function to free a list, as well as one to
search a list for a string. As a result it would seem like a natural
division of the work: run though the table in one function calling
another to free the nodes.
But this reminds me of the another small problem I keep forgetting! You
still have a memory leak because the storage for the words themselves is
not being freed. A simple solution to that is to call free on
list->word in free_node_list.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-03-16 04:37 -0700 |
| Message-ID | <f12a17b3-ab87-4685-ae84-fcb323934f72@googlegroups.com> |
| In reply to | #84080 |
On Wednesday, March 16, 2016 at 3:19:51 PM UTC+4, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Tuesday, March 15, 2016 at 11:20:27 PM UTC+4, Ben Bacarisse wrote:
> <snip>
> >> But there are two more substantive points. One is that I think there is
> >> still a leak -- you need to free hashtable->list. The second is that
> >> this strikes me as an odd, rather uneaen, division of the work. There
> >> are two data types here -- a list and an array -- so surely the
> >> freeing-up should be done by one function that can free a list:
> >>
> >> void free_node_list(node *list)
> >> {
> >> while (list != NULL) {
> >> node *temp = list->next;
> >> free(list);
> >> list = temp;
> >> }
> >> }
> <snip>
> >> and another one that runs through the table:
> >>
> >> void unload(void) // should take a hash table but...
> >> {
> >> if (hashtable != NULL) {
> >> for(int i = 0; i < HASHTABLE_SIZE; i++)
> >> free_node_list(hashtable->list[i]);
> >> free(hashtable->list);
> >
> > Is the main difference in the above statement - to free the list
> > not within free_node_list() function but within this unload()
> > function?
>
> I would not put it like that, but (if I understand you) that is the
> difference. I'd say the list *is* freed within free_node_list -- this
> is the purpose of the function.
>
> If you'd come to this exercise via a few other that were about building
> an using lists (a very common data structure in programming) you would
> probably already have a function to free a list, as well as one to
> search a list for a string. As a result it would seem like a natural
> division of the work: run though the table in one function calling
> another to free the nodes.
>
> But this reminds me of the another small problem I keep forgetting! You
> still have a memory leak because the storage for the words themselves is
> not being freed. A simple solution to that is to call free on
> list->word in free_node_list.
>
This is most likely the reason for the below valgrind message, which
I am trying to understand - it does show a definite leak, indicating that
unload() doesn't free all memory:
89 bytes in 13 blocks are definitely lost in loss record 7 of 14
==811== at 0xC258: malloc (vg_replace_malloc.c:303)
==811== by 0x100001466: create_node (dictionary.c:36)
==811== by 0x1000016CB: load (dictionary.c:89)
==811== by 0x100000B28: main (speller.c:45)
node *create_node(const char *word)
{
node *new_node = malloc(sizeof *new_node);
if (new_node != NULL)
{
new_node->word = malloc(strlen(word) + 1); dictionary.c:36
if (new_node->word != NULL)
{
strcpy(new_node->word, word);
new_node->next = NULL;
}
else
{
free(new_node);
new_node = NULL;
}
}
return new_node;
}
bool load(const char *dictionary)
{
FILE *open_dict;
node *new_node = NULL;
char new_word[LENGTH] = {0};
if ((open_dict = fopen(dictionary, "r")) != NULL)
{
if ((hashtable = create_table()) != NULL)
{
while (fscanf(open_dict, "%44s", new_word) == 1 && // dictionary.c:88
(new_node = create_node(new_word)) != NULL) dictionary.c:89
{
//******dictionary_size += 1;
unsigned int hash_index = hash(new_word);
new_node->next = hashtable->list[hash_index];
hashtable->list[hash_index] = new_node;
}
return true;
}
else
{
printf("Couldn't create a table: out of memory\n");
return false;
}
fclose(open_dict);
}
printf("Couldn't open dictionary\n");
return false;
}
// load dictionary
getrusage(RUSAGE_SELF, &before);
bool loaded = load(dictionary); speller.c: 45
getrusage(RUSAGE_SELF, &after);
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-03-16 11:51 +0000 |
| Message-ID | <ncbh5h$6fc$1@dont-email.me> |
| In reply to | #84082 |
On 16/03/16 11:37, Alla _ wrote: > On Wednesday, March 16, 2016 at 3:19:51 PM UTC+4, Ben Bacarisse wrote: <snip> >> But this reminds me of the another small problem I keep forgetting! You >> still have a memory leak because the storage for the words themselves is >> not being freed. A simple solution to that is to call free on >> list->word in free_node_list. >> > This is most likely the reason for the below valgrind message, which > I am trying to understand - it does show a definite leak, indicating that > unload() doesn't free all memory: > > 89 bytes in 13 blocks are definitely lost in loss record 7 of 14 I've snipped the rest of the valgrind message, useful though it undoubtedly is, because the above line is a HUGE clue, and is probably enough all by itself to help you track down the leak. Why? Two reasons spring to mind: 1) the leak is of 89 bytes. Not 88 or 92 or even 90, but 89. That's an odd number, which gives us a strong hint that the data that's being retained is byte-aligned, so it's very probably character data, or at least /includes/ character data. And you only have one kind of character data -- the words themselves. 2) there are 13 blocks of memory being leaked. What's the betting that your dictionary has 13 words in it? -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-03-16 05:20 -0700 |
| Message-ID | <69b1790d-8125-43d2-963b-dc0ea7f329e0@googlegroups.com> |
| In reply to | #84085 |
On Wednesday, March 16, 2016 at 3:51:20 PM UTC+4, Richard Heathfield wrote:
> On 16/03/16 11:37, Alla _ wrote:
> > On Wednesday, March 16, 2016 at 3:19:51 PM UTC+4, Ben Bacarisse wrote:
>
> <snip>
>
> >> But this reminds me of the another small problem I keep forgetting! You
> >> still have a memory leak because the storage for the words themselves is
> >> not being freed. A simple solution to that is to call free on
> >> list->word in free_node_list.
> >>
> > This is most likely the reason for the below valgrind message, which
> > I am trying to understand - it does show a definite leak, indicating that
> > unload() doesn't free all memory:
> >
> > 89 bytes in 13 blocks are definitely lost in loss record 7 of 14
>
> I've snipped the rest of the valgrind message, useful though it
> undoubtedly is, because the above line is a HUGE clue, and is probably
> enough all by itself to help you track down the leak. Why? Two reasons
> spring to mind:
>
> 1) the leak is of 89 bytes. Not 88 or 92 or even 90, but 89. That's an
> odd number, which gives us a strong hint that the data that's being
> retained is byte-aligned, so it's very probably character data, or at
> least /includes/ character data. And you only have one kind of character
> data -- the words themselves.
>
> 2) there are 13 blocks of memory being leaked. What's the betting that
> your dictionary has 13 words in it?
>
That's beautiful ) And an immediate lesson on how to read and interpret
data. Thank you. Yes, indeed, the dictionary has 13 words )
This is tricky (and so interesting): I have memory allocated for structure
table, which I free by free(hashtabe); then there are blocks of memory
allocated for each list in hashtable and these are an arrays of pointers
to node* pointers, I free them by free(hashtable->list[i]);
each hashtable->list[i] has a pointer to the next node within it, hence
I free those with the while loop and temp value:
void free_node_list(node *list)
{
while (list != NULL)
{
node *temp = list->next;
free(list);
list = temp;
}
}
But each of those nodes also have memory allocated to list->word; so
the memory allocated for the word should be freed before I free memory
allocated for the whole node, otherwise I won't be able to access freed
list anymore.
void free_node_list(node *list)
{
while (list != NULL)
{
node *temp = list->next;
free(list->word);
free(list);
list = temp;
}
}
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-03-16 07:13 -0700 |
| Message-ID | <17b52bb3-031b-4757-a38b-4e62f9d35b77@googlegroups.com> |
| In reply to | #84089 |
<snip>
>
> This is tricky (and so interesting): I have memory allocated for structure
> table, which I free by free(hashtabe); then there are blocks of memory
> allocated for each list in hashtable and these are an arrays of pointers
> to node* pointers, I free them by free(hashtable->list[i]);
> each hashtable->list[i] has a pointer to the next node within it, hence
> I free those with the while loop and temp value:
> void free_node_list(node *list)
> {
> while (list != NULL)
> {
> node *temp = list->next;
> free(list);
> list = temp;
> }
> }
> But each of those nodes also have memory allocated to list->word; so
> the memory allocated for the word should be freed before I free memory
> allocated for the whole node, otherwise I won't be able to access freed
> list anymore.
> void free_node_list(node *list)
> {
> while (list != NULL)
> {
> node *temp = list->next;
> free(list->word);
> free(list);
> list = temp;
> }
> }
nope, this is incorrect, and valgrind is not happy. Analyzing further.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-03-16 09:05 -0700 |
| Message-ID | <d0515855-c4a3-4dad-86d0-4a9d3dea2b76@googlegroups.com> |
| In reply to | #84104 |
On Wednesday, March 16, 2016 at 6:13:50 PM UTC+4, Alla _ wrote:
> <snip>
> >
> > This is tricky (and so interesting): I have memory allocated for structure
> > table, which I free by free(hashtabe); then there are blocks of memory
> > allocated for each list in hashtable and these are an arrays of pointers
> > to node* pointers, I free them by free(hashtable->list[i]);
> > each hashtable->list[i] has a pointer to the next node within it, hence
> > I free those with the while loop and temp value:
> > void free_node_list(node *list)
> > {
> > while (list != NULL)
> > {
> > node *temp = list->next;
> > free(list);
> > list = temp;
> > }
> > }
> > But each of those nodes also have memory allocated to list->word; so
> > the memory allocated for the word should be freed before I free memory
> > allocated for the whole node, otherwise I won't be able to access freed
> > list anymore.
> > void free_node_list(node *list)
> > {
> > while (list != NULL)
> > {
> > node *temp = list->next;
> > free(list->word);
> > free(list);
> > list = temp;
> > }
> > }
>
> nope, this is incorrect, and valgrind is not happy. Analyzing further.
nope again - it worked ) I have no idea why it didn't work few times, but
now it does work in both separate-functions version and within one-function
version of unload().
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-03-16 11:45 +0000 |
| Message-ID | <ncbgrh$59s$1@dont-email.me> |
| In reply to | #84080 |
On 16/03/16 11:19, Ben Bacarisse wrote: <snip> > But this reminds me of the another small problem I keep forgetting! You > still have a memory leak because the storage for the words themselves is > not being freed. A simple solution to that is to call free on > list->word in free_node_list. It's interesting that such a problem survived for so long. (I am taking you at your word about this leak, since I haven't gone back to check.) I think this is because of the way in which the program has been developed. First, take a poorly-designed and poorly-understood interface. Next, bolt onto it a few pieces that you think might be handy. The next stage is to take careful note of several pieces of advice, trying hard to ignore the problem that, although each piece might make sense individually, they don't necessarily work /together/ all that well. Finally, tweak the code until it seems to do more or less what the spec requires. This is not an uncommon way for learners to develop programs. I'm sure I wrote many similar programs once upon a time, and no doubt others here did the same when they were learning. Top-down design works well, provided that you don't nail yourself to interfaces too early. Bottom-up design allows you to build robust components that can then be assembled in useful ways. The best bottom-up design is application-blind -- the components one creates become one's own library. As the library grows and becomes more useful, it becomes easier and easier for future programs to be designed in a top-down way, because you've got more tools to choose from. In this case, I'd have done it something like this (if I were starting from scratch and were not constrained by the interface design): 1) a module for storing text data, and for destroying it when no longer needed, with the 'constructor' and 'destructor' adhering to a generic, flexible format; 2) a module for storing /arbitrary/ data in a linked list, for searching that list, for destroying specific nodes in that list, and for destroying the whole list; 3) a module for calculating a hash from arbitrary data; 4) a module for building, using, and destroying a hash table with arbitrarily many buckets. 5) main(), which would have been trivially simple to write by this stage. Except that I'd have used a BBST in each bucket, rather than a linked list. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 10 of 17 — ← Prev page 1 … 8 9 [10] 11 12 … 17 Next page →
Back to top | Article view | comp.lang.c
csiph-web