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 2 of 15 — ← Prev page 1 [2] 3 4 … 15 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-24 12:11 -0700 |
| Message-ID | <lnvaqy8p6s.fsf@kst-u.example.com> |
| In reply to | #106966 |
scott@slp53.sl.home (Scott Lurndal) writes:
> BartC <bc@freeuk.com> writes:
[...]
>>I'm not talking about OS system headers, but the standard headers from
>>the C standard.
>
> Which are provided by the compiler vendor.
Or by a separate library vendor.
[...]
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-24 19:56 +0000 |
| Message-ID | <ob3tfo$ev2$1@dont-email.me> |
| In reply to | #106966 |
On 24/03/2017 18:13, Scott Lurndal wrote: > BartC <bc@freeuk.com> writes: >> (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. stdio.h exists in /usr/include/. There is also a version in /usr/include/x64_64-linux-gnu/bits/ So the OS is providing stdio.h, and gcc tells me that is the one it uses (the bits directory isn't directly specified in the include search path). In the case of clang for Windows, it doesn't provide any headers at all, but expects to use the ones from MSVC (and previously used the ones for gcc/mingw). >> 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. MSVC seems to be rather heavyweight too (see below); how many OSes and platforms does that work with? Anyway I'm not sure why this is relevant: does the definition of printf() differ wildly across OSes? And if there are platform-specific lines, does every copy of every Linux have to contain code for every conceivable platform? Sounds like a 'configure' script is needed - or is this /after/ running it?! Take this program: #include <assert.h> //#include <complex.h> #include <ctype.h> #include <errno.h> #include <fenv.h> #include <float.h> #include <inttypes.h> //#include <iso646.h> #include <limits.h> #include <locale.h> #include <math.h> #include <setjmp.h> #include <signal.h> #include <stdarg.h> #include <stdbool.h> #include <stddef.h> #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <time.h> #include <wchar.h> #include <wctype.h> Preprocessing this requires processing these source lines and involves these total header files, using the following C implementations to provide the files: lccwin 3.3K 24 unique include files Pelles C 3.5K 22 DMC 4.7K 22 Tiny C 11K 31 gcc/Win 27K 44 gcc/Linux 28K 89 Most headers from /usr/include MSVC2008 47K 24 Excludes stdint/inttypes/fenv/stdbool (This old MSVC doesn't support C99 headers.) What does this show? Probably nothing, except that some implementations have more and/or bigger files than others. There's no indication that those extra lines are needed or serve any benefit. Both MS and gcc are worked on by lots of people, presumably none of whom is responsible for taking stuff out, and simplifying. > 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. Yeah, only programs that take input from keyboard and/or file, and write output to screen and/or disk. Which includes C compilers. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-24 13:48 -0700 |
| Message-ID | <lnmvca8kq3.fsf@kst-u.example.com> |
| In reply to | #106997 |
BartC <bc@freeuk.com> writes:
[...]
> stdio.h exists in /usr/include/. There is also a version in
> /usr/include/x64_64-linux-gnu/bits/
It's /usr/include/x86_64-linux-gnu/bits/,
not /usr/include/x64_64-linux-gnu/bits/
But that second one is just another file that happens to have the same
name. On my system, it includes the following lines:
#ifndef _STDIO_H
# error "Never include <bits/stdio.h> directly; use <stdio.h> instead."
#endif
It's an *internal* file, part of the implementation, not something that
any C programmer needs to care about. It doesn't provide, for example,
a declaration of printf, just some low-level declarations that are used
by the real <stdio.h>. Apparently the designers found it useful to use
parallel file names (that directory contains several other files whose
names match those of standard headers).
> So the OS is providing stdio.h, and gcc tells me that is the one it uses
> (the bits directory isn't directly specified in the include search path).
Actually it's provided by the libc6-dev package, at least on my Ubuntu
system -- but I think that package is preinstalled, so you could say
it's provided by the OS.
[...]
> Anyway I'm not sure why this is relevant: does the definition of
> printf() differ wildly across OSes?
(I'm sure you mean the *declaration* of printf.) It doesn't vary a
whole lot, though some systems will probably have to make the "restrict"
optional somehow to allow for pre-C99 compilers.
But the definition of type FILE probably does vary a great deal.
[...]
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-24 21:17 +0000 |
| Message-ID | <ob428f$c2$1@dont-email.me> |
| In reply to | #107000 |
On 24/03/2017 20:48, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
> (I'm sure you mean the *declaration* of printf.) It doesn't vary a
> whole lot, though some systems will probably have to make the "restrict"
> optional somehow to allow for pre-C99 compilers.
>
> But the definition of type FILE probably does vary a great deal.
I tried to have a look, but after several minutes I couldn't even find
what FILE was defined as! They seem intent on making this impenetrable.
I worked out that FILE was an alias for 'struct _IO_FILE', and that that
was probably defined in libio.h.
Oh, hang on, I think I've just found it. _IO_FILE occurs quite a lot in
libio.h. And for good measure, it also defines:
typedef struct _IO_FILE _IO_FILE;
just to keep you on your toes. Here's the version in my fledging stdio.h:
typedef struct {
char *_ptr;
int _cnt;
char *_base;
int _flag;
int _file;
int _charbuf;
int _bufsiz;
char *_tmpfname;
} FILE;
Clearly I have a lot to learn about making it hard to unravel!
But the main requirement is that this struct takes up 48 bytes in 64-bit
Windows (because stdin/out/err are defined as entries in an array of
such structs). So I know now that this won't work under Linux as it is.
I'll have to see how to make that possible without /my/ headers
suffering the same fate of drowning in a sea of macros and conditionals.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-24 22:40 +0100 |
| Message-ID | <ob43jr$51m$1@dont-email.me> |
| In reply to | #107004 |
Le 24/03/2017 à 22:17, BartC a écrit :
> Here's the version in my fledging stdio.h:
>
> typedef struct {
> char *_ptr;
> int _cnt;
> char *_base;
> int _flag;
> int _file;
> int _charbuf;
> int _bufsiz;
> char *_tmpfname;
> } FILE;
>
> Clearly I have a lot to learn about making it hard to unravel!
I have another definition, that's even better:
typedef struct __FILE FILE;
And "struct __FILE" is defined NOWHERE.
Isn't that great?
You just can't access any of the fields of that structure, it is an
opaque structure. This
1) Keeps current practice. I have never seen anyone using any of those
fields directly.
2) It is concise and not at all verbose. Just ONE LINE!
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-24 21:56 +0000 |
| Message-ID | <ob44h7$82q$1@dont-email.me> |
| In reply to | #107007 |
On 24/03/2017 21:40, jacobnavia wrote:
> Le 24/03/2017 à 22:17, BartC a écrit :
>
>> Here's the version in my fledging stdio.h:
>>
>> typedef struct {
>> char *_ptr;
>> int _cnt;
>> char *_base;
>> int _flag;
>> int _file;
>> int _charbuf;
>> int _bufsiz;
>> char *_tmpfname;
>> } FILE;
>>
>> Clearly I have a lot to learn about making it hard to unravel!
>
>
> I have another definition, that's even better:
> typedef struct __FILE FILE;
>
> And "struct __FILE" is defined NOWHERE.
>
> Isn't that great?
>
> You just can't access any of the fields of that structure, it is an
> opaque structure. This
> 1) Keeps current practice. I have never seen anyone using any of those
> fields directly.
> 2) It is concise and not at all verbose. Just ONE LINE!
Well, the contents of the struct don't matter, just the size. So they
could be replaced by char[48] in this case. Except that, if the same
declaration is used for a 32-bit target, the size will then be wrong.
The size is needed, as far as I can make out, in order to properly deal
with the _iob array of FILE exported by msvcrt.dll, or by the exported
_iob_func() function which returns a pointer to that array. This array
gives you stdin, stdout and stderr. (There wasn't any other way of
getting those, last time I asked.)
Of course I could just have the opaque FILE type, and hard-code the _iob
array stride as 48 bytes or whatever it would be for 32-bits. It's
hardly going to change any time soon.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-25 01:14 +0100 |
| Message-ID | <ob4cjc$3mt$1@dont-email.me> |
| In reply to | #107008 |
Le 24/03/2017 à 22:56, BartC a écrit : > Well, the contents of the struct don't matter, just the size. So they > could be replaced by char[48] in this case. Except that, if the same > declaration is used for a 32-bit target, the size will then be wrong. No. We never use the structure directly we use a FILE *. The size of the structure does NOT matter. You see the difference? A file POINTER, pointing to an unknown structure that is returned by fopen, and should be disposed of with fclose. The function fread() uses that pointer, but nowhere are any fields of that pointer specified. That is a slightly different thing as char[48]; All code that follows those rules is portable to any C compiler. And I have never seen any code that doesn't follow those rules. The implementation can add any required fields at any time, without affecting old code that continues to run. New code can use new functionalities that could be added to fopen. For instance opening URLs with it, and abstracting away the network layer. FILE *fopen( URL, "rn|"); This would start reading the URL into disk, determined by NET_BUFSIZ in stdio.h. The optional vertical bar could mean non-locking. A NULL would mean that the host or the network is down. An open connection would have a non NULL result, that can be used by other functions. fread would have the same parameters, as fclose. An easy way to abstract the network into C. the "system" function could use URLs too, by starting a command in a remote machine. Would this be more useful than a new network layer? What was the fate of the proposed network layer some years ago by the C committee?
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-25 01:19 +0000 |
| Message-ID | <ob4gcs$d7m$1@dont-email.me> |
| In reply to | #107020 |
On 25/03/2017 00:14, jacobnavia wrote: > Le 24/03/2017 à 22:56, BartC a écrit : >> Well, the contents of the struct don't matter, just the size. So they >> could be replaced by char[48] in this case. Except that, if the same >> declaration is used for a 32-bit target, the size will then be wrong. > > No. We never use the structure directly we use a FILE *. The size of the > structure does NOT matter. > > You see the difference? The problem is here: extern FILE _iob[]; #define stdin (&_iob[0]) #define stdout (&_iob[1]) #define stderr (&_iob[2]) The array calculation requires the size of FILE to be correct. How do we get the right size of FILE? By creating a struct with the right pattern of members (of size 44 bytes but rounded to 48 - on Win64). However after that has been determined, then the struct can be discarded, an opaque type used for FILE, and a different mechanism used to get the right offsets from _iob. But since the FILE struct already exists, it might as well stay. (The above is for Windows; in Linux, stdout for example is defined as a pointer to FILE (or struct _IO_FILE). Hopefully these reside in the C library and have already been initialised, and don't require initialisation code to be be invoked by my program, as I have no idea how to do that. But, I plan to access stdout etc via dynamic linking. It's not clear whether the resulting values even belong to my process. A test using dynamic access to _iob worked in Windows; a similar test under Linux failed. This might be a bit of a stumbling block...) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-25 01:30 +0000 |
| Message-ID | <ob4h1j$elu$1@dont-email.me> |
| In reply to | #107027 |
On 25/03/2017 01:19, BartC wrote: > (The above is for Windows; in Linux, stdout for example is defined as a > pointer to FILE (or struct _IO_FILE). Hopefully these reside in the C > library and have already been initialised, and don't require > initialisation code to be be invoked by my program, as I have no idea > how to do that. > > But, I plan to access stdout etc via dynamic linking. It's not clear > whether the resulting values even belong to my process. A test using > dynamic access to _iob worked in Windows; a similar test under Linux > failed. This might be a bit of a stumbling block...) I've got it to work, for the time being. The value returned by dlsym(lib,"stdout") is a pointer to stdout, not stdout itself. It seems to work either with fputs directly (belonging to the current process), or a fputs obtained via dlsym().
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-25 12:46 -0700 |
| Message-ID | <b5af9adb-ca91-474d-8b5b-029d8592ff00@googlegroups.com> |
| In reply to | #107027 |
On Friday, March 24, 2017 at 8:19:15 PM UTC-5, Bart wrote:
> On 25/03/2017 00:14, jacobnavia wrote:
> The problem is here:
>
> extern FILE _iob[];
>
> #define stdin (&_iob[0])
> #define stdout (&_iob[1])
> #define stderr (&_iob[2])
If stdio.h defines stdin etc. in those ways, it will need to know the size
of the objects in question. Likewise, if an implementation were to say
inline int getc(FILE * restrict f)
{
if (f->simpleGetPtr)
{
f->simpleGetsLeft--;
return *f->simpleGetPtr;
}
else
return __do_getc(f);
}
it would need to have the complete definition of FILE available to fetch
those fields. Headers like <stdio.h> are expected to have aspects which are
customized to fit the underlying library implementation. They're not
required to do so, but performance can be improved when they are [e.g. a
compiler might be able to optimize a loop which calls getc() multiple times
so that it can process up to f->simpleGetsLeft characters at once].
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-25 20:10 +0000 |
| Message-ID | <ob6imq$2e1$1@dont-email.me> |
| In reply to | #107057 |
On 25/03/2017 19:46, supercat@casperkitty.com wrote: > On Friday, March 24, 2017 at 8:19:15 PM UTC-5, Bart wrote: >> On 25/03/2017 00:14, jacobnavia wrote: >> The problem is here: >> >> extern FILE _iob[]; >> >> #define stdin (&_iob[0]) >> #define stdout (&_iob[1]) >> #define stderr (&_iob[2]) > > If stdio.h defines stdin etc. in those ways, it will need to know the size > of the objects in question. It's determined by the library. For MSVCRT.DLL, the only way I've found is to somehow obtain the address of the _iob array which is apparently a set of FILE structs. Alternatively the implementation could decide to do things entirely differently, such as map stdout to some handle from Win32. Then all C library functions need to be revised to be based on Win32 functions. However, I don't want to rewrite the C library, as the existing ones seem perfectly adequate. So far. > it would need to have the complete definition of FILE available to fetch > those fields. Headers like <stdio.h> are expected to have aspects which are > customized to fit the underlying library implementation. They're not > required to do so, but performance can be improved when they are [e.g. a > compiler might be able to optimize a loop which calls getc() multiple times > so that it can process up to f->simpleGetsLeft characters at once]. I wouldn't rely on an implementation having a fast getc(); I would just load the entire file in one go. (And ignore the nonsense about files possibly being too big to load; my RAM is sufficient to hold 100,000 copies of the typical size of file I use.) Anyway, how much of an overhead would a function call actually be: what MB/second throughputs can people get with a macro getc(), and how does that compare with a function getc()? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | gordonb.l3ybu@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2017-03-27 03:34 -0500 |
| Message-ID | <ke6dncR_34w1U0XFnZ2dnUU7-R3NnZ2d@posted.internetamerica> |
| In reply to | #107027 |
> extern FILE _iob[]; There's no reason to put this internal stuff in <stdio.h>, except perhaps historical reasons. > But since the FILE struct already exists, it might as well stay. > > (The above is for Windows; in Linux, stdout for example is defined as a > pointer to FILE (or struct _IO_FILE). Hopefully these reside in the C > library and have already been initialised, and don't require > initialisation code to be be invoked by my program, as I have no idea > how to do that. C doesn't like to define symbols like stdin to have linkage directly since it shouldn't collide with a user's names if he DOESN'T include <stdio.h> in a particular source file. Thus we have the defines below, and reserved variable names __stdinp, __stdoutp, and __stderrp instead of stdin, stdout, and stderr directly: In stdio.h: /* You don't need a definition of FILE with a correct size here. */ /* Use an opaque type */ #define stdin __stdinp #define stdout __stdoutp #define stderr __stderrp extern FILE * __stdinp; extern FILE * __stdoutp; extern FILE * __stderrp; In fopen.c or some other source code file for the C library: static FILE _iob[__MAX_FILES]; FILE * __stdinp = &_iob[0]; FILE * __stdoutp = &_iob[1]; FILE * __stderrp = &_iob[2]; You don't need any initialization code in your program for this to work. _iob is static here so you can't reference it from user code, as it should be. It should be renamed to something nobody can spell, like _supercalifragilisticexpalidociouss. Note: since the trend is for __MAX_FILES is to be large, like 1000, and not necessarily a fixed limit, perhaps this should be dynamically allocated. FreeBSD breaks up the array: the first 3 are statically allocated (and initialized - I didn't show that here), and the rest are dynamic. > But, I plan to access stdout etc via dynamic linking. Windows has some wierdness that sometimes requires variables be put in a DLL or not be put in a DLL. Linux doesn't. > It's not clear whether the resulting values even belong to my process. If they do not, you can't get to them. Period. The C library (excluding the kernel code run because of system calls) runs in user process space. > A test using > dynamic access to _iob worked in Windows; a similar test under Linux > failed. This might be a bit of a stumbling block...) Was this with the header file that referenced &_iob[1] and had the wrong size for a FILE? That would explain it. It's possible that _iob was made static or renamed. You shouldn't be referencing it anyway other than using definitions in <stdio.h>.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-27 11:41 +0100 |
| Message-ID | <obaq43$bb9$1@dont-email.me> |
| In reply to | #107146 |
On 27/03/2017 09:34, Gordon Burditt wrote: > Was this with the header file that referenced &_iob[1] and had the wrong > size for a FILE? That would explain it. It's possible that _iob was > made static or renamed. You shouldn't be referencing it anyway other > than using definitions in <stdio.h>. I was under the impression that functions and things exported from shared libraries could be accessed from any language using the right ABI, not just the original language (eg. C). Then it should be possible to do that without requiring a 'stdio.h' file or involving a C compiler. But it does require equivalent definitions in whatever language /is/ being used, and that means /knowing/ what is going on. So, under Windows, using stdout (which might be needed to make use of fprintf) requires that stdout is a pointer to the second element of some array exported by the C shared library. Under Linux, from what I've seen, stdout is itself directly exported from the C shared library. (I'm guessing that the dlopen() function on the Linux library creates new, private instances of the exported variables, and an internal initialisation routine sets them up.) (Did you yourself mention using this stuff from Perl, in another post? I guess Perl wasn't using stdio.h.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | gordonb.15yss@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2017-03-27 14:48 -0500 |
| Message-ID | <5f2dnZm7l7YU8UTFnZ2dnUU7-X3NnZ2d@posted.internetamerica> |
| In reply to | #107149 |
> I was under the impression that functions and things exported from
> shared libraries could be accessed from any language using the right
> ABI, not just the original language (eg. C).
Then you need the appropriate headers for that language.
If the language doesn't come with the system, the language writer,
not the system writer, may be responsible for supplying header
files. Consider, for example, PL/1 or COBOL for UNIX. I see
no COBOL header files here.
A different language may have difficulties with some of the C names,
for example, not allowing _ in a variable name or function name.
FORTRAN had a different convention than the leading _; it may have
been a *trailing* _. Also, the C linker may not like some characters
in names that the other language uses.
> Then it should be possible to do that without requiring a 'stdio.h' file
> or involving a C compiler.
If the language requires function declarations (and perhaps wrapper functions
if the calling conventions aren't compatible), then it needs something
equivalent to <stdio.h> for that language.
> But it does require equivalent definitions in whatever language /is/
> being used, and that means /knowing/ what is going on.
Some languages provide means of automatically constructing <whatever
language> header files from C header files (e.g. Perl). Other
languages use wrapper functions and change the interface, for
example, you might pass a Perl or FORTRAN I/O handle instead of the
C stdout, and the wrapper takes care of the difference (A FORTRAN
or Perl I/O handle contains or can figure out a stdio stream to
use).
As I recall, at least one implementation of FORTRAN on UNIX had a
wrapper function for just about everything, including all the math
functions, a different one for every precision, and I/O because the
function/subroutine linkage wasn't the same. Also, FORTRAN I/O
wasn't just calling C functions with slightly different names. As
I recall, there were some funky rules about mixing C and FORTRAN
I/O in the same program, which I was trying to do. It seems they
each have their own set of buffers.
> So, under Windows, using stdout (which might be needed to make use of
> fprintf) requires that stdout is a pointer to the second element of some
> array exported by the C shared library. Under Linux, from what I've
> seen, stdout is itself directly exported from the C shared library.
If you export a pointer to stdout, you don't need to export the fact
that the FILE struct is a member of an array, the name of the array
(if the array even has a name ... it may be allocated with malloc() ),
the size of a FILE struct, or the fact that it's the second element.
Perhaps the easiest way to export something like stdout is to compile
a 3-line file like this as C:
---------------
#include <stdio.h>
FILE *pointerToSTDOUT = stdout;
---------------
and link it with the other-language code (assuming that pointer
format and variable names are compatible) which uses "extern
pointerToSTDOUT or whatever the equivalent is in that language.
You don't have to worry about whether _ is a legal character in
your language, nor the contents of <stdio.h>. Just treat it as an
opaque pointer that you pass to fprintf() or whatever.
> (I'm guessing that the dlopen() function on the Linux library creates
> new, private instances of the exported variables, and an internal
> initialisation routine sets them up.)
Assume you have a private library you can require in addition to the
C library. I think there is a way for "extern FILE *stdout;" in
the main program to match up with "FILE *stdout;" in the private library
as one variable if you use RTLD_GLOBAL. It also works this way if
you use shared libraries without dlopen().
Attempting to dlopen() the C library is a little bit pointless.
Guess where the dlopen() code is? You need to have it already
linked to call dlopen(). Well, it is possible to dlopen() the
executable itself and read its symbols, so it might have some use.
With RTLD_LOCAL, you can dlopen() multiple shared objects and each
may have functions and variables private to the library and with
duplicate names. In particular, each library may have _init and
_fini functions, which get automatically called and can do initializations
(like, say, C++ constructors).
> (Did you yourself mention using this stuff from Perl, in another post? I
> guess Perl wasn't using stdio.h.)
I mentioned that the C code from Perl used code that accessed the
fields of a FILE that it wasn't really supposed to. Yes, the Perl
C code was using <stdio.h>. (I was building Perl, not using it,
watching the Configure script test whether this worked. And in one
case, it failed with spectacular error messages but went on to build
a working Perl). However, Perl does have a way of converting C
header files to Perl header files. There's a tree of Perl *.ph
files, one for each C include file, hidden under the site_perl directory.
It even translates all the #if's!
In C++, you can (and have to) tell it to use C rather than C++
calling conventions. extern "C" { ... }
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-27 13:31 -0700 |
| Message-ID | <f26c1cb1-cdd9-4b39-9f48-2704dc048acb@googlegroups.com> |
| In reply to | #107202 |
On Monday, March 27, 2017 at 2:48:37 PM UTC-5, Gordon Burditt wrote:
> If you export a pointer to stdout, you don't need to export the fact
> that the FILE struct is a member of an array, the name of the array
> (if the array even has a name ... it may be allocated with malloc() ),
> the size of a FILE struct, or the fact that it's the second element.
>
> Perhaps the easiest way to export something like stdout is to compile
> a 3-line file like this as C:
>
> ---------------
> #include <stdio.h>
>
> FILE *pointerToSTDOUT = stdout;
> ---------------
> and link it with the other-language code (assuming that pointer
> format and variable names are compatible) which uses "extern
> pointerToSTDOUT or whatever the equivalent is in that language.
That approach may cause an extra layer of indirection compared with what
would be necessary if e.g. stdout reported the address of an element within
a an exported FILE[]. Some C compilers provide means of exporting symbols
with particular addresses, but there's no consistent syntax. It would have
been helpful if the Standard had specifies a syntax for exporting a symbol
with a pointer-constant address, subject to Implementation-Defined
constraints. Such constraints might allow any C pointer-constant expression,
might not allow any, or might e.g. allow only pointer constants which do not
depend upon any imported symbols.
If an implementation were to accept:
uint32_t volatile MoeLarryCurly[3];
uint32_t volatile Moe : MoeLarryCurly[0]; // Syntax with no other meaning
uint32_t volatile Larry : MoeLarryCurly[1];
uint32_t volatile Curly : MoeLarryCurly[2];
then the behavior of accessing "Larry" would be equivalent to that of
accessing MoeLarryCurly[1]. Systems would be required to reject such
code if the linker wouldn't be able to achieve the required semantics,
but enough linkers can handle such things that it shouldn't be necessary
to use assembly language to accomplish them.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-03-27 22:22 +0100 |
| Message-ID | <OofCA.186700$fL.181126@fx24.am4> |
| In reply to | #107202 |
On 27/03/2017 20:48, Someone wrote: >> I was under the impression that functions and things exported from >> shared libraries could be accessed from any language using the right >> ABI, not just the original language (eg. C). > > Then you need the appropriate headers for that language. Yes, that's what I'm trying to create. > If the language doesn't come with the system, the language writer, > not the system writer, may be responsible for supplying header > files. What do you mean by the language writer? If you mean the implementor, then he will need the information necessary in order to be able to write the headers (or the equivalent in the language). I'm the implementor. I'm using a variety of sources including existing C headers in order to glean enough info to do the job, but solutions /requiring/ you to use stdio.h and /assuming/ you're going to use an existing C compiler aren't much good. I might, for example, want to be able to use C's file functions from assembly code. >> Then it should be possible to do that without requiring a 'stdio.h' file >> or involving a C compiler. > > If the language requires function declarations (and perhaps wrapper functions > if the calling conventions aren't compatible), then it needs something > equivalent to <stdio.h> for that language. Suppose the problem is to execute the equivalent of this: fprintf(stdout, "hello"); but to do it from assembly as I suggested above. Your only tools are an assembler and a linker that can manage the connection between your ASM code and a shared library of either msvcrt.dll or libc.so.6. How do you do it? 'fprintf' is just an address, so it easy. What about 'stdout'? Where do you find the information that tells you where to get 'stdout'? (Windows and Linux manage this differently.) > Perhaps the easiest way to export something like stdout is to compile > a 3-line file like this as C: > > --------------- > #include <stdio.h> > > FILE *pointerToSTDOUT = stdout; > --------------- > and link it with the other-language code (assuming that pointer > format and variable names are compatible) which uses "extern > pointerToSTDOUT or whatever the equivalent is in that language. > You don't have to worry about whether _ is a legal character in > your language, nor the contents of <stdio.h>. Just treat it as an > opaque pointer that you pass to fprintf() or whatever. I'm writing a C compiler. I can't make it half-dependent on another C compiler for it to work! How did the authors of that other compiler manage it - did they depend on yet another compiler, so that there is a chain of dozen compilers? (Like 5 buses following a sixth because only the one in front knows the way!) (The only concession I can make, for people who want to compile from source, is to require an existing C compiler to bootstrap, then it can be set aside.) >> (I'm guessing that the dlopen() function on the Linux library creates >> new, private instances of the exported variables, and an internal >> initialisation routine sets them up.) > > Assume you have a private library you can require in addition to the > C library. I think there is a way for "extern FILE *stdout;" in > the main program to match up with "FILE *stdout;" in the private library > as one variable if you use RTLD_GLOBAL. It also works this way if > you use shared libraries without dlopen(). > > Attempting to dlopen() the C library is a little bit pointless. > Guess where the dlopen() code is? You need to have it already > linked to call dlopen(). The point of opening it is to get a handle to pass to dlsym(). But also, when I get into it, to ensure that I'm using a different invocation of the library from the program that is being executed. (One use of this is when the primary executable is an interpreter of a language which can itself directly call functions in a library such as C. Any local state within its use of the library needs to be kept separate from that of the host. Another, which I'm doing now, is a program which converts C source to native code to be directly executed. It will need its own private fixups to an external C library, separate from its host. The host may also need to stay resident while different versions of the target program are run.) . Well, it is possible to dlopen() the > executable itself and read its symbols, so it might have some use. Is there a dl function to enumerate all the symbols rather than look for a specific one? (Sometimes you won't know which library a symbol might be in.) >> (Did you yourself mention using this stuff from Perl, in another post? I >> guess Perl wasn't using stdio.h.) > > I mentioned that the C code from Perl used code that accessed the > fields of a FILE that it wasn't really supposed to. Yes, the Perl > C code was using <stdio.h>. (I was building Perl, not using it, > watching the Configure script test whether this worked. And in one > case, it failed with spectacular error messages but went on to build > a working Perl). However, Perl does have a way of converting C > header files to Perl header files. There's a tree of Perl *.ph > files, one for each C include file, hidden under the site_perl directory. > It even translates all the #if's! I wonder what it converts them to, unless .ph files are not very different from .h files. (With my own such language, converting .h files is not easy, as there is no equivalent in the target language! It works completely differently.) -- bart --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-27 15:05 -0700 |
| Message-ID | <a2df871d-0b3e-45ac-83d4-03d72e016ffe@googlegroups.com> |
| In reply to | #107216 |
On Monday, March 27, 2017 at 4:23:02 PM UTC-5, Bart wrote:
> I'm writing a C compiler. I can't make it half-dependent on another C
> compiler for it to work! How did the authors of that other compiler
> manage it - did they depend on yet another compiler, so that there is a
> chain of dozen compilers? (Like 5 buses following a sixth because only
> the one in front knows the way!)
There are two approaches a C implementation may take to handling things like
the FILE type:
1. Define FILE however it likes, and then implement functions like fopen,
fwrite, etc. which use those fields however they see fit, and in turn
call some OS routines never receive a FILE, but will likely be passed
one or more members from it. The OS routine would have no reason to
know or care how the C implementation defined FILE.
2. Define FILE in a fashion consistent with a file-control structure used
by an underlying operating system.
If one wants to use a C implementation to do the equivalent of
fprintf(stdout, "hello"); one should write a compilation unit like:
#include <stdarg.h>
#include <stdio.h>
int do_fprintf(FILE *f, char const *restrict fmt, ...)
{
va_list vp;
va_start(va, fmt);
vfprintf(f, fmt, va);
va_end(vp);
}
FILE *get_stdout(void)
{
return stdout;
}
which will export two functions which can be invoked from within assembly
language. C implementations may omit library code which is not used within
a C file, or may select from among different implementations of things like
fprintf() based upon the ways they see it invoked. If a C implementation
sees that none of the printf functions receive any format specifier more
complicated that %d or %u, it may link in an implementation that omits other
specifiers. If a machine-code function tries to call printf with other kinds
of format specifiers, the linked implementation might not work. If code
chains to vfprintf from an exported function, however, the implementation
would know that it would need to include an "fprintf" that could handle
anything.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-03-27 23:22 +0100 |
| Message-ID | <sggCA.318572$8b6.246389@fx19.am4> |
| In reply to | #107223 |
On 27/03/2017 23:05, supercat@casperkitty.com wrote:
> On Monday, March 27, 2017 at 4:23:02 PM UTC-5, Bart wrote:
>> I'm writing a C compiler. I can't make it half-dependent on another C
>> compiler for it to work! How did the authors of that other compiler
>> manage it - did they depend on yet another compiler, so that there is a
>> chain of dozen compilers? (Like 5 buses following a sixth because only
>> the one in front knows the way!)
>
> There are two approaches a C implementation may take to handling things like
> the FILE type:
>
> 1. Define FILE however it likes, and then implement functions like fopen,
> fwrite, etc. which use those fields however they see fit, and in turn
> call some OS routines never receive a FILE, but will likely be passed
> one or more members from it. The OS routine would have no reason to
> know or care how the C implementation defined FILE.
>
> 2. Define FILE in a fashion consistent with a file-control structure used
> by an underlying operating system.
Yes, one way is to write an entirely new C library, then it doesn't
matter how it's done. But there are some problems:
(1) It's a huge amount of work
(2) It will likely be tied to one OS, so I might need one for each target OS
(3) I don't know if there are going to be clashes when my code using its
own library interacts with functions in external shared libraries using
a more standard one.
(4) I don't want to do it and hadn't planned to. There are perfectly
good existing libraries, which already exist on my target OSes, and this
is what I'd intended to use. (Actually my interpreted stuff already
makes use of them.)
>
> If one wants to use a C implementation to do the equivalent of
> fprintf(stdout, "hello"); one should write a compilation unit like:
>
> #include <stdarg.h>
> #include <stdio.h>
> int do_fprintf(FILE *f, char const *restrict fmt, ...)
> {
> va_list vp;
> va_start(va, fmt);
> vfprintf(f, fmt, va);
> va_end(vp);
> }
> FILE *get_stdout(void)
> {
> return stdout;
> }
>
> which will export two functions which can be invoked from within assembly
> language.
Imagine if the C language didn't exist. But you still have a binary API
that works remarkably similarly to the current C library. How could you
call such functions?
And in fact the fprintf example wasn't concerned with variadic
arguments, but getting access to the stdout used by the shared library.
This is surprisingly difficult to obtain (outside of just using C).
Sometimes you can get a file handle which does the same job, but it's
not stdout. So if you passed it to a function which /did/ have access to
the real thing, then f==stdout would be false.
> C implementations may omit library code which is not used within
> a C file, or may select from among different implementations of things like
> fprintf() based upon the ways they see it invoked. If a C implementation
> sees that none of the printf functions receive any format specifier more
> complicated that %d or %u, it may link in an implementation that omits other
> specifiers. If a machine-code function tries to call printf with other kinds
> of format specifiers, the linked implementation might not work. If code
> chains to vfprintf from an exported function, however, the implementation
> would know that it would need to include an "fprintf" that could handle
> anything.
Well, hopefully I won't be implementing any printf functions!
--
bartc
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-28 00:35 +0200 |
| Message-ID | <obc3u5$8ml$1@dont-email.me> |
| In reply to | #107224 |
Le 28/03/2017 à 00:22, bartc a écrit : > > Yes, one way is to write an entirely new C library, then it doesn't > matter how it's done. But there are some problems: > > (1) It's a huge amount of work > Yes. I did that, and it is true. it is a HUGE amount of work. > (2) It will likely be tied to one OS, so I might need one for each > target OS > Yes. You have to port it to each new OS that you support. > (3) I don't know if there are going to be clashes when my code using its > own library interacts with functions in external shared libraries using > a more standard one. > The new library will be incompatible with any existing library. > (4) I don't want to do it and hadn't planned to. There are perfectly > good existing libraries, which already exist on my target OSes, and this > is what I'd intended to use. (Actually my interpreted stuff already > makes use of them.) > Use CRTDLL.DLL then, and libc in linux. I am doing that under linux for the time being. Since the implementation of the library is open source I can use it and hack it at will. > > Well, hopefully I won't be implementing any printf functions! > I did implement printf since there is no compiler around that will understand 480 bit floats, or 128 bit integers, etc.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-04-16 19:09 -0700 |
| Message-ID | <kfn1ssr9440.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #107225 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > [...] > > I did implement printf since there is no compiler around that will > understand 480 bit floats, or 128 bit integers, etc. I'm curious - did you implement the POSIX positional extensions?
[toc] | [prev] | [next] | [standalone]
Page 2 of 15 — ← Prev page 1 [2] 3 4 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web