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 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-24 16:57 +0200 |
| Message-ID | <mmeger$n01$1@dont-email.me> |
| In reply to | #64050 |
On 24/06/15 14:27, jacobnavia wrote: > Le 24/06/2015 14:20, David Brown a écrit : >> Let me get this straight - you say that one of the great things about >> gcc is the extensions. You use those extensions to write better code, >> and then you are complaining that gcc is "forcing" you to write >> non-portable code and locking you in? > > No, he is confusing things. I think someone might be - but I don't know if it is Bart or I. > > Extensions are OK when is gcc. Extensions are fine if you find them useful, and don't mind the limitations they imply. The issue here is that Bart seems to want to take advantage of some gcc extensions, but dislikes that this limits him to gcc. However, many of gcc's extensions are supported by other compilers (clang in particular, but also Intel's compiler and a number of embedded compilers), and gcc supports a huge range of hosts and targets. So using gcc extensions /is/ lock-in, but it is lock-in to a wide range of popular compilers. > > Extensions are a "vendor lock in" when they are lcc-win's extensions. Yes, using lcc-win extensions is clearly vendor lock-in. It is still a perfectly good idea if you are using lcc-win and find the extensions useful - and I would imagine that such extensions are a major motive for many of lcc-win's users. But the extensions are usable solely with the one specific compiler for the one specific platform, and it is a compiler that is only available as a paid-for commercial product or for hobby usage. This makes such extensions much more "vendor lock-in" than gcc extensions - but it is a matter of degree, as any compiler extensions places limits on the tools you can use. > > Discussing gcc trivia in this group is OK. Discussing lcc-win is not. Both are off-topic, but both can lead to interesting discussions. And it is worth noting that for every lcc-win user there will be 10,000 gcc users - it is quite natural that gcc trivia has a wider audience and acceptance. gcc is the nearest thing there is to a "standard C compiler" (it is quite far from being such a standard, but it is still the /nearest/ - it is the compiler against which all others are compared). lcc-win, on the other hand, is a very niche product, and it is also a highly commercial product. You will see people here being a lot more tolerant to discussions about gcc than MSVC, for example - since it also is a closed commercial compiler for a very limited range of hosts and targets. (Note that I don't mean any disrespect to either you or lcc-win here - I am very impressed with what you have achieved and that you have made a living from it, and wish you all the luck in the world with the tool. I am merely trying to answer your questions here as best I can, pointing out some of the real-world differences between gcc and lcc-win.) > > Why? > > Because... well, I do not know. >
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-24 13:47 +0100 |
| Message-ID | <mme8ql$p8b$1@dont-email.me> |
| In reply to | #64047 |
On 24/06/2015 13:20, David Brown wrote: > On 24/06/15 13:58, Bartc wrote: >> If you think that being locked in to a particular compiler and toolset >> is acceptable, that the code involved is still considered portable, then >> that's fine; I'll withdraw my comments. > Let me get this straight - you say that one of the great things about > gcc is the extensions. You use those extensions to write better code, > and then you are complaining that gcc is "forcing" you to write > non-portable code and locking you in? Well ... yes. For example, performance is important to me (otherwise, forget gcc, I'll just use the compiler I like best). gcc offers 'label pointers' which can make a substantial difference, so I can't just ignore that feature (not when I'm comparing my product to one that does make use of it. Or in my case, comparing my own language with label pointers, to C without; that would be cheating. Besides which, my language sometimes needs to target C source code, and it rather helps if the C target supports them too!) But now I have the hassle of making the code work also with compilers that don't have it. It's easy to be lazy and not bother. (I also like using '$' in identifiers to endow special meaning, because '_' is practically invisible. Many compilers accept it, but a few don't. So what do I do? I like to be able to read my code!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-24 14:48 +0100 |
| Message-ID | <871th1i5e1.fsf@bsb.me.uk> |
| In reply to | #64053 |
Bartc <bc@freeuk.com> writes: > On 24/06/2015 13:20, David Brown wrote: >> On 24/06/15 13:58, Bartc wrote: > >>> If you think that being locked in to a particular compiler and toolset >>> is acceptable, that the code involved is still considered portable, then >>> that's fine; I'll withdraw my comments. > >> Let me get this straight - you say that one of the great things about >> gcc is the extensions. You use those extensions to write better code, >> and then you are complaining that gcc is "forcing" you to write >> non-portable code and locking you in? > > Well ... yes. Ah, right. So why did you not simply agree with me when I suggest that the problem you see is the attractive extensions? You've accused me of deliberately missing your meaning just for the same of being argumentative (at least in the past), but I've been trying to pin it down and you keep suggesting I've got it all wrong. <snip> > (I also like using '$' in identifiers to endow special meaning, > because '_' is practically invisible. Many compilers accept it, but a > few don't. So what do I do? I like to be able to read my code!) $ conveys little meaning. Why not use something that conveys a bit more meaning like PCC_SYS_ or PCC_TEMP_ or PCC_IO_? (I'm using caps because you wnat it to stand out but I find pcc_temp_ et. al. to be visible enough for my taste.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-24 18:45 +0100 |
| Message-ID | <mmeq9l$vsk$1@dont-email.me> |
| In reply to | #64058 |
On 24/06/2015 14:48, Ben Bacarisse wrote: > Bartc <bc@freeuk.com> writes: > $ conveys little meaning. Why not use something that conveys a bit more > meaning like PCC_SYS_ or PCC_TEMP_ or PCC_IO_? (I'm using caps because > you wnat it to stand out but I find pcc_temp_ et. al. to be visible > enough for my taste.) I don't mean $ by itself! Usually the rest of it will explain a bit more. The $ just denotes something not in user-space but it's clearer than _ and __ (Python uses __name__ which is a bit much). I don't think $ is used for anything else in C so why not? (Most compilers let it through anyway even if they might warn. Only lccwin, of the ones I've tried, gives an actual error when $ starts an identifier, but it's OK with an embedded $. But if it was really a deal-breaker, then with generated code it's possible to fix it without too much trouble.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-24 14:12 -0500 |
| Message-ID | <mmevmj$mro$1@news.albasani.net> |
| In reply to | #64086 |
On 6/24/2015 12:45 PM, Bartc wrote: > On 24/06/2015 14:48, Ben Bacarisse wrote: >> Bartc <bc@freeuk.com> writes: > >> $ conveys little meaning. Why not use something that conveys a bit more >> meaning like PCC_SYS_ or PCC_TEMP_ or PCC_IO_? (I'm using caps because >> you wnat it to stand out but I find pcc_temp_ et. al. to be visible >> enough for my taste.) > > I don't mean $ by itself! Usually the rest of it will explain a bit more. > > The $ just denotes something not in user-space but it's clearer than _ > and __ (Python uses __name__ which is a bit much). I don't think $ is > used for anything else in C so why not? > > (Most compilers let it through anyway even if they might warn. Only > lccwin, of the ones I've tried, gives an actual error when $ starts an > identifier, but it's OK with an embedded $. But if it was really a > deal-breaker, then with generated code it's possible to fix it without > too much trouble.) > yeah, my compiler also allows it. off-hand, I don't really know of any others which don't, but who knows (not really tested or looked into it much, as I don't really use it personally in normal code, but it may be used in tool-generated code, such as in name mangling). MSVC only lists it as allowed for C++, but it also works in C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-24 17:12 +0200 |
| Message-ID | <mmehao$pse$2@dont-email.me> |
| In reply to | #64053 |
On 24/06/15 14:47, Bartc wrote: > On 24/06/2015 13:20, David Brown wrote: >> On 24/06/15 13:58, Bartc wrote: > >>> If you think that being locked in to a particular compiler and toolset >>> is acceptable, that the code involved is still considered portable, then >>> that's fine; I'll withdraw my comments. > >> Let me get this straight - you say that one of the great things about >> gcc is the extensions. You use those extensions to write better code, >> and then you are complaining that gcc is "forcing" you to write >> non-portable code and locking you in? > > > Well ... yes. For example, performance is important to me (otherwise, > forget gcc, I'll just use the compiler I like best). gcc offers 'label > pointers' which can make a substantial difference, so I can't just > ignore that feature (not when I'm comparing my product to one that does > make use of it. > > Or in my case, comparing my own language with label pointers, to C > without; that would be cheating. Besides which, my language sometimes > needs to target C source code, and it rather helps if the C target > supports them too!) > > But now I have the hassle of making the code work also with compilers > that don't have it. It's easy to be lazy and not bother. > > (I also like using '$' in identifiers to endow special meaning, because > '_' is practically invisible. Many compilers accept it, but a few don't. > So what do I do? I like to be able to read my code!) > OK, I believe I understand you now. And you know your choices - you have to decide what works best for you. (Have you checked if clang supports these two extensions?)
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-24 10:27 -0500 |
| Message-ID | <mmeigj$sfb$1@news.albasani.net> |
| In reply to | #64047 |
On 6/24/2015 7:20 AM, David Brown wrote: > On 24/06/15 13:58, Bartc wrote: >> On 24/06/2015 11:50, Ben Bacarisse wrote: >>> Bartc <bc@freeuk.com> writes: >> >>>> So I mean portability in the sense of being able to grab the nearest C >>>> compiler, whichever it is, and just use that. >>> >>> You meant, then, that by using the extensions you wave goodbye to >>> portability? That's true of course but hardly unique to gcc. Your >>> complaint about gcc is that it has particularly attractive extensions? >> >> Go back a few posts and see my reasons why people might use gcc or feel >> obliged to. >> >> If you think that being locked in to a particular compiler and toolset >> is acceptable, that the code involved is still considered portable, then >> that's fine; I'll withdraw my comments. >> >> (However I privately feel that a project that is ostensibly written in >> C, but in reality depends on these other factors, isn't actually in C at >> all, but in C-GCC-4.X.X-BASH-MAKE-6.X-whatever. Whether the C involved >> is -89, -90, -99, or -11 is a minor detail! >> >> And this is even more true when much of the C source is buried under >> masses of preprocessor directives. Because IMO overuse of those isn't >> proper C either. But there at least, that doesn't matter too much if you >> just want to compile the code, not understand it.) >> > > Let me get this straight - you say that one of the great things about > gcc is the extensions. You use those extensions to write better code, > and then you are complaining that gcc is "forcing" you to write > non-portable code and locking you in? > if one writes their own compiler though, they can clone most of the relevant GCC extensions, nevermind the pain and hassle of writing a C compiler. personally though, I don't write much GCC-specific code, and have mostly shied away from extensions I can't at least emulate in normal C (mostly resulting in features implemented via macros and/or builtin-functions, rather than via syntax extensions...). this applies to my C-Aux variant, which ironically, means that valid C-Aux is also generally valid C (just not all C is valid in C-Aux, as it is technically a subset). most of its tweaks and extensions effect the way the language works and behaves, and are mostly invisible at the source-code level. almost got Quake ported to it though, but ran into a few roadblocks which were not easily addressed, such as an inability to let code in the current interpreter pass callbacks to the Win32 API (there is no "good" way to do this with a plain-C interpreter, don't want to depend on using specialized native code in the interpreter backend). well, and even getting this far involved a considerable amount of debugging (and some hackery), so was pretty burnt out on it at the time. partly it is because pretty much nothing in Quake is outside the scope of C-Aux, though there was a lot of special cases which tripped up the compiler, and who knows how many bugs which have managed to leak through into the output code, or which still exist in the VM backend. for a more specialized language, I have tended to use BGBScript, which has mutated considerably from the lazy JavaScript clone it started out as a decade ago, and may well end up splitting into multiple sub-languages. as-is, it covers too much area, as trying to address JS-like, Java-like, C-like, and GLSL-like use-cases (dense numerical A/V filtering) with a single language is, problematic... thing is basically a multi-headed multi-backend hydra-like beast. a current split underway is BS-RT, which apart from using the same basic name and syntax as BS, will be essentially a different language with an independent compiler and VM (though, BS-RT and C-Aux will share the VM). ironically, BS is a lot bigger and more complex than C is at this point (and C-Aux is pretty much a semantic subset of BS-RT). if I later wanted to do an offline or AOT compiler, there are a few possible options: do my own native backends (most likely for JIT, maybe AOT); use something like LLVM (AOT or offline); translate to C and feed it through a native C compiler for the target (offline only).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-24 14:41 +0100 |
| Message-ID | <877fqti5qk.fsf@bsb.me.uk> |
| In reply to | #64043 |
Bartc <bc@freeuk.com> writes: > On 24/06/2015 11:50, Ben Bacarisse wrote: >> Bartc <bc@freeuk.com> writes: > >>> So I mean portability in the sense of being able to grab the nearest C >>> compiler, whichever it is, and just use that. >> >> You meant, then, that by using the extensions you wave goodbye to >> portability? That's true of course but hardly unique to gcc. Your >> complaint about gcc is that it has particularly attractive extensions? > > Go back a few posts and see my reasons why people might use gcc or > feel obliged to. Yes, I did. But you don't have to use the extensions and you certainly should not feel obliged to. If you are obliged to use gcc, that alone should have little impact on portability. I keep offering re-phrasings that make sense to me but you keep rejecting them. You seem to be saying gcc has some effect on portability but I can't pin down what it is. If it's not the siren call of it's extensions, what is it? > If you think that being locked in to a particular compiler and toolset > is acceptable, that the code involved is still considered portable, > then that's fine; I'll withdraw my comments. How could you possibly think that? I want to know how you think gcc impacts on portability precisely because I *don't* want people to be locked into tool sets. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-24 07:53 -0700 |
| Message-ID | <c6c2d829-e226-41b7-884b-4fade069f556@googlegroups.com> |
| In reply to | #64039 |
On Wednesday, June 24, 2015 at 11:50:35 AM UTC+1, Ben Bacarisse wrote: > > You meant, then, that by using the extensions you wave goodbye to > portability? That's true of course but hardly unique to gcc. Your > complaint about gcc is that it has particularly attractive extensions? > It should be obvious you're using an extension. If the source file should have a .gnuc extension, then it's no longer C, it's gnuc, and anyone would expect a superset of C. Equally if you've got to #include "gnux.h" you know that the file won't be portable. But if, for example, they just quietly add the symbol NaN and allow if(x == NaN) then it's easy to use it without realising that you're not using standard C.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-24 16:17 +0100 |
| Message-ID | <874mlxw2yf.fsf@bsb.me.uk> |
| In reply to | #64065 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, June 24, 2015 at 11:50:35 AM UTC+1, Ben Bacarisse wrote: >> >> You meant, then, that by using the extensions you wave goodbye to >> portability? That's true of course but hardly unique to gcc. Your >> complaint about gcc is that it has particularly attractive extensions? >> > It should be obvious you're using an extension. Yes. > If the source file should have a .gnuc extension, then it's no longer > C, it's gnuc, and anyone would expect a superset of C. But a .c is probably not "C" as in "the current standard". Do you want .c90, .c95, .c99, .c11-vlas, .c11+vlas? I think the boat has sailed on that one. But note that gcc can (unlike some older compilers I remember) have the language specified independently of the extension. > Equally if you've got to > #include "gnux.h" > you know that the file won't be portable. > > But if, for example, they just quietly add the symbol NaN and allow > if(x == NaN) > then it's easy to use it without realising that you're not using > standard C. Obviously you have to hope they do it right. The general rule is that when you turn on -std=cXX -pedantic you will have to ask for extras with a "feature" request macro. This is the way gcc has been going and while is was not so careful in the past, it's pretty good now. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-24 08:34 -0700 |
| Message-ID | <lny4j986j2.fsf@nuthaus.mib.org> |
| In reply to | #64065 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, June 24, 2015 at 11:50:35 AM UTC+1, Ben Bacarisse wrote:
>> You meant, then, that by using the extensions you wave goodbye to
>> portability? That's true of course but hardly unique to gcc. Your
>> complaint about gcc is that it has particularly attractive extensions?
>>
> It should be obvious you're using an extension.
> If the source file should have a .gnuc extension, then it's no longer
> C, it's gnuc, and anyone would expect a superset of C. Equally if
> you've got to #include "gnux.h" you know that the file won't be
> portable.
I've never seen anyone use a ".gnuc" extension, even for gcc-specific
code, and gcc doesn't recognize it. You'd have to compile with
something like "gcc -c -xc foo.gnuc".
> But if, for example, they just quietly add the symbol NaN and allow
> if(x == NaN)
> then it's easy to use it without realising that you're not using standard C.
Not the best example; the macros NAN and isnan() and the function nan()
are standard. I think they were added in C99.
"gcc -std=cNN, -pedantic" does a reasonably good job of warning about
code that uses gcc extensions.
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-10 18:48 -0700 |
| Message-ID | <kfnegkf31ml.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #64077 |
Keith Thompson <kst-u@mib.org> writes: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> On Wednesday, June 24, 2015 at 11:50:35 AM UTC+1, Ben Bacarisse wrote: >>> You meant, then, that by using the extensions you wave goodbye to >>> portability? That's true of course but hardly unique to gcc. >>> Your complaint about gcc is that it has particularly attractive >>> extensions? >> >> It should be obvious you're using an extension. If the source file >> should have a .gnuc extension, then it's no longer C, it's gnuc, >> and anyone would expect a superset of C. Equally if you've got to >> #include "gnux.h" you know that the file won't be portable. > > I've never seen anyone use a ".gnuc" extension, even for > gcc-specific code, and gcc doesn't recognize it. You'd have to > compile with something like "gcc -c -xc foo.gnuc". > >> But if, for example, they just quietly add the symbol NaN and allow >> if(x == NaN) >> then it's easy to use it without realising that you're not using >> standard C. > > Not the best example; the macros NAN and isnan() and the function > nan() are standard. I think they were added in C99. > > "gcc -std=cNN, -pedantic" does a reasonably good job of warning > about code that uses gcc extensions. Do you know if it does any better job than just "gcc -pedantic" does?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-10 18:56 -0700 |
| Message-ID | <fc97418d-1ca4-49df-b210-53760847de76@googlegroups.com> |
| In reply to | #65218 |
On Saturday, July 11, 2015 at 2:48:59 AM UTC+1, Tim Rentsch wrote:
> Keith Thompson <kst-u@mib.org> writes:
>
>
> >> But if, for example, they just quietly add the symbol NaN and allow
> >> if(x == NaN)
^^^^^^^^^^^^
> >> then it's easy to use it without realising that you're not using
> >> standard C.
> >
> > Not the best example; the macros NAN and isnan() and the function
> > nan() are standard. I think they were added in C99.
> >
>
Piggybacking (you're not killfiled, Google groups didn't like your
post).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-10 20:53 -0700 |
| Message-ID | <ln4mlbqri7.fsf@kst-u.example.com> |
| In reply to | #65218 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> "gcc -std=cNN, -pedantic" does a reasonably good job of warning
>> about code that uses gcc extensions.
>
> Do you know if it does any better job than just "gcc -pedantic" does?
If you don't specify "-std=..." (or "-ansi"), gcc defaults to
"-std=gnu89" for versions earlier than 5.1, and to "-std=gnu11" for 5.1.
I *think* that "-pedantic" enables the same diagnostics for "-std=gnuNN"
as for "-std=cNN". It may be that "gcc -std=gnuNN -pedantic" and
"gcc -std=cNN -pedantic" are equivalent.
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-11 13:52 -0700 |
| Message-ID | <kfnh9pav2m9.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65230 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: > > [...] > >>> "gcc -std=cNN, -pedantic" does a reasonably good job of warning >>> about code that uses gcc extensions. >> >> Do you know if it does any better job than just "gcc -pedantic" does? > > If you don't specify "-std=..." (or "-ansi"), gcc defaults to > "-std=gnu89" for versions earlier than 5.1, and to "-std=gnu11" for 5.1. > > I *think* that "-pedantic" enables the same diagnostics for "-std=gnuNN" > as for "-std=cNN". It may be that "gcc -std=gnuNN -pedantic" and > "gcc -std=cNN -pedantic" are equivalent. That's what I would guess. I thought you might have more information available than I do.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2015-06-24 10:31 -0500 |
| Message-ID | <mmeiop$sss$1@news.albasani.net> |
| In reply to | #64065 |
On 6/24/2015 9:53 AM, Malcolm McLean wrote: > On Wednesday, June 24, 2015 at 11:50:35 AM UTC+1, Ben Bacarisse wrote: >> >> You meant, then, that by using the extensions you wave goodbye to >> portability? That's true of course but hardly unique to gcc. Your >> complaint about gcc is that it has particularly attractive extensions? >> > It should be obvious you're using an extension. > If the source file should have a .gnuc extension, then it's no longer C, it's gnuc, > and anyone would expect a superset of C. Equally if you've got to #include "gnux.h" > you know that the file won't be portable. > > But if, for example, they just quietly add the symbol NaN and allow > if(x == NaN) > then it's easy to use it without realising that you're not using standard C. > most common issue I have run into has been people doing pointer arithmetic on 'void *'. a lot of people seem to fail to realize this is an extension.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-24 14:15 +0200 |
| Message-ID | <mme6v5$im5$1@dont-email.me> |
| In reply to | #64026 |
On 24/06/15 10:53, Bartc wrote: > On 24/06/2015 04:25, BGB wrote: >> On 6/23/2015 7:52 PM, Bartc wrote: > >>> gcc is a monster that keeps getting bigger - and slower. I'm not >>> surprised that hundreds of people are needed to keep feeding it. > >> customizing GCC is likely a big pain, whereas a smaller compiler could >> likely be tweaked a little easier. > > I think that's where compilers such as lccwin come in. > Creating a custom gcc or porting it to a new target is a serious job, but many people have managed it - even some one-man teams. However, llvm/clang is generally the easiest starting point for new compiler targets these days. > I wouldn't know where to start with gcc. Forget customising, how do you > even build it to work normally when it's outside its comfort zone (ie. > Linux)? Lots of people manage that too, though it is undoubtedly harder on Windows than on a *nix system. But then, the same applies to most compilation of software, especially if it is cross-platform. If you really want to know where to start with developing or changing gcc, then I would suggest the "Getting Started" wiki page as an obvious place to begin: <https://gcc.gnu.org/wiki/GettingStarted> But there is no doubt that gcc is a massive project, and the modularisation and separation of parts is far from perfect. > > There are a few reasons why people use gcc: > > * It produces quite good code (at least for x86; apparently it's not so > hot on ARM) It produces some of the best code for the x86, but to get the very fastest results always requires a knowledge of the tools and the target cpu, and good testing and profiling. There was a time when gcc did not generate very good code for the ARM, but that was something like 12 years ago. A number of expensive commercial ARM toolchain vendors worked hard to keep that myth alive as long as possible. gcc is far and away the most used compiler for ARMs, from the tiniest microcontrollers to the largest server chips. ARM are a major contributor to the gcc arm port. llvm/clang is the other alternative for ARMs, and ARM are in the process of making it the core of their official development tools. There various reasons why they are doing so, such as llvm/clang being faster to run, easier to work with and having more "corporate friendly" licensing, but this is in parallel with their work on gcc. gcc produces top-of-the-range code for most of its targets. It is not always at the very top, but is seldom far out (again, assuming you know how to use it properly). > > * It exists for practically every processor imaginable I know (and use) a few for which it does not work, but this is certainly one of the reasons why I use it. > > * It has a few attractive extensions, such as label addresses. > (Apparently, CPython makes use of label pointers within gcc, which it > uses for Linux. On Windows, it compiles with MSVC without label > pointers, hence CPython runs somewhat slower on Windows than under Linux > on exactly the same machine.) It does indeed have some useful extensions. I can't say label addresses have ever been relevant to me, but there are a number of other extensions that I /do/ use. Many have been copied by clang, by several other compiler vendors, and sometimes by the C (or C++) standards committees. > > * If code is developed on Linux, and most open source code seems to be, > then it seems to be a rule that it has to use gcc. Makefiles will make > certain of that anyway! gcc is usually the most convenient choice of compiler on Linux systems. Modern BSD systems have clang as their standard compiler - but sometimes (at least on Macs) it is common to have a symbolic link called "gcc" pointing to clang. The huge majority of the code I develop is not open source. And almost all of it is developed on Linux, simply because I find Linux a much nicer platform for software development (and most other uses) - it's a matter of personal choice, of course. Very little of my work uses the native gcc - it is mostly cross-compilers (usually with Windows and Linux builds). > > * Because it is ubiquitous, if you are distributing code, it makes sense > to make sure it compiles with gcc. Indeed. > > So it's big, slow and complex, but it's difficult to get away from it! /All/ serious toolchains are big and complex. gcc is not the fastest compiler - clang is usually several times faster. But it is not the slowest tool I have seen either. > You also wave goodbye to portability, unless portability means being > able to build on anything that has gcc installed. > You only "wave goodbye to portability" if you choose to use non-portable constructs. You can use gcc extensions in order to generate faster code, or to write simpler or clearer source code, and then you lose portability - but the same applies to any toolchain. If you want your code to be portable across a range of compilers, stick to the common subset that they all support. I can add a few more reasons why I choose gcc for most of my work: * Its free license means we can archive and distribute the toolchains in source and binary format, both within the company and outside. As I mentioned elsewhere, getting exact copies of the toolchain is important to us. * It is cross-platform, and most gcc toolchains I use have builds for Windows and Linux. * You can install it as a copy of a directory tree, and run it from the command line and make. There is no need for a gui, or special drivers, or other configuration. * It has extensive warning flags that can help enforce development practices and spot small errors.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2015-06-25 09:57 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmgc70$3tq$1@dont-email.me> |
| In reply to | #64026 |
On 24/06/2015 10:53, Bartc wrote: >>> gcc is a monster that keeps getting bigger - and slower. I'm not >>> surprised that hundreds of people are needed to keep feeding it. [ Typical barely accurate FUD and half-truths ] Although you offer no supporting evidence, I'll grant you that gcc is getting bigger: gcc-4.7.4.tar.gz 104190 KB gcc-4.8.5.tar.gz 108366 KB gcc-4.9.2.tar.gz 112976 KB gcc-5.1.0.tar.gz 119498 KB Did you ever consider that it is getting bigger because... 1) it supports an increasing number of platforms (mostly embedded) 2) it supports an increasing number of sophisticated optimization passes 3) some languages such as C++ are constantly evolving, and compilers have to support language standards for decades Slower. Slower how? At what setting? Could you /be/ more vague? And maybe you're right. Maybe there's a regression or three. Or maybe the set of default options was changed. But why should anyone take your word for it? Also, I am quite sure there are not "hundreds of people" working on gcc full time. >> customizing GCC is likely a big pain, whereas a smaller compiler could >> likely be tweaked a little easier. > > I think that's where compilers such as lccwin come in. FFS, does JN need an impresario, now? > I wouldn't know where to start with gcc. Forget customising, how do you > even build it to work normally when it's outside its comfort zone (ie. > Linux)? So, because YOU don't know where to start means it must be too complex a task? For all the whiners who cry "but how am I supposed to get paid for writing software when those fucking GNU hippies are giving away theirs for free", this is the business model that IBM has embraced. You sell your expertise in setting up, configuring, running and fixing GPL systems. > [snip pros of gcc] > > So it's big, slow and complex, but it's difficult to get away from it! Citation needed. Otherwise FUD. > You also wave goodbye to portability, unless portability means being > able to build on anything that has gcc installed. Clang and Intel provide compatibility with gcc extensions. AFAIU, Microsoft has given up on tracking the C standard. Aside from the Linux kernel, what other software makes heavy use of gcc extensions? EOT
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-25 11:34 +0100 |
| Subject | Re: gcc FUD |
| Message-ID | <mmglda$2je$1@dont-email.me> |
| In reply to | #64108 |
On 25/06/2015 08:57, Noob wrote: > On 24/06/2015 10:53, Bartc wrote: > >>>> gcc is a monster that keeps getting bigger - and slower. I'm not >>>> surprised that hundreds of people are needed to keep feeding it. > > [ Typical barely accurate FUD and half-truths ] > > Did you ever consider that it is getting bigger because... > > 1) it supports an increasing number of platforms (mostly embedded) > 2) it supports an increasing number of sophisticated optimization passes > 3) some languages such as C++ are constantly evolving, and compilers > have to support language standards for decades I have two Windows gcc installations: mingw/32-bit (as I found it impossible to install mingw-w64), and TDM/64-bit. The installation of TDM comprises 6100 files and directories, about 375MB. The installation of mingw has 14000 files and directories, some 1200MB. Wow! But I've just realised TDM is short by 8000 files. I haven't missed them so far but should I be worried about it? But if I can lose 8000 files and something still works, how many of the remaining 6000 are actually needed? Is it possible that my Windows installation include support for dozens of different targets? That would be crazy if it was the case. (My own compiler comprises about a dozen files in one directory, and comes to 0.3MB. However it uses a 3rd party assembler and linker, otherwise it might be 1 more file (the compiler would generate object code directly) and be big enough to fill a third of a floppy disk.) > Slower. Slower how? At what setting? Could you /be/ more vague? Execution speed (of the compiler) is not that terrible, however it is decidedly sluggish. Other C compilers are up to 4 times as fast; Clang however was 40% slower than gcc! (On my machine gcc compiles at around 3000 lines per second on one test compiling a dozen files. My own compiler runs at about 5000 lines/second, but is hampered (1) by using a slow external assembler (Nasm); (2) by /being interpreted/!) This is with gcc -O0; at -03, gcc reduces to 2000 lines per second.) > And maybe you're right. Maybe there's a regression or three. > Or maybe the set of default options was changed. But why should > anyone take your word for it? > > Also, I am quite sure there are not "hundreds of people" working > on gcc full time. > >>> customizing GCC is likely a big pain, whereas a smaller compiler could >>> likely be tweaked a little easier. >> >> I think that's where compilers such as lccwin come in. > > FFS, does JN need an impresario, now? > >> I wouldn't know where to start with gcc. Forget customising, how do you >> even build it to work normally when it's outside its comfort zone (ie. >> Linux)? > > So, because YOU don't know where to start means it must be too > complex a task? I've just download the gcc sources again (it only took ten minutes to locate them because the links kept going around in circles, like everything to do with gcc on the web). The sources are 94,000 files and directories. 80,000 files in 14,000 directories, which are astronomical figures. If you think that's not complex, then I wouldn't like to know what you /do/ consider complex! (/My/ sources are a couple of dozen files in one directory.) >> So it's big, slow and complex, but it's difficult to get away from it! > > Citation needed. Otherwise FUD. No citation necessary. The figures speak for themselves. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-25 13:11 +0200 |
| Subject | Re: gcc FUD |
| Message-ID | <mmgnj1$9k5$1@dont-email.me> |
| In reply to | #64113 |
On 25/06/15 12:34, Bartc wrote: > I've just download the gcc sources again (it only took ten minutes to > locate them because the links kept going around in circles, like > everything to do with gcc on the web). > > The sources are 94,000 files and directories. 80,000 files in 14,000 > directories, which are astronomical figures. > Something like 50K of these files are in the test suite. How comprehensive is /your/ automatic test suite? And remember, the sources support some 30-odd targets and a range of languages (C, C++, Objective C, Objective C++, Java, Go, Fortran, Ada). As for installation directories, a quick check on my system shows my gcc for ARM at around 5.5K files, gcc 4.9 native (Linux) at 5.8K files, and for comparison, Freescale Code Warrior for the PPC microcontrollers is at about 25K files. Of course, these include not just the compiler itself, but a variety of libraries (both as part of the compiler, and target libraries), linker files, include files, documentation, etc. gcc installations also typically include support for C++ as well as C, and a variety of other utilities for profiling, code coverage, object file manipulation, debuggers, etc. The sizes here are big - gcc is not a small or simple project by any reckoning. But comparing it to your compiler is not just an apples-to-oranges comparison, it is a an apples to a farming community comparison.
[toc] | [prev] | [next] | [standalone]
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web