Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #63716 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2015-06-21 16:20 +0200 |
| Last post | 2015-06-22 03:25 -0500 |
| Articles | 20 on this page of 214 — 26 participants |
Back to article view | Back to comp.lang.c
More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-21 16:20 +0200
Re: More useful memory functions Reinhardt Behm <rbehm@hushmail.com> - 2015-06-21 22:31 +0800
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-21 16:35 +0200
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 13:20 -0700
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-21 22:52 +0200
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 14:43 -0700
Re: More useful memory functions James Kuyper <jameskuyper@verizon.net> - 2015-06-21 17:50 -0400
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-22 00:21 +0200
Re: More useful memory functions James Kuyper <jameskuyper@verizon.net> - 2015-06-21 18:39 -0400
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-22 00:44 +0200
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-21 16:00 -0700
Re: More useful memory functions raltbos@xs4all.nl (Richard Bos) - 2015-06-22 21:03 +0000
Re: More useful memory functions Robert Wessel <robertwessel2@yahoo.com> - 2015-06-22 18:47 -0500
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-23 00:50 -0700
Re: More useful memory functions Ian Collins <ian-news@hotmail.com> - 2015-06-23 20:19 +1200
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-23 01:46 -0700
Re: More useful memory functions Ian Collins <ian-news@hotmail.com> - 2015-06-23 21:07 +1200
Re: More useful memory functions Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 10:22 +0100
Re: More useful memory functions Ian Collins <ian-news@hotmail.com> - 2015-06-23 21:27 +1200
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-23 08:30 -0700
Re: More useful memory functions Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 16:43 +0100
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-23 02:36 -0700
Re: More useful memory functions Ian Collins <ian-news@hotmail.com> - 2015-06-23 21:54 +1200
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-23 05:38 -0700
Re: More useful memory functions Ian Collins <ian-news@hotmail.com> - 2015-06-24 09:03 +1200
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-23 17:20 -0700
Re: More useful memory functions Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 01:36 +0100
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-23 00:34 -0700
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-23 09:55 +0200
Re: More useful memory functions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-23 08:35 +0000
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-23 11:32 +0200
Re: More useful memory functions raltbos@xs4all.nl (Richard Bos) - 2015-06-24 09:51 +0000
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 17:03 -0700
Re: More useful memory functions gordonb.muhly@burditt.org (Gordon Burditt) - 2015-06-22 05:17 -0500
Re: More useful memory functions James Kuyper <jameskuyper@verizon.net> - 2015-06-22 09:08 -0400
Re: Snipping attribution lines Noob <root@127.0.0.1> - 2015-06-23 22:20 +0200
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 16:57 -0700
Re: More useful memory functions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-22 00:54 +0000
Re: More useful memory functions raltbos@xs4all.nl (Richard Bos) - 2015-06-22 12:35 +0000
Re: More useful memory functions James Kuyper <jameskuyper@verizon.net> - 2015-06-21 21:10 -0400
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 19:21 -0700
Re: More useful memory functions James Kuyper <jameskuyper@verizon.net> - 2015-06-21 22:55 -0400
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-22 13:41 -0500
Re: More useful memory functions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-22 05:01 +0000
Re: More useful memory functions Robert Wessel <robertwessel2@yahoo.com> - 2015-06-22 01:48 -0500
Re: More useful memory functions Waldek Hebisch <hebisch@antispam.uni.wroc.pl> - 2015-06-23 00:06 +0000
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-22 23:42 -0500
Re: More useful memory functions Waldek Hebisch <hebisch@antispam.uni.wroc.pl> - 2015-06-23 23:04 +0000
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-23 22:28 -0500
Re: More useful memory functions Nathan Wagner <nw@hydaspes.if.org> - 2015-06-23 13:23 +0000
Re: More useful memory functions James Kuyper <jameskuyper@verizon.net> - 2015-06-23 09:53 -0400
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-22 08:34 +0200
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-22 10:38 +0200
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-22 11:09 +0200
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-22 07:47 -0700
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-22 16:49 +0200
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-22 17:43 +0200
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-22 17:47 +0200
Re: More useful memory functions raltbos@xs4all.nl (Richard Bos) - 2015-06-22 20:42 +0000
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-22 18:10 -0500
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-23 10:52 +0200
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-22 09:16 -0700
Re: More useful memory functions Ian Collins <ian-news@hotmail.com> - 2015-06-23 09:38 +1200
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-22 10:53 +0100
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-22 11:56 -0500
Re: More useful memory functions James Kuyper <jameskuyper@verizon.net> - 2015-06-22 09:21 -0400
Re: More useful memory functions Nathan Wagner <nw@hydaspes.if.org> - 2015-06-23 13:32 +0000
Re: More useful memory functions Robert Wessel <robertwessel2@yahoo.com> - 2015-06-23 22:37 -0500
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-23 11:07 +0100
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-23 13:40 +0200
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-23 13:56 +0100
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-23 16:20 +0200
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-23 15:44 +0100
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-23 15:50 +0100
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-23 16:57 +0200
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-23 17:38 -0500
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-23 07:49 -0700
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-23 17:17 +0200
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-23 18:34 +0100
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-23 20:08 +0200
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-23 20:42 +0100
More useful memory functions asetofsymbols@gmail.com - 2015-06-21 07:43 -0700
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-21 17:25 +0200
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-21 10:06 -0700
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-21 21:46 +0200
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-21 14:26 -0700
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 13:17 -0700
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-21 22:55 +0200
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 14:45 -0700
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-21 15:14 -0700
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-22 09:44 -0500
Re: More useful memory functions Richard Heathfield <rjh@cpax.org.uk> - 2015-06-21 19:18 +0100
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-21 23:42 +0200
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-22 00:33 +0200
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-22 08:42 +0200
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-22 08:23 -0500
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-21 21:45 +0200
Re: More useful memory functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 10:56 -0700
Re: More useful memory functions Noob <root@127.0.0.1> - 2015-06-21 18:35 +0200
Re: More useful memory functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-21 21:39 +0100
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-22 00:39 +0200
Re: More useful memory functions James Kuyper <jameskuyper@verizon.net> - 2015-06-21 18:41 -0400
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-22 00:47 +0200
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 17:08 -0700
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-21 17:12 -0700
Re: More useful memory functions gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-22 00:58 +0000
Re: More useful memory functions raltbos@xs4all.nl (Richard Bos) - 2015-06-22 21:02 +0000
Re: More useful memory functions Noob <root@127.0.0.1> - 2015-06-23 20:56 +0200
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-23 21:17 +0200
Re: More useful memory functions Noob <root@127.0.0.1> - 2015-06-23 21:58 +0200
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-23 22:06 +0200
Re: More useful memory functions Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 21:21 +0100
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-23 22:48 +0200
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-23 23:17 +0200
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-23 23:25 +0200
Re: More useful memory functions Noob <root@127.0.0.1> - 2015-06-24 00:35 +0200
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-24 00:39 +0200
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-23 15:37 -0700
Re: Microsoft C run-time Noob <root@127.0.0.1> - 2015-06-23 23:22 +0200
Re: Microsoft C run-time jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-23 23:27 +0200
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-23 13:42 -0700
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-23 19:00 -0500
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-24 01:52 +0100
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-23 22:25 -0500
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-24 09:53 +0100
Re: More useful memory functions gwowen <gwowen@gmail.com> - 2015-06-24 01:59 -0700
Re: More useful memory functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-24 11:05 +0100
Re: More useful memory functions Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 11:23 +0100
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-24 07:55 -0500
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-24 07:48 -0700
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-24 10:47 -0500
Re: More useful memory functions raltbos@xs4all.nl (Richard Bos) - 2015-07-03 17:34 +0000
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-05 05:27 -0700
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-24 11:28 +0100
Re: More useful memory functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-24 11:50 +0100
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-24 12:58 +0100
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-24 14:20 +0200
Re: More useful memory functions jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-24 14:27 +0200
Re: More useful memory functions Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 13:38 +0100
Re: More useful memory functions gwowen <gwowen@gmail.com> - 2015-06-24 08:16 -0700
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-24 16:57 +0200
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-24 13:47 +0100
Re: More useful memory functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-24 14:48 +0100
Re: More useful memory functions Bartc <bc@freeuk.com> - 2015-06-24 18:45 +0100
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-24 14:12 -0500
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-24 17:12 +0200
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-24 10:27 -0500
Re: More useful memory functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-24 14:41 +0100
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-24 07:53 -0700
Re: More useful memory functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-24 16:17 +0100
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-06-24 08:34 -0700
Re: More useful memory functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 18:48 -0700
Re: More useful memory functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 18:56 -0700
Re: More useful memory functions Keith Thompson <kst-u@mib.org> - 2015-07-10 20:53 -0700
Re: More useful memory functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 13:52 -0700
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-24 10:31 -0500
Re: More useful memory functions David Brown <david.brown@hesbynett.no> - 2015-06-24 14:15 +0200
Re: gcc FUD Noob <root@127.0.0.1> - 2015-06-25 09:57 +0200
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-25 11:34 +0100
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-25 13:11 +0200
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-25 12:38 +0100
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-25 16:13 +0200
Re: gcc FUD Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-25 09:49 -0700
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-25 11:32 -0500
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-25 18:37 +0100
Re: gcc FUD Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-25 19:56 +0100
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-25 20:33 +0100
Re: gcc FUD Siri Cruz <chine.bleu@yahoo.com> - 2015-06-25 12:46 -0700
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-26 13:08 +0200
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-26 13:22 +0100
Re: gcc FUD Keith Thompson <kst-u@mib.org> - 2015-06-25 11:57 -0700
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-25 16:32 -0500
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-25 23:11 +0100
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-25 20:09 -0500
Re: gcc FUD "Morten W. Petersen" <morphex@gmail.com> - 2015-06-26 10:15 +0200
Re: gcc FUD Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-26 01:54 -0700
Re: gcc FUD "Morten W. Petersen" <morphex@gmail.com> - 2015-06-26 11:17 +0200
Re: gcc FUD Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-26 13:36 +0100
Re: gcc FUD "Morten W. Petersen" <morphex@gmail.com> - 2015-06-26 17:45 +0200
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-26 09:28 -0500
Re: gcc FUD "Morten W. Petersen" <morphex@gmail.com> - 2015-06-26 17:48 +0200
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-26 11:30 -0500
Re: gcc FUD "Morten W. Petersen" <morphex@gmail.com> - 2015-06-27 09:00 +0200
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-27 11:08 -0500
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-28 18:07 +0100
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-28 22:26 -0500
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-29 09:49 +0200
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-29 09:05 -0500
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-29 16:54 +0200
Re: gcc FUD BGB <cr88192@hotmail.com> - 2015-06-29 12:39 -0500
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-26 14:05 +0200
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-27 11:40 +0100
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-27 16:33 +0100
Re: gcc FUD Keith Thompson <kst-u@mib.org> - 2015-06-27 12:24 -0700
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-27 22:37 +0200
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-27 22:31 +0100
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-28 00:47 +0200
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-28 11:28 +0100
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-28 14:00 +0200
Re: gcc FUD Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-28 05:44 -0700
Re: gcc FUD Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-28 13:47 +0100
Re: gcc FUD Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-28 05:55 -0700
Re: gcc FUD Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-28 18:42 +0100
Re: gcc FUD "Morten W. Petersen" <morphex@gmail.com> - 2015-06-29 07:27 +0200
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-29 10:17 +0200
Re: gcc FUD "Morten W. Petersen" <morphex@gmail.com> - 2015-06-29 11:05 +0200
Re: gcc FUD David Brown <david.brown@hesbynett.no> - 2015-06-29 11:34 +0200
Re: gcc FUD Robert Wessel <robertwessel2@yahoo.com> - 2015-06-28 02:14 -0500
Re: gcc FUD Ian Collins <ian-news@hotmail.com> - 2015-06-28 08:57 +1200
Re: gcc FUD Bartc <bc@freeuk.com> - 2015-06-26 10:18 +0100
Re: gcc FUD "Morten W. Petersen" <morphex@gmail.com> - 2015-06-26 11:26 +0200
Re: gcc FUD Paul <nospam@needed.com> - 2015-06-26 08:05 -0400
Re: More useful memory functions BGB <cr88192@hotmail.com> - 2015-06-21 11:56 -0500
Re: More useful memory functions Gordon Burditt <gordon@hammy.burditt.org> - 2015-06-22 03:25 -0500
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-21 19:21 -0700 |
| Message-ID | <lny4jccwkm.fsf@nuthaus.mib.org> |
| In reply to | #63779 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 06/21/2015 07:57 PM, Keith Thompson wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
> ...
>>> If it can find the allocation, for the purposes of free()ing it, it
>>> should be able to determine the allocated size - otherwise how would it
>>> know how much space to free?
>>
>> That assumes that the underlying routine called by free() takes a size
>> argument, or something similar -- in other words, that at some level you
>> have to know how big a block is before you can free it.
>>
>> I'm sure that assumption is valid for many implementations. It might be
>> valid for all of them; I don't know. It's at least something to consider.
>
> I did consider it before responding. I can't quite see my way to a
> formal proof that free() needs to be able to figure out, somehow, how
> much memory to free. However, the only counter-example I've been able to
> form is a malloc() family where free() is essentially a nop - it uses
> the as-if rule to justify not actually making the memory "available for
> further allocation" (7.22.3.3p2). Since that's clearly a cheat, it
> doesn't provide much useful insight.
> I've often been surprised by things that I didn't think were possible,
> turning out to be possible (and in some cases, even pretty easy).
> However, I don't think this is likely to be one of those surprises.
Well, the free() function itself doesn't need to be told how much memory
to free. I can imagine an implementation of malloc() and free() on top
of something with similar behavior, that doesn't have or need access to
any internal information used by the underlying functions. (Perhaps the
underlying functions don't quite match the C interface, so wrappers are
needed.) Possibly at *some* level the size of the block being freed is
known, but the implementation of malloc() and free() don't necessarily
have or need access to that level.
--
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 | 2015-06-21 22:55 -0400 |
| Message-ID | <mm7tcs$p4f$1@dont-email.me> |
| In reply to | #63780 |
On 06/21/2015 10:21 PM, Keith Thompson wrote: > James Kuyper <jameskuyper@verizon.net> writes: ... >> I did consider it before responding. I can't quite see my way to a >> formal proof that free() needs to be able to figure out, somehow, how >> much memory to free. However, the only counter-example I've been able to >> form is a malloc() family where free() is essentially a nop - it uses >> the as-if rule to justify not actually making the memory "available for >> further allocation" (7.22.3.3p2). Since that's clearly a cheat, it >> doesn't provide much useful insight. >> I've often been surprised by things that I didn't think were possible, >> turning out to be possible (and in some cases, even pretty easy). >> However, I don't think this is likely to be one of those surprises. > > Well, the free() function itself doesn't need to be told how much memory > to free. I can imagine an implementation of malloc() and free() on top > of something with similar behavior, that doesn't have or need access to > any internal information used by the underlying functions. (Perhaps the > underlying functions don't quite match the C interface, so wrappers are > needed.) Possibly at *some* level the size of the block being freed is > known, but the implementation of malloc() and free() don't necessarily > have or need access to that level. You're right, of course. But the highest level routines that do know the size present the same issue: why don't they provide access to that information to the user. Or, if they do provide that access, why does the next higher level not take advantage of that fact and pass it on. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-22 13:41 -0500 |
| Message-ID | <mm9l4d$hiu$1@news.albasani.net> |
| In reply to | #63781 |
On 6/21/2015 9:55 PM, James Kuyper wrote: > On 06/21/2015 10:21 PM, Keith Thompson wrote: >> James Kuyper <jameskuyper@verizon.net> writes: > ... >>> I did consider it before responding. I can't quite see my way to a >>> formal proof that free() needs to be able to figure out, somehow, how >>> much memory to free. However, the only counter-example I've been able to >>> form is a malloc() family where free() is essentially a nop - it uses >>> the as-if rule to justify not actually making the memory "available for >>> further allocation" (7.22.3.3p2). Since that's clearly a cheat, it >>> doesn't provide much useful insight. >>> I've often been surprised by things that I didn't think were possible, >>> turning out to be possible (and in some cases, even pretty easy). >>> However, I don't think this is likely to be one of those surprises. >> >> Well, the free() function itself doesn't need to be told how much memory >> to free. I can imagine an implementation of malloc() and free() on top >> of something with similar behavior, that doesn't have or need access to >> any internal information used by the underlying functions. (Perhaps the >> underlying functions don't quite match the C interface, so wrappers are >> needed.) Possibly at *some* level the size of the block being freed is >> known, but the implementation of malloc() and free() don't necessarily >> have or need access to that level. > > You're right, of course. But the highest level routines that do know the > size present the same issue: why don't they provide access to that > information to the user. Or, if they do provide that access, why does > the next higher level not take advantage of that fact and pass it on. > could be like asking why malloc implementations are often also so terrible?... many are pretty usable, some others are pretty bad (slow, wastes memory, ...). and, many of the major implementations can provide additional info via extensions. probably people don't really care. likewise, you would need malloc to generally be pretty consistently good on most targets to convince applications to move away from rolling their own or using a 3rd party allocator (otherwise then the effort and code footprint spent on making their malloc not suck goes to waste...).
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-06-22 05:01 +0000 |
| Message-ID | <mm84re$kvp$1@speranza.aioe.org> |
| In reply to | #63779 |
James Kuyper <jameskuyper@verizon.net> wrote: > On 06/21/2015 07:57 PM, Keith Thompson wrote: (snip) >> I'm sure that assumption is valid for many implementations. It might be >> valid for all of them; I don't know. It's at least something to consider. > I did consider it before responding. I can't quite see my way to a > formal proof that free() needs to be able to figure out, somehow, how > much memory to free. However, the only counter-example I've been able to > form is a malloc() family where free() is essentially a nop - it uses > the as-if rule to justify not actually making the memory "available for > further allocation" (7.22.3.3p2). Yes, it seems that a garbage collection system would be legal. You could have one where actual references were indirect, and the second level pointer was removed on free, but the length information wasn't available. Or a segment allocation system like protected mode 80286. I forget now if segment descriptors are readable, but otherwise the segment selector is passed to the free routine. > Since that's clearly a cheat, it doesn't provide much useful insight. > I've often been surprised by things that I didn't think were possible, > turning out to be possible (and in some cases, even pretty easy). > However, I don't think this is likely to be one of those surprises. With a large enough virtual address space, you could allocate a big block for each request, not worry about the actual size, and still never run out of virtual address space. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-06-22 01:48 -0500 |
| Message-ID | <qjbfoat1gorajsdh0p7b541v45hud4dc79@4ax.com> |
| In reply to | #63784 |
On Mon, 22 Jun 2015 05:01:34 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >You could have one where actual references were indirect, and the >second level pointer was removed on free, but the length information >wasn't available. > >Or a segment allocation system like protected mode 80286. I forget >now if segment descriptors are readable, but otherwise the segment >selector is passed to the free routine. Not by default, but some OSs make (at least) the LDT readable by applications in some way (Linux used to do that, at least in x86-32 mode). OTOH, it's not relevant, you can determine the size of a segment using the selector value and the LSL instruction.
[toc] | [prev] | [next] | [standalone]
| From | Waldek Hebisch <hebisch@antispam.uni.wroc.pl> |
|---|---|
| Date | 2015-06-23 00:06 +0000 |
| Message-ID | <mma7u4$2kc$1@z-news.wcss.wroc.pl> |
| In reply to | #63779 |
James Kuyper <jameskuyper@verizon.net> wrote:
> On 06/21/2015 07:57 PM, Keith Thompson wrote:
> > James Kuyper <jameskuyper@verizon.net> writes:
> ...
> >> If it can find the allocation, for the purposes of free()ing it, it
> >> should be able to determine the allocated size - otherwise how would it
> >> know how much space to free?
> >
> > That assumes that the underlying routine called by free() takes a size
> > argument, or something similar -- in other words, that at some level you
> > have to know how big a block is before you can free it.
> >
> > I'm sure that assumption is valid for many implementations. It might be
> > valid for all of them; I don't know. It's at least something to consider.
>
> I did consider it before responding. I can't quite see my way to a
> formal proof that free() needs to be able to figure out, somehow, how
> much memory to free. However, the only counter-example I've been able to
> form is a malloc() family where free() is essentially a nop - it uses
> the as-if rule to justify not actually making the memory "available for
> further allocation" (7.22.3.3p2). Since that's clearly a cheat, it
> doesn't provide much useful insight.
> I've often been surprised by things that I didn't think were possible,
> turning out to be possible (and in some cases, even pretty easy).
> However, I don't think this is likely to be one of those surprises.
Consider the following scheme: small allocations are taken sequentially
from pages. For each pages there is counter of live allocations.
free decrements the counter. When counter drops to 0 then page
can be recycled. Realloc is a bit tricky, but can be done:
we capy smaller of the new length and lenght from pointer to
end of the page.
Classical way seem to much better as general purpose allocator.
But I can imagine situation when the scheme above has some
advantages.
--
Waldek Hebisch
hebisch@antispam.uni.wroc.pl
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-22 23:42 -0500 |
| Message-ID | <mmaobq$q7t$1@news.albasani.net> |
| In reply to | #63875 |
On 6/22/2015 7:06 PM, Waldek Hebisch wrote: > James Kuyper <jameskuyper@verizon.net> wrote: >> On 06/21/2015 07:57 PM, Keith Thompson wrote: >>> James Kuyper <jameskuyper@verizon.net> writes: >> ... >>>> If it can find the allocation, for the purposes of free()ing it, it >>>> should be able to determine the allocated size - otherwise how would it >>>> know how much space to free? >>> >>> That assumes that the underlying routine called by free() takes a size >>> argument, or something similar -- in other words, that at some level you >>> have to know how big a block is before you can free it. >>> >>> I'm sure that assumption is valid for many implementations. It might be >>> valid for all of them; I don't know. It's at least something to consider. >> >> I did consider it before responding. I can't quite see my way to a >> formal proof that free() needs to be able to figure out, somehow, how >> much memory to free. However, the only counter-example I've been able to >> form is a malloc() family where free() is essentially a nop - it uses >> the as-if rule to justify not actually making the memory "available for >> further allocation" (7.22.3.3p2). Since that's clearly a cheat, it >> doesn't provide much useful insight. >> I've often been surprised by things that I didn't think were possible, >> turning out to be possible (and in some cases, even pretty easy). >> However, I don't think this is likely to be one of those surprises. > > Consider the following scheme: small allocations are taken sequentially > from pages. For each pages there is counter of live allocations. > free decrements the counter. When counter drops to 0 then page > can be recycled. Realloc is a bit tricky, but can be done: > we capy smaller of the new length and lenght from pointer to > end of the page. > > Classical way seem to much better as general purpose allocator. > But I can imagine situation when the scheme above has some > advantages. > I would think you would need more info than this. but, yeah, assuming a bitmap and 16-byte cells, if done per-page, with 2 bits/cell, 64 bytes would be needed for the bitmap, leaving around 4032 bytes for data. if using 64-byte cells, we would need 16 bytes for the bitmap (but would have 48 bytes left over in the cell, so still 4032 usable bytes). likewise if using 4 bits/cell. if 32 byte cells were uses, 32 bytes would be needed for the bitmap, leaving 4064 bytes useable. on the PC, generally I have used much bigger allocation regions (typically 4MB or so), but the idea can probably be scaled down. for a very small heap, a case could be made for smaller cells, which would give a larger number of allocations at a cost to a larger constant overhead. though, a lot depends on the size distribution of the objects and of the size of the object headers. in past tests (for my 3D engine codebase), the highest point for allocations was around 16-24 bytes (alloc counts were around 10M to 20M here, with a rapid drop-off as sizes increased), and the number of objects drop off rapidly from there. however, still, a small number of larger allocations represented a little over half the memory use (thousands of multi-kB allocations, and a small number of larger allocations). one helpful strategy for small object types is to use "slabs" or "pools", where multiple small objects can share the same logical memory block and header. this can be used to help reduce the cost for 4-16 byte allocations, which although a smaller number of allocs (vs 16-24 bytes), can risk using a disproportionate amount of memory (ex: don't need spend 32 bytes of memory to hold an 8 byte object).
[toc] | [prev] | [next] | [standalone]
| From | Waldek Hebisch <hebisch@antispam.uni.wroc.pl> |
|---|---|
| Date | 2015-06-23 23:04 +0000 |
| Message-ID | <mmcom8$qdm$1@z-news.wcss.wroc.pl> |
| In reply to | #63879 |
BGB <cr88192@hotmail.com> wrote:
> On 6/22/2015 7:06 PM, Waldek Hebisch wrote:
> > James Kuyper <jameskuyper@verizon.net> wrote:
> >> On 06/21/2015 07:57 PM, Keith Thompson wrote:
> >>> James Kuyper <jameskuyper@verizon.net> writes:
> >> ...
> >>>> If it can find the allocation, for the purposes of free()ing it, it
> >>>> should be able to determine the allocated size - otherwise how would it
> >>>> know how much space to free?
> >>>
> >>> That assumes that the underlying routine called by free() takes a size
> >>> argument, or something similar -- in other words, that at some level you
> >>> have to know how big a block is before you can free it.
> >>>
> >>> I'm sure that assumption is valid for many implementations. It might be
> >>> valid for all of them; I don't know. It's at least something to consider.
> >>
> >> I did consider it before responding. I can't quite see my way to a
> >> formal proof that free() needs to be able to figure out, somehow, how
> >> much memory to free. However, the only counter-example I've been able to
> >> form is a malloc() family where free() is essentially a nop - it uses
> >> the as-if rule to justify not actually making the memory "available for
> >> further allocation" (7.22.3.3p2). Since that's clearly a cheat, it
> >> doesn't provide much useful insight.
> >> I've often been surprised by things that I didn't think were possible,
> >> turning out to be possible (and in some cases, even pretty easy).
> >> However, I don't think this is likely to be one of those surprises.
> >
> > Consider the following scheme: small allocations are taken sequentially
> > from pages. For each pages there is counter of live allocations.
> > free decrements the counter. When counter drops to 0 then page
> > can be recycled. Realloc is a bit tricky, but can be done:
> > we capy smaller of the new length and lenght from pointer to
> > end of the page.
> >
> > Classical way seem to much better as general purpose allocator.
> > But I can imagine situation when the scheme above has some
> > advantages.
> >
>
> I would think you would need more info than this.
>
> but, yeah, assuming a bitmap and 16-byte cells, if done per-page, with 2
> bits/cell, 64 bytes would be needed for the bitmap, leaving around 4032
> bytes for data.
>
> if using 64-byte cells, we would need 16 bytes for the bitmap (but would
> have 48 bytes left over in the cell, so still 4032 usable bytes).
> likewise if using 4 bits/cell.
>
> if 32 byte cells were uses, 32 bytes would be needed for the bitmap,
> leaving 4064 bytes useable.
Well, above I was writing about using a single counter to count
allocations. With allocations on multiple on 8 bytes and pages
of 1024 byte a single byte counter is enough. Keeping counters
is separate area we can get extremally small overhead of 1 byte
per 1024 bytes of allocation. Bigger pages would require bigger
counters. Hovever, in this scheme page can be reused only
when all allocations on it get freed. so big pages risk loosing
a lot of memory in pages where only one allocation is live.
Such scheme may be reasonable when allocations and deallocations
a very bursty, that is there is good chance that all allocations
on a page will be freed simultanously.
AFAICS you describe a different system, with bitmaps to trace
free space. With bitmaps you have more administrative data
but better tracking of usage: you can reuse memory immediately
after it is freed. But with bitmaps I do not see how you can
free space without (implicitely of explisitely) storing sizes
of allocations.
>
> on the PC, generally I have used much bigger allocation regions
> (typically 4MB or so), but the idea can probably be scaled down.
AFAICS once you get above size of hardware page it make sense
to allocate memory in multiples of pages and use virtaly memory
subsystem to reuse free memory even if it is mot continous.
IIUC modern processors are more afficient with big (say 4MB)
pages, but in the past 4kB hardware pages we popular.
Also, while allocation size gets above few kilobytes you can
spent a lot of cycles in memory menagement. Presumably you
are going to use allocated memory which will take time, so
cost of memory management will be amortized against actual
computations. Only with very small allocations cost of
memory menagement becomes really significant.
> for a very small heap, a case could be made for smaller cells, which
> would give a larger number of allocations at a cost to a larger constant
> overhead.
>
>
> though, a lot depends on the size distribution of the objects and of the
> size of the object headers.
>
> in past tests (for my 3D engine codebase), the highest point for
> allocations was around 16-24 bytes (alloc counts were around 10M to 20M
> here, with a rapid drop-off as sizes increased), and the number of
> objects drop off rapidly from there. however, still, a small number of
> larger allocations represented a little over half the memory use
> (thousands of multi-kB allocations, and a small number of larger
> allocations).
>
> one helpful strategy for small object types is to use "slabs" or
> "pools", where multiple small objects can share the same logical memory
> block and header.
>
> this can be used to help reduce the cost for 4-16 byte allocations,
> which although a smaller number of allocs (vs 16-24 bytes), can risk
> using a disproportionate amount of memory (ex: don't need spend 32 bytes
> of memory to hold an 8 byte object).
>
--
Waldek Hebisch
hebisch@antispam.uni.wroc.pl
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-23 22:28 -0500 |
| Message-ID | <mmd8dc$n1d$2@news.albasani.net> |
| In reply to | #64009 |
On 6/23/2015 6:04 PM, Waldek Hebisch wrote:
> BGB <cr88192@hotmail.com> wrote:
>> On 6/22/2015 7:06 PM, Waldek Hebisch wrote:
>>> James Kuyper <jameskuyper@verizon.net> wrote:
>>>> On 06/21/2015 07:57 PM, Keith Thompson wrote:
>>>>> James Kuyper <jameskuyper@verizon.net> writes:
>>>> ...
>>>>>> If it can find the allocation, for the purposes of free()ing it, it
>>>>>> should be able to determine the allocated size - otherwise how would it
>>>>>> know how much space to free?
>>>>>
>>>>> That assumes that the underlying routine called by free() takes a size
>>>>> argument, or something similar -- in other words, that at some level you
>>>>> have to know how big a block is before you can free it.
>>>>>
>>>>> I'm sure that assumption is valid for many implementations. It might be
>>>>> valid for all of them; I don't know. It's at least something to consider.
>>>>
>>>> I did consider it before responding. I can't quite see my way to a
>>>> formal proof that free() needs to be able to figure out, somehow, how
>>>> much memory to free. However, the only counter-example I've been able to
>>>> form is a malloc() family where free() is essentially a nop - it uses
>>>> the as-if rule to justify not actually making the memory "available for
>>>> further allocation" (7.22.3.3p2). Since that's clearly a cheat, it
>>>> doesn't provide much useful insight.
>>>> I've often been surprised by things that I didn't think were possible,
>>>> turning out to be possible (and in some cases, even pretty easy).
>>>> However, I don't think this is likely to be one of those surprises.
>>>
>>> Consider the following scheme: small allocations are taken sequentially
>>> from pages. For each pages there is counter of live allocations.
>>> free decrements the counter. When counter drops to 0 then page
>>> can be recycled. Realloc is a bit tricky, but can be done:
>>> we capy smaller of the new length and lenght from pointer to
>>> end of the page.
>>>
>>> Classical way seem to much better as general purpose allocator.
>>> But I can imagine situation when the scheme above has some
>>> advantages.
>>>
>>
>> I would think you would need more info than this.
>>
>> but, yeah, assuming a bitmap and 16-byte cells, if done per-page, with 2
>> bits/cell, 64 bytes would be needed for the bitmap, leaving around 4032
>> bytes for data.
>>
>> if using 64-byte cells, we would need 16 bytes for the bitmap (but would
>> have 48 bytes left over in the cell, so still 4032 usable bytes).
>> likewise if using 4 bits/cell.
>>
>> if 32 byte cells were uses, 32 bytes would be needed for the bitmap,
>> leaving 4064 bytes useable.
>
> Well, above I was writing about using a single counter to count
> allocations. With allocations on multiple on 8 bytes and pages
> of 1024 byte a single byte counter is enough. Keeping counters
> is separate area we can get extremally small overhead of 1 byte
> per 1024 bytes of allocation. Bigger pages would require bigger
> counters. Hovever, in this scheme page can be reused only
> when all allocations on it get freed. so big pages risk loosing
> a lot of memory in pages where only one allocation is live.
> Such scheme may be reasonable when allocations and deallocations
> a very bursty, that is there is good chance that all allocations
> on a page will be freed simultanously.
>
> AFAICS you describe a different system, with bitmaps to trace
> free space. With bitmaps you have more administrative data
> but better tracking of usage: you can reuse memory immediately
> after it is freed. But with bitmaps I do not see how you can
> free space without (implicitely of explisitely) storing sizes
> of allocations.
>
ok.
yeah, with a counter, couldn't see how things could be freed exactly.
you can free objects using just the bitmap, as noted, there are
different bit patterns for header-cells vs data cells.
so, to free an object, you mark the header cell as free followed by any
data cells which follow directly afterwards.
typically a header is used with some other useful info, but isn't
strictly necessary for the basic allocation strategy to work.
>>
>> on the PC, generally I have used much bigger allocation regions
>> (typically 4MB or so), but the idea can probably be scaled down.
>
> AFAICS once you get above size of hardware page it make sense
> to allocate memory in multiples of pages and use virtaly memory
> subsystem to reuse free memory even if it is mot continous.
> IIUC modern processors are more afficient with big (say 4MB)
> pages, but in the past 4kB hardware pages we popular.
>
errm, this isn't for pages, but just the size of memory which the MM
grabs from the OS. 4MB is a good size to grab and divide up.
Windows itself uses a logical page size of 64kB, which is itself
composed of individual pages, whereas Linux tends to use 4kB pages.
> Also, while allocation size gets above few kilobytes you can
> spent a lot of cycles in memory menagement. Presumably you
> are going to use allocated memory which will take time, so
> cost of memory management will be amortized against actual
> computations. Only with very small allocations cost of
> memory menagement becomes really significant.
>
mentioned elsewhere in the thread, some of my apps have around 10M+
small-object allocations. this use-case demands a lot in terms of
overhead and performance.
also the MM uses different allocation strategies for different object
size-ranges:
0-32 bytes: uses pool allocation (they are aggregated by size and type);
33-3kB: uses 16-byte memory cells;
under 256 bytes: free-lists are used by cell-count, with lazy freeing;
over 256 bytes: objects are freed immediately.
3kB+: uses a strategy based around sorted arrays of memory-spans.
this is because, as may be inferred, much past a few kB and the relative
overhead of the bitmaps goes up considerably.
likewise, very small objects tend to be dominated by constant costs (so
the memory and time overhead needs to be kept small).
there are special allocation API calls to optimize the small object case
by fetching a "handle" for the size and type of an object, and
allocating/freeing objects using this handle.
this is pretty fast, but to be thread-safe, still involves the cost of
locking/unlocking a mutex (a Win32 CriticalSection object).
basically, pseudocode:
EnterCriticalSection(info->mutex);
if(info->free)
ptr=info->free;
info->free=*(void **)ptr;
LeaveCriticalSection(info->mutex);
return(ptr);
fall-back to more generic logic.
for very small objects, the fallback involves allocating a bigger piece
of memory and dividing it up into pieces, which are added to the free list.
for small objects, they are fetched from size-specific type-generic
free-lists (for objects under 256 bytes), or failing this, allocated via
the bitmaps. a rover is used which considerably increases the speed of
bitmap scans (by avoiding endlessly scanning over areas with a low
probability of free cells).
by convention, code uses dedicated functions to allocate and free
objects, which are implicitly responsible for using the correct method
for allocating/freeing this object type (as opposed to having this
scattered around in the code).
in an OO-sense, this would be equivalent to having new/delete be
method-calls (which default to the main MM). this strategy has been
considered as a possibility for BS-RT, ex:
public class Foo {
public Foo() { ... } //ctor
public ~Foo() { ... } //dtor
//possibility:
public static *void operator new(native long size) { ... }
public static void operator delete(*void obj, native long size) {...}
}
this is still TBD (its parent language doesn't do this).
[toc] | [prev] | [next] | [standalone]
| From | Nathan Wagner <nw@hydaspes.if.org> |
|---|---|
| Date | 2015-06-23 13:23 +0000 |
| Message-ID | <slrnmoinec.1mn.nw@granicus.if.org> |
| In reply to | #63761 |
On 2015-06-21, James Kuyper <jameskuyper@verizon.net> wrote: > If [free/malloc] can find the allocation, for the purposes of > free()ing it, it should be able to determine the allocated size - > otherwise how would it know how much space to free? Can't free() be a no-op and still be conforming? In such an implementation, the malloc system wouldn't need to track the size at all, since all it would do is carve out a maximally aligned pointer from its free space and hand it out. If there wasn't enough space, ask the system for more, or return NULL. Effectively, malloc could be a thin wrapper around sbrk and free a no-op. Unless the argument is that this would be non-conforming because it doesn't make the space "available for further allocation". I can't think of a way for a conforming program to tell since there's no way to force malloc to give you the same space again. -- nw
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-23 09:53 -0400 |
| Message-ID | <mmbob1$b3a$1@dont-email.me> |
| In reply to | #63919 |
On 06/23/2015 09:23 AM, Nathan Wagner wrote: > On 2015-06-21, James Kuyper <jameskuyper@verizon.net> wrote: > >> If [free/malloc] can find the allocation, for the purposes of >> free()ing it, it should be able to determine the allocated size - >> otherwise how would it know how much space to free? > > Can't free() be a no-op and still be conforming? In such an > implementation, the malloc system wouldn't need to track the size > at all, since all it would do is carve out a maximally aligned > pointer from its free space and hand it out. If there wasn't > enough space, ask the system for more, or return NULL. Effectively, > malloc could be a thin wrapper around sbrk and free a no-op. > > Unless the argument is that this would be non-conforming because > it doesn't make the space "available for further allocation". > I can't think of a way for a conforming program to tell since > there's no way to force malloc to give you the same space again. I've address this before - the nop version of free() is precisely what I described elsewhere as a "cheat". -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-22 08:34 +0200 |
| Message-ID | <mm8a6u$n2d$1@dont-email.me> |
| In reply to | #63759 |
On 21/06/15 23:43, Keith Thompson wrote:
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> Le 21/06/2015 22:20, Keith Thompson a écrit :
>>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>>> Le 21/06/2015 16:31, Reinhardt Behm a écrit :
>>>>> This is the 9 billionth re-invention of the wheel.
>>>> Yes. Wheels *ARE* useful.
>>>>
>>>> Do not be afraid of reinventing wheels. Reinvent them rather than not
>>>> use them!
>>>>
>>>> What I would like to stress here is that the C standard, with all its
>>>> new stuff like "generics", etc, did NOT seem to have discovered this wheels!
>>>
>>> I don't think it's a matter of not discovering them. Rather, adding
>>> these features to the standard would impose a burden on implementers.
>>> For example, there is no portable way to determine whether a given
>>> pointer value is valid or not. Some implementations might have a
>>> non-portable way to do so; others might not. I suspect the authors of
>>> the standard just made a deliberate tradeoff.
>>>
>>
>>
>> Excuse me but since we have
>>
>> malloc(size);
>>
>> I do not see how would it be so difficult to return the size of a memory
>> block!!!
>
> Implementations of malloc can typically allocate more memory than was
> asked for in the call. A conforming implementation needn't store the
> requested size; it can store only the actual allocated size (since
> there's currently no requirement to be able to retrieve either). I can
> imagine implementations where neither size is stored explicitly (say, if
> all allocations are managed in multiple linked lists, one for each
> size).
>
> I'm not saying it would be a large burden, or even that I'd oppose
> adding msize() to the standard, but it would be imposed on *all*
> malloc() calls, whether the program calls msize() or not.
>
There are also systems that use minimal versions of malloc/free, for
which something like msize() would be impossible or at least inefficient:
#define heapSize 2048
static union
{ unsigned long alignment; unsigned char heap[heapSize]; } heap;
static unsigned char* topOfHeap = heap.heap;
void* malloc(size_t size) {
// Note - size or topOfHeap might need adjustment for alignment
void* p = topOfHeap;
topOfHeap += size;
return p;
}
void free(void* ptr) {
}
I believe this is conforming - it is certainly a practical
implementation for some small embedded systems that find it convenient
to use dynamic memory allocation at startup, but never stop or free the
memory.
Implementing msize() would require storing the size of allocations
somewhere, which would be a waste of space for a fairly useless function
(since the function calling malloc() knows the size of the allocation,
and can store the information if you need it later).
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-06-22 10:38 +0200 |
| Message-ID | <mm8hft$cuj$1@dont-email.me> |
| In reply to | #63787 |
Le 22/06/2015 08:34, David Brown a écrit :
[snip]
> There are also systems that use minimal versions of malloc/free, for
> which something like msize() would be impossible or at least inefficient:
>
> #define heapSize 2048
> static union
> { unsigned long alignment; unsigned char heap[heapSize]; } heap;
> static unsigned char* topOfHeap = heap.heap;
>
> void* malloc(size_t size) {
> // Note - size or topOfHeap might need adjustment for alignment
> void* p = topOfHeap;
> topOfHeap += size;
> return p;
> }
>
> void free(void* ptr) {
> }
>
>
This implementation allocates and never frees.
GREAT!
> I believe this is conforming - it is certainly a practical
> implementation for some small embedded systems that find it convenient
> to use dynamic memory allocation at startup, but never stop or free the
> memory.
>
This is absolutely nonsense. Precisely in small systems managing a
scarce resource like memory should be done with utmost care.
Providing rubbish like that is worst than nothing.
> Implementing msize() would require storing the size of allocations
> somewhere, which would be a waste of space for a fairly useless function
> (since the function calling malloc() knows the size of the allocation,
> and can store the information if you need it later).
>
>
So, you mean because some hypothetical system compiler provides a bad
implementation of the memory systems, ALL OTHER USERS OF THE C LANGUAGE
should not have a function that is useful, specially if you are using a
library that allocates memory indepndently of YOUR application?
The fact that Windows, Linux, and other systems provide it means it IS a
useful function.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-22 11:09 +0200 |
| Message-ID | <mm8j9b$iug$1@dont-email.me> |
| In reply to | #63792 |
On 22/06/15 10:38, jacobnavia wrote:
> Le 22/06/2015 08:34, David Brown a écrit :
> [snip]
>
>> There are also systems that use minimal versions of malloc/free, for
>> which something like msize() would be impossible or at least inefficient:
>>
>> #define heapSize 2048
>> static union
>> { unsigned long alignment; unsigned char heap[heapSize]; } heap;
>> static unsigned char* topOfHeap = heap.heap;
>>
>> void* malloc(size_t size) {
>> // Note - size or topOfHeap might need adjustment for alignment
>> void* p = topOfHeap;
>> topOfHeap += size;
>> return p;
>> }
>>
>> void free(void* ptr) {
>> }
>>
>>
>
> This implementation allocates and never frees.
>
Yes, I know.
> GREAT!
It is exactly what is required in systems that allocate memory on
startup, but do not need dynamic allocation/free while running.
Supporting a fully functional dynamic memory heap would be a waste of
resources (runtime, code space, and ram space).
>
>> I believe this is conforming - it is certainly a practical
>> implementation for some small embedded systems that find it convenient
>> to use dynamic memory allocation at startup, but never stop or free the
>> memory.
>>
>
> This is absolutely nonsense. Precisely in small systems managing a
> scarce resource like memory should be done with utmost care.
>
> Providing rubbish like that is worst than nothing.
You are demonstrated a total and complete lack of understanding of such
systems. I am sure you are a great Windows programmer - but there is a
vast array of systems in the world outside, with totally different
requirements and constraints. I am merely giving you some ideas about
them, so that you can understand why features like msize() or related
functions are inappropriate in the C standards - they would impose
impossible requirements on some systems.
For the majority of small embedded systems, dynamic memory of any sort
is inappropriate - and most coding standards targeted at such systems
explicitly ban it. malloc/free are high-risk functions - they make it
much harder to be sure that your code is bug-free. For normal
malloc/free implementations, they are costly in terms of code space and
ram overhead, and have unpredictable runtimes (no one cares if a Windows
program has an unexpected millisecond pause, but that would be
unacceptable in many embedded systems). And typical malloc/free systems
are subject to heap fragmentation, as well as making it extremely
difficult for developers to be sure that there is always enough memory -
generally, it is not acceptable to have a situation where malloc() fails
to find the desired resources.
Thus embedded systems typically use static allocation, or fixed-sized
resource pools.
But one way to get the flexibility of dynamic memory without the risks
is to use an unfreeable system, like I showed above. A typical use-case
is for a real-time operating system - malloc is used to allocate space
for tasks, queues, etc., at initialisation. But as the tasks never end
and the queues are never destroyed, free() is completely superfluous.
The implementation I gave is small, fast, safe, and easily analysed -
and is in common use.
A slightly more sophisticated alternative is to make the heap into a
FIFO - you may call free, but only in reverse order to mallocs. This is
less common, but is sometimes used.
>
>> Implementing msize() would require storing the size of allocations
>> somewhere, which would be a waste of space for a fairly useless function
>> (since the function calling malloc() knows the size of the allocation,
>> and can store the information if you need it later).
>>
>>
>
> So, you mean because some hypothetical system compiler provides a bad
> implementation of the memory systems, ALL OTHER USERS OF THE C LANGUAGE
> should not have a function that is useful, specially if you are using a
> library that allocates memory indepndently of YOUR application?
>
> The fact that Windows, Linux, and other systems provide it means it IS a
> useful function.
I would guess that in your household, you have something like 5
processors running Windows or Linux. And you have perhaps a couple of
hundred processors that /don't/ run Windows or Linux. Some of these
embedded systems will be bigger, with dynamic memory systems of some
sort, but the great majority will either have no malloc/free system at
all, or will have a simple system such as the one I described.
Frankly, I can't see any use of a function returning the size of a
malloc-allocated block. Your code should know the size of the block it
asked for, and if you have a pointer you should know what sort of data
it points to. If you have to try and ask the library what your pointer
is, you have big problems in your code organisation (or you should have
chosen a programming language that supports that sort of thing - perhaps
C++).
At best, it is a useful function in Windows, Linux, and other big
systems - so let those systems provide it. The C standards do not
restrict them.
But it is an unwanted function in other systems - if the C standards
insist that it is implemented, then such systems either have to provide
a library that is weighted down by useless anti-features, or they cannot
conform to the C standards here.
So implement the function on systems that you think have use of it. Put
it in /additional/ standards, such as Posix. But don't put it in the C
standards - other C users don't want it there.
(It would be possible to have it in the C standards but marked as
optional for freestanding systems - but even then I think this
particular type of function would be an unreasonable burden on hosted
system implementers.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-22 07:47 -0700 |
| Message-ID | <lnpp4ndcl8.fsf@nuthaus.mib.org> |
| In reply to | #63793 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> (It would be possible to have it in the C standards but marked as
> optional for freestanding systems - but even then I think this
> particular type of function would be an unreasonable burden on hosted
> system implementers.)
[...]
Most of the standard library (including malloc and free) is optional for
freestanding impementations.
--
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 | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-06-22 16:49 +0200 |
| Message-ID | <mm977e$q31$1@dont-email.me> |
| In reply to | #63812 |
Le 22/06/2015 16:47, Keith Thompson a écrit : > David Brown <david.brown@hesbynett.no> writes: > [...] >> (It would be possible to have it in the C standards but marked as >> optional for freestanding systems - but even then I think this >> particular type of function would be an unreasonable burden on hosted >> system implementers.) > > [...] > > Most of the standard library (including malloc and free) is optional for > freestanding impementations. > So, this argument is over. If they do not want malloc/free or msize, they can ignore it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-22 17:43 +0200 |
| Message-ID | <mm9ad0$7qg$1@dont-email.me> |
| In reply to | #63814 |
On 22/06/15 16:49, jacobnavia wrote: > Le 22/06/2015 16:47, Keith Thompson a écrit : >> David Brown <david.brown@hesbynett.no> writes: >> [...] >>> (It would be possible to have it in the C standards but marked as >>> optional for freestanding systems - but even then I think this >>> particular type of function would be an unreasonable burden on hosted >>> system implementers.) >> >> [...] >> >> Most of the standard library (including malloc and free) is optional for >> freestanding impementations. >> > > So, this argument is over. If they do not want malloc/free or msize, > they can ignore it. Obviously no one is going to be using your tools for embedded development - thus people considering specialised malloc/free behaviour would not be using your code anyway. But if you are - as you have said - interested in writing portable code with a view to making new "standard" libraries, then you really have to learn about wider usage of C. If you want to learn about how C is used in the world beyond Windows, ask and we will be happy to tell you - don't claim to know it all. Small systems embedded programmers /do/ sometimes want malloc/free - but sometimes they want specialised versions that don't work in the same way as traditional versions, which work fine with the normal malloc/free interface but which could not possibly support new functions such as msize() that depend on the implementation of the heap.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-06-22 17:47 +0200 |
| Message-ID | <mm9akb$8c9$1@dont-email.me> |
| In reply to | #63820 |
Le 22/06/2015 17:43, David Brown a écrit : > Obviously no one is going to be using your tools for embedded > development My system has been used for an embedded TI 16 bit processor, and in general I have several customers in that sector. But of course you know better than me who my customers are!
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-06-22 20:42 +0000 |
| Message-ID | <5588729e.15130343@news.xs4all.nl> |
| In reply to | #63822 |
jacobnavia <jacob@jacob.remcomp.fr> wrote: > Le 22/06/2015 17:43, David Brown a écrit : > > Obviously no one is going to be using your tools for embedded > > development > > My system has been used for an embedded TI 16 bit processor, and in > general I have several customers in that sector. Ooohhh!! All of sixteen bits!!!! I cut my programming teeth on eight-bit chips, mate. And 48 _kilo_bytes was a luxury - the systems we're talking about here may have a fraction of that. You'll have to to better to convince the real professionals, I'm afraid. Including in the field of sarcasm. Richard
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-22 18:10 -0500 |
| Message-ID | <mma4s5$c0l$1@news.albasani.net> |
| In reply to | #63864 |
On 6/22/2015 3:42 PM, Richard Bos wrote: > jacobnavia <jacob@jacob.remcomp.fr> wrote: > >> Le 22/06/2015 17:43, David Brown a écrit : >>> Obviously no one is going to be using your tools for embedded >>> development >> >> My system has been used for an embedded TI 16 bit processor, and in >> general I have several customers in that sector. > > Ooohhh!! All of sixteen bits!!!! > > I cut my programming teeth on eight-bit chips, mate. And 48 _kilo_bytes > was a luxury - the systems we're talking about here may have a fraction > of that. > most of the TI 16-bit MCUs also have a lot less RAM than this (8kB or 16kB is typical). unless you mean ROM, then it is typically between 64 and 256kB on most of them. > You'll have to to better to convince the real professionals, I'm afraid. > Including in the field of sarcasm. > yeah. in my case, I am mostly targeting 32-bit hardware, so it is a bit higher end. a lot of the ways things are being done likely wouldn't be viable on 8 or 16 bit hardware.
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web