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 | 14 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 11 of 11 — ← Prev page 1 … 9 10 [11]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-28 13:47 +0100 |
| Subject | Re: gcc FUD |
| Message-ID | <87egkwf19f.fsf@bsb.me.uk> |
| In reply to | #64341 |
Bartc <bc@freeuk.com> writes: <snip> > I've never been into OSes, it was enough that MSDOS provided a disk > file system, everything else I was happy to supply (for graphics, > fonts, printers, plotters, mice and tablets, that sort of stuff). I've long had a soft spot for preemptive scheduling, memory protection, some degree of user security, a network stack, a usable shell, that kind of thing. I did not have the time time to provide all those so I tried to avoid MSDOS (not always possible of course), and though I might now have the time, I don't have the inclination to do it all myself. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-28 05:55 -0700 |
| Subject | Re: gcc FUD |
| Message-ID | <59710150-1e93-44b1-821c-03a10ad0c4b0@googlegroups.com> |
| In reply to | #64359 |
On Sunday, June 28, 2015 at 1:47:32 PM UTC+1, Ben Bacarisse wrote: > > > I've never been into OSes, it was enough that MSDOS provided a disk > > file system, everything else I was happy to supply (for graphics, > > fonts, printers, plotters, mice and tablets, that sort of stuff). > > I've long had a soft spot for preemptive scheduling, memory protection, > some degree of user security, a network stack, a usable shell, that kind > of thing. I did not have the time time to provide all those so I tried > to avoid MSDOS (not always possible of course), and though I might now > have the time, I don't have the inclination to do it all myself. > Depends what you're doing. Most of the programs I wrote for my PhD simply needed a data file in setting up the simulation and soft-coded parameters, and outputted the results, usually a protein structure in Protein Data Bank format. Memory protection was handy, but it wouldn't have been a game changer to do without it. However a lot of the programs were parallel, and I wasn't about to write my own parallel programming protocol - I used MPI.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-28 18:42 +0100 |
| Subject | Re: gcc FUD |
| Message-ID | <87vbe7enlk.fsf@bsb.me.uk> |
| In reply to | #64360 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Sunday, June 28, 2015 at 1:47:32 PM UTC+1, Ben Bacarisse wrote: >> >> > I've never been into OSes, it was enough that MSDOS provided a disk >> > file system, everything else I was happy to supply (for graphics, >> > fonts, printers, plotters, mice and tablets, that sort of stuff). >> >> I've long had a soft spot for preemptive scheduling, memory protection, >> some degree of user security, a network stack, a usable shell, that kind >> of thing. I did not have the time time to provide all those so I tried >> to avoid MSDOS (not always possible of course), and though I might now >> have the time, I don't have the inclination to do it all myself. >> > Depends what you're doing. Most of the programs I wrote for my PhD simply > needed a data file in setting up the simulation and soft-coded parameters, > and outputted the results, usually a protein structure in Protein Data Bank > format. I don't know when you did this, but all my PhD students relied heavily on e-mail, even in the 80s. Did you always drop your supervisor a paper note? Did you never get or post protein data via FTP or even that newfangled www thingy? And the programs needed to be written, for which having the tools provided by a good OS (such as as good shell that I mentioned) would have been of some use, no? Of course my area was networks and communications, so there was never any point in considering anything that could not run a proper network server but in other areas those things can be handy. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-29 07:27 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmqkuk$60u$1@speranza.aioe.org> |
| In reply to | #64333 |
On 28.06.2015 00:47, David Brown wrote: > On 27/06/15 23:31, Bartc wrote: >> On 27/06/2015 21:37, David Brown wrote: >> >>> To be honest, I have somewhat lost track of what the discussion was >>> supposed to be about. >> >> The sub-thread was started by someone who objected to my saying that gcc >> was getting bigger and slower. >> >> But it seems to be generally agreed that it /is/ quite big and it /is/ >> fairly slow among C compilers, and it /is/ getting bigger and slower, so >> I wasn't wrong. >> > > Actually, it appears to be getting faster again (tests show gcc 5 is > faster than 4.9). > > Certainly 3.x and 4.x gcc are a lot slower than the old 2.x generations > - but they are vastly more advanced compilers with lots more features, > and better code generation. How good is gcc at exploiting multiple processors/cores? I know with make one can use the -j command line argument to control how many jobs will be run at the same time. As for compiling, I'm used to Python which is interpreted, but it should be possible to have at least two compile modes if compile speed is an issue, one for development and one for production. Whether or not compiling with different settings is a good idea or not is another question, but a complete test suite should be able to detect errors. -Morten
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-29 10:17 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmqusf$viu$1@dont-email.me> |
| In reply to | #64413 |
On 29/06/15 07:27, Morten W. Petersen wrote: > On 28.06.2015 00:47, David Brown wrote: >> On 27/06/15 23:31, Bartc wrote: >>> On 27/06/2015 21:37, David Brown wrote: >>> >>>> To be honest, I have somewhat lost track of what the discussion was >>>> supposed to be about. >>> >>> The sub-thread was started by someone who objected to my saying that gcc >>> was getting bigger and slower. >>> >>> But it seems to be generally agreed that it /is/ quite big and it /is/ >>> fairly slow among C compilers, and it /is/ getting bigger and slower, so >>> I wasn't wrong. >>> >> >> Actually, it appears to be getting faster again (tests show gcc 5 is >> faster than 4.9). >> >> Certainly 3.x and 4.x gcc are a lot slower than the old 2.x generations >> - but they are vastly more advanced compilers with lots more features, >> and better code generation. > > How good is gcc at exploiting multiple processors/cores? I know > with make one can use the -j command line argument to control > how many jobs will be run at the same time. > That sounds like you are talking about using multiple cores to speed up compiling rather than generating code that takes advantage of multiple cores (which is a very different issue). Normally, a compilation runs on a single processor - it is fundamentally a serial process. As you say, it is "make" (or other build systems, like ant, bake, etc.) that control the multiple processor resources and make everything run in parallel. Other compilers that I know of work in basically the same way, even if the actual building and compilation is hidden within an IDE. You can benefit from multiple cores if there are multiple source files to compile at the same time. The only part of gcc that deals directly with multiple threads or processes, as far as I know, is when using link-time optimisation. The linking is done with a single gcc command, but this spawns multiple threads or processes to LTO-compile parts of the code in parallel. I haven't tested this much, and can't say how well it scales - but I do know this is an area that has received a good deal of attention in recent gcc releases (with testing on LTO compilation of massive code bases like Firefox or OpenOffice). > As for compiling, I'm used to Python which is interpreted, but it > should be possible to have at least two compile modes if compile > speed is an issue, one for development and one for production. Some people like to use unoptimised compilation for compile speed, as it is faster than having optimisation enabled. Personally, I prefer to use optimisation at all times - amongst other things, it makes the static error checking better. > > Whether or not compiling with different settings is a good idea > or not is another question, but a complete test suite should be > able to detect errors. > > -Morten >
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-29 11:05 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmr1nl$3of$1@speranza.aioe.org> |
| In reply to | #64427 |
On 29.06.2015 10:17, David Brown wrote: [...] > The only part of gcc that deals directly with multiple threads or > processes, as far as I know, is when using link-time optimisation. The > linking is done with a single gcc command, but this spawns multiple > threads or processes to LTO-compile parts of the code in parallel. I > haven't tested this much, and can't say how well it scales - but I do > know this is an area that has received a good deal of attention in > recent gcc releases (with testing on LTO compilation of massive code > bases like Firefox or OpenOffice). Ah, that's interesting. Which can probably be translated to that with a structured, broken up design of the code and make, gcc is fast enough for huge code bases. >> As for compiling, I'm used to Python which is interpreted, but it >> should be possible to have at least two compile modes if compile >> speed is an issue, one for development and one for production. > > Some people like to use unoptimised compilation for compile speed, as it > is faster than having optimisation enabled. Personally, I prefer to use > optimisation at all times - amongst other things, it makes the static > error checking better. OK, that's good to know. -Morten
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-29 11:34 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmr3c3$g2k$1@dont-email.me> |
| In reply to | #64428 |
On 29/06/15 11:05, Morten W. Petersen wrote: > On 29.06.2015 10:17, David Brown wrote: > [...] >> The only part of gcc that deals directly with multiple threads or >> processes, as far as I know, is when using link-time optimisation. The >> linking is done with a single gcc command, but this spawns multiple >> threads or processes to LTO-compile parts of the code in parallel. I >> haven't tested this much, and can't say how well it scales - but I do >> know this is an area that has received a good deal of attention in >> recent gcc releases (with testing on LTO compilation of massive code >> bases like Firefox or OpenOffice). > > Ah, that's interesting. Which can probably be translated to that with > a structured, broken up design of the code and make, gcc is fast enough > for huge code bases. gcc has always been used for huge code bases - far more compilation of huge code bases (for any value of "huge") is done with gcc than with any other compiler. (There are big code bases compiled with other tools - presumably MS uses MSVC for Windows, for example - but far more people compile programs like Firefox with gcc than with other tools.) And gcc has always been "fast enough" for such uses - but of course, everyone likes it to be faster :-) What is new is that gcc is fast enough at LTO (which is itself relatively new to gcc) to be practical for huge code bases. <https://gcc.gnu.org/gcc-4.9/changes.html> "Memory usage building Firefox with debug enabled was reduced from 15GB to 3.5GB; link time from 1700 seconds to 350 seconds. " Of course, to take advantage of parallel compilation, the build procedure for software must support "make -j" (or equivalent for other build systems). There are some software packages that won't work with parallel builds, and therefore don't scale with more cores. > >>> As for compiling, I'm used to Python which is interpreted, but it >>> should be possible to have at least two compile modes if compile >>> speed is an issue, one for development and one for production. >> >> Some people like to use unoptimised compilation for compile speed, as it >> is faster than having optimisation enabled. Personally, I prefer to use >> optimisation at all times - amongst other things, it makes the static >> error checking better. > > OK, that's good to know. > > -Morten >
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-06-28 02:14 -0500 |
| Subject | Re: gcc FUD |
| Message-ID | <7j7voat15bh02ummliulave6ub58km51to@4ax.com> |
| In reply to | #64324 |
On Sat, 27 Jun 2015 22:37:53 +0200, David Brown <david.brown@hesbynett.no> wrote: >No, gcc is not part of Linux (though currently it is the only compiler >that can be used to compile the Linux kernel, due to the kernel's use of >gcc extensions - clang support is close, however). At least at one point it was possible to compile the Linux kernel with ICC, although I don't know if Intel has maintained that.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-06-28 08:57 +1200 |
| Subject | Re: gcc FUD |
| Message-ID | <cv8h16F5vd9U1@mid.individual.net> |
| In reply to | #64282 |
Bartc wrote: > On 26/06/2015 13:05, David Brown wrote: > >> What does this tell us? The total pre-processed source code of all the >> files is about 750 KLOC. On Linux, with serial build, that's an average >> of 15.6 K lines per second. With realistic builds using parallel make, >> the effective figure is 65 K lines per second. > > This is not really about Linux vs. Windows. I'm sure that gcc and its > toolset, developed on Linux, will be highly optimised for Linux. (Maybe > these tools are part /of/ Linux and therefore even more streamlined; I > don't know.) > > But other compilers /are/ capable of running very quickly under Windows. > > I've just dug up an old compiler of mine (not interpreted this time), > and an old project, and it managed about 100K lines per second - on a > single core. (60K lines of code in 22 modules, plus 140K lines of > headers; one big header is frequently included unnecessarily, > nevertheless it totalled 200K lines and it compiled that lot in about 2 > seconds.) You aren't comparing apples with apples. More like a grape with a bunch of grapes. Real world projects use parallel and distributed builds which present a different workload to the host. If I'm cross-compiling a large ARM project (a real past example was a layer 3 switch, which included a specialised Linux kernel), the compiler is fixed so my choice build environment is crucial if I want (and who doesn't?) to minimise build times. So I guess what David is saying is there are other important factors to consider when choosing a build environment along with the serial speed of the compiler. If compiler A is twice as fast as compiler B, but it only runs on a platform where parallel builds don't scale well, it would be a poor choice for a big project. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-26 10:18 +0100 |
| Subject | Re: gcc FUD |
| Message-ID | <mmj59s$bfm$1@dont-email.me> |
| In reply to | #64163 |
On 25/06/2015 19:57, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: > [...] >> Because, first thing in the morning especially, you can count to 10 >> while waiting for gcc to compile even Hello World! > > Perhaps you have a slow computer, or you count quickly? > > "gcc hello.c -o hello" just took me 1.34 seconds on a reasonably fast > machine. Running it again took 0.024 seconds, probably because of > caching effects. Well, it's morning, and I tried to compile hello.c. (This happened to be auto-generated so a bit busier than a normal hello, with an extra include file with a few typedefs and defines. Still, no more than 50 lines in total.) First time compilation by gcc/TDM (64-bits) was 8.something seconds. (with Mingw/32-bits, 5.6 seconds.) So you /can/ count to 10 if counting marginally under once per second. Especially if starting from 1! (In the morning, the machine starts up from hibernation. The test was done after SVCHOST had done its thing -- taking over one core and most of the RAM for 10 to 20 minutes. I've no idea what it is or what it's doing except it's not a virus, but presumably it clears out a lot of the cache in the process.) This has little impact on subsequent use of the compiler, although it's still sluggish, but it shows I wasn't exaggerating much! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-26 11:26 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmj5qd$sep$1@speranza.aioe.org> |
| In reply to | #64202 |
On 26.06.2015 11:18, Bartc wrote: > On 25/06/2015 19:57, Keith Thompson wrote: >> Bartc <bc@freeuk.com> writes: >> [...] >>> Because, first thing in the morning especially, you can count to 10 >>> while waiting for gcc to compile even Hello World! >> >> Perhaps you have a slow computer, or you count quickly? >> >> "gcc hello.c -o hello" just took me 1.34 seconds on a reasonably fast >> machine. Running it again took 0.024 seconds, probably because of >> caching effects. > > Well, it's morning, and I tried to compile hello.c. (This happened to be > auto-generated so a bit busier than a normal hello, with an extra > include file with a few typedefs and defines. Still, no more than 50 > lines in total.) > > First time compilation by gcc/TDM (64-bits) was 8.something seconds. > (with Mingw/32-bits, 5.6 seconds.) > > So you /can/ count to 10 if counting marginally under once per second. > Especially if starting from 1! > > (In the morning, the machine starts up from hibernation. The test was > done after SVCHOST had done its thing -- taking over one core and most > of the RAM for 10 to 20 minutes. I've no idea what it is or what it's > doing except it's not a virus, but presumably it clears out a lot of the > cache in the process.) > > This has little impact on subsequent use of the compiler, although it's > still sluggish, but it shows I wasn't exaggerating much! I just compiled my 750 line C project in GCC/Cygwin after having done a lot of different things and not coding for days and it compiled in 2.2 seconds, after having started it using make. I guess a better comparison would've been for example Linux on runlevel 1 on a simple shell but it isn't possible to run MSVC there. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.com> |
|---|---|
| Date | 2015-06-26 08:05 -0400 |
| Subject | Re: gcc FUD |
| Message-ID | <mmjf4f$ctu$1@dont-email.me> |
| In reply to | #64202 |
Bartc wrote:
> On 25/06/2015 19:57, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>> [...]
>>> Because, first thing in the morning especially, you can count to 10
>>> while waiting for gcc to compile even Hello World!
>>
>> Perhaps you have a slow computer, or you count quickly?
>>
>> "gcc hello.c -o hello" just took me 1.34 seconds on a reasonably fast
>> machine. Running it again took 0.024 seconds, probably because of
>> caching effects.
>
> Well, it's morning, and I tried to compile hello.c. (This happened to be
> auto-generated so a bit busier than a normal hello, with an extra
> include file with a few typedefs and defines. Still, no more than 50
> lines in total.)
>
> First time compilation by gcc/TDM (64-bits) was 8.something seconds.
> (with Mingw/32-bits, 5.6 seconds.)
>
> So you /can/ count to 10 if counting marginally under once per second.
> Especially if starting from 1!
>
> (In the morning, the machine starts up from hibernation. The test was
> done after SVCHOST had done its thing -- taking over one core and most
> of the RAM for 10 to 20 minutes. I've no idea what it is or what it's
> doing except it's not a virus, but presumably it clears out a lot of the
> cache in the process.)
>
> This has little impact on subsequent use of the compiler, although it's
> still sluggish, but it shows I wasn't exaggerating much!
>
At startup, Windows Defender might be scanning stuff. And even
if you disable "real time protection", that does not disable
system folder scanning at startup.
*******
The other outstanding bug against Windows 7, is the Windows Update
problem. wuauserv lives with some other services, in a particular
svchost. You can move that service to its own svchost. The file
that is actually running has wuaueng in the name. As administrator
sc config wuauserv type= own
After a reboot, if you find a svchost has gone to 100% CPU usage,
you can use
tasklist /svc
but that command is not supported on every version of Windows. You
can also use Sysinterals.com Process Explorer to get information.
If the svchost which now hosts wuauserv alone, is running at
100%, then you know it's a Windows Update problem.
This bug also existed in WinXP, and Microsoft just doesn't want
to fix it.
This patch, issued this month, reduces wuauserv memory usage. On my
Win7 test setup, it reduces memory use from 900MB peak to 155MB peak.
However, this "bandaid" does not stop wasted CPU, which could run at
100% on a single core of the processor for at least 40 minutes or so.
This bandaid is intended for people with single core machines,
who were actually running out of RAM (i.e. machine is practically
bricked while this happens). On my Win7 setups, I still have some
RAM left, so installing this patch isn't as critical.
https://support.microsoft.com/en-us/kb/3050265
It's pathetic really, that the bug has lasted for this
long... and nobody cares. At some companies, as many as 3000 PCs
are plagued with this high CPU problem at the same time.
And the way this bug works, is it gets worse with time. The more
patches issued by Microsoft, the larger the dependency tree
is. And some non-scalable algorithm must be present, because
when the bug is present, the time for 100% CPU usage roughly
doubles every month. So December, the CPU might be railed for
5 minutes, 10 minutes after January Patch Tuesday, 20 minutes
after February Patch Tuesday. And the trick that served
as a workaround in the WinXP era, no longer has any effect
on the problem seen in Windows 7.
Turning off the Windows Update subsystems will fix it :-)
Paul
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-21 11:56 -0500 |
| Message-ID | <mm6qji$9e9$1@news.albasani.net> |
| In reply to | #63716 |
On 6/21/2015 9:20 AM, 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. > MSVC also basically has this, just called _msize(). > 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. is this for consistency checks, or for verifying if the pointer points to a valid heap object? if the latter, I would recommend splitting the behaviors into separate functions. if the former, will note that functions to check whether or not pointers are valid can be pretty useful. otherwise, some potentially useful functions: int _isheap(void *ptr); returns 0 if the pointer is not a valid heap object. returns >0 if the pointer is a valid heap object. returns <0 if an error occurs. void *_getobjbase(void *ptr); gets the base for a pointer into an object, returns NULL if not _isheap(). int _getobjtag(void *ptr); returns a user-defined tag for the object, or -1 if given an invalid pointer. int _setobjtag(void *ptr, int value); sets the user-defined tag for an object. default object tag is 0. value range should be probably at least 16 bits. a big use-case for these tags would be for things like dynamic types, where a type-ID can be assigned to objects. while it might seem like 8 or 12 bits should be plenty sufficient, for a larger program there may easily end up being a considerable number of object types (enough to fill a 12-bit table). also 16-bits tries to avoid being sufficiently large to pose as serious of a risk to the size of object headers. hopefully also these functions can be implemented in a way where they are not ridiculously slow (such as naively doing linear searches over the heap objects or similar). then again, most non-trivial apps implement their own memory managers anyways, with malloc mostly as a quick/dirty MM for small tools (in some implementations, prone to poor performance and/or considerable space wasted due to allocation overheads), so who knows?...
[toc] | [prev] | [next] | [standalone]
| From | Gordon Burditt <gordon@hammy.burditt.org> |
|---|---|
| Date | 2015-06-22 03:25 -0500 |
| Message-ID | <IpKdnXfwhbr2WxrInZ2dnUU7-UmdnZ2d@posted.internetamerica> |
| In reply to | #63716 |
> 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.
Is this program guaranteed to never trigger the assert to abort the
program? That is, msize() returns *EXACTLY* the argument given to
malloc() to allocate the memory in the first place. No rounding
up. It's OK if malloc() fails for "large" allocations. And yes,
for a 64-bit architecture, this program is going to be VERY
(heat-death-of-the-universe) slow.
#include <assert.h>
void leak(void *p)
{
/* calling leak(p) indicates you never intend */
/* to free the memory pointed at by p */
/* do nothing */
return;
}
int main(int argc, char **argv)
{
unsigned int size;
void *p;
for (size = 1; size < UINT_MAX; size++) {
p = malloc(size);
if (p != NULL) {
assert(msize(p) == size);
}
leak(p);
}
exit(EXIT_SUCCESS);
}
Architecture assumptions: This program has to work properly
on a machine with 64-bit pointers and ints where strict alignment
(multiple of 8) is required to access them. malloc() will have
to return pointers that are a multiple of 8 bytes.
[toc] | [prev] | [standalone]
Page 11 of 11 — ← Prev page 1 … 9 10 [11]
Back to top | Article view | comp.lang.c
csiph-web