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 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-25 19:51 +0000 |
| Message-ID | <ob6hjf$uae$1@dont-email.me> |
| In reply to | #107056 |
On 25/03/2017 19:42, Ian Collins wrote:
> On 03/26/17 12:24 AM, BartC wrote:
>> 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?
> 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
Yes:
# GNU C11 (tdm64-1) version 5.1.0 (x86_64-w64-mingw32)
# c.c -m64 -masm=intel -mtune=generic -march=x86-64 -O3 -fverbose-asm
....
.L2:
| call rbx # tmp92
| mov rcx, rax #, D.2589
| call getc #
| cmp eax, 122 # c,
| jne .L2 #,
....
> .ident "GCC: (GNU) 6.3.0"
Maybe that makes a difference. But for how many decades has getc been a
macro just for this purpose? Has gcc only just got round to it?
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-26 09:10 +1300 |
| Message-ID | <ejo14qFrv02U3@mid.individual.net> |
| In reply to | #107058 |
On 03/26/17 08:51 AM, BartC wrote:
> On 25/03/2017 19:42, Ian Collins wrote:
>> On 03/26/17 12:24 AM, BartC wrote:
>
>>> 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?
>
>> 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
>
> Yes:
>
> # GNU C11 (tdm64-1) version 5.1.0 (x86_64-w64-mingw32)
> # c.c -m64 -masm=intel -mtune=generic -march=x86-64 -O3 -fverbose-asm
> ....
> .L2:
> | call rbx # tmp92
> | mov rcx, rax #, D.2589
> | call getc #
> | cmp eax, 122 # c,
> | jne .L2 #,
> ....
>
> > .ident "GCC: (GNU) 6.3.0"
>
> Maybe that makes a difference. But for how many decades has getc been a
> macro just for this purpose? Has gcc only just got round to it?
No, the difference is -m64, which is odd...
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-25 20:24 +0000 |
| Message-ID | <ob6jg6$44f$1@dont-email.me> |
| In reply to | #107063 |
On 25/03/2017 20:10, Ian Collins wrote: > On 03/26/17 08:51 AM, BartC wrote: >> > .ident "GCC: (GNU) 6.3.0" >> >> Maybe that makes a difference. But for how many decades has getc been a >> macro just for this purpose? Has gcc only just got round to it? > > No, the difference is -m64, which is odd... I tested with -m32, and tried -m64 to see if it made a difference. It didn't. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-25 13:43 -0700 |
| Message-ID | <ln60ix84va.fsf@kst-u.example.com> |
| In reply to | #107058 |
BartC <bc@freeuk.com> writes:
[...]
> Maybe that makes a difference. But for how many decades has getc been a
> macro just for this purpose? Has gcc only just got round to it?
gcc doesn't provide getc. If you're on Windows, you're probably using a
different library implementation than is commonly used on Linux.
The compiler sees a call to getc(), and it generates code for it in
accordance with the declaration (as a function, as an inline function,
or as a macro) it sees in <stdio.h>.
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-26 10:30 +1300 |
| Message-ID | <ejo5r6Frv02U4@mid.individual.net> |
| In reply to | #107070 |
On 03/26/17 09:43 AM, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > [...] >> Maybe that makes a difference. But for how many decades has getc been a >> macro just for this purpose? Has gcc only just got round to it? > > gcc doesn't provide getc. If you're on Windows, you're probably using a > different library implementation than is commonly used on Linux. > > The compiler sees a call to getc(), and it generates code for it in > accordance with the declaration (as a function, as an inline function, > or as a macro) it sees in <stdio.h>. That was the reply I originally typed. The odd thing was that on my Solaris machine, gcc (unlike Sun cc) calls getc() in 64 bit mode but expands the macro in 32 bit mode. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2017-03-26 10:23 +0200 |
| Message-ID | <87r31k4fb1.fsf@news.bourguet.org> |
| In reply to | #107076 |
Ian Collins <ian-news@hotmail.com> writes: > That was the reply I originally typed. The odd thing was that on my > Solaris machine, gcc (unlike Sun cc) calls getc() in 64 bit mode but > expands the macro in 32 bit mode. A differente default for threading support? POSIX mandates that getc is thread save and has getc_unlocked for the case where you can handle such issue yourself. Yours, -- Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-24 15:08 -0700 |
| Message-ID | <0b965946-ab59-43b6-8a95-6e224b9d40c7@googlegroups.com> |
| In reply to | #107004 |
On Friday, March 24, 2017 at 4:18:08 PM UTC-5, Bart wrote:
> 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.
It is often convenient to have FILE be a struct whose layout coincides with
some sort of file-based structure used in the underlying system, but all that
really matters is that all code which uses FILE* as anything other than an
opaque pointer use it the same way. In fact, FILE doesn't even need to be
a defined struct, and file pointers don't have to point at *anything*. If
some underlying system assigns all files a handle from 0 to 255, and code
knows of any static object which is at least 256 bytes, then fopen() could do
something like
int fileNumber = openFile(...); // A method that returns 1-255 on success
if (fileNumber > 0)
return (FILE*)((char*)dummyObject)+fileNumber;
and fwrite() could do something like:
int fileNumber = (char*)theFile - (char*)dummyObject;
writeFile(fileNumber, ...);
Such code would be fully portable to any system with a suitable set of I/O
functions and the 256-byte object. The behavior of all the pointer arithmetic
would be fully defined by the C Standard.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-24 22:43 +0000 |
| Message-ID | <ob479t$h4m$1@dont-email.me> |
| In reply to | #107009 |
On 24/03/2017 22:08, supercat@casperkitty.com wrote: > On Friday, March 24, 2017 at 4:18:08 PM UTC-5, Bart wrote: >> 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. > > It is often convenient to have FILE be a struct whose layout coincides with > some sort of file-based structure used in the underlying system, but all that > really matters is that all code which uses FILE* as anything other than an > opaque pointer use it the same way. When I use FILE* types from outside of the C language, I just use the equivalent of void*. But I haven't yet managed to get hold of stdin/stdout which are surprisingly difficult when no C headers are involved. However I now know I can use _iob/_iob_func under Windows; I'll have to find the equivalent for Linux. -- bart
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-24 15:55 -0700 |
| Message-ID | <16b91e7c-08c8-4fad-b072-41fbdeea615e@googlegroups.com> |
| In reply to | #107013 |
On Friday, March 24, 2017 at 5:44:04 PM UTC-5, Bart wrote:
> But I haven't yet managed to get hold of stdin/stdout which are
> surprisingly difficult when no C headers are involved.
What does the Standard require of those? I would think that on some platforms
it would be most useful to say
FILE stdin[1];
and on some it would be more helpful to say:
FILE *stdin = (FILE*)&stdin_descriptor;
while others might use something like:
FILE *stdin = (FILE*)1; // Dummy address that won't identify a real object
Would the Standard forbid any of those (bearing in mind that the first would
require that headers declare stdin as FILE[], while the others would need it
to be declared as FILE*)? I could certainly imagine situations where each
could be superior.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-24 16:27 -0700 |
| Message-ID | <lninmy8ddj.fsf@kst-u.example.com> |
| In reply to | #107014 |
supercat@casperkitty.com writes:
> On Friday, March 24, 2017 at 5:44:04 PM UTC-5, Bart wrote:
>> But I haven't yet managed to get hold of stdin/stdout which are
>> surprisingly difficult when no C headers are involved.
>
> What does the Standard require of those? I would think that on some platforms
> it would be most useful to say
>
> FILE stdin[1];
>
> and on some it would be more helpful to say:
>
> FILE *stdin = (FILE*)&stdin_descriptor;
>
> while others might use something like:
>
> FILE *stdin = (FILE*)1; // Dummy address that won't identify a real object
>
> Would the Standard forbid any of those (bearing in mind that the first would
> require that headers declare stdin as FILE[], while the others would need it
> to be declared as FILE*)? I could certainly imagine situations where each
> could be superior.
stdin, stdout, and stderr are required to be macros, so you'd
additionally need something like:
#define stdin stdin
#define stdout stdout
#define stderr stderr
(GNU libc does this.)
Your first suggestion:
FILE stdin[1];
would be non-conforming, since stdin is required to expand to an
expression of type FILE*.
Making FILE an incomplete type is a mildly interesting idea, but some
stdio functions are commonly defined as macros that access the members
of the FILE object. They'd have to use pointer casts to some complete
type.
--
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 | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-25 01:17 +0100 |
| Message-ID | <ob4cor$3mt$2@dont-email.me> |
| In reply to | #107015 |
Le 25/03/2017 à 00:27, Keith Thompson a écrit : > Making FILE an incomplete type is a mildly interesting idea, Implemented in lcc-win 64.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-25 01:18 +0100 |
| Message-ID | <ob4cqg$3mt$3@dont-email.me> |
| In reply to | #107015 |
Le 25/03/2017 à 00:27, Keith Thompson a écrit : > some > stdio functions are commonly defined as macros that access the members > of the FILE object They are real functions when the pointer is opaque. They can be easily inlined though, but I haven't done that yet.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-27 15:06 +0000 |
| Message-ID | <0U9CA.121647$Ip6.104616@fx38.iad> |
| In reply to | #107004 |
BartC <bc@freeuk.com> writes:
>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;
Ah, so you don't care about thread-safety, it appears. Your
data structure layout also leaves holes on 64-bit systems.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-27 16:37 +0100 |
| Message-ID | <obbbf3$ack$1@dont-email.me> |
| In reply to | #107157 |
On 27/03/2017 16:06, Scott Lurndal wrote:
> BartC <bc@freeuk.com> writes:
>> 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;
>
> Ah, so you don't care about thread-safety, it appears.
It was lifted from MS's own headers (the ones supplied with MSVC2008, a
32-bit system):
struct _iobuf {
char *_ptr;
int _cnt;
char *_base;
int _flag;
int _file;
int _charbuf;
int _bufsiz;
char *_tmpfname;
};
typedef struct _iobuf FILE;
> Your
> data structure layout also leaves holes on 64-bit systems.
C requires padding on such a structure for 64-bit pointers. I don't know
what struct is actually used, but the size is 48 bytes, and mine is 48
bytes, which is all that is really needed.
I don't know what significance the presence of padding holes has.
BTW here's the struct as defined in the Tiny C's stdio.h for 64-bit Windows:
struct _iobuf {
char *_ptr;
int _cnt;
char *_base;
int _flag;
int _file;
int _charbuf;
int _bufsiz;
char *_tmpfname;
};
typedef struct _iobuf FILE;
Look familiar? And actually, it's identical to what's used in
gcc/mingw's stdio.h. I hadn't bothered looking before because I assumed
it would be something horrendous.
Anyway, if you're saying my header has something wrong with it
(obviously, trying to belittle my efforts), then you need to complain to
the gcc/mingw people too.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-27 16:25 +0000 |
| Message-ID | <R1bCA.225726$ff2.15867@fx41.iad> |
| In reply to | #107162 |
BartC <bc@freeuk.com> writes:
>On 27/03/2017 16:06, Scott Lurndal wrote:
>>> 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;
>>
>> Ah, so you don't care about thread-safety, it appears.
>
>It was lifted from MS's own headers (the ones supplied with MSVC2008, a
>32-bit system):
So what? MS is hardly an exemplar of intelligent operating system
design.
>> Your
>> data structure layout also leaves holes on 64-bit systems.
>
>C requires padding on such a structure for 64-bit pointers. I don't know
>what struct is actually used, but the size is 48 bytes, and mine is 48
>bytes, which is all that is really needed.
You could easily reduce that to 44 bytes by simply rearranging
the order of the elements. Anything to make more effective use
of the limited L1/L2 cache heirarchies is useful, particuarly in
library code. Four bytes may not seem much, but for an array of
several hundred FILE instances, it adds up quickly.
>Anyway, if you're saying my header has something wrong with it
>(obviously, trying to belittle my efforts), then you need to complain to
>the gcc/mingw people too.
I simply pointed out:
1) You don't take into account that many of the functions that
access FILE are required to be thread-safe (e.g. getc),
so one would expect some form of mutual exclusion mechanism
to be included in struct FILE.
2) One should, in library code, be very cognizent of the data
structure layout for performance reasons.
Here's one on linux:
struct _IO_FILE {
int _flags; /* 0 4 */
/* XXX 4 bytes hole, try to pack */
char * _IO_read_ptr; /* 8 8 */
char * _IO_read_end; /* 16 8 */
char * _IO_read_base; /* 24 8 */
char * _IO_write_base; /* 32 8 */
char * _IO_write_ptr; /* 40 8 */
char * _IO_write_end; /* 48 8 */
char * _IO_buf_base; /* 56 8 */
/* --- cacheline 1 boundary (64 bytes) --- */
char * _IO_buf_end; /* 64 8 */
char * _IO_save_base; /* 72 8 */
char * _IO_backup_base; /* 80 8 */
char * _IO_save_end; /* 88 8 */
class _IO_marker * _markers; /* 96 8 */
class _IO_FILE * _chain; /* 104 8 */
int _fileno; /* 112 4 */
int _flags2; /* 116 4 */
__off_t _old_offset; /* 120 8 */
/* --- cacheline 2 boundary (128 bytes) --- */
short unsigned int _cur_column; /* 128 2 */
signed char _vtable_offset; /* 130 1 */
char _shortbuf[1]; /* 131 1 */
/* XXX 4 bytes hole, try to pack */
_IO_lock_t * _lock; /* 136 8 */
__off64_t _offset; /* 144 8 */
void * __pad1; /* 152 8 */
void * __pad2; /* 160 8 */
void * __pad3; /* 168 8 */
void * __pad4; /* 176 8 */
size_t __pad5; /* 184 8 */
/* --- cacheline 3 boundary (192 bytes) --- */
int _mode; /* 192 4 */
char _unused2[20]; /* 196 20 */
/* size: 216, cachelines: 4, members: 29 */
/* sum members: 208, holes: 2, sum holes: 8 */
/* last cacheline: 24 bytes */
};
Yes, they have holes - I suspect they're there for backward
compatability.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-27 17:57 +0000 |
| Message-ID | <0ocCA.153936$sJ.141218@fx06.iad> |
| In reply to | #107170 |
scott@slp53.sl.home (Scott Lurndal) writes:
>BartC <bc@freeuk.com> writes:
>>On 27/03/2017 16:06, Scott Lurndal wrote:
>
>>>> 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;
>>>
>>Anyway, if you're saying my header has something wrong with it
>>(obviously, trying to belittle my efforts), then you need to complain to
>>the gcc/mingw people too.
>
>
>Here's one on linux:
>
>struct _IO_FILE {
[omitted]
> char _unused2[20]; /* 196 20 */
>
> /* size: 216, cachelines: 4, members: 29 */
> /* sum members: 208, holes: 2, sum holes: 8 */
> /* last cacheline: 24 bytes */
>};
And the one thing you should take home from this example is that
they've futureproofed the structure by leaving unused bytes
at the end to support adding new fields in the future without
breaking binary compatability with existing applications.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-27 19:12 +0100 |
| Message-ID | <obbkhb$ebg$1@dont-email.me> |
| In reply to | #107170 |
On 27/03/2017 17:25, Scott Lurndal wrote:
> BartC <bc@freeuk.com> writes:
>> On 27/03/2017 16:06, Scott Lurndal wrote:
>
>>>> 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;
>>>
>>> Ah, so you don't care about thread-safety, it appears.
>>
>> It was lifted from MS's own headers (the ones supplied with MSVC2008, a
>> 32-bit system):
>
> So what? MS is hardly an exemplar of intelligent operating system
> design.
I'm not sure what you're on about. Are you having a go at me or at
Microsoft, or both?
In any case, you don't seem to understand that I can't just make up my
own FILE structure, it has to be compatible with what is exported by
MSVCRT.DLL. If I was making up my own stuff, I wouldn't stop with just
one small structure, I would change everything, including the language
(this is what I used to do actually).
> You could easily reduce that to 44 bytes by simply rearranging
> the order of the elements. Anything to make more effective use
> of the limited L1/L2 cache heirarchies is useful, particuarly in
> library code. Four bytes may not seem much, but for an array of
> several hundred FILE instances, it adds up quickly.
Then it won't work because it has to be 48 bytes to work properly with
the FILE _iob[] array exported by MSVCRT.DLL. The first three elements
have been set up to work as C's stdin, stdout and stdout descriptors.
The stride used is 48 bytes.
(For just that purpose, I can hard-code the 48 bytes via char pointer
casts, but then it won't work in 32 bits. This way it should work on both.)
> I simply pointed out:
> 2) One should, in library code, be very cognizent of the data
> structure layout for performance reasons.
In every other case, I do exactly that. In spades. My structs are
usually carefully crafted to be a power-of-two bytes in size, if there
are going to be lots of them. Here's one which looks bigger but is
actually only 16 bytes:
struct _varrec {
union {
struct {
uint16 tag;
byte hasref;
union {
byte stackadj;
byte opdims;
byte ittype;
};
};
uint32 tagx;
};
union {
struct {
uint16 refelemtag;
byte refbitoffset;
byte spare2;
};
struct {
int16 frameoffset;
byte exceptiontype;
byte nexceptions;
};
int32 frameptr_low;
int32 itcount;
int32 bndigits;
};
union {
objrec * objptr;
struct _varrec* varptr;
byte * packptr;
byte * ptr;
int64 * dptr;
int64 value;
uint64 uvalue;
double xvalue;
int32 * retaddr;
struct {
int32 range_lower;
int32 range_upper;
};
};
};
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-03-27 14:19 -0500 |
| Message-ID | <evoidchfv8ihn6k484silqoa5uq2cshtdo@4ax.com> |
| In reply to | #107170 |
On Mon, 27 Mar 2017 16:25:21 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:
>BartC <bc@freeuk.com> writes:
>>On 27/03/2017 16:06, Scott Lurndal wrote:
>
>>>> 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;
>>>
>>> Ah, so you don't care about thread-safety, it appears.
>>
>>It was lifted from MS's own headers (the ones supplied with MSVC2008, a
>>32-bit system):
>
>So what? MS is hardly an exemplar of intelligent operating system
>design.
Given that few programs likely create large numbers of FILE
structures, a bit of excess padding is not much of an issue. Plus
that way MS didn't have to do a different version for Win64 (which
would have given BartC another #ifdef to complain about). Besides it
wouldn't have actually made any difference anyway (see below).
>>> Your
>>> data structure layout also leaves holes on 64-bit systems.
>>
>>C requires padding on such a structure for 64-bit pointers. I don't know
>>what struct is actually used, but the size is 48 bytes, and mine is 48
>>bytes, which is all that is really needed.
>
>You could easily reduce that to 44 bytes by simply rearranging
>the order of the elements. Anything to make more effective use
>of the limited L1/L2 cache heirarchies is useful, particuarly in
>library code. Four bytes may not seem much, but for an array of
>several hundred FILE instances, it adds up quickly.
You probably actually couldn't. With 64-bit pointers, the minimum
alignment for the structure would (usually) be 8 bytes, and you'd
ended up with four bytes of padding at the end of each instance for an
array. Nor would those extra four bytes usually be enough to allow a
smaller physical allocation if each instance were malloc'd.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-24 19:25 +0100 |
| Message-ID | <ob3o4l$rhq$1@dont-email.me> |
| In reply to | #106963 |
On 24/03/17 18:57, BartC wrote: > On 24/03/2017 14:43, David Brown wrote: >> On 24/03/17 13:39, BartC wrote: > >>> __builtin_expect is something to do with you telling the compiler >>> whether you think some particular expression is more likely to be true >>> than false, or something along those lines. >> >> First, read the manual - then you will have some basis for commenting: >> >> <https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fexpect> >> >> >> __builtin_expect(x, y) has the value "x", but tells the compiler that >> "x" is probably equal to "y". A typical use is the Linux macros: >> >> #define likely(x) __builtin_expect((x),1) >> #define unlikely(x) __builtin_expect((x),0) >> >> Thus you can write: >> >> if (likely(n > 3)) ... >> >> and know that the compiler will use branch prediction instructions or >> optimisation on the assumption that "n > 3" should be the fastest path. > > Suppose you get it wrong? Then your code is a little slower than it could be. > > Anyway the real problem is writing things like __builtin_expect(....) > all over the place (and dozens of other examples), and then trying to > compile it on something that doesn't understand __builtin_expect. I > don't want to have implement both C and half of gcc, even if the latter > justinvolves having to look all this stuff up and devising a workaround. > It is a pretty minor part of writing a C compiler, I would think. > (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.) Implementation-specific files are allowed to use implementation-specific extensions. And an OS or library is allowed to place requirements on the compilers used for it. There are several compilers typically used on Linux systems (gcc, clang, icc, plus a few others). They manage all right. > >> #define __builtin_expect(x, y) (x) > > It's not standard C, so I'm not interested. I just wanted to compile > some code not get involved in gcc yet again. The above define is perfectly good standard C (with an implementation reserved identifier). > >> That is because Linux - like most operating systems except Windows - has >> system headers to let people write programs for their system. And these >> system headers are /not/ the same as a compiler's standard headers, and >> the compiler's standard headers are not the same as the C library's >> headers. In the Windows world, these are usually thrown together in one >> lump because the OS does not have standard headers, and because >> compilers for Windows usually don't have a choice of libraries. > > I'm not talking about OS system headers, but the standard headers from > the C standard. The C standard describes some of the features of the standard headers, it does not give them as complete files. (They don't even have to /be/ files.) > > For Windows, I plan to use the C library provided in msvcrt.dll. For > Linux, I think the equivalent is libc.so.6. Yes. But people typically want more than just the standard C library - they usually also want access to OS-specific functions. > > The standard headers need to provide function signatures for functions > exported from those libraries. Plus define those other entities > mentioned in the C standard (NULL for example). > > There doesn't seem to me to be much to it. > > Now, to go beyond the C standard library, in Windows a big give-away is > the presence of windows.h, which I don't intend to duplicate at the > minute (I can borrow one from an existing compiler, but not gcc because > it's full of advanced gcc-specific features and is also up to 20 times > the size of the smallest). > > In Linux, it's a bit tricker - perhaps headers such as dirent.h. The > dividing line between C functions and OS functions isn't as clear, and > people will probably use headers from either without even thinking about > it. > > This is why I'm only bothering with C sources either known to compile on > Windows with /any/ compiler, or that are designed to, and do, compile on > both OSes. > > Supporting dirent.h etc can come later, however debugging what goes > wrong is hard if the only other compiler I can compare with happens to > be gcc. > >>> The same program using Linux headers will fetch 80 includes. > >> So what? > > So 800 would be no problem? What about 8000? We are still talking about > STANDARD C. The library isn't that big, but you're not curious as to why > Linux and/or gcc make such a meal of it? > I have a reasonable idea of why there are many files included by Linux and/or gcc. And I don't see a problem with it.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-24 08:10 -0700 |
| Message-ID | <4097edfd-bc57-44bb-b45b-51883e8fc93e@googlegroups.com> |
| In reply to | #106900 |
On Friday, March 24, 2017 at 7:39:18 AM UTC-5, Bart wrote: > __builtin_expect is something to do with you telling the compiler > whether you think some particular expression is more likely to be true > than false, or something along those lines. > > You don't want stuff like that cluttering up your code. If you're going > to those lengths, then you might as well write assembly code. In order for an entity (human or automated) to generate efficient code, it needs to know a variety of things. There are some things programmers will know more about than a compiler (e.g. what kinds of inputs is a program more likely to receive, or which parts of a program will cause more annoyance if they run slowly) and there are some things a compiler is likely to know more about than a programmer (e.g. how will the costs of different alternative versions of a piece of code compare in the "true" and "false" cases). The purpose of things like "expect" directives generally isn't to compel compilers to generate code a precise way, but rather to give the compiler information which it may use or not as it sees fit; a good compiler should be able to combine that information with the things it knows to make good decisions about code generation. If the programmer doesn't tell the compiler which branches will be more likely *with the kinds of input the program is expected to receive* how is a compiler supposed to know?
[toc] | [prev] | [next] | [standalone]
Page 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web