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 12 of 15 — ← Prev page 1 … 10 11 [12] 13 14 15 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-30 18:49 +0000 |
| Message-ID | <%qcDA.98500$_83.55770@fx07.iad> |
| In reply to | #107508 |
bartc <bc@freeuk.com> writes: >On 30/03/2017 00:17, Gordon Burditt wrote: > >That's unlikely. It should be possible to create an arbitrary language >without any dependency on a C compiler. Of course it is. How do you think the first COBOL, FORTRAN and ALGOL68 compilers were created? Today, however, one would likely use C instead of assembler simply for ease of development.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-03-30 20:07 +0100 |
| Message-ID | <NHcDA.265389$y83.197980@fx30.am4> |
| In reply to | #107511 |
On 30/03/2017 19:49, Scott Lurndal wrote: > bartc <bc@freeuk.com> writes: >> On 30/03/2017 00:17, Gordon Burditt wrote: > >> >> That's unlikely. It should be possible to create an arbitrary language >> without any dependency on a C compiler. > > Of course it is. How do you think the first COBOL, FORTRAN and ALGOL68 > compilers were created? That was then. Now C insinuates itself everywhere and avoiding it is harder. I'm saying that even now, it should be possible, and in fact I've been doing it for a long time, but not so much on Linux. It's slightly harder for me as every language of mine has been implemented with a previous one. (Sometimes starting with an assembler, which I probably wrote; I can't remember. And sometimes starting with machine code, which your examples probably didn't.) -- bartc --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[toc] | [prev] | [next] | [standalone]
| From | gordonb.b709o@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2017-04-16 03:45 -0500 |
| Message-ID | <zLWdnT37lfzdsm7FnZ2dnUU7-QPNnZ2d@posted.internetamerica> |
| In reply to | #107508 |
>> If you are writing a *C* compiler but using the existing library,
>> you need to supply headers like <stdio.h>. This might be done by
>> (a) using the system compiler headers (if the system compiler and/or
>> its headers are not installed by default, this requires installing
>> it), (b) copy the headers into your distribution (might draw copyright
>> lawsuits or encumber your compiler), (c) write your own and
>> reverse-engineer the system-dependent stuff in the header
>
> A lot of this stuff will be in the C Standard. Will it still need a
> copyright notice even for things like this which are common knowledge:
>
> extern int printf(char*, ...);
>
> ?
No. That's an interface in the C standard. Copy it from there and
you're fine. However, if you need to define a FILE type that matches
up with what's in msvcrt.dll, that's *NOT* in the C standard and
Microsoft might well sue you if you just copied it out of one of
their headers (and especially if you just copied *and distributed*
it with your compiler). Also, copyright notices do not protect you
from copyright lawsuits. Copyright notices you add are to warn
other people not to copy YOUR stuff. Does <stdio.h> from the
Microsoft compiler contain Microsoft copyright notices? The license
agreement probably says you can't copy individual pieces or files
anyway.
They will likely also get upset if you distribute a copy of msvcrt.dll
with your compiler.
>> If you are implementing a language other than C, or something very
>> C-like: Just because the language implementor wants/needs something
>> doesn't mean that he gets it in a convenient form, or that he can
>> do it without putting bits of C in his source code, or even that
>> he gets it at all. The system compiler might also (a) be closed-source,
>> (b) use pre-compiled headers in a form you can't decode, and (c)
>> not provide a way of getting post-preprocessed code (which would
>> include the header files).
>
> I expect the system I'm compiling for to document its interfaces. With
> Windows, their docs are quite good, and stable.
Microsoft is not going to supply a COBOL, PL/1, assembly-language,
or Schnitzel headers for its libraries, especially if they do not
sell their own COBOL, PL/1, assembly-language, or Schnitzel
implementations. There is a good chance that those languages cannot
use the provided (and documented) interfaces without some glue code.
FORTRAN seems to be particularly a problem, since calling conventions
between FORTRAN routines don't work like C's pass-by-value, and
bending FORTRAN calling conventions to use those of C tends to break
it.
>> C can't be implemented without bits of assembly language.
>
> Well, if you're generating code, usually you will need that.
The bits of assembly language I am referring to are instructions
that are not normally generated (or needed) by a compiler for a
normal C program. These would include:
- The INT n or "Supervisor Call" instruction used to call the
operating system. It is possible to use an ordinary CALL instruction
but somehow that's not the choice usually made.
- Any kind of I/O port instructions, like the 8086 "IN" and "OUT".
- Anything relating to switching between "supervisor" and "user"
modes in the processor.
- Enabling and disabling hardware device interrupts.
- Invalidating cache
- Reloading the stack pointer (assuming there is one) as distinguished
from adjusting it relative to its current position.
- Switching tasks, including saving/restoring registers, floating
point registers, and changing the memory map.
- There are likely to be special-purpose instructions that get too
specific for a compiler to generate, but are useful to use in
library functions (things like some of the MMX instructions come
to mind) perhaps called as compiler "helper" routines.
Many of these show up as macros defined using asm() calls in some C
non-standard-specified header files.
> Although it
> should be possible to write a C interpreter without knowledge of the
> underlying hardware and no actual machine instructions. (Something I
> considered actually, but it would have been too slow relative to the
> fast compiler.)
>
>> You're likely needed
>> to implement things like math rounding modes as well.
>
> I'm sure C compilers in the 1970s and 80s all did their own thing.
Is it acceptable to you that your program starts with the rounding
modes and precision set to whatever the last program left them set to,
so it behaves differently between runs?
> But I'm not implementing Java where floating point results always have
> to be identical whatever the hardware or version.
Nobody said you had to. The issue is much bigger than that.
>> It's
>> quite possible that your language can't be implemented without some
>> C glue.
If you're using mscvrt.dll, you already have a big C dependency.
> That's unlikely. It should be possible to create an arbitrary language
> without any dependency on a C compiler. Maybe to run some tests, but it
> shouldn't be part of a distribution. (Supplying such an implementation
> as source language X requiring a compiler/interpreter for X is a
> different matter.)
What happens if the arbitrary language uses calling conventions
completely unlike mscvrt.dll? I think your arbitrary language is
screwed if the linkage conventions are not identical to C's and it
does not provide a way of specifying alternative linkage conventions
that do match C e.g.
extern "C" { ... };
or
pascal int foo();
Is your arbitrary language going to support something like:
asm("int 20h");
? That's assembly language, even if it gets stuck into something that
looks like a C header..
>> One approach is write a program to parse the structure declaration
>> in <time.h>, have it produce a program which calls offsetof() and
>> sizeof() for each field in the structure, and create a Perl or
>> assembly-language header file that just defines symbols for each
>> field offset. I've actually run into this being done.
>
> I've done something like that to get the sizes used by various Win32 API
> structs. Just to check the ones I have to build - in a different
> language with its one padding/alignment rules - match up.
>
> However I understand that on a given platform, all C compilers have to
> follow the same rules for structs.
Incorrect. There is no rule that code from different C compilers
(or even the SAME C compiler with different compile options)
on a given platform can be linked together AT ALL. Do you know
what a memory model is? C on the 8086 managed to define at at least
4 different models. They used all possible combinations of 16/32
data and 16/32 function pointers. They can't follow the same rules
for structs if the sizes of pointers change. Trying to mix memory
models, especially if all parts of the program call the C library,
is an invitation to disaster, even if you litter your program
with "near" and "far" keywords. 8086 is obsolete? The same
issue exists on 32-bit x86 processors with 32 vs. 48-bit pointers.
It should be a long time before programs bloat enough that 64-bit
pointers aren't enough.
>> You don't have enough information. Furthermore, the implementation
>> might change on you. I think FreeBSD had one change that did alter
>> sizeof(FILE).
>
> Then, surely, every compiled binary program would fail? Assuming
> sizeof(FILE) was a crucial part.
sizeof(FILE) SHOULD NOT be a crucial part. FILE is an opaque type.
If a program declares a FILE struct (as opposed to a pointer to one),
computes sizeof(FILE), increments a FILE * pointer, or dereferences
a FILE * pointer, it's broken. FILE should be treated as an opaque
type.
The situation is different for, say, struct tm. User code is
expected to access individual members of that struct, and some of
them are documented.
> Symbol versioning allowed old programs to continue
>> working and new ones to use the new code, but you couldn't mix old
>> and new objects in the same link.
>
> Oh, they had some sense then in overlapping versions...
Another protection here is that they bump the version on the C library
when needed. Old executables use the version they were linked with,
even if a newer one is available.
.
>>> I'm writing a C compiler. I can't make it half-dependent on another C
>>> compiler for it to work!
>>
>> It's already dependent on the C library from another compiler!
>
> On a binary library. We don't know its provenance; maybe it was written
> in assembly, or in machine code, or some other language entirely.
You can't write a C library entirely in C.
You still have to have the darn thing installed for your compiler to
function (which includes running the programs it compiles). Do you
intend distributing it along with your compiler? I smell a lawsuit.
> Besides the libraries I've chosen already exist, so are effectively part
> of the OS.
But are they INSTALLED?
I believe in Microsoft-speak that "Part Of The OS" means "To be used by the
OS only. Applications keep hands off! We Will Patch This Or Remove
It Entirely Without Notice".
> (I started using C libraries nearly 20 years before I used C. I just saw
> them as a simpler-to-use alternative to the Win API.)
>
>> The only thing you need from the old compiler is the old <stdio.h>,
>> or a new one that works the same in this regard. Your compiler
>> should be able to compile the 3-line file above just fine. If you
>> are writing a C compiler, what are you supplying as <stdio.h>?
>
> This is how it works at the minute:
>
> * Start with an empty set of standard headers
You really could start here with declarations that the C standard requires.
> * Try and compile some code
>
> * If it complains about a missing standard function, then:
>
> * Find which header it's supposed to go in
>
> * Find the signature
>
> * Add the header in as simple a form as possible
>
> * Try compiling again (sometimes it needs a 'const' added)
>
> * Repeat with the next missing bit
That's fine for the function prototypes, but it may not work well
where you HAVE to have something implementation-defined, especially
when matching up to Microsoft code is critical. And this is where
you can end up drawing a copyright lawsuit.
> Sources of info include the C standard, online resources such as the
> MSDN website, and existing headers, although the latter tend to have a
> lot of implementation-specific crap.
C headers are required to have quite a bit of implementation-specific
crap. (You have to define FILE as something). This does not mean
it has to have multiple sets of implementation-specific crap selected
by preprocessor directives.
>>> 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.
>>
>> I don't believe that you can dlopen() multiple copies of the same
>> library and get multiple instances of that library.
>
> I'm calling dlopen() once. Surely it will give me a different instance
> from the one used by the program that called dlopen()?
Don't say program if you mean process. Which do you mean here?
Please explain why, if you want separate library instances, why you
need to dlopen() the program instead of just running it? What
*needs* to be shared? Why? If the answer is "nothing", why not
just run it? Don't you get a separate instance of the library
in each process that uses it if you just run it?
If you call dlsym() 3 times to get the addresses of malloc(), free(),
and exit(), you will get 3 different addresses in the *SAME COPY*
of the library. The routines will share one copy of the static
data they share, which contains in some form the list of allocated
memory. You cannot malloc() from one copy of the library and free()
it in a different copy. That way lie segmentation faults. It would
make no sense to make multiple copies. Here, I'm assuming you are
talking about only one PROCESS. Parent and child would share the
same copy on fork() (which would gradually become separate due to
copy-on-write for writes done after the fork()) but they'd end up
with separate copies if either does an exec().
>>> (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.
>>
>> That sounds like a call for a wrapper function. If a function has
>> state (such as strtok() or localtime()), arrange to store the state
>> and use the appropriate state on the next call.
>
> I would expect static data belonging to a shared library to have
> separate copies for each instance. The question then is whether a dlopen
> call belonging to process X will return a handle identical to that used
> by X (assuming X is not using a statically linked version).
>
>
>> Perl. Try reading one sometime (see below). It looks like all the
>> translations of #if are done at *RUN TIME*, although it's possible
>> that some optimization may be possible.
>
>> stdio.ph:
>> ------------------
>>
>> require '_h2ph_pre.ph';
>>
>> no warnings qw(redefine misc);
>>
>> unless(defined(&_STDIO_H_)) {
>> eval 'sub _STDIO_H_ () {1;}' unless defined(&_STDIO_H_);
>> require 'sys/cdefs.ph';
>> require 'sys/_null.ph';
>> require 'sys/_types.ph';
>> unless(defined(&_SIZE_T_DECLARED)) {
>> eval 'sub _SIZE_T_DECLARED () {1;}' unless defined(&_SIZE_T_DECLARED);
>> }
>> if((defined(&__POSIX_VISIBLE) ? &__POSIX_VISIBLE : undef) >= 200809) {
>> unless(defined(&_OFF_T_DECLARED)) {
>> eval 'sub _OFF_T_DECLARED () {1;}' unless defined(&_OFF_T_DECLARED);
> <snip>
>
> Interesting. So the people who created Perl didn't want to get as far
> away from C as possible! They created an interpreter for a
> preprocessor-like language, it looks like.
Perl is a lot more than a preprocessor-like language, although from
the beginning it came with programs to convert awk scripts to Perl
scripts, and awk is somewhat like a pre-processor.
Almost all of the C (and POSIX) calls in the C library (and other
commonly used libraries, such as the DBM library, termcap library,
math library, etc.) have counterparts in Perl. A lot of the build
procedure involves determining which of these calls exist, so the
corresponding Perl function can be built or omitted. In some cases,
missing functions can be emulated. Most of them need a wrapper
function (for example, Perl uses Perl I/O handles; C uses FILE *,
and the wrapper handles the difference).
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-16 16:34 +0100 |
| Message-ID | <U9MIA.392878$fL.108273@fx24.am4> |
| In reply to | #108170 |
On 16/04/2017 09:45, Gordon Burditt wrote:
>> A lot of this stuff will be in the C Standard. Will it still need a
>> copyright notice even for things like this which are common knowledge:
> They will likely also get upset if you distribute a copy of msvcrt.dll
> with your compiler.
msvcrt.dll comes with every Windows system. I've paid for my copy of
Windows, and everyone who wants to use one of my programs that calls
msvcrt.dll needs to pay for theirs. So it's not as though MS are losing out.
Are you saying it's illegal to write programs that contain information
(eg. function headers) necessary to call a function in msvcrt.dll?
Even though information is publicly available via sites such a msdn?
(In the case of the implementation of FILE, I've seen elements of the
version in MS' stdio.h, in stdio files provided with DMC, lccwin,
gcc/mingw and Tiny C. Tiny C's stdio.h even said it was in the public
domain!)
>> I'm sure C compilers in the 1970s and 80s all did their own thing.
>
> Is it acceptable to you that your program starts with the rounding
> modes and precision set to whatever the last program left them set to,
> so it behaves differently between runs?
If that unlikely problem comes up, it'll be fixed. (I've been using
floating point on x86 for some 30 years, I reckon I can deal with it.)
> If you're using mscvrt.dll, you already have a big C dependency.
No, it's a library that I've decided to use. Its implementation language
is irrelevant.
And I can today provide applications as source in my language, as asm
source, or as binary files, that do not involve C. Using C as a
distribution medium is just for convenience.
If it came to it, I could eliminate the msvcrt.dll/libc.so.6 dependency,
but it would be a big headache. Especially on Linux where I have little
idea what is C and what is OS. But then on Linux, not having libc.so
might cause problems elsewhere.
> What happens if the arbitrary language uses calling conventions
> completely unlike mscvrt.dll? I think your arbitrary language is
> screwed if the linkage conventions are not identical to C's and it
> does not provide a way of specifying alternative linkage conventions
> that do match C e.g.
> extern "C" { ... };
>
> or
> pascal int foo();
>
On x64, applications I believe are required to use one of two call
conventions, depending on whether they run on Windows or Linux, if they
want to export functions to be called as foreign functions in other
languages.
On other hardware, I already in the past supported 'windows' and 'clang'
call conventions as well as my own, so it's not a particular problem.
>
> Is your arbitrary language going to support something like:
> asm("int 20h");
> ? That's assembly language, even if it gets stuck into something that
> looks like a C header..
In what, C code? No, that will be a compiler-specific feature. I'm not
going to implement every extension in every C implementation just so I
can compile arbitrary code.
>> However I understand that on a given platform, all C compilers have to
>> follow the same rules for structs.
>
> Incorrect. There is no rule that code from different C compilers
> (or even the SAME C compiler with different compile options)
> on a given platform can be linked together AT ALL.
Well, if you want to talk to the Win32 API, which uses structs heavily
to communicate, then it would be a good idea if a C compiler laid out
structs in a compatible manner.
>> Besides the libraries I've chosen already exist, so are effectively part
>> of the OS.
>
> But are they INSTALLED?
Yes. If msvcrt.dll is not there, it can be downloaded. I don't really
know if Linux can function without libc.so.
You seem intent on inventing difficulties!
> I believe in Microsoft-speak that "Part Of The OS" means "To be used by the
> OS only. Applications keep hands off! We Will Patch This Or Remove
> It Entirely Without Notice".
They can do what they like. But it won't be popular when a million apps
stop working!
>> I'm calling dlopen() once. Surely it will give me a different instance
>> from the one used by the program that called dlopen()?
>
> Don't say program if you mean process. Which do you mean here?
It's one program X running another Y which it has synthesised in its
memory space. That second program Y needs to think it is independent of
its host and would like to have its own invocation of the external library.
But the OS may think X and Y are the same process.
> Please explain why, if you want separate library instances, why you
> need to dlopen() the program instead of just running it?
dlopen is the library that Y uses. X may not may not be using the same
library, or parts may be statically linked.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-04-16 20:27 +0200 |
| Message-ID | <od0ct0$aba$1@dont-email.me> |
| In reply to | #108170 |
On 16/04/2017 10:45, Gordon Burditt wrote: > However, if you need to define a FILE type that matches up with > what's in msvcrt.dll, that's *NOT* in the C standard and Microsoft > might well sue you if you just copied it out of one of their headers Relevant articles: https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc. https://patentlyo.com/patent/2017/02/google-oracle-copyrighted.html
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-16 12:16 -0700 |
| Message-ID | <fcfbe390-6d1e-44d3-8203-f3ec3022ef28@googlegroups.com> |
| In reply to | #108170 |
On Sunday, April 16, 2017 at 3:46:06 AM UTC-5, Gordon Burditt wrote:
> sizeof(FILE) SHOULD NOT be a crucial part. FILE is an opaque type.
> If a program declares a FILE struct (as opposed to a pointer to one),
> computes sizeof(FILE), increments a FILE * pointer, or dereferences
> a FILE * pointer, it's broken. FILE should be treated as an opaque
> type.
A program shouldn't do any of the above things unless it is targeting a
particular implementation that defines the behavior of FILE in ways beyond
what the Standard would require. Some platforms, for example, may define a
way of creating a "FILE" which, when data is written to it, will call a
user-supplied function. If the function receives a pointer to the FILE,
it can couple in any other data it needs by doing something like:
struct CONTROLLED_TERMINAL_FILE
{
FILE f; // Address of this is address of outer structure
TERMINAL_STATE state;
FILE *out;
}
If the structure were to use a FILE* rather than a FILE, there would be
no way to locate any of the other information when given a FILE*.
An alternative approach would be to have every FILE object hold a void* to
user-supplied information, and have user code pass the address of its own
data structure to a function that would create and return a FILE* object
for it. Using an approach like the above, however, maximizes the amount
of configuration that can be accomplished statically, however.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-04-17 02:29 -0500 |
| Message-ID | <3lq8fchinbqs3vak11i2k7o38af1rnjsmb@4ax.com> |
| In reply to | #108170 |
On Sun, 16 Apr 2017 03:45:52 -0500, gordonb.b709o@burditt.org (Gordon Burditt) wrote: >Microsoft is not going to supply a COBOL, PL/1, assembly-language, >or Schnitzel headers for its libraries, especially if they do not >sell their own COBOL, PL/1, assembly-language, or Schnitzel >implementations. There is a good chance that those languages cannot >use the provided (and documented) interfaces without some glue code. >FORTRAN seems to be particularly a problem, since calling conventions >between FORTRAN routines don't work like C's pass-by-value, and >bending FORTRAN calling conventions to use those of C tends to break >it. OTOH, MS *does* provided bindings for a number of languages. It would not be unreasonable for an OS to supply a language independent representation of its exposed API, and then to rely on the language implementers to cook that into whatever form is locally needed. You might say the C definitions *are* such a format, but it's far from easy to parse (you basically need much of a C compiler), and much important information is not cleanly encoded at all (for example, version dependencies - eg. function xyz() is only available in OS version 1.2 or later). Conceptually something like the XDR definition language.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-27 19:01 -0400 |
| Message-ID | <obc5f8$con$1@jstuckle.eternal-september.org> |
| In reply to | #107202 |
On 3/27/2017 3:48 PM, Gordon Burditt 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. > > 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. > What non-kernel header files for C are supplied with Linux? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-03-25 21:45 +0000 |
| Message-ID | <58d6e334.20765046@news.xs4all.nl> |
| In reply to | #107020 |
jacobnavia <jacob@jacob.remcomp.fr> 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. Extreme nitpick: yes, it does, but only in silly cases. You are allowed to do this: FILE t_stdin; memcpy(t_stdin, stdin, sizeof(FILE)); memset(stdin, 0, sizeof(FILE)); memcpy(stdin, t_stdin, sizeof(FILE)); and all input from stdin must then function as if you'd never blanked it. You are not allowed to use t_stdin _as_ a FILE object (because, uniquely, the address of a FILE is allowed to be as meaningful as its contents); you are not allowed, unless I am very much mistaken, to use file funtions on stdin in between both copies; but you _are_ allowed to treat it as an abstract object. For this reason, you _must_ know its size. Not its contents, that is off-limits, so the gist of your objection to Bart's usual wilful confusion is perfectly valid; but FILE's size needs to be available to the user-programmer. Richard
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-25 23:19 +0100 |
| Message-ID | <ob6q8t$pi9$1@dont-email.me> |
| In reply to | #107078 |
Le 25/03/2017 à 22:45, Richard Bos a écrit : > Extreme nitpick: yes, it does, but only in silly cases. Yes, but then, it would be better to tell the people in the committee to accept that FILE is an opaque structure and allow implementations that do not support that kind of silly code. I see no practical application of that code anyway. That would not work with lcc-win, but you could do: memcpy(tmp,stdin,sizeof(FILE *)); stdin = NULL; memcpy(stdin,tmp,sizeof(FILE *)); You can also get silly with lcc-win...
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-03-25 19:10 -0400 |
| Message-ID | <2d5cf3b9-5413-35c4-c239-6c2658ae851d@verizon.net> |
| In reply to | #107078 |
On 03/25/2017 05:45 PM, Richard Bos wrote: > jacobnavia <jacob@jacob.remcomp.fr> 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. > > Extreme nitpick: yes, it does, but only in silly cases. You are allowed > to do this: > > FILE t_stdin; > > memcpy(t_stdin, stdin, sizeof(FILE)); > memset(stdin, 0, sizeof(FILE)); > memcpy(stdin, t_stdin, sizeof(FILE)); > > and all input from stdin must then function as if you'd never blanked > it. > You are not allowed to use t_stdin _as_ a FILE object (because, > uniquely, the address of a FILE is allowed to be as meaningful as its > contents); you are not allowed, unless I am very much mistaken, to use > file funtions on stdin in between both copies; but you _are_ allowed to > treat it as an abstract object. > For this reason, you _must_ know its size. Not its contents, that is > off-limits, so the gist of your objection to Bart's usual wilful > confusion is perfectly valid; but FILE's size needs to be available to > the user-programmer. FILE is required to be an object type (7.21.1p2), and that is unchanged from previous versions of the standard. However, in C99 and earlier, object types and incomplete types were distinct non-overlapping categories (6.2.5p1). In C2011, this was changed: incomplete types are now a subset of object types. Someone carefully reviewed every use of the terms "object type", "complete", and "incomplete", making the appropriate changes in each case. It was deliberately decided to NOT change that part of the wording of 7.21.1p2, with the result that the meaning of those words HAS changed: it's now permitted for a FILE object to have an incomplete type, which means the above code now has undefined behavior (6.7p7). This decision was made to allow for it to be an array of unknown size, or a opaque struct type. I was completely thrown by this change in the type categories the first time someone pointed it out to me. I've gotten used to it, but I'm still occasionally surprised when it becomes relevant.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-26 00:54 +0100 |
| Message-ID | <ob6vpd$bkc$1@dont-email.me> |
| In reply to | #107085 |
Le 26/03/2017 à 00:10, James R. Kuyper a écrit : > owever, in C99 and earlier, object types and incomplete types were > distinct non-overlapping categories (6.2.5p1). In C2011, this was > changed: incomplete types are now a subset of object types. Someone > carefully reviewed every use of the terms "object type", "complete", and > "incomplete", making the appropriate changes in each case. It was > deliberately decided to NOT change that part of the wording of 7.21.1p2, > with the result that the meaning of those words HAS changed: it's now > permitted for a FILE object to have an incomplete type, which means the > above code now has undefined behavior (6.7p7). This decision was made to > allow for it to be an array of unknown size, or a opaque struct type. WOW! I am 100% standards compliant then. I wasn't aware of this (good) decision! It is good because obviously FILE is n object managed by the runtime and should be used as a BLACK BOX. Thanks for this information.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-03-25 19:48 -0700 |
| Message-ID | <af0b3dbf-de96-47ae-8366-b9b7c9085b91@googlegroups.com> |
| In reply to | #107087 |
On Saturday, March 25, 2017 at 7:54:13 PM UTC-4, jacobnavia wrote: > Le 26/03/2017 à 00:10, James R. Kuyper a écrit : > > owever, in C99 and earlier, object types and incomplete types were > > distinct non-overlapping categories (6.2.5p1). In C2011, this was > > changed: incomplete types are now a subset of object types. Someone > > carefully reviewed every use of the terms "object type", "complete", and > > "incomplete", making the appropriate changes in each case. It was > > deliberately decided to NOT change that part of the wording of 7.21.1p2, > > with the result that the meaning of those words HAS changed: it's now > > permitted for a FILE object to have an incomplete type, which means the > > above code now has undefined behavior (6.7p7). This decision was made to > > allow for it to be an array of unknown size, or a opaque struct type. > > > WOW! > > I am 100% standards compliant then. I wasn't aware of this (good) decision! > > It is good because obviously FILE is n object managed by the runtime and > should be used as a BLACK BOX. > > Thanks for this information. You're welcome! I thought you'd like it.
[toc] | [prev] | [next] | [standalone]
| From | mertesthomas@gmail.com |
|---|---|
| Date | 2017-03-26 05:12 -0700 |
| Message-ID | <5f8bb2f8-d0e5-489f-8a81-248346be38a0@googlegroups.com> |
| In reply to | #107089 |
Am Sonntag, 26. März 2017 04:49:10 UTC+2 schrieb james...@verizon.net: > On Saturday, March 25, 2017 at 7:54:13 PM UTC-4, jacobnavia wrote: > > Le 26/03/2017 à 00:10, James R. Kuyper a écrit : > > > owever, in C99 and earlier, object types and incomplete types were > > > distinct non-overlapping categories (6.2.5p1). In C2011, this was > > > changed: incomplete types are now a subset of object types. Someone > > > carefully reviewed every use of the terms "object type", "complete", and > > > "incomplete", making the appropriate changes in each case. It was > > > deliberately decided to NOT change that part of the wording of 7.21.1p2, > > > with the result that the meaning of those words HAS changed: it's now > > > permitted for a FILE object to have an incomplete type, which means the > > > above code now has undefined behavior (6.7p7). This decision was made to > > > allow for it to be an array of unknown size, or a opaque struct type. > > > > > > WOW! > > > > I am 100% standards compliant then. I wasn't aware of this (good) decision! > > > > It is good because obviously FILE is n object managed by the runtime and > > should be used as a BLACK BOX. > > > > Thanks for this information. > > You're welcome! I thought you'd like it. I agree that information hiding (FILE used as BLACK BOX) makes sense. But I have a problem: The functions provided for FILE are not sufficient for me. Let me explain: I want to have a function that tells me for a FILE if I can read (at least) one character without blocking. Reading from a regular file will not block, but reading from a character device (keyboard) or pipe (fifo) or socket can block. Linux provides poll but poll uses a file descriptor. Windows has PeekConsoleInput and PeekNamedPipe, which both use a handle. In both cases there might be some characters in the buffer of the FILE object. When there is something in the buffer reading the next char from a FILE will not block. The system specific functions are just needed, when the buffer is empty. For that reason I introduced the macro read_buffer_empty. This is the extension to the C file functions that I need. Determining the macro read_buffer_empty for a C run-time is not so hard as people might thing. When getc is defined as macro the condition to determine, if the read buffer is empty is part of the getc macro. You can just get it from there. Basically the buffer handling of FILE objects has two possibilities: Either there is a pointer comparison or a counter is checked. I have a program that checks the properties of C compiler and C run-time library. This program (chkccomp.c) tries to compile different versions of my read_buffer_empty macro. Finally there is a test if read_buffer_empty works as expected. The following variants are checked: #define read_buffer_empty(fp) ((fp)->_IO_read_ptr >= (fp)->_IO_read_end) #define read_buffer_empty(fp) ((fp)->_cnt <= 0) #define read_buffer_empty(fp) ((fp)->__cnt <= 0) #define read_buffer_empty(fp) ((fp)->level <= 0) #define read_buffer_empty(fp) ((fp)->_r <= 0) #define read_buffer_empty(fp) ((fp)->ptr >= (fp)->getend) #define read_buffer_empty(fp) (*((int *)&((char *)(fp))[%d])==0) #define read_buffer_empty(fp) (*((int **)&((char *)(fp))[32]) >= *((int **)&((char *)(fp))[40])) So one of my wishes for the next C standard is a macro (or function) that provides the functionality of read_buffer_empty. Regards, Thomas Mertes -- Seed7 Homepage: http://seed7.sourceforge.net Seed7 - The extensible programming language: User defined statements and operators, abstract data types, templates without special syntax, OO with interfaces and multiple dispatch, statically typed, interpreted or compiled, portable, runs under linux/unix/windows.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-26 14:00 -0700 |
| Message-ID | <7b9d9088-89e5-4bf3-a7d0-4de06d5aafc1@googlegroups.com> |
| In reply to | #107103 |
On Sunday, March 26, 2017 at 7:12:19 AM UTC-5, mertes...@gmail.com wrote: > For that reason I introduced the macro read_buffer_empty. This is > the extension to the C file functions that I need. Any such macro will require that FILE be a structure with certain known characteristics beyond any mandated by the Standard. Any system using a type without those characteristics will fail, whether it is a structure or something else. I'm not sure how allowing "something else" makes things any worse than they already were. Personally, I think the Standard should have long ago added functions to poll perform I/O with a requested timeout and an indicator whether they should perform partial operations or whether they should behave in all- or-nothing fashion, along with a compile-time means of indicating what features might be supported on at least some streams, and a run-time means of querying what features are available on a particular stream. Not all features will be available on all implementations, but many implementations will support at least some, and many programs may be able to offer useful partial functionality on implementations which can't support all the features. Having a standard way to request such things would be better than requiring programmers to write different code to interface with every OS.
[toc] | [prev] | [next] | [standalone]
| From | gordonb.zdxct@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2017-03-27 02:03 -0500 |
| Message-ID | <5eqdnUHjf-O0JEXFnZ2dnUU7-WXNnZ2d@posted.internetamerica> |
| In reply to | #107020 |
> 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. I believe I have. I think it was in early versions of Perl. It probably isn't there in current versions. It had some kind of shortcut that needed to peek at (and probably fiddle with) the fields in a FILE if they matched one of a few common setups. However, it was still "portable". The Configure script was prepared to try and compile a test program using those fields, and if it wouldn't compile or the test program didn't see the fields do what was expected, it would turn off compilation of the "optimization". I don't recall it ever being turned on when it didn't work. I think the test program may have turned off the optimization on a few systems where it could have worked. > New code can use new functionalities that could be added to fopen. > For instance opening URLs with it, and abstracting away the network layer. I believe that has the effect of opening a potential security hole in any program that accepts filenames as input without checking that they are NOT URLs. If you want a function that opens remote URLs, fine, but *DON'T* call it fopen(). (This was more than a theoretical issue with PHP, and the combination of (a) being able to set variables in a HTTP request, and (b) feeding a variable file name to PHP in PHP code, and (c) not shutting off fopen() accepting remote URLs (it was a configurable option, and I think the default was OFF) could result in a compromised system. Granted, (a) and (b) are coding problems on the to-be-compromised web site, and (c) was an administration problem. PHP has since been changed (long, long ago) to make it less easy to confuse local variables and those provided remotely, permitting execution of whatever (malicious) PHP code was contained in the URL contents by the target system running PHP.) > 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. For networking I want much clearer error messages. For example, what if the host wasn't in DNS, or the nameserver didn't reply, etc. NULL isn't very descriptive here. Also not very descriptive is what happens if you get part of the file and THEN the network goes down. That rarely happens with local hard disks. > fread would have the same parameters, as fclose. An easy way to abstract > the network into C. An easy way to abstract real viruses into your system.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-03-24 22:39 -0500 |
| Message-ID | <0tobdc58n3gburqbov5pafpks4rhpq3fcl@4ax.com> |
| In reply to | #107007 |
On Fri, 24 Mar 2017 22:40:59 +0100, jacobnavia
<jacob@jacob.remcomp.fr> 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!
That makes it rather more difficult to support fast macro versions of
things like getc and putc. OTOH, if you compiler supports those as
known builtin functions, or supports LTCG for library functions, that
would do mostly the same thing.
We can debate whether or not one should use getc/putc for I/O, but a
design consideration for C has always been that those are very fast,
and so are actually a reasonable alternative to the functions that
read or write larger chunks.
But yes, no one *should* be using those internal fields directly,
*except* for other parts of the standard library.
And there's also no reason you can't always implement getc as a
function, but that will surprise people expecting it to be fast.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-25 09:13 +0100 |
| Message-ID | <ob58m0$sco$1@dont-email.me> |
| In reply to | #107035 |
Le 25/03/2017 à 04:39, Robert Wessel a écrit : > That makes it rather more difficult to support fast macro versions of > things like getc and putc. No, because getc and putc and be inlined, what is the equivalent of the macros. It wouldn't be too difficult to do, and inlined in assembly, much easier than those macros that expand to C code...
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-25 11:24 +0000 |
| Message-ID | <ob5jsh$sk6$1@dont-email.me> |
| In reply to | #107035 |
On 25/03/2017 03:39, Robert Wessel wrote:
> On Fri, 24 Mar 2017 22:40:59 +0100, jacobnavia
>> I have another definition, that's even better:
>> typedef struct __FILE FILE;
> That makes it rather more difficult to support fast macro versions of
> things like getc and putc.
With the following code, gcc always generated a call to getc(), even
with -O3:
int c=0,sum=0;
while (c!='z'){
sum+= (c=getc(stdin));
}
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-26 08:42 +1300 |
| Message-ID | <ejnvgcFrv02U2@mid.individual.net> |
| In reply to | #107039 |
On 03/26/17 12:24 AM, BartC wrote:
> On 25/03/2017 03:39, Robert Wessel wrote:
>> On Fri, 24 Mar 2017 22:40:59 +0100, jacobnavia
>
>>> I have another definition, that's even better:
>>> typedef struct __FILE FILE;
>
>> That makes it rather more difficult to support fast macro versions of
>> things like getc and putc.
>
> With the following code, gcc always generated a call to getc(), even
> with -O3:
>
> int c=0,sum=0;
>
> while (c!='z'){
> sum+= (c=getc(stdin));
> }
Does it?
cat x.c; gcc x.c -O3 -S; cat x.s
#include <stdio.h>
void f()
{
int c=0,sum=0;
while (c!='z'){
sum+= (c=getc(stdin));
}
}
.file "x.c"
.text
.p2align 4,,15
.globl f
.type f, @function
f:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
.L8:
movl __iob, %eax
.L2:
subl $1, %eax
testl %eax, %eax
movl %eax, __iob
js .L10
movl __iob+4, %edx
leal 1(%edx), %ecx
movl %ecx, __iob+4
cmpb $122, (%edx)
jne .L2
leave
ret
.p2align 4,,10
.p2align 3
.L10:
subl $12, %esp
pushl $__iob
call __filbuf
addl $16, %esp
cmpl $122, %eax
jne .L8
leave
ret
.size f, .-f
.ident "GCC: (GNU) 6.3.0"
--
Ian
[toc] | [prev] | [next] | [standalone]
Page 12 of 15 — ← Prev page 1 … 10 11 [12] 13 14 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web