Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #106884 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2017-03-24 11:25 +0100 |
| Last post | 2017-03-30 00:50 -0700 |
| Articles | 20 on this page of 287 — 34 participants |
Back to article view | Back to comp.lang.c
Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 11:25 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 11:04 +0000
Re: Even more problems with lcc-win Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-24 11:44 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 12:59 +0100
Re: Even more problems with lcc-win Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-24 14:06 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 13:01 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 12:39 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 13:17 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 13:38 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 13:50 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 14:06 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 14:20 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 15:49 +0100
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-24 16:35 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 14:51 +0000
Re: Even more problems with lcc-win Noob <root@127.0.0.1> - 2017-03-24 23:36 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 15:43 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 17:57 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 18:13 +0000
Re: Even more problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-24 18:32 +0000
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-24 12:11 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 19:56 +0000
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-24 13:48 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 21:17 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 22:40 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 21:56 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 01:14 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 01:19 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 01:30 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-25 12:46 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 20:10 +0000
Re: Even more problems with lcc-win gordonb.l3ybu@burditt.org (Gordon Burditt) - 2017-03-27 03:34 -0500
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-27 11:41 +0100
Re: Even more problems with lcc-win gordonb.15yss@burditt.org (Gordon Burditt) - 2017-03-27 14:48 -0500
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-27 13:31 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-27 22:22 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-27 15:05 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-27 23:22 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-28 00:35 +0200
Re: Even more problems with lcc-win Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-16 19:09 -0700
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-21 21:01 +0200
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-21 12:33 -0700
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-21 21:44 +0200
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-21 13:37 -0700
Re: Even more problems with lcc-win Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 13:03 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-21 13:15 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-21 13:35 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-21 15:30 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-04-21 18:44 -0500
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-22 21:08 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-23 10:26 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-23 19:08 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-23 14:26 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-23 16:52 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-23 16:31 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-23 20:42 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-23 22:32 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-04-24 13:37 +0000
Re: Even more problems with lcc-win Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 07:13 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-27 07:54 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-04-27 18:20 -0500
Re: Even more problems with lcc-win Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 14:23 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-30 18:18 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 12:12 -0500
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-05-01 11:14 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 13:29 -0500
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-27 16:00 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-28 13:24 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 15:20 +0200
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 16:50 +0100
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-28 09:28 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 19:45 +0100
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-28 12:06 -0700
Re: Even more problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-28 20:14 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 20:24 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 21:33 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-28 13:10 -0700
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 22:15 +0200
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 13:23 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 21:29 +0200
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 20:47 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 22:46 +0200
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 23:46 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-29 00:53 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 02:00 +0100
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-29 05:05 -0700
Re: Even more problems with lcc-win "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-29 10:57 -0400
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-29 17:06 +0200
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-29 08:39 -0700
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-30 18:29 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-28 23:44 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 12:33 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 08:54 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 17:38 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 16:42 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 10:28 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 20:09 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 13:29 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 13:18 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-30 08:22 -0700
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-30 00:20 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 15:38 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 13:19 +0000
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-28 18:29 -0500
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-29 01:36 +0200
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-29 22:36 +0200
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-29 23:50 +0200
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-30 10:57 +1300
Re: Even more problems with lcc-win David Kleinecke <dkleinecke@gmail.com> - 2017-03-29 15:10 -0700
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-30 11:15 +1300
Re: Even more problems with lcc-win David Kleinecke <dkleinecke@gmail.com> - 2017-03-30 09:22 -0700
Re: Even more problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-30 18:50 +0200
Re: Even more problems with lcc-win David Kleinecke <dkleinecke@gmail.com> - 2017-03-31 09:31 -0700
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 10:26 +0200
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 13:23 +0000
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 12:01 -0500
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-02 13:51 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-02 23:04 +0200
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-03 17:45 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-03 22:09 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 23:24 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 15:52 -0700
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-30 12:26 +1300
Re: Even more problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-30 12:00 +0200
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 12:43 +0200
Re: Even more problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-30 13:38 +0200
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-30 14:21 +0200
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-31 04:30 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-31 09:39 +0200
Re: Even more problems with lcc-win jadill33@gmail.com - 2017-03-30 07:12 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 12:10 -0500
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 13:25 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 14:55 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-29 16:11 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 16:40 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-29 18:14 +0200
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-30 18:32 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 20:53 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-21 00:36 +0100
Re: Even more problems with lcc-win Thiago Adams <thiago.adams@gmail.com> - 2017-04-24 05:41 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-24 15:14 +0100
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-04-26 14:02 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-26 16:04 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-27 12:24 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-27 14:43 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-29 23:21 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 23:58 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 11:10 +0200
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-30 00:09 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 01:51 +0100
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-30 01:58 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 12:24 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 14:29 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 14:36 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 16:23 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-01 11:59 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-01 14:41 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-03 11:08 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-03 12:02 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-03 14:32 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-03 14:40 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-03 16:47 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 16:56 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 18:06 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-07 20:02 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 19:49 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-08 13:26 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-08 13:33 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-08 16:27 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-08 22:28 +0100
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-04-09 13:54 +1200
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-04-09 07:55 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-09 10:24 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-09 10:45 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-09 10:53 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-09 14:03 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-10 16:17 -0700
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-14 10:24 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-14 12:29 -0700
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-09 13:04 +0000
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-04-08 14:13 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-08 14:33 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-08 07:36 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-08 10:22 +0100
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-07 11:11 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 19:28 +0100
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-07 11:44 -0700
Re: Even more problems with lcc-win jameskuyper@verizon.net - 2017-04-08 08:00 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 12:29 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-07 13:46 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 14:10 +0100
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-30 21:59 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-31 00:19 +0100
Re: Even more problems with lcc-win me <crisdunbar@gmail.com> - 2017-03-30 17:53 -0700
Re: Even more problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-31 11:34 +0200
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 12:35 +0200
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-30 04:38 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 13:14 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 14:38 +0200
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-31 08:52 +1300
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-02 13:58 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-02 17:02 +0200
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-03 17:50 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-03 23:10 +0200
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-04-03 07:20 +1200
Optimized? (Was: Even more problems with lcc-win) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-02 19:39 +0000
Re: Even more problems with lcc-win "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-02 15:59 -0400
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-02 14:11 -0700
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-04-03 17:08 +1200
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-04-03 13:42 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 13:06 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 14:58 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 14:50 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 16:27 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 16:57 +0100
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-30 14:31 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-28 15:54 -0500
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-28 08:07 -0700
Re: Even more problems with lcc-win gordonb.uls6t@burditt.org (Gordon Burditt) - 2017-03-29 18:17 -0500
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 19:20 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 18:49 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 20:07 +0100
Re: Even more problems with lcc-win gordonb.b709o@burditt.org (Gordon Burditt) - 2017-04-16 03:45 -0500
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-16 16:34 +0100
Re: Even more problems with lcc-win Noob <root@127.0.0.1> - 2017-04-16 20:27 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-16 12:16 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-04-17 02:29 -0500
Re: Even more problems with lcc-win Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-27 19:01 -0400
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-03-25 21:45 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 23:19 +0100
Re: Even more problems with lcc-win "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-25 19:10 -0400
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-26 00:54 +0100
Re: Even more problems with lcc-win jameskuyper@verizon.net - 2017-03-25 19:48 -0700
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-26 05:12 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-26 14:00 -0700
Re: Even more problems with lcc-win gordonb.zdxct@burditt.org (Gordon Burditt) - 2017-03-27 02:03 -0500
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-24 22:39 -0500
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 09:13 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 11:24 +0000
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-26 08:42 +1300
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 19:51 +0000
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-26 09:10 +1300
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 20:24 +0000
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-25 13:43 -0700
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-26 10:30 +1300
Re: Even more problems with lcc-win Jean-Marc Bourguet <jm@bourguet.org> - 2017-03-26 10:23 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-24 15:08 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 22:43 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-24 15:55 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-24 16:27 -0700
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 01:17 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 01:18 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 15:06 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-27 16:37 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 16:25 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 17:57 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-27 19:12 +0100
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 14:19 -0500
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 19:25 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-24 08:10 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 13:01 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 15:50 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 13:07 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 15:48 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 16:26 +0100
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-24 16:32 +0000
Re: Even more problems with lcc-win James Kuyper <jameskuyper@verizon.net> - 2017-03-24 12:53 -0400
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 18:24 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 17:29 +0000
Re: Even more problems with lcc-win jameskuyper@verizon.net - 2017-03-24 10:55 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-24 10:47 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-24 09:37 -0700
Re: Even more problems with lcc-win Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:07 -0500
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-29 09:56 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 10:39 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-29 12:22 -0700
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-29 15:10 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-29 16:58 -0700
Re: Even more problems with Seed7 jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-30 01:02 +0200
Re: Even more problems with Seed7 Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 01:05 -0500
Re: Even more problems with Seed7 Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 01:19 -0500
Re: Even more problems with Seed7 mertesthomas@gmail.com - 2017-04-02 04:19 -0700
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-30 00:34 -0700
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 13:05 +0200
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-31 00:00 +0200
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-04-02 00:28 -0700
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-30 00:50 -0700
Page 1 of 15 [1] 2 3 … 15 Next page →
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-24 11:25 +0100 |
| Subject | Even more problems with lcc-win |
| Message-ID | <ob2s0r$nl7$1@dont-email.me> |
Hi I am starting to get results with my ARM64 port. lcc-win is compiling big programs now, without any problems... The acid test is to compile the compiler with itself. To do that, I need to parse the includes furnished by the linux system/gcc. There is a confusing mixture of include files in /usr/include, /usr/include/aarch64/bits, /usr/local/include/aarch64, and a LONG list of "places" where includes with the same name are stored. Which one should I use? How could I figure out which ones are used by gcc? To avoid these problems, I decided to move the includes I am using from windows to linux, but that would mean that I port my standard C library into linux, not an easy task, specially because the source code is 100% adapted to lcc and not easily used by other compilers, and that could introduce a new set of bugs! Besides, this produces binary incompatibilities between the generated code and what the functions in the library expect, even more trouble... So, I have no other choice than to parse include files full of "gccisms" and to make that work, and that starts with figuring out WHICH include files should I use, hence my question in the subject line. The standard is silent on this subject, not even specifying a common command that all compilers could support, telling the user how the search paths are built.
[toc] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-24 11:04 +0000 |
| Message-ID | <ob2u9s$v2s$1@dont-email.me> |
| In reply to | #106884 |
On 24/03/2017 10:25, jacobnavia wrote:
> Hi
>
> I am starting to get results with my ARM64 port. lcc-win is compiling
> big programs now, without any problems...
>
> The acid test is to compile the compiler with itself. To do that, I need
> to parse the includes furnished by the linux system/gcc. There is a
> confusing mixture of include files in
> /usr/include,
> /usr/include/aarch64/bits,
> /usr/local/include/aarch64,
>
> and a LONG list of "places" where includes with the same name are stored.
>
> Which one should I use? How could I figure out which ones are used by gcc?
>
> To avoid these problems, I decided to move the includes I am using from
> windows to linux, but that would mean that I port my standard C library
> into linux, not an easy task, specially because the source code is 100%
> adapted to lcc and not easily used by other compilers, and that could
> introduce a new set of bugs!
>
> Besides, this produces binary incompatibilities between the generated
> code and what the functions in the library expect, even more trouble...
>
> So, I have no other choice than to parse include files full of "gccisms"
> and to make that work, and that starts with figuring out WHICH include
> files should I use, hence my question in the subject line.
I found exactly the same set of problems [with my experimental C
compiler that was supposed to be OS-agnostic]. Programs that also
compile under Window with other than gcc are good candidates. Programs
that expect to compile under Linux tend to be full of gcc dependencies.
As I said elsewhere, it's hard to prise gcc and Linux apart. (Just
yesterday I had to try and compile code - on Windows this time - full of
'__builtin_expect(x,y)'. __builtin_expect is a gcc thing.)
I would also, if trying to compile for Linux, need to provide a private
set of headers. But if a program uses /and depends/ on
__builtin_whatever, that won't help. FWIW, initial experiments used gcc
headers in these paths:
"/usr/lib/gcc/x86_64-linux-gnu/6/include/"
"/usr/lib/gcc/x86_64-linux-gnu/bits/"
"/usr/include/"
However, gcc headers seem to be full of special features such as inline
assembly code, as well being huge. Programs using standard headers from
here also seem to involve twice as many include files as the equivalents
under Windows. Linux system headers seem to be a huge ugly mess.
> The standard is silent on this subject, not even specifying a common
> command that all compilers could support, telling the user how the
> search paths are built.
I think this is up to the implementation. Except that on Linux, I don't
know to what extent implementations can do their own thing, if the
interface to the OS - via some C libraries - is defined through headers
in /usr/include.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-03-24 11:44 +0000 |
| Message-ID | <87vaqyvqzb.fsf@bsb.me.uk> |
| In reply to | #106886 |
BartC <bc@freeuk.com> writes: <snip> > As I said elsewhere, it's hard to prise gcc and Linux apart. (Just > yesterday I had to try and compile code - on Windows this time - full > of '__builtin_expect(x,y)'. __builtin_expect is a gcc thing.) Why do you think __builtin_expect is a Linux thing? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-24 12:59 +0100 |
| Message-ID | <ob31hc$9hb$1@dont-email.me> |
| In reply to | #106891 |
Le 24/03/2017 à 12:44, Ben Bacarisse a écrit : > BartC <bc@freeuk.com> writes: > <snip> >> As I said elsewhere, it's hard to prise gcc and Linux apart. (Just >> yesterday I had to try and compile code - on Windows this time - full >> of '__builtin_expect(x,y)'. __builtin_expect is a gcc thing.) > > Why do you think __builtin_expect is a Linux thing? > > <snip> > He doesn't. He said: "__builtin_expect is a gcc thing". Just read what you quoted!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-03-24 14:06 +0000 |
| Message-ID | <87k27evkf4.fsf@bsb.me.uk> |
| In reply to | #106894 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 24/03/2017 à 12:44, Ben Bacarisse a écrit : >> BartC <bc@freeuk.com> writes: >> <snip> >>> As I said elsewhere, it's hard to prise gcc and Linux apart. (Just >>> yesterday I had to try and compile code - on Windows this time - full >>> of '__builtin_expect(x,y)'. __builtin_expect is a gcc thing.) >> >> Why do you think __builtin_expect is a Linux thing? >> >> <snip> > > He doesn't. He said: "__builtin_expect is a gcc thing". Just read what > you quoted! Yes, I too can read, but the paragraph was about the the fact that gcc and Linux can't be separated. A parenthetical remark after such a statement would be expected to offer support, evidence or examples related to it. It reads "a gcc thing" that is example of how you can't "prise gcc and Linux apart". -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-24 13:01 +0100 |
| Message-ID | <ob31kd$abf$1@dont-email.me> |
| In reply to | #106891 |
On 24/03/17 12:44, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > <snip> >> As I said elsewhere, it's hard to prise gcc and Linux apart. (Just >> yesterday I had to try and compile code - on Windows this time - full >> of '__builtin_expect(x,y)'. __builtin_expect is a gcc thing.) > > Why do you think __builtin_expect is a Linux thing? > He doesn't know what it does, but deep down he knows it is probably useful, documented in the obvious place (compiler builtins for gcc are documented in the gcc manual, in the chapter called "builtins"), and easily found using Google. That applies to pretty much everything he has trouble with in Linux. Therefore, __builtin_expect must be a "linuxy thing".
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-24 12:39 +0000 |
| Message-ID | <ob33s0$iib$1@dont-email.me> |
| In reply to | #106895 |
On 24/03/2017 12:01, David Brown wrote: > On 24/03/17 12:44, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> <snip> >>> As I said elsewhere, it's hard to prise gcc and Linux apart. (Just >>> yesterday I had to try and compile code - on Windows this time - full >>> of '__builtin_expect(x,y)'. __builtin_expect is a gcc thing.) >> >> Why do you think __builtin_expect is a Linux thing? >> > > He doesn't know what it does, but deep down he knows it is probably > useful, No, really it isn't. Not when you're trying to write code where you let the compiler get on with /its/ job and you get on with yours. __builtin_expect is something to do with you telling the compiler whether you think some particular expression is more likely to be true than false, or something along those lines. You don't want stuff like that cluttering up your code. If you're going to those lengths, then you might as well write assembly code. In this case, all I needed to know was whether a dummy macro for __builtin_expect should be empty, or return some value, to order to get around a stalled compile. But typical gcc and/or Linux code (that is, code using Linux headers) is just chock-full of this stuff. A Linux system header includes another, and that includes another, and that includes... it just goes on and on. (Why do I care? Because when duplicating those headers under Windows for easier development, I have to scour the Linux system for all those dependent headers! Apparently in Linux they're not allowed to be all in one place.) documented in the obvious place (compiler builtins for gcc are > documented in the gcc manual, in the chapter called "builtins"), and > easily found using Google. That applies to pretty much everything he > has trouble with in Linux. Therefore, __builtin_expect must be a > "linuxy thing". Linux system headers are more complicated that the equivalent under Windows, even using gcc. Fact. A program containing 20 standard includes will end up fetching 20-30 headers on Windows, apart from gcc, where 40 headers are required (and much bigger ones too). The same program using Linux headers will fetch 80 includes. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-24 13:17 +0000 |
| Message-ID | <P%8BA.31843$yo7.2575@fx16.iad> |
| In reply to | #106900 |
BartC <bc@freeuk.com> writes: >On 24/03/2017 12:01, David Brown wrote: >> He doesn't know what it does, but deep down he knows it is probably >> useful, > >No, really it isn't. Not when you're trying to write code where you let >the compiler get on with /its/ job and you get on with yours. > >__builtin_expect is something to do with you telling the compiler >whether you think some particular expression is more likely to be true >than false, or something along those lines. > >You don't want stuff like that cluttering up your code. If you're going >to those lengths, then you might as well write assembly code. Pure nonsense. Having used this extensively in multiple codebases (operating systems, hypervisors, functional models) encompassing hundreds of thousands of lines of C-code, the idea that all that code would be better off written in Assembler is just plain nonsense. > >In this case, all I needed to know was whether a dummy macro for >__builtin_expect should be empty, or return some value, to order to get >around a stalled compile. > >But typical gcc and/or Linux code (that is, code using Linux headers) is >just chock-full of this stuff. A Linux system header includes another, >and that includes another, and that includes... it just goes on and on. > >(Why do I care? Because when duplicating those headers under Windows for >easier development, I have to scour the Linux system for all those >dependent headers! Apparently in Linux they're not allowed to be all in >one place.) It doesn't make _sense_ to put them all in one place. Some are provided by the compiler (portland, intel or gcc); some are provided by the kernel and some are provided by the distribution, with a fair division. >Linux system headers are more complicated that the equivalent under Linux is a far more capable system than Windows, one which supports literally dozens of dissimilar architectures.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-24 13:38 +0000 |
| Message-ID | <ob37ag$ubv$1@dont-email.me> |
| In reply to | #106902 |
On 24/03/2017 13:17, Scott Lurndal wrote: > BartC <bc@freeuk.com> writes: >> Linux system headers are more complicated that the equivalent under > > Linux is a far more capable system than Windows, one which supports > literally dozens of dissimilar architectures. I'm talking about standard headers for C, a language. Besides, a particular set of headers, if it does depends on a particular architecture, should only concern itself with one. If I compile hello.c using lccwin's headers, I get this trace: INCLUDE stdio.h FROM hello.c 2 INCLUDE safelib.h FROM c:/lcc64/include/stdio.h 158 INCLUDE _syslist.h FROM c:/lcc64/include/stdio.h 221 If I use a set of headers from Ubuntu, I get this: INCLUDE stdio.h FROM hello.c 2 INCLUDE features.h FROM c:/bcc/include/stdio.h 28 INCLUDE stdc-predef.h FROM c:/bcc/include/features.h 343 INCLUDE sys/cdefs.h FROM c:/bcc/include/features.h 365 INCLUDE bits/wordsize.h FROM c:/bcc/include/sys/cdefs.h 416 INCLUDE gnu/stubs.h FROM c:/bcc/include/features.h 389 INCLUDE gnu/stubs-32.h FROM c:/bcc/include/gnu/stubs.h 8 INCLUDE stddef.h FROM c:/bcc/include/stdio.h 34 INCLUDE bits/types.h FROM c:/bcc/include/stdio.h 36 INCLUDE features.h FROM bits/types.h 27 INCLUDE bits/wordsize.h FROM bits/types.h 28 INCLUDE bits/typesizes.h FROM bits/types.h 122 INCLUDE libio.h FROM c:/bcc/include/stdio.h 75 INCLUDE _G_config.h FROM c:/bcc/include/libio.h 32 INCLUDE bits/types.h FROM c:/bcc/include/_G_config.h 10 INCLUDE stddef.h FROM c:/bcc/include/_G_config.h 16 INCLUDE wchar.h FROM c:/bcc/include/_G_config.h 21 INCLUDE stddef.h FROM c:/bcc/include/wchar.h 52 INCLUDE stdarg.h FROM c:/bcc/include/libio.h 50 INCLUDE stdarg.h FROM c:/bcc/include/stdio.h 84 INCLUDE bits/stdio_lim.h FROM c:/bcc/include/stdio.h 167 INCLUDE bits/sys_errlist.h FROM c:/bcc/include/stdio.h 856 A little bit different. While my own early headers give: INCLUDE stdio.h FROM hello.c 2 INCLUDE stddef.h FROM ./headers/stdio.h 7 My first thought here was that it's pity it's showing two headers rather than just stdio.h; what can I do to simplify it? (stddef.h defines size_t) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-24 13:50 +0000 |
| Message-ID | <Ju9BA.93705$mb5.47190@fx19.iad> |
| In reply to | #106906 |
BartC <bc@freeuk.com> writes: >On 24/03/2017 13:17, Scott Lurndal wrote: >> BartC <bc@freeuk.com> writes: > >>> Linux system headers are more complicated that the equivalent under >> >> Linux is a far more capable system than Windows, one which supports >> literally dozens of dissimilar architectures. > >I'm talking about standard headers for C, a language. For which the programmer uses the standard names and the C language itself makes no requirements on the implementation other than to correctly respond to '#include <ctype.h>'. An implementation is free to store the headers in any fashion it pleases - an implementation may not even have a file system. > >Besides, a particular set of headers, if it does depends on a particular >architecture, should only concern itself with one. > >If I compile hello.c using lccwin's headers, I get this trace: > >INCLUDE stdio.h FROM hello.c 2 >INCLUDE safelib.h FROM c:/lcc64/include/stdio.h 158 >INCLUDE _syslist.h FROM c:/lcc64/include/stdio.h 221 > >If I use a set of headers from Ubuntu, I get this > >INCLUDE stdio.h FROM hello.c 2 >INCLUDE features.h FROM c:/bcc/include/stdio.h 28 >INCLUDE stdc-predef.h FROM c:/bcc/include/features.h 343 >INCLUDE sys/cdefs.h FROM c:/bcc/include/features.h 365 >INCLUDE bits/wordsize.h FROM c:/bcc/include/sys/cdefs.h 416 >INCLUDE gnu/stubs.h FROM c:/bcc/include/features.h 389 >INCLUDE gnu/stubs-32.h FROM c:/bcc/include/gnu/stubs.h 8 >INCLUDE stddef.h FROM c:/bcc/include/stdio.h 34 >INCLUDE bits/types.h FROM c:/bcc/include/stdio.h 36 >INCLUDE features.h FROM bits/types.h 27 >INCLUDE bits/wordsize.h FROM bits/types.h 28 >INCLUDE bits/typesizes.h FROM bits/types.h 122 >INCLUDE libio.h FROM c:/bcc/include/stdio.h 75 >INCLUDE _G_config.h FROM c:/bcc/include/libio.h 32 >INCLUDE bits/types.h FROM c:/bcc/include/_G_config.h 10 >INCLUDE stddef.h FROM c:/bcc/include/_G_config.h 16 >INCLUDE wchar.h FROM c:/bcc/include/_G_config.h 21 >INCLUDE stddef.h FROM c:/bcc/include/wchar.h 52 >INCLUDE stdarg.h FROM c:/bcc/include/libio.h 50 >INCLUDE stdarg.h FROM c:/bcc/include/stdio.h 84 >INCLUDE bits/stdio_lim.h FROM c:/bcc/include/stdio.h 167 >INCLUDE bits/sys_errlist.h FROM c:/bcc/include/stdio.h 856 > >A little bit different. Why would any C programmer care? You omitted the justification for the linux arrangement from the quoted article above.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-24 14:06 +0000 |
| Message-ID | <ob390g$4nn$1@dont-email.me> |
| In reply to | #106907 |
On 24/03/2017 13:50, Scott Lurndal wrote:
> BartC <bc@freeuk.com> writes:
>> A little bit different.
>
> Why would any C programmer care?
I think you've just explained it all. After all what does it matter if
these system headers - on which so many things depend - are a huge,
ugly, bloated unmaintainable mess?
> You omitted the justification for the linux arrangement from the quoted article above.
The test program was Hello World, which only needs the declaration for
printf. It could also be written like this:
int printf(char*, ...);
int main (void) {printf("Hello, World!\n");}
Amazingly, barring typos above, it will still work, and without needing
to pre-process 5000 lines of gobbledygook.
But feel free to explain what all that extra stuff adds to this program.
A shared library somewhere exports printf(), and a C source file wants
to use it. In between should be a header giving the function signature
of printf. That is all that is needed.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-24 14:20 +0000 |
| Message-ID | <GW9BA.166545$ff2.63949@fx41.iad> |
| In reply to | #106913 |
BartC <bc@freeuk.com> writes: >On 24/03/2017 13:50, Scott Lurndal wrote: >> BartC <bc@freeuk.com> writes: > >>> A little bit different. >> >> Why would any C programmer care? > >I think you've just explained it all. After all what does it matter if >these system headers - on which so many things depend - are a huge, >ugly, bloated unmaintainable mess? Again, tell me why a C programmer would care?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-24 15:49 +0100 |
| Message-ID | <ob3bh7$dtk$1@dont-email.me> |
| In reply to | #106914 |
On 24/03/17 15:20, Scott Lurndal wrote: > BartC <bc@freeuk.com> writes: >> On 24/03/2017 13:50, Scott Lurndal wrote: >>> BartC <bc@freeuk.com> writes: >> >>>> A little bit different. >>> >>> Why would any C programmer care? >> >> I think you've just explained it all. After all what does it matter if >> these system headers - on which so many things depend - are a huge, >> ugly, bloated unmaintainable mess? > > Again, tell me why a C programmer would care? > Also, why would you (Bart) think that the Linux system is unmaintainable? In reality, a key motivation for all these headers is that it /is/ maintainable. It means that if the folks maintaining the MIPS port of Linux change something in their headers, the C library automatically gets the benefit of the change - without the C library people needing to do anything, including test on a MIPS machine. And when the gcc folk added support for C11 to their headers, they did not need to co-ordinate with the makers of a dozen different C libraries or the maintainers of three dozen Linux ports - they make the change in /their/ headers, and anyone with that version of gcc gets the benefits. With your little Windows compilers, if MS adds new features to their API, you need to change your compilers' headers and libraries to match - /that/ is the maintenance nightmare.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-03-24 16:35 +0000 |
| Message-ID | <874lyi63b2.fsf@gmail.com> |
| In reply to | #106923 |
David Brown <david.brown@hesbynett.no> writes: > On 24/03/17 15:20, Scott Lurndal wrote: >> BartC <bc@freeuk.com> writes: >>> On 24/03/2017 13:50, Scott Lurndal wrote: >>>> BartC <bc@freeuk.com> writes: >>> >>>>> A little bit different. >>>> >>>> Why would any C programmer care? >>> >>> I think you've just explained it all. After all what does it matter if >>> these system headers - on which so many things depend - are a huge, >>> ugly, bloated unmaintainable mess? >> >> Again, tell me why a C programmer would care? >> > > Also, why would you (Bart) think that the Linux system is unmaintainable? This is a man who claims he is writing a C compiler, and then asks questions about aliasing in the Standard so trivial that even I can answer them. The working of his mind is not something that mortals should ponder.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-24 14:51 +0000 |
| Message-ID | <ob3bk4$e95$1@dont-email.me> |
| In reply to | #106914 |
On 24/03/2017 14:20, Scott Lurndal wrote: > BartC <bc@freeuk.com> writes: >> On 24/03/2017 13:50, Scott Lurndal wrote: >>> BartC <bc@freeuk.com> writes: >> >>>> A little bit different. >>> >>> Why would any C programmer care? >> >> I think you've just explained it all. After all what does it matter if >> these system headers - on which so many things depend - are a huge, >> ugly, bloated unmaintainable mess? > > Again, tell me why a C programmer would care? > Well, they might care when things go wrong and they have to delve into the implementation headers to find out why. The might care if they know that their code compiles on a wing and a prayer, dependent on some very hairy sets of declarations. They might care if they inadvertently use gcc or Linux dependencies, if they want their code to compile on anything else (there's a dirent.h or unistd.h for example). Or if they actually make use of, in user code, of some of those extra definitions in you find in Linux headers that don't exist elsewhere. (And if they don't make use of them, then what's the point.) Or they might just care if they have any sort of pride in their language and how it's used. A lot of what I've seen is just abuse of it. (I've compiled one of my projects, a 32Kloc interpreter when expressed as C source. Compiled with gcc/Windows headers, an extra 20Kloc of headers are processed. With lccwin headers, it's about 1.5Kloc. With my own early headers, it only needs about 150 lines of declarations. I haven't tried it on Linux headers, as it stalls at some point. Looking at it, the problem is in stdargs.h, which is not standard Linux, but from its gcc. I can't compile gcc's stdargs.h because it uses gcc-specific features. I need to provide my own stdargs.h at some point. However, there is no reason to do it now because my project DOESN'T USE STDARG.H! But it must get included from another header.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-03-24 23:36 +0100 |
| Message-ID | <ob46rv$fm1$1@dont-email.me> |
| In reply to | #106925 |
On 24/03/2017 15:51, BartC wrote: > They might care if they inadvertently use gcc or Linux dependencies, if > they want their code to compile on anything else (there's a dirent.h or > unistd.h for example). gcc -std=c11 -Wall -pedantic -pedantic-errors would catch most inadvertent uses of gcc extensions. As for "Linux dependencies", you are confusing POSIX/SUS, glibc, and the kernel proper, which is standard fare for you.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-24 15:43 +0100 |
| Message-ID | <ob3b4m$ce7$1@dont-email.me> |
| In reply to | #106900 |
On 24/03/17 13:39, BartC wrote: > On 24/03/2017 12:01, David Brown wrote: >> On 24/03/17 12:44, Ben Bacarisse wrote: >>> BartC <bc@freeuk.com> writes: >>> <snip> >>>> As I said elsewhere, it's hard to prise gcc and Linux apart. (Just >>>> yesterday I had to try and compile code - on Windows this time - full >>>> of '__builtin_expect(x,y)'. __builtin_expect is a gcc thing.) >>> >>> Why do you think __builtin_expect is a Linux thing? >>> >> >> He doesn't know what it does, but deep down he knows it is probably >> useful, > > No, really it isn't. Not when you're trying to write code where you let > the compiler get on with /its/ job and you get on with yours. > > __builtin_expect is something to do with you telling the compiler > whether you think some particular expression is more likely to be true > than false, or something along those lines. First, read the manual - then you will have some basis for commenting: <https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fexpect> __builtin_expect(x, y) has the value "x", but tells the compiler that "x" is probably equal to "y". A typical use is the Linux macros: #define likely(x) __builtin_expect((x),1) #define unlikely(x) __builtin_expect((x),0) Thus you can write: if (likely(n > 3)) ... and know that the compiler will use branch prediction instructions or optimisation on the assumption that "n > 3" should be the fastest path. > > You don't want stuff like that cluttering up your code. If you're going > to those lengths, then you might as well write assembly code. No, you use features like that specifically so that you /don't/ need to write assembly code - but you can still guide the compiler with the aim of getting the fastest possible code. When you are writing code that should be as fast as you can reasonably make it, and you want it to be portable to a wide range of processors (some of which have static branch prediction bits in their jump instructions), then extensions like this can be useful. You don't "clutter up" your code with such features, but you may use them occasionally. > > In this case, all I needed to know was whether a dummy macro for > __builtin_expect should be empty, or return some value, to order to get > around a stalled compile. And the manual page will give you that information: #define __builtin_expect(x, y) (x) > > But typical gcc and/or Linux code (that is, code using Linux headers) is > just chock-full of this stuff. A Linux system header includes another, > and that includes another, and that includes... it just goes on and on. > > (Why do I care? Because when duplicating those headers under Windows for > easier development, I have to scour the Linux system for all those > dependent headers! Apparently in Linux they're not allowed to be all in > one place.) That is because Linux - like most operating systems except Windows - has system headers to let people write programs for their system. And these system headers are /not/ the same as a compiler's standard headers, and the compiler's standard headers are not the same as the C library's headers. In the Windows world, these are usually thrown together in one lump because the OS does not have standard headers, and because compilers for Windows usually don't have a choice of libraries. > > documented in the obvious place (compiler builtins for gcc are >> documented in the gcc manual, in the chapter called "builtins"), and >> easily found using Google. That applies to pretty much everything he >> has trouble with in Linux. Therefore, __builtin_expect must be a >> "linuxy thing". > > Linux system headers are more complicated that the equivalent under > Windows, even using gcc. Fact. A program containing 20 standard includes > will end up fetching 20-30 headers on Windows, apart from gcc, where 40 > headers are required (and much bigger ones too). > > The same program using Linux headers will fetch 80 includes. > So what? When I use a header, I can't think of any reason to care how many sub-headers are pulled in. The C standards don't define any restrictions here. It makes no difference to /my/ code. System headers are not where I look for information on functions or types, so I don't need to refer to them. If I were making a compiler, I would not care either. If I wanted my compiler to work with implementation-specific headers for a different compiler, then of course I would need to support any extensions used by them. But that's all you need to do - the compiler you are making presumably already supports include files that include other files.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-24 17:57 +0000 |
| Message-ID | <ob3mgd$lj7$1@dont-email.me> |
| In reply to | #106921 |
On 24/03/2017 14:43, David Brown wrote: > On 24/03/17 13:39, BartC wrote: >> __builtin_expect is something to do with you telling the compiler >> whether you think some particular expression is more likely to be true >> than false, or something along those lines. > > First, read the manual - then you will have some basis for commenting: > > <https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fexpect> > > __builtin_expect(x, y) has the value "x", but tells the compiler that > "x" is probably equal to "y". A typical use is the Linux macros: > > #define likely(x) __builtin_expect((x),1) > #define unlikely(x) __builtin_expect((x),0) > > Thus you can write: > > if (likely(n > 3)) ... > > and know that the compiler will use branch prediction instructions or > optimisation on the assumption that "n > 3" should be the fastest path. Suppose you get it wrong? Anyway the real problem is writing things like __builtin_expect(....) all over the place (and dozens of other examples), and then trying to compile it on something that doesn't understand __builtin_expect. I don't want to have implement both C and half of gcc, even if the latter justinvolves having to look all this stuff up and devising a workaround. (I don't know the provenance of this particular set of sources files, and whether they were specifically configured for gcc, or whether they could be configured for anything else. But anything that needs to be configured for specific compilers would ring alarm bells if it will not also work with a generic C compiler.) > #define __builtin_expect(x, y) (x) It's not standard C, so I'm not interested. I just wanted to compile some code not get involved in gcc yet again. > That is because Linux - like most operating systems except Windows - has > system headers to let people write programs for their system. And these > system headers are /not/ the same as a compiler's standard headers, and > the compiler's standard headers are not the same as the C library's > headers. In the Windows world, these are usually thrown together in one > lump because the OS does not have standard headers, and because > compilers for Windows usually don't have a choice of libraries. I'm not talking about OS system headers, but the standard headers from the C standard. For Windows, I plan to use the C library provided in msvcrt.dll. For Linux, I think the equivalent is libc.so.6. The standard headers need to provide function signatures for functions exported from those libraries. Plus define those other entities mentioned in the C standard (NULL for example). There doesn't seem to me to be much to it. Now, to go beyond the C standard library, in Windows a big give-away is the presence of windows.h, which I don't intend to duplicate at the minute (I can borrow one from an existing compiler, but not gcc because it's full of advanced gcc-specific features and is also up to 20 times the size of the smallest). In Linux, it's a bit tricker - perhaps headers such as dirent.h. The dividing line between C functions and OS functions isn't as clear, and people will probably use headers from either without even thinking about it. This is why I'm only bothering with C sources either known to compile on Windows with /any/ compiler, or that are designed to, and do, compile on both OSes. Supporting dirent.h etc can come later, however debugging what goes wrong is hard if the only other compiler I can compare with happens to be gcc. >> The same program using Linux headers will fetch 80 includes. > So what? So 800 would be no problem? What about 8000? We are still talking about STANDARD C. The library isn't that big, but you're not curious as to why Linux and/or gcc make such a meal of it? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-24 18:13 +0000 |
| Message-ID | <AldBA.41789$%b1.36860@fx21.iad> |
| In reply to | #106963 |
BartC <bc@freeuk.com> writes: >On 24/03/2017 14:43, David Brown wrote: >> On 24/03/17 13:39, BartC wrote: > >>> __builtin_expect is something to do with you telling the compiler >>> whether you think some particular expression is more likely to be true >>> than false, or something along those lines. >> >> First, read the manual - then you will have some basis for commenting: >> >> <https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fexpect> >> >> __builtin_expect(x, y) has the value "x", but tells the compiler that >> "x" is probably equal to "y". A typical use is the Linux macros: >> >> #define likely(x) __builtin_expect((x),1) >> #define unlikely(x) __builtin_expect((x),0) >> >> Thus you can write: >> >> if (likely(n > 3)) ... >> >> and know that the compiler will use branch prediction instructions or >> optimisation on the assumption that "n > 3" should be the fastest path. > >Suppose you get it wrong? The code generated by the compiler may not be quite as efficient as it would otherwise be. > >Anyway the real problem is writing things like __builtin_expect(....) >all over the place (and dozens of other examples), and then trying to >compile it on something that doesn't understand __builtin_expect. Well, the documentation for __builtin_expect notes what to do in this case. Which is up to the programmer, not the compiler developer. In other words, don't worry about it, if someone uses your compile to compile code with GNU extensions, that's their problem. >(I don't know the provenance of this particular set of sources files, >and whether they were specifically configured for gcc, or whether they >could be configured for anything else. But anything that needs to be >configured for specific compilers would ring alarm bells if it will not >also work with a generic C compiler.) If the term 'gcc' or 'gnu' is in the path to the header file, you can be sure that it is specific to the gcc compiler. Note that linux supports gcc, clang, portland group compilers and the intel compiler (all at the same time, on the same system) which requires the non-gcc header files to be independent of the compilation suite used. >I'm not talking about OS system headers, but the standard headers from >the C standard. Which are provided by the compiler vendor. > >For Windows, I plan to use the C library provided in msvcrt.dll. For >Linux, I think the equivalent is libc.so.6. There is far more in libc than simply the C standard-defined run-time functions. > >The standard headers need to provide function signatures for functions >exported from those libraries. No, they need to provide function signature for functions defined by the standards. Which library the implementation is located is irrelevent. > Plus define those other entities >mentioned in the C standard (NULL for example). > >There doesn't seem to me to be much to it. Get back to us when you can install, build and use your compiler on dozens of wildly different operating systems. > >In Linux, it's a bit tricker - perhaps headers such as dirent.h. The >dividing line between C functions and OS functions isn't as clear, It's quite clear. Posix incorporates by reference the C standard. > >So 800 would be no problem? What about 8000? We are still talking about >STANDARD C. The library isn't that big, but you're not curious as to why >Linux and/or gcc make such a meal of it? We've told you several times _why_ the header files are arranged as they are on unix/linux systems. You're not listening. Very few _useful_ programs can be built using only STANDARD C functionality.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-24 18:32 +0000 |
| Message-ID | <ob3oj3$t36$1@dont-email.me> |
| In reply to | #106966 |
On 24/03/17 18:13, Scott Lurndal wrote: > Very few _useful_ programs can be built using only STANDARD C > functionality. If you mean strictly conforming programs, I'm inclined to agree. If, however, you mean clc-conforming programs, I would argue that there are infinitely many useful programs that can be built using only standard C functionality. If you allow extensions as well, you get infinitely many /more/. I do very occasionally make use of extensions, but it's surprisingly rare that it's necessary. (On the increasingly rare occasions that I write Windows GUI programs, I decreasingly often use C, since C++ Builder is so much more convenient.) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 1 of 15 [1] 2 3 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web