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 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-23 16:43 +0100 |
| Message-ID | <mmbupa$69j$2@dont-email.me> |
| In reply to | #63954 |
On 23/06/15 16:30, Keith Thompson wrote: > Using the phrase "beg the question" to mean "raise the question" > is verbal shorthand for "please correct my usage and tell me a > little about Latin and Aristotle", though it's not usually intended > that way. > > Using the phrase "beg the question" to mean "assume the conclusion" > is verbal shorthand for "I'm educated, and I'm hoping for an > opportunity to tell you a little about Latin and Aristotle". *applause* -- 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-23 02:36 -0700 |
| Message-ID | <64d7f79e-2911-4bb3-a1e7-ac1fc837ef63@googlegroups.com> |
| In reply to | #63896 |
On Tuesday, June 23, 2015 at 10:07:47 AM UTC+1, Ian Collins wrote: > Malcolm McLean wrote: > > But your example creates two objects in C++ and one in C. So it's bound > to be doing more work, isn't it? It also begs the question why create > temp and assign it to obj? > Exactly. In C, it's obvious what you're doing. In C++, you only realise if you're especially thinking about efficiency. We have to to create an object with the data, then test whether it is suitable or not. We only want obj to be that object if suitable. You can of course rewrite the fragment - making up real examples that are suitable as code fragments is quite difficult
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-06-23 21:54 +1200 |
| Message-ID | <cuson8Fmh53U4@mid.individual.net> |
| In reply to | #63900 |
Malcolm McLean wrote: > On Tuesday, June 23, 2015 at 10:07:47 AM UTC+1, Ian Collins wrote: >> Malcolm McLean wrote: >> >> But your example creates two objects in C++ and one in C. So it's bound >> to be doing more work, isn't it? It also begs the question why create >> temp and assign it to obj? >> > Exactly. In C, it's obvious what you're doing. In C++, you only realise if you're > especially thinking about efficiency. Why? It is pretty clear that two objects are being created. Why not just create one and use it if it is suitable? C++ provides the means for disallowing or providing low cost copy assignment (which would be used in this case). > We have to to create an object with the data, then test whether it is suitable or > not. We only want obj to be that object if suitable. You can of course rewrite > the fragment - making up real examples that are suitable as code fragments > is quite difficult You made the original claim, so it's up to you so supply the examples that back it up. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-23 05:38 -0700 |
| Message-ID | <79406b08-6203-4f71-951a-2e9d6c3de668@googlegroups.com> |
| In reply to | #63902 |
On Tuesday, June 23, 2015 at 10:54:59 AM UTC+1, Ian Collins wrote:
> Malcolm McLean wrote:
>
> You made the original claim, so it's up to you so supply the examples
> that back it up.
>
Ok let's use a more realistic example, but essentially the same.
Sequence dna; /* dna an empty "sequence" object of zero length */
Sequence temp("myfile.fasta"); // load an empty sequence
if(temp.isdna())
dna = temp;
double GCcontent = dna.GCcontent();
return GCcontent;
double Sequence.GCcontent()
{
if(length == 0)
return NaN;
else return (count('G') + count('C')) / (double) length;
}
Now we can of course rewrite this.
Let's do so.
Sequence dna("myfile.fasta");
if(dna.isdna())
GCcontent = dna.GCcontent();
else
{
Sequence empty;
GCContent = empty.GCContent();
}
return GCContent;
But it's not as nice. We've got a variable called "dna" hanging about, which likely
is neither an empty sequence nor contains DNA, it's a protein or RNA sequence.
Let's say we've got a few unknown bases. So we change the requirements to
return the maximum of GCContent and 1.0 - ATcontent, AT content being exactly
the same function as GC content with A and T
So someone writes
ATcontent = dna.ATContent(); /* it's called dna, it must contain a dna sequence, right?*/
return GCcontent > 1 - ATcontent ? GCContent : 1 - ATContent;
Now we've introduced a bug, if the sequence is a protein sequence containing 20
letters (including G,C, A and T).
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-06-24 09:03 +1200 |
| Message-ID | <cutvtpFmh53U6@mid.individual.net> |
| In reply to | #63912 |
Malcolm McLean wrote:
> On Tuesday, June 23, 2015 at 10:54:59 AM UTC+1, Ian Collins wrote:
>> Malcolm McLean wrote:
>>
>> You made the original claim, so it's up to you so supply the examples
>> that back it up.
>>
> Ok let's use a more realistic example, but essentially the same.
>
> Sequence dna; /* dna an empty "sequence" object of zero length */
>
> Sequence temp("myfile.fasta"); // load an empty sequence
>
> if(temp.isdna())
> dna = temp;
>
> double GCcontent = dna.GCcontent();
>
> return GCcontent;
>
> double Sequence.GCcontent()
> {
> if(length == 0)
> return NaN;
> else return (count('G') + count('C')) / (double) length;
> }
>
>
> Now we can of course rewrite this.
>
> Let's do so.
>
> Sequence dna("myfile.fasta");
>
> if(dna.isdna())
> GCcontent = dna.GCcontent();
> else
> {
> Sequence empty;
> GCContent = empty.GCContent();
> }
> return GCContent;
>
> But it's not as nice. We've got a variable called "dna" hanging about, which likely
> is neither an empty sequence nor contains DNA, it's a protein or RNA sequence.
No you haven't, you have just executed "return GCContent;". You would
have had the same problem (only worse) with your C example.
Anyway, the first example would be efficient with move assignment or in
the likely case that Sequence were little more than a wrapper for some
dynamic memory.
So to sum up, the C++ version would be no less efficient with the
additional benefit of freeing the programmer from having to know which
pointer to free and how to free it.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-23 17:20 -0700 |
| Message-ID | <26cf5bc1-68cc-4e23-ab6e-5259462e7d2c@googlegroups.com> |
| In reply to | #63990 |
On Tuesday, June 23, 2015 at 10:04:03 PM UTC+1, Ian Collins wrote: > Malcolm McLean wrote: > > No you haven't, you have just executed "return GCContent;". You would > have had the same problem (only worse) with your C example. > > Anyway, the first example would be efficient with move assignment or in > the likely case that Sequence were little more than a wrapper for some > dynamic memory. > A pointer is essentially "move assignment". C++ invents some elaborate syntax and a hidden function call. Then you've got to put the source into a "valid but indeterminate state" - essentially you've reinvented null. The fact that C++ 11 had to invent the move assignment operator shows that my point was correct. > > So to sum up, the C++ version would be no less efficient with the > additional benefit of freeing the programmer from having to know which > pointer to free and how to free it. > C++ does call destructors, and that's a real benefit. It can be made extremely efficient, but you need tricky programming to do so. (Before move, the standard way to achieve the same result was to "swap", but that was confusing as swapping is a reasonably common algorithmic requirement when you need to retain both values, to use it as an efficiency hack for assignment and disposal made code hard to read).
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-24 01:36 +0100 |
| Message-ID | <mmcu0e$v8b$1@dont-email.me> |
| In reply to | #64013 |
On 24/06/15 01:20, Malcolm McLean wrote: <snip> > A pointer is essentially "move assignment". C++ invents some elaborate > syntax and a hidden function call. Then you've got to put the > source into a "valid but indeterminate state" - essentially you've > reinvented null. No, you've invented llun. A null pointer is invalid but determinate. -- 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-23 00:34 -0700 |
| Message-ID | <141a84ca-f645-4f4a-a374-f63b036d633c@googlegroups.com> |
| In reply to | #63867 |
On Monday, June 22, 2015 at 10:03:34 PM UTC+1, Richard Bos wrote: > and go straight to automagic memory > allocation where you can just copy one constant string to another > declared object and one array of structures to another dynamically > allocated area, and trust that it all goes away when it goes out of > scope. > Which many people have had a shot at, and nobody has yet hit. > Javascript is fine. Whatever the problems with the language, memory management isn't one of them. But it's meant for "glue" logic, not suitable for processor- intensive operations. If you're not too bothered about memory take or runtime efficiency, then the problem is soluble and the Javascript programmer doesn't need to worry about allocation failures, leaks, or buffer management.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-23 09:55 +0200 |
| Message-ID | <mmb3al$152$1@dont-email.me> |
| In reply to | #63768 |
On 22/06/15 00:44, jacobnavia wrote:
> Le 22/06/2015 00:39, James Kuyper a écrit :
>> I think is should say "increased" rather than "adjusted".
>
> You are right, it can only be increased, so it is better to say so.
>
> A standard function msize would make life easier for programmers trying
> to avoid buffer overflows. Besides it could save many extra parameters
> to functions since if you know it is a malloced block you can get the
> size at any moment.
>
> Imagine then how easy would be to check for buffer overflows!
>
> We are stuck with the memory allocation schema of the last century.
>
>
As I understand it, msize() would return the size of the block allocated
by malloc. That is /not/ the same as the size of data you are pointing
at. It might happen to be the same, but it might be bigger.
So you can easily have situations like this:
// Fill the block with A's, and null-terminate
void fillBuffer(char * p) {
size_t n = msize(p); // This could be bigger
memset(p, 'A', n - 1);
p[n - 1] = '\0';
}
void foo(void) {
char * p = malloc(100);
fillBuffer(p);
char s[100];
memcpy(s, p, 100);
printf(s); // s is not necessarily null-terminated!
}
The code using fillBuffer passes on a pointer to 100 characters - but
msize() might return a bigger value, such as 112. There would
/probably/ be no problem with code that overwrites this extra space, but
other things can easily go wrong when the size returned by msize() does
not match the size expected by the code that called malloc().
So the use of msize() does not really help programmers, nor does it
reduce the need to pass length parameters around. At best, it might
help bad programmers (or good programmers who have to deal with bad
code) write marginally safer code.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-06-23 08:35 +0000 |
| Message-ID | <mmb5nu$u3d$1@speranza.aioe.org> |
| In reply to | #63887 |
David Brown <david.brown@hesbynett.no> wrote: > On 22/06/15 00:44, jacobnavia wrote: (snip) >> A standard function msize would make life easier for programmers trying >> to avoid buffer overflows. Besides it could save many extra parameters >> to functions since if you know it is a malloced block you can get the >> size at any moment. (snip) > As I understand it, msize() would return the size of the block allocated > by malloc. That is /not/ the same as the size of data you are pointing > at. It might happen to be the same, but it might be bigger. It wouldn't be that hard to save the requested length in addition to the allocated request. -- glen
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-23 11:32 +0200 |
| Message-ID | <mmb90k$i56$1@dont-email.me> |
| In reply to | #63890 |
On 23/06/15 10:35, glen herrmannsfeldt wrote: > David Brown <david.brown@hesbynett.no> wrote: >> On 22/06/15 00:44, jacobnavia wrote: > > (snip) >>> A standard function msize would make life easier for programmers trying >>> to avoid buffer overflows. Besides it could save many extra parameters >>> to functions since if you know it is a malloced block you can get the >>> size at any moment. > > (snip) >> As I understand it, msize() would return the size of the block allocated >> by malloc. That is /not/ the same as the size of data you are pointing >> at. It might happen to be the same, but it might be bigger. > > It wouldn't be that hard to save the requested length in addition > to the allocated request. > That's true - but that is not what the existing (non-standard, MS-specific) _msize() function does. And it means storing more data in the malloc() block, wasting more ram, and more time and effort, for a feature that would be used very rarely. Any code that actually /needed/ this information could store it itself.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-06-24 09:51 +0000 |
| Message-ID | <558a7d75.3046406@news.xs4all.nl> |
| In reply to | #63890 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > David Brown <david.brown@hesbynett.no> wrote: > > As I understand it, msize() would return the size of the block allocated > > by malloc. That is /not/ the same as the size of data you are pointing > > at. It might happen to be the same, but it might be bigger. > > It wouldn't be that hard to save the requested length in addition > to the allocated request. It would be harder than _necessary_, though. Richard
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-21 17:03 -0700 |
| Message-ID | <lnbng8ehi3.fsf@nuthaus.mib.org> |
| In reply to | #63763 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 21/06/2015 23:50, James Kuyper a écrit :
>> hat shouldn't be a problem - it's the actual allocated size that is
>> usually desired when people ask for such a feature.
>
> As I said elsewhere, the standard could just say:
>
> The value may be adjusted by the implementation and not necessarily be
> the original requested size.
Sure, with a guarantee that the actual size is at least as big as the
requested size.
BTW, another possible argument (perhaps not a particularly strong one)
against standardizing msize() is that it could become a source of bugs.
I presume the standard would say that msize() returns the actual
allocated size for a pointer returned by malloc() and friends (and not
subsequently freed), and that its behavior is undefined for a non-heap
pointer. (msize(NULL) could either return some particular value or have
undefined behavior.)
I can imagine a lot of programmers, particularly inexperienced ones,
calling msize() on a pointer passed to a function and expecting a
meaningful result, even if the pointer is the address of an
automatically or statically allocated object.
Of course that's fundamentally the programmer's responsibility, and
msize(ptr) would be undefined in the same cases where free(ptr) is
undefined. But some people complain that C has too much undefined
behavior already; adding more would have a non-zero cost.
Making the behavior of msize() well defined for all pointer values
would, I think, impose a substantial burden on implementers.
--
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 | gordonb.muhly@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2015-06-22 05:17 -0500 |
| Message-ID | <hdGdnZOxHts3fRrInZ2dnUU7-dOdnZ2d@posted.internetamerica> |
| In reply to | #63763 |
>> hat shouldn't be a problem - it's the actual allocated size that is >> usually desired when people ask for such a feature. > > As I said elsewhere, the standard could just say: > > The value may be adjusted by the implementation and not necessarily be > the original requested size. I'd prefer that it say "adjusted" in every sentence that refers to the return value. Preferably in a bright red blinking 50-point font with a police siren audio. Returning the adjusted value makes it very difficult to actually use msize() and properly test that the code works - even (or perhaps especially) on a system where msize() returns the memory size originally asked for. One potential trap is trying to use msize(p) as the size of an arbitrary "data blob" (that is, not a string nor something that describes itself, so the length is needed but not provided) p without storing the length elsewhere. The "adjustment" will effectively add a few bytes of garbage on to the end of the data blob, even if calloc() was originally used to allocate the memory. Does calloc() clear the extra unrequested bytes allocated by malloc() on any known system? I know of one implementation that does for calloc(0,0) (because the size is zero) but not for, for example, calloc(11,13) (because the size is not a multiple of 4 or 8 or whatever). Another potential trap is having the adjustment be so much that the code to lengthen the allocation if necessary rarely, if ever, gets used. E.g. on a 64-bit system, you might end up rounding up to a multiple of 8 bytes. So the error might never be noticed if you're tacking on a ".z" extension. I am reminded here of the old UNIX-V7 directory slot problem. A directory slot consisted of a 14-character array (*NOT* necessarily nul-terminated) and a 16-bit inode number. Many programs mis-handled 14-character file names by assuming that the name was nul-terminated, when it wasn't guaranteed to be nul-terminated (and usually wasn't unless the following slot was present and empty). There were plenty of compatability routines that read old directories using the new (BSD) readdir() interface that got this wrong.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-22 09:08 -0400 |
| Message-ID | <mm919n$3r6$1@dont-email.me> |
| In reply to | #63796 |
On 06/22/2015 06:17 AM, Gordon Burditt wrote: [While responding to jacob navia, and trimming out jacob's proper attribution of the following text to me:] >>> hat shouldn't be a problem - it's the actual allocated size that is >>> usually desired when people ask for such a feature. I know that you mistakenly believe that it's legally safer to not attribute something to anybody unless you know for certain that that it was written by that person, and I agree with you that such certainty is unavailable on usenet. However, as I've told you several times before, I deny you (or anyone else) permission to quote me without proper attribution. As has been pointed out to you many times already, you can satisfy your legal misconceptions by using a attribution line like the following: Someone claiming to be "James Kuyper" wrote: Note that you only need to do this with your own direct attribution lines. When quoting attributions provided by others, as long as you correctly describe your own uncertain identification of the person you're quoting, you can't be held responsible for the accuracy of their attributions. You are, however, responsible for copying those attributions whenever they remain applicable to text that has not been trimmed from your response. Either quote me with correct attribution, or not at all - your choice. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2015-06-23 22:20 +0200 |
| Subject | Re: Snipping attribution lines |
| Message-ID | <mmcevd$c6v$1@dont-email.me> |
| In reply to | #63807 |
On 22/06/2015 15:08, James Kuyper wrote: > On 06/22/2015 06:17 AM, Gordon Burditt wrote: > [While responding to jacob navia, and trimming out jacob's proper > attribution of the following text to me:] >>>> That shouldn't be a problem - it's the actual allocated size that is >>>> usually desired when people ask for such a feature. > > I know that you mistakenly believe that it's legally safer to not > attribute something to anybody unless you know for certain that that it > was written by that person, and I agree with you that such certainty is > unavailable on usenet. However, as I've told you several times before, I > deny you (or anyone else) permission to quote me without proper > attribution. As has been pointed out to you many times already, you can > satisfy your legal misconceptions by using a attribution line like the > following: > > Someone claiming to be "James Kuyper" wrote: > > Note that you only need to do this with your own direct attribution > lines. When quoting attributions provided by others, as long as you > correctly describe your own uncertain identification of the person > you're quoting, you can't be held responsible for the accuracy of their > attributions. You are, however, responsible for copying those > attributions whenever they remain applicable to text that has not been > trimmed from your response. > > Either quote me with correct attribution, or not at all - your choice. Same request here. Gordon, you don't have permission to quote my messages with missing attribution lines.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-21 16:57 -0700 |
| Message-ID | <lnfv5kehsr.fsf@nuthaus.mib.org> |
| In reply to | #63761 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 06/21/2015 05:43 PM, 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).
>
> That shouldn't be a problem - it's the actual allocated size that is
> usually desired when people ask for such a feature.
>
>> I can
>> imagine implementations where neither size is stored explicitly (say, if
>> all allocations are managed in multiple linked lists, one for each
>> size).
>
> 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.
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-06-22 00:54 +0000 |
| Message-ID | <mm7mc3$sgn$1@speranza.aioe.org> |
| In reply to | #63773 |
Keith Thompson <kst-u@mib.org> wrote: (snip on allocating and freeing) > 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. The OS/360 (and successor) GETMAIN and FREEMAIN are a little different. You can allocate (GETMAIN) a block, and then free part of it. You can free the beginning, middle, or end. You give the address that you want to free and the length. I am not sure how much checking it does. Also, there is an option where you give a range (maximum and minumum) needed, and it finds a block within that range. OS/360 MVT also uses GETMAIN for allocating regions for tasks before running them. It might be that later systems don't do that. -- glen
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-06-22 12:35 +0000 |
| Message-ID | <558800c9.9816484@news.xs4all.nl> |
| In reply to | #63777 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > Keith Thompson <kst-u@mib.org> wrote: > > (snip on allocating and freeing) > > > 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. > > The OS/360 (and successor) GETMAIN and FREEMAIN are a little different. > > You can allocate (GETMAIN) a block, and then free part of it. You can > free the beginning, middle, or end. You give the address that you want > to free and the length. I am not sure how much checking it does. Mind you, none of that is compatible with the behaviour of malloc() as it is, so I don't see how it prevents a C implementation on the OS/360 from implementing msize() using the same methods it already uses to make malloc() and free() behave as they should. Richard
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-21 21:10 -0400 |
| Message-ID | <mm7n7m$89b$1@dont-email.me> |
| In reply to | #63773 |
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. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web