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 1 of 11 [1] 2 3 … 11 Next page →
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-06-21 16:20 +0200 |
| Subject | More useful memory functions |
| Message-ID | <mm6h4c$mqb$1@dont-email.me> |
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. 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. 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] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2015-06-21 22:31 +0800 |
| Message-ID | <mm6hp7$p7o$1@dont-email.me> |
| In reply to | #63716 |
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. > > 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. > > 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. Congratulations, This is the 9 billionth re-invention of the wheel. The first such things I remember was in the mid eighties of the last century by Walter Bright - and he was not the first. -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-06-21 16:35 +0200 |
| Message-ID | <mm6i0g$p1v$1@dont-email.me> |
| In reply to | #63717 |
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!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-21 13:20 -0700 |
| Message-ID | <lnwpyweru7.fsf@nuthaus.mib.org> |
| In reply to | #63718 |
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.
--
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:52 +0200 |
| Message-ID | <mm783t$o0t$1@dont-email.me> |
| In reply to | #63747 |
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!!!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-21 14:43 -0700 |
| Message-ID | <lnoak8eo02.fsf@nuthaus.mib.org> |
| In reply to | #63752 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 21/06/2015 22:20, Keith Thompson a écrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>> Le 21/06/2015 16:31, Reinhardt Behm a écrit :
>>>> This is the 9 billionth re-invention of the wheel.
>>> Yes. Wheels *ARE* useful.
>>>
>>> Do not be afraid of reinventing wheels. Reinvent them rather than not
>>> use them!
>>>
>>> What I would like to stress here is that the C standard, with all its
>>> new stuff like "generics", etc, did NOT seem to have discovered this wheels!
>>
>> I don't think it's a matter of not discovering them. Rather, adding
>> these features to the standard would impose a burden on implementers.
>> For example, there is no portable way to determine whether a given
>> pointer value is valid or not. Some implementations might have a
>> non-portable way to do so; others might not. I suspect the authors of
>> the standard just made a deliberate tradeoff.
>>
>
>
> Excuse me but since we have
>
> malloc(size);
>
> I do not see how would it be so difficult to return the size of a memory
> block!!!
Implementations of malloc can typically allocate more memory than was
asked for in the call. A conforming implementation needn't store the
requested size; it can store only the actual allocated size (since
there's currently no requirement to be able to retrieve either). I can
imagine implementations where neither size is stored explicitly (say, if
all allocations are managed in multiple linked lists, one for each
size).
I'm not saying it would be a large burden, or even that I'd oppose
adding msize() to the standard, but it would be imposed on *all*
malloc() calls, whether the program calls msize() or not.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-21 17:50 -0400 |
| Message-ID | <mm7bhi$420$1@dont-email.me> |
| In reply to | #63759 |
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? -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-06-22 00:21 +0200 |
| Message-ID | <mm7db6$dom$1@dont-email.me> |
| In reply to | #63761 |
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.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-21 18:39 -0400 |
| Message-ID | <mm7ec6$h77$1@dont-email.me> |
| In reply to | #63763 |
On 06/21/2015 06:21 PM, jacobnavia wrote: > 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. I think is should say "increased" rather than "adjusted". I'm not suggesting that this would change the actual meaning - the only possible way it could be adjusted is upward. I just think it's clearer to be more specific. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-06-22 00:44 +0200 |
| Message-ID | <mm7elv$i2r$1@dont-email.me> |
| In reply to | #63766 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-21 16:00 -0700 |
| Message-ID | <864e6e2c-5cc0-4c1e-985a-4513ef2ebb01@googlegroups.com> |
| In reply to | #63768 |
On Sunday, June 21, 2015 at 11:44:39 PM UTC+1, jacobnavia wrote: > > We are stuck with the memory allocation schema of the last century. > The problems of automatically freeing expired items completely dominates some languages, and turns them into a mess, particularly when you've got facilities for marking an object as "retained" for passing it on to a module written in another language, or as "freed" if you need to destroy it before it goes out of scope for efficiency reasons. Any fix would be blessing. But experience has shown that it's a hard thing to get right. The C method is reasonable, but a weakness is that there's no way of saying which pointer holds the "master" copy of the memory.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-06-22 21:03 +0000 |
| Message-ID | <55887349.15301328@news.xs4all.nl> |
| In reply to | #63768 |
jacobnavia <jacob@jacob.remcomp.fr> 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. This is the most sensible thing you've said in this thread, and it _is_ important. If this were a tool which could make bad programmers avoid buffer overflows, it would be a very good thing indeed, and you are quite correct to want it. Unfortunately, I fear you overestimate the average bad programmer; the kind who fail to check whether malloc() succeeded, and who assume a default memory size to their functions, are the very same who will also fail to call msize(). Sad - and I'd be on your side if it weren't true - but it _is_ true. > 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. _If_, is the operant word. What happens if you don't know that? A user-library function can't always know that, and may well want to. Take, for example, a function to add a new node to a tree, with the pointer pointing at the payload. If the existing payload was malloc()'ed, all is well. But what if it's a declared object? What if it's a string literal? Do we expect msize() to know the sizes of those as well? If so, it's a headache to implement. If not, it's a headache to write the function that calls it on pointers of unknown provenance. Either way, msize() _seems_ the solution, but is in fact a red herring. Don't get me wrong, I don't think msize() is useless /per se/. But neither do I believe it's the panacea you make it out to be. > We are stuck with the memory allocation schema of the last century. ...and you drop into the morass of attempted sarcasm again. You are no good at that, and it's time you learned that lesson. For one, it would help you get your message across more acceptably to people who, face it, have decades more experience at C programming _and_ English-language sarcasm than you do. If you want to get out of a "last century" allocation scheme and into a next-century one, adding a piddly little msize() function is risible. What you need to do is get rid of malloc() altogether, skip even you beloved C++'s new/destroy (which, after all, has its own 21st century problems all of its own, rather more convoluted and _definitely_ more MIPS-costly than malloc()/free()), 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. Richard
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-06-22 18:47 -0500 |
| Message-ID | <5c7hoahdkbv3cvbfpsidc05u80rraj1cro@4ax.com> |
| In reply to | #63867 |
On Mon, 22 Jun 2015 21:03:28 GMT, raltbos@xs4all.nl (Richard Bos) wrote: >If you want to get out of a "last century" allocation scheme and into a >next-century one, adding a piddly little msize() function is risible. >What you need to do is get rid of malloc() altogether, skip even you >beloved C++'s new/destroy (which, after all, has its own 21st century >problems all of its own, rather more convoluted and _definitely_ more >MIPS-costly than malloc()/free()), (...) Why would new/delete be more expensive than malloc/free? Certainly if the ctors and dtors actually do something, they may be, but if you have ctors and dtors doing something, you'd probably be coding something similar after/before the malloc/free anyway. On most platforms the *memory* allocation actually goes through the same code for both malloc/free and new/delete (it doesn't have to, of course).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-23 00:50 -0700 |
| Message-ID | <6ce25ac1-fcd4-4756-a091-824b0df91505@googlegroups.com> |
| In reply to | #63874 |
On Tuesday, June 23, 2015 at 12:47:43 AM UTC+1, robert...@yahoo.com wrote: > > Why would new/delete be more expensive than malloc/free? Certainly if > the ctors and dtors actually do something, they may be, but if you > have ctors and dtors doing something, you'd probably be coding > something similar after/before the malloc/free anyway. On most > platforms the *memory* allocation actually goes through the same code > for both malloc/free and new/delete (it doesn't have to, of course). > Yes, C++ tends to be less efficient that C because it's harder and less convenient for the human programmer to use, not because the underlying mechanisms are inherently less efficient than C. A ctor / dtor pair written in C is obviously executing code, the calling programmer is fully aware. So he tends to avoid unnecessary calls. A C++ programmer can easily call a constructor on an empty object, call another one to construct a valid object, and then call a copy constructor to assign to the empty object, soaking up lots of cycles, where a C programmer would have assigned to a null pointer, called the unavoidable valid constructor, and then assigned the temporary to the null.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-06-23 20:19 +1200 |
| Message-ID | <cusj56Fmh53U1@mid.individual.net> |
| In reply to | #63886 |
Malcolm McLean wrote: > On Tuesday, June 23, 2015 at 12:47:43 AM UTC+1, robert...@yahoo.com wrote: >> >> Why would new/delete be more expensive than malloc/free? Certainly if >> the ctors and dtors actually do something, they may be, but if you >> have ctors and dtors doing something, you'd probably be coding >> something similar after/before the malloc/free anyway. On most >> platforms the *memory* allocation actually goes through the same code >> for both malloc/free and new/delete (it doesn't have to, of course). >> > Yes, C++ tends to be less efficient that C because it's harder and > less convenient for the human programmer to use, not because the > underlying mechanisms are inherently less efficient than C. A > ctor / dtor pair written in C is obviously executing code, the > calling programmer is fully aware. So he tends to avoid unnecessary > calls. That's pretty nonsensical, isn't it? If code needs to run, how can the programmer avoid running it? > A C++ programmer can easily call a constructor on an empty > object, call another one to construct a valid object, and then call > a copy constructor to assign to the empty object, soaking up lots of > cycles, where a C programmer would have assigned to a null pointer, > called the unavoidable valid constructor, and then assigned the > temporary to the null. I don't really get that bit either. If you are saying what I think you are, you are describing a sequence of events the compiler would optimise away. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-23 01:46 -0700 |
| Message-ID | <e24af939-ff75-42a1-a633-a0dea7633a05@googlegroups.com> |
| In reply to | #63889 |
On Tuesday, June 23, 2015 at 9:19:58 AM UTC+1, Ian Collins wrote:
>
> > Yes, C++ tends to be less efficient that C because it's harder and
> > less convenient for the human programmer to use, not because the
> > underlying mechanisms are inherently less efficient than C. A
> > ctor / dtor pair written in C is obviously executing code, the
> > calling programmer is fully aware. So he tends to avoid unnecessary
> > calls.
>
> That's pretty nonsensical, isn't it?
>
> If code needs to run, how can the programmer avoid running it?
>
> > A C++ programmer can easily call a constructor on an empty
> > object, call another one to construct a valid object, and then call
> > a copy constructor to assign to the empty object, soaking up lots of
> > cycles, where a C programmer would have assigned to a null pointer,
> > called the unavoidable valid constructor, and then assigned the
> > temporary to the null.
>
> I don't really get that bit either. If you are saying what I think you
> are, you are describing a sequence of events the compiler would optimise
> away.
>
Consider this
BigObject obj; /* we've called the default constructor, it's an empty or null object */
BigObject temp( data); /* real constructor */
if(temp.issuitable()) /* if it passes certain tests, we want obj to be that object */
obj = temp;
The same in C
BIGOBJECT *obj = 0;
BIGOBJECT *temp = 0;
temp = bigobject(data):
if(bigobject_issuitable(temp))
{
obj = temp;
temp = 0;
}
They're not exactly equivalent, but they're the obvious way to write the code. However the
C++ may or may not be doing a lot of unnecessary work, you can't tell by looking
at the source itself. But the copy is likely expensive.
You can avoid it by making obj a pointer and calling new, however the code then looks
a mess if the normal code convention is to create objects on the stack.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-06-23 21:07 +1200 |
| Message-ID | <cusluqFmh53U2@mid.individual.net> |
| In reply to | #63893 |
Malcolm McLean wrote:
> On Tuesday, June 23, 2015 at 9:19:58 AM UTC+1, Ian Collins wrote:
>>
>>> Yes, C++ tends to be less efficient that C because it's harder and
>>> less convenient for the human programmer to use, not because the
>>> underlying mechanisms are inherently less efficient than C. A
>>> ctor / dtor pair written in C is obviously executing code, the
>>> calling programmer is fully aware. So he tends to avoid unnecessary
>>> calls.
>>
>> That's pretty nonsensical, isn't it?
>>
>> If code needs to run, how can the programmer avoid running it?
>>
>>> A C++ programmer can easily call a constructor on an empty
>>> object, call another one to construct a valid object, and then call
>>> a copy constructor to assign to the empty object, soaking up lots of
>>> cycles, where a C programmer would have assigned to a null pointer,
>>> called the unavoidable valid constructor, and then assigned the
>>> temporary to the null.
>>
>> I don't really get that bit either. If you are saying what I think you
>> are, you are describing a sequence of events the compiler would optimise
>> away.
>>
> Consider this
>
> BigObject obj; /* we've called the default constructor, it's an empty or null object */
>
> BigObject temp( data); /* real constructor */
>
> if(temp.issuitable()) /* if it passes certain tests, we want obj to be that object */
> obj = temp;
>
>
> The same in C
>
> BIGOBJECT *obj = 0;
> BIGOBJECT *temp = 0;
>
> temp = bigobject(data):
> if(bigobject_issuitable(temp))
> {
> obj = temp;
> temp = 0;
> }
>
> They're not exactly equivalent, but they're the obvious way to write the code.
Or it could be a dangerous way if the C object isn't safe to copy (say
it contains a pointer to some allocated memory). Then there's the
question of who frees the object now pointed to be both temp and obj.
> However the
> C++ may or may not be doing a lot of unnecessary work, you can't tell by looking
> at the source itself. But the copy is likely expensive.
In modern C++, the copy could be a move assignment, which does very
little work.
> You can avoid it by making obj a pointer and calling new, however the code then looks
> a mess if the normal code convention is to create objects on the stack.
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?
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-23 10:22 +0100 |
| Message-ID | <mmb8em$h5t$1@dont-email.me> |
| In reply to | #63896 |
On 23/06/15 10:07, Ian Collins wrote: <snip> > 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? <AOL>I was going to make the same point</AOL>, but I see you've made it for me. So, instead, I will simply take issue with the phrasing. It does not /beg/ the question. It /raises/ the question. http://begthequestion.info/ explains the matter very simply, and from the nature of the domain name we can perhaps infer that the author of that site may have done a little basic research into the matter. :-) -- 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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-06-23 21:27 +1200 |
| Message-ID | <cusn4gFmh53U3@mid.individual.net> |
| In reply to | #63897 |
Richard Heathfield wrote: > On 23/06/15 10:07, Ian Collins wrote: > > <snip> > >> 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? > > <AOL>I was going to make the same point</AOL>, but I see you've made it > for me. So, instead, I will simply take issue with the phrasing. It does > not /beg/ the question. It /raises/ the question. > > http://begthequestion.info/ explains the matter very simply, and from > the nature of the domain name we can perhaps infer that the author of > that site may have done a little basic research into the matter. :-) Thank you for the educational link Richard! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-23 08:30 -0700 |
| Message-ID | <lnoak6a1ch.fsf@nuthaus.mib.org> |
| In reply to | #63897 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 23/06/15 10:07, Ian Collins wrote:
>
> <snip>
>
>> 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?
>
> <AOL>I was going to make the same point</AOL>, but I see you've made it
> for me. So, instead, I will simply take issue with the phrasing. It does
> not /beg/ the question. It /raises/ the question.
>
> http://begthequestion.info/ explains the matter very simply, and from
> the nature of the domain name we can perhaps infer that the author of
> that site may have done a little basic research into the matter. :-)
Yes -- and we have this problem because "beg the question" is a
poor and misleading translation of the Latin "petitio principii".
The English phrase "beg the question", in the absence of the original
Latin, would be a halfway reasonable way to say "raise the question"
-- though "raise the question" would be a clearer way to express it.
To beg the question is to assume the conclusion -- and "assume the
conclusion" is a clearer way to say that.
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".
(Not that that's a bad thing.)
https://en.wikipedia.org/wiki/Begging_the_question
It's sort of like "ANSI C". We know what it *really* means in
pedanticallyl correct usage (the version of C endorsed by the
American National Standards Institute, currently the 2011 standard),
and we know what most people use it to mean (C89, the only version
of the C standard that was *originally* published by ANSI). We can
avoid confusion by using less ambiguous terms (ISO C, C89, C90,
C95, C99, C11).
--
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]
Page 1 of 11 [1] 2 3 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web