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 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-23 20:42 +0100 |
| Message-ID | <mmccoi$39g$1@dont-email.me> |
| In reply to | #63969 |
On 23/06/2015 19:08, jacobnavia wrote:
> Le 23/06/2015 19:34, Bartc a écrit :
>> (That pow() expression is a crazy way to work out the iteration, however
>> it should still work.)
>>
> Please send me some reproducible problem... You know I will fix it :-)
Yes, I know. That's why I didn't want to bother you with something that
only occurs in a benchmark I was using to make a point.
> The pow() function crashes???
This is the minimal program (other than the printf) which shows the
problem on the latest lccwin64 (under Windows 7):
#include <stdio.h>
#include <math.h>
int main(void) {
unsigned a,b=2;
a = pow(2, b);
printf("%d\n",a);
}
You can't just replace b with 2 (nor (unsigned)2), as then it'll work.
However, if you could run the original binary_tree benchmark with pow(),
then you may not be able to reproduce it.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-06-21 07:43 -0700 |
| Message-ID | <e8a1d987-6aee-4127-a7fd-8e9debf66294@googlegroups.com> |
| In reply to | #63716 |
What about: u32 memRes(u8* p) Return the number of bytes are reserved [in heap] after p or -1 if p is not one valid address of heap... for example u8 *p; p=malloc(100) memRes(p) == 99 memRes(p+1) == 98 memRes(p+2) == 97 ... memRes(p+99) == 0 but it is ok memRes(p+100) == -1 not in the heap
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-21 17:25 +0200 |
| Message-ID | <mm6kvm$ejh$1@dont-email.me> |
| In reply to | #63716 |
On 21/06/15 16:20, jacobnavia wrote: > After adding recalloc, I thought I would add other functions I always > wanted to have. > > size_t msize(void *ptr); > > Returns the size of the given block. If the pointer is NULL or is not a > memory block allocated with malloc/realloc/recalloc (size_t)-1 is returned. > I would suggest that it returns 0 for NULL pointers. You might also prefer to say that its behaviour is undefined if ptr was not allocated using malloc - it would make it /much/ easier to implement, and stop people trying to be smart or lazy about memory management. > int memcheck(void *ptr); > > Checks that the block pointed to by ptr is valid. If ptr is NULL, the > whole memory system will be checked for corruption. This can take a > while in slow systems or systems with a lot of memory. What does "valid" and "corrupt" mean here? > > If the function fails and you are in a debugger, the debugger will be > called and you can examine the program when the corruption is detected.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-21 10:06 -0700 |
| Message-ID | <d5d94cc4-d9a8-4ed5-83c4-5c08023e15ca@googlegroups.com> |
| In reply to | #63720 |
On Sunday, June 21, 2015 at 4:26:06 PM UTC+1, David Brown wrote: > > > Returns the size of the given block. If the pointer is NULL > > or is not a memory block allocated with malloc/realloc/recalloc > > (size_t)-1 is returned. > > > > I would suggest that it returns 0 for NULL pointers. You might also > prefer to say that its behaviour is undefined if ptr was not allocated > using malloc - it would make it /much/ easier to implement, and stop > people trying to be smart or lazy about memory management. > I agree. If malloc(0) can return null, then msize(null) should return zero. Also, size_t and -1 don't work well together, because the natural logic of if(msize(ptr) < neededsize) ptr = realloc(ptr, neededsize); won't work. Then you don't want people using msize() to check if a block is genuinely allocated with malloc() or not - it's not unreasonable to have such a function, but it should definitely be memcheck() rather than msize(). Then as you say, if you implement malloc() by storing a control block before the returned pointer, msize() is trivial to write as long as passing an invalid block is UB, otherwise it's a major headache.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-06-21 21:46 +0200 |
| Message-ID | <mm747s$9kq$2@dont-email.me> |
| In reply to | #63731 |
Le 21/06/2015 19:06, Malcolm McLean a écrit : I changed that. It returns zero for NULL. Thanks
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-21 14:26 -0700 |
| Message-ID | <32bf86a7-73bb-4fb9-8085-057b4f3981e5@googlegroups.com> |
| In reply to | #63740 |
On Sunday, June 21, 2015 at 8:46:28 PM UTC+1, jacobnavia wrote: > Le 21/06/2015 19:06, Malcolm McLean a écrit : > > > I changed that. It returns zero for NULL. > What would really be worth thinking about, especially if you have an msize, is some syntax for specifying that a pointer must be a return value from malloc(). Something like char ^concatenate(char ^str, char *cat) We implement it by calling msize, and if str is too small, reallocating, then we return the new buffer. Clearly it only works if str has been allocated on the heap.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-21 13:17 -0700 |
| Message-ID | <ln1th4g6j8.fsf@nuthaus.mib.org> |
| In reply to | #63731 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Sunday, June 21, 2015 at 4:26:06 PM UTC+1, David Brown wrote:
>> > Returns the size of the given block. If the pointer is NULL
>> > or is not a memory block allocated with malloc/realloc/recalloc
>> > (size_t)-1 is returned.
>> >
>>
>> I would suggest that it returns 0 for NULL pointers. You might also
>> prefer to say that its behaviour is undefined if ptr was not allocated
>> using malloc - it would make it /much/ easier to implement, and stop
>> people trying to be smart or lazy about memory management.
>>
> I agree. If malloc(0) can return null, then msize(null) should return
> zero. Also, size_t and -1 don't work well together, because the
> natural logic of
>
> if(msize(ptr) < neededsize)
> ptr = realloc(ptr, neededsize);
>
> won't work.
In-band signalling (reserving an otherwise valid result as an error
indication, like EOF for getchar()) can be awkward.
Rather than an msize() function returning a single integer result, you
might consider a function that takes a pointer and tells you how it was
allocated *and* how big the corresponding block is, with the latter
presumably being meaningful only for heap-allocated memory.
enum allocation {
NULL_POINTER, STATIC, THREAD, AUTOMATIC, ALLOCATED, INVALID
};
void minfo(void *ptr, enum allocation *allocation, size_t *size);
That's just off the top of my head, and I have no doubt it could be
improved.
Assuming the msize() interface, many implementations of malloc() will
sometimes allocate more than you ask for. For example, suppose malloc()
always allocates a multiple of 64 bytes. Would msize(malloc(42)) return
42 or 64? If it returns 42, and if it becomes part of the standard,
some implementations will have to store additional information that they
don't currently store.
--
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-21 22:55 +0200 |
| Message-ID | <mm789j$p1f$1@dont-email.me> |
| In reply to | #63746 |
Le 21/06/2015 22:17, Keith Thompson a écrit : Assuming the msize() interface, many implementations of malloc() will > sometimes allocate more than you ask for. For example, suppose malloc() > always allocates a multiple of 64 bytes. Would msize(malloc(42)) return > 42 or 64? If it returns 42, and if it becomes part of the standard, > some implementations will have to store additional information that they > don't currently store. > If malloc increases the size of the block (to whatever is needed), then the block's size IS 64 and not 42... The standard knows how to keep silent in so many occasions that this is no problem at all. "The returned value may have been adjusted by the implementation". That suffices
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-21 14:45 -0700 |
| Message-ID | <lnk2uwenwu.fsf@nuthaus.mib.org> |
| In reply to | #63753 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 21/06/2015 22:17, Keith Thompson a écrit :
> Assuming the msize() interface, many implementations of malloc() will
>> sometimes allocate more than you ask for. For example, suppose malloc()
>> always allocates a multiple of 64 bytes. Would msize(malloc(42)) return
>> 42 or 64? If it returns 42, and if it becomes part of the standard,
>> some implementations will have to store additional information that they
>> don't currently store.
>>
>
> If malloc increases the size of the block (to whatever is needed),
> then the block's size IS 64 and not 42... The standard knows how to
> keep silent in so many occasions that this is no problem at all.
>
> "The returned value may have been adjusted by the implementation".
>
> That suffices
Ok. It wasn't clear from your original description whether msize()
would return the requested size or the actual allocated size.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-21 15:14 -0700 |
| Message-ID | <df3e4799-1427-4da5-9901-ec44ab3bd3ef@googlegroups.com> |
| In reply to | #63753 |
On Sunday, June 21, 2015 at 9:55:39 PM UTC+1, jacobnavia wrote: > > If malloc increases the size of the block (to whatever is needed), then > the block's size IS 64 and not 42... The standard knows how to keep > silent in so many occasions that this is no problem at all. > > "The returned value may have been adjusted by the implementation". > > That suffices > The question is whether you want to allow msize() to function as a replacement for an N parameter or not. If you take the decision no, the it can return the size of the underlying block. If you take the decision that es it can, you must keep track of the exact allocation.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-22 09:44 -0500 |
| Message-ID | <mm977p$a41$1@news.albasani.net> |
| In reply to | #63753 |
On 6/21/2015 3:55 PM, jacobnavia wrote: > Le 21/06/2015 22:17, Keith Thompson a écrit : > Assuming the msize() interface, many implementations of malloc() will >> sometimes allocate more than you ask for. For example, suppose malloc() >> always allocates a multiple of 64 bytes. Would msize(malloc(42)) return >> 42 or 64? If it returns 42, and if it becomes part of the standard, >> some implementations will have to store additional information that they >> don't currently store. >> > > If malloc increases the size of the block (to whatever is needed), then > the block's size IS 64 and not 42... The standard knows how to keep > silent in so many occasions that this is no problem at all. > > "The returned value may have been adjusted by the implementation". > > That suffices > though, FWIW, if the storage is in terms of a fixed-size unit, it is possible to encode the size as a modulo. say, for 64 bytes, you could store a 6 or 8 bit modulo. say: if mod is 0, returned size is the full (padded) size. other mod's would mean, say, 'sz=(psz-64)+mod;'. could also do it like 'sz=psz-mod;'. though, there might still be justifiable reasons for storing the size directly, so it depends.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-21 19:18 +0100 |
| Message-ID | <mm6v32$l6p$1@dont-email.me> |
| In reply to | #63720 |
On 21/06/15 16:25, David Brown wrote:> On 21/06/15 16:20, jacobnavia wrote: >> int memcheck(void *ptr); >> >> Checks that the block pointed to by ptr is valid. If ptr is NULL, the >> whole memory system will be checked for corruption. This can take a >> while in slow systems or systems with a lot of memory. > > What does "valid" and "corrupt" mean here? Presumably it means that ptr either: (a) is a null pointer, OR (b) points to or into a block of memory (anywhere within that block) that has been allocated by *alloc() and not yet released by free(), OR (c) points to or into a static object OR (d) points to or into a local object that currently exists. -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-21 23:42 +0200 |
| Message-ID | <mm7b1f$1ke$1@dont-email.me> |
| In reply to | #63734 |
On 21/06/15 20:18, Richard Heathfield wrote: > On 21/06/15 16:25, David Brown wrote:> On 21/06/15 16:20, jacobnavia wrote: > > >> int memcheck(void *ptr); > >> > >> Checks that the block pointed to by ptr is valid. If ptr is NULL, the > >> whole memory system will be checked for corruption. This can take a > >> while in slow systems or systems with a lot of memory. > > > > What does "valid" and "corrupt" mean here? > > Presumably it means that ptr either: > > (a) is a null pointer, OR > (b) points to or into a block of memory (anywhere within that block) > that has been allocated by *alloc() and not yet released by free(), OR > (c) points to or into a static object OR > (d) points to or into a local object that currently exists. > These are all possibilities - but to be useful, the memcheck function has to have a clear definition of what "valid" and "corrupt" mean here, as well as to have a clear implementation of how to determine the validity of the pointer. So I am curious as to what Jacob is thinking of here. (Maybe it is still at the stage of "it would be nice if such a function existed", rather than having the details worked out.)
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-06-22 00:33 +0200 |
| Message-ID | <mm7e1u$gaf$1@dont-email.me> |
| In reply to | #63734 |
Le 21/06/2015 20:18, Richard Heathfield a écrit : > On 21/06/15 16:25, David Brown wrote:> On 21/06/15 16:20, jacobnavia wrote: > > >> int memcheck(void *ptr); > >> > >> Checks that the block pointed to by ptr is valid. If ptr is NULL, the > >> whole memory system will be checked for corruption. This can take a > >> while in slow systems or systems with a lot of memory. > > > > What does "valid" and "corrupt" mean here? > > Presumably it means that ptr either: > > (a) is a null pointer, OR > (b) points to or into a block of memory (anywhere within that block) > that has been allocated by *alloc() and not yet released by free(), OR > (c) points to or into a static object OR > (d) points to or into a local object that currently exists. > At this moment it means Valid: A memory address returned by a malloc/calloc call Corrupt: Internal heap structures are destroyed by overwriting of memory beyond the limits of a block. I would like to extend memcheck to return an enum of Data segment (initialized data) My linker coud conveniently store __firstDataAddress __LastData address to delimit that segment Stack. At program startup I could store RSP into __StackBottom, and the current RSP would give the top of the stack. If the address lies within those, it can be (abstracting out return addresses and frame pointers) easily assumed it is a local variable. Heap. I could walk the heap and see if the address is within the bounds of a malloced block. But if it is the result of a dll library call using another heap I can't recognize it. I could ask the OS for the handles of all heaps currently in use by the process, then enumerate and walk them all. Or I could do a dirty job with VirtualAlloc, what doesn't really help. Currently memcheck crashes if it is passed an invalid address. This calls the debugger, and the program can be examined.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-22 08:42 +0200 |
| Message-ID | <mm8al9$oao$1@dont-email.me> |
| In reply to | #63764 |
On 22/06/15 00:33, jacobnavia wrote: > Le 21/06/2015 20:18, Richard Heathfield a écrit : >> On 21/06/15 16:25, David Brown wrote:> On 21/06/15 16:20, jacobnavia >> wrote: >> >> >> int memcheck(void *ptr); >> >> >> >> Checks that the block pointed to by ptr is valid. If ptr is NULL, the >> >> whole memory system will be checked for corruption. This can take a >> >> while in slow systems or systems with a lot of memory. >> > >> > What does "valid" and "corrupt" mean here? >> >> Presumably it means that ptr either: >> >> (a) is a null pointer, OR >> (b) points to or into a block of memory (anywhere within that block) >> that has been allocated by *alloc() and not yet released by free(), OR >> (c) points to or into a static object OR >> (d) points to or into a local object that currently exists. >> > > At this moment it means > > Valid: A memory address returned by a malloc/calloc call How do you plan to implement that? It would not be possible with a traditional heap implementation (where the size of an allocated block is stored just below the malloc-returned pointer, so that free can find it). You would need to store a list of all valid allocations as an independent list. > > Corrupt: Internal heap structures are destroyed by overwriting of memory > beyond the limits of a block. > > I would like to extend memcheck to return an enum of > > Data segment (initialized data) My linker coud conveniently store > __firstDataAddress > __LastData address > to delimit that segment > > Stack. At program startup I could store RSP into __StackBottom, and > the current RSP would give the top of the stack. If the address lies > within those, it can be (abstracting out return addresses and frame > pointers) easily assumed it is a local variable. > > Heap. I could walk the heap and see if the address is within the bounds > of a malloced block. But if it is the result of a dll library call using > another heap I can't recognize it. I could ask the OS for the handles of > all heaps currently in use by the process, then enumerate and walk them > all. This sounds very slow. And it relies on the heap structure being intact - that's not a good starting point if you are checking for corruption! > > Or I could do a dirty job with VirtualAlloc, what doesn't really help. > > Currently memcheck crashes if it is passed an invalid address. This > calls the debugger, and the program can be examined. > >
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-22 08:23 -0500 |
| Message-ID | <mm92fe$aiv$1@news.albasani.net> |
| In reply to | #63788 |
On 6/22/2015 1:42 AM, David Brown wrote: > On 22/06/15 00:33, jacobnavia wrote: >> Le 21/06/2015 20:18, Richard Heathfield a écrit : >>> On 21/06/15 16:25, David Brown wrote:> On 21/06/15 16:20, jacobnavia >>> wrote: >>> >>> >> int memcheck(void *ptr); >>> >> >>> >> Checks that the block pointed to by ptr is valid. If ptr is NULL, the >>> >> whole memory system will be checked for corruption. This can take a >>> >> while in slow systems or systems with a lot of memory. >>> > >>> > What does "valid" and "corrupt" mean here? >>> >>> Presumably it means that ptr either: >>> >>> (a) is a null pointer, OR >>> (b) points to or into a block of memory (anywhere within that block) >>> that has been allocated by *alloc() and not yet released by free(), OR >>> (c) points to or into a static object OR >>> (d) points to or into a local object that currently exists. >>> >> >> At this moment it means >> >> Valid: A memory address returned by a malloc/calloc call > > How do you plan to implement that? It would not be possible with a > traditional heap implementation (where the size of an allocated block is > stored just below the malloc-returned pointer, so that free can find > it). You would need to store a list of all valid allocations as an > independent list. > this is one possibility. he mentioned walking the list of allocations, which is one way to do it, but is too slow to make such a mechanism readily useful. an array of allocations works (essentially encoding memory spans), and can be made a bit faster by keeping them sorted and using binary-search and binary insert. however, this has a fairly high overhead, so is better if left mostly for larger objects (several kB or more). a typical solution for smaller objects (at least in my case) has been to divide regions of memory into an array of fixed size cells (typically 16-byte), which are managed with a bitmap (say, 4 bits/cell, though 2-bits could also be used). where cell states may be 0=free, 1=object header, 2=object data, 3=lock. looking up an object involves first looking up the memory region (with a binary lookup), calculating the cell index, and if we have landed on data, walking backwards until the header is found. allocation may consist of checking the free-list, or scanning for free-cells (relative to a rover). the overhead of the bitmap for small objects tends to be a fair bit lower than that of structures like allocation-arrays. however, performance of the bitmaps drops rapidly as object sizes increase. for one allocator, had considered using 256-byte cells as an intermediate level (16-byte cells for small objects, 256-byte cells for larger objects, and leaving the arrays for very-large objects). however, didn't really finish it, as there wasn't much data to justify needing this (at least for a several GB heap in a 32-bit process). IIRC, in past tests, time for looking up random objects in a relatively full (32-bit) heap was somewhere around 200 clock cycles. part of the cost for a sorted allocation array (namely inserts and deletes being expensive due to array-sliding) could be reduced by using a B-Tree instead of an array. an AVL tree can also work, but has a high level of overhead relative to stored payload. however, an AVL tree may still be ok for the relatively small number of larger allocations. though, part of the reason for an emphasis on overheads and times, is my projects have often tended to use large numbers of smaller objects, and have made a lot of use for using heap lookups to dynamically type-check objects. meanwhile, normal malloc implementations have tended to often be... insufficient... >> >> Corrupt: Internal heap structures are destroyed by overwriting of memory >> beyond the limits of a block. >> >> I would like to extend memcheck to return an enum of >> >> Data segment (initialized data) My linker coud conveniently store >> __firstDataAddress >> __LastData address >> to delimit that segment >> >> Stack. At program startup I could store RSP into __StackBottom, and >> the current RSP would give the top of the stack. If the address lies >> within those, it can be (abstracting out return addresses and frame >> pointers) easily assumed it is a local variable. >> >> Heap. I could walk the heap and see if the address is within the bounds >> of a malloced block. But if it is the result of a dll library call using >> another heap I can't recognize it. I could ask the OS for the handles of >> all heaps currently in use by the process, then enumerate and walk them >> all. > > This sounds very slow. And it relies on the heap structure being intact > - that's not a good starting point if you are checking for corruption! > agreed. for a non-trivial heap-size, linear searches can become absurdly expensive. typically, something with an O(log n) or O(1) average-case complexity is better (ideally with an O(log n) worst-case). it is better to walk the heap with some external "safer" structures (IOW: wont be destroyed by array overruns or similar). also, for good measure, putting check-values into various structures (say, for larger heap structures, using a combination of a magic value and a header-check value). for heap-object headers, a small check-value is typically sufficient (when the object is created/updated, the check value is calculated and stored, and operations can check the check-value to verify that the header is intact). >> >> Or I could do a dirty job with VirtualAlloc, what doesn't really help. >> >> Currently memcheck crashes if it is passed an invalid address. This >> calls the debugger, and the program can be examined. >> >> >
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-06-21 21:45 +0200 |
| Message-ID | <mm745r$9kq$1@dont-email.me> |
| In reply to | #63720 |
Le 21/06/2015 17:25, David Brown a écrit : > I would suggest that it returns 0 for NULL pointers. Actually you are right. I changed that. Thanks
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-11 10:56 -0700 |
| Message-ID | <kfnsi8uwpbz.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #63720 |
David Brown <david.brown@hesbynett.no> writes: > On 21/06/15 16:20, jacobnavia wrote: >> After adding recalloc, I thought I would add other functions I always >> wanted to have. >> >> size_t msize(void *ptr); >> >> Returns the size of the given block. If the pointer is NULL or is not a >> memory block allocated with malloc/realloc/recalloc (size_t)-1 is returned. > > I would suggest that it returns 0 for NULL pointers. [snip] There's a potential problem with that definition, in that it is troublesome for implementations that return a valid pointer for a malloc(0) request. Such pointers could reasonably be seen as having zero bytes allocated, especially if, eg, they pointed to unmapped address space (which is consistent with how the Standard specifies them). All in all I think it is better for the value of a NULL argument to be a distinguished value like (size_t)-1 rather than 0.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2015-06-21 18:35 +0200 |
| Message-ID | <mm6p2p$tud$1@dont-email.me> |
| In reply to | #63716 |
On 21/06/2015 16:20, jacobnavia wrote: > After adding recalloc, I thought I would add other functions > I always wanted to have. You don't say why this newsgroup should care what you implement in your proprietary compiler? glibc users have mallopt, mallinfo, malloc_info, etc. http://man7.org/linux/man-pages/man3/mallopt.3.html http://man7.org/linux/man-pages/man3/mallinfo.3.html http://man7.org/linux/man-pages/man3/malloc_info.3.html
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-21 21:39 +0100 |
| Message-ID | <87fv5kkd8i.fsf@bsb.me.uk> |
| In reply to | #63723 |
Noob <root@127.0.0.1> writes: <snip> > glibc users have mallopt, mallinfo, malloc_info, etc. A closer match to Jacob's msize is glibc's malloc_usable_size. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web