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 4 of 15 — ← Prev page 1 2 3 [4] 5 6 … 15 Next page →
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-04-27 18:20 -0500 |
| Message-ID | <r3u4gcdvfg2h8jo31thmk54ikhuk8pqifi@4ax.com> |
| In reply to | #108603 |
On Thu, 27 Apr 2017 07:13:20 -0700, Tim Rentsch
<txr@alumni.caltech.edu> wrote:
>Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> [...] one thing I've wished for in printf is a way to specify a
>> *maximum* output width* (which could combine with a minimum width
>> to create a fixed width field), [...]
>
>This is an interesting idea; maybe it's worth adding to printx().
>What do you think of, eg
>
> %12:15.2f
>
>as a specification for between 12 and 15 columns?
That's nicer than what I had in mind. Obviously a specification of
"*" would be allowed as well.
>Also, what happens if the maximum width cannot accommodate a
>complete representation? For example, if we have a call
>like
>
> printx( "%2:4d\n", 12345 );
>
>what should be printed? FORTRAN's answer to this was
>to print *'s in all columns (ie, of the maximum width
>specified). I'm not sure that's such a great idea,
>but what's better?
If it doesn't fit, asterisks are fine with me, although crosshatches
("####") might be more fashionable. Or something like "#ERR"
(although that has the disadvantage of not scaling to very short
output fields).
For integer types the notion of "fitting" is pretty straight-forward.
For floating types it would probably be useful to have an intermediate
stage where the precision is reduced (so 12345. in a six character
field would print as "123456", but 1234560000. would print as
"1.2E+9"). Perl or Python (or maybe both) already do that.
>Related question: for strings, is a maximum width treated the
>same as a maximum length (ie, precision), or are those different?
>Eg, for a call like
>
> printx( "%5:10s\n", "internationalization" );
>
>should that be the same as a "%5.10s\n" format, or might it
>do something different?
Hard to say. The precision will cause truncation if the string is too
long ("internatio" in your example), perhaps for consistency exceeding
the maximum width should generate the "too big" output instead
("##########").
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-04-30 14:23 -0700 |
| Message-ID | <kfn37cp1tfe.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #108633 |
Robert Wessel <robertwessel2@yahoo.com> writes:
> On Thu, 27 Apr 2017 07:13:20 -0700, Tim Rentsch
> <txr@alumni.caltech.edu> wrote:
>
>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>
>>> [...] one thing I've wished for in printf is a way to specify a
>>> *maximum* output width* (which could combine with a minimum width
>>> to create a fixed width field), [...]
>>
>> This is an interesting idea; maybe it's worth adding to printx().
>> What do you think of, eg
>>
>> %12:15.2f
>>
>> as a specification for between 12 and 15 columns?
>
> That's nicer than what I had in mind.
Pretty much just the first thing that popped into my head. I
think it's not too bad either for readability or to implement.
> Obviously a specification of "*" would be allowed as well.
Oh but of course! That goes without saying, or at least I
thought it did.
>> Also, what happens if the maximum width cannot accommodate a
>> complete representation? For example, if we have a call
>> like
>>
>> printx( "%2:4d\n", 12345 );
>>
>> what should be printed? FORTRAN's answer to this was
>> to print *'s in all columns (ie, of the maximum width
>> specified). I'm not sure that's such a great idea,
>> but what's better?
>
> If it doesn't fit, asterisks are fine with me, although crosshatches
> ("####") might be more fashionable.
Yes, I like the #### suggestion better. (In a whimsical moment
it occurred to me to use a sequence of non-alphanumeric characters
such as might be used to indicate swearing. Maybe that should be
under control of one of the flag characters. ;)
> Or something like "#ERR"
> (although that has the disadvantage of not scaling to very short
> output fields).
>
> For integer types the notion of "fitting" is pretty straight-forward.
> For floating types it would probably be useful to have an intermediate
> stage where the precision is reduced (so 12345. in a six character
> field would print as "123456", but 1234560000. would print as
> "1.2E+9"). Perl or Python (or maybe both) already do that.
Good suggestion. Probably won't be in release 1 though. :)
>> Related question: for strings, is a maximum width treated the
>> same as a maximum length (ie, precision), or are those different?
>> Eg, for a call like
>>
>> printx( "%5:10s\n", "internationalization" );
>>
>> should that be the same as a "%5.10s\n" format, or might it
>> do something different?
>
> Hard to say. The precision will cause truncation if the string is too
> long ("internatio" in your example), perhaps for consistency exceeding
> the maximum width should generate the "too big" output instead
> ("##########").
Yes, it's not obvious what the right choices are here. If you
come across use cases I definitely am interested to hear about
them.
In the meantime I have implemented the simple scheme that just
puts in #'s for any overly wide field, including doing nothing
if the maximum width is less than or equal to zero. I haven't
yet looked carefully at all the edge cases (and printf() has a
lot of those, plus I also need to look at how this feature should
interact with the printx() extensions), so still a bit of work
to do before it can be marked Done.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-30 18:18 -0700 |
| Message-ID | <d5b7ff59-9c3b-44bd-b950-815634789673@googlegroups.com> |
| In reply to | #108809 |
On Sunday, April 30, 2017 at 4:23:23 PM UTC-5, Tim Rentsch wrote: > Yes, I like the #### suggestion better. (In a whimsical moment > it occurred to me to use a sequence of non-alphanumeric characters > such as might be used to indicate swearing. Maybe that should be > under control of one of the flag characters. ;) Out of curiosity, how often would it be useful to have separate minimum and maximum lengths? In nearly all cases where there's a field-width specifier, it represents a value sufficient to hold all correct output, and anything longer than that should be viewed as an error. The only case I know of where that would not apply would be in some cases where e.g. %03d is used as an alternative to %.3d to ensure that at least three digits will be produced (which could be helpful if e.g. code inserts a decimal point three digits from the right). Otherwise, I don't see a use for specifying a minimum field width for blank padding. Either things fit, or there's an error and the only question will be how to handle it.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-01 12:12 -0500 |
| Message-ID | <scqegc1qoh1j9oa19t65albr3kar1cf6o4@4ax.com> |
| In reply to | #108829 |
On Sun, 30 Apr 2017 18:18:59 -0700 (PDT), supercat@casperkitty.com wrote: >On Sunday, April 30, 2017 at 4:23:23 PM UTC-5, Tim Rentsch wrote: >> Yes, I like the #### suggestion better. (In a whimsical moment >> it occurred to me to use a sequence of non-alphanumeric characters >> such as might be used to indicate swearing. Maybe that should be >> under control of one of the flag characters. ;) > >Out of curiosity, how often would it be useful to have separate minimum and >maximum lengths? In nearly all cases where there's a field-width specifier, >it represents a value sufficient to hold all correct output, and anything >longer than that should be viewed as an error. The only case I know of where >that would not apply would be in some cases where e.g. %03d is used as an >alternative to %.3d to ensure that at least three digits will be produced >(which could be helpful if e.g. code inserts a decimal point three digits >from the right). Otherwise, I don't see a use for specifying a minimum >field width for blank padding. Either things fit, or there's an error and >the only question will be how to handle it. Part of the problem is that you can't really change the existing behavior, so you can't alter the existing "minimum width" semantics. I agree that having (different) minimum and maximum widths on a single field would be relatively rare, but I do see some use cases. The other alternative would be to have a modifier of some sort that would change the interpretation of the existing minimum width to be a fixed/maximum width. But since I really want both of those (fixed and maximum width), then you have to have two modifiers so that you can interpret the length as min, max or fixed. So having "min:max" works out well (and "fixed" is just the case of having the same, non-zero, min and max).
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-01 11:14 -0700 |
| Message-ID | <f4de3dc0-c6f5-4e5b-adca-2f62e4466a22@googlegroups.com> |
| In reply to | #108896 |
On Monday, May 1, 2017 at 12:13:10 PM UTC-5, robert...@yahoo.com wrote: > Part of the problem is that you can't really change the existing > behavior, so you can't alter the existing "minimum width" semantics. I > agree that having (different) minimum and maximum widths on a single > field would be relatively rare, but I do see some use cases. The > other alternative would be to have a modifier of some sort that would > change the interpretation of the existing minimum width to be a > fixed/maximum width. But since I really want both of those (fixed and > maximum width), then you have to have two modifiers so that you can > interpret the length as min, max or fixed. So having "min:max" works > out well (and "fixed" is just the case of having the same, non-zero, > min and max). What realistic usage cases would not be accommodated by a flag character which, if present, would cause the system to handle the case where a field was wider than the specified width by replace a field with asterisks rather than outputting more data than specified? I suppose one might also want to combine the above with a "no-padding" option, but I tend to be a fan of the "don't repeat yourself" principle. If the most common usage case for a maximum-width specifier would have the minimum width be the same, such a case really shouldn't require specifying the width twice.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-01 13:29 -0500 |
| Message-ID | <kruegctghd5mmimqm8gi06nn48npliqs2f@4ax.com> |
| In reply to | #108914 |
On Mon, 1 May 2017 11:14:56 -0700 (PDT), supercat@casperkitty.com wrote: >On Monday, May 1, 2017 at 12:13:10 PM UTC-5, robert...@yahoo.com wrote: >> Part of the problem is that you can't really change the existing >> behavior, so you can't alter the existing "minimum width" semantics. I >> agree that having (different) minimum and maximum widths on a single >> field would be relatively rare, but I do see some use cases. The >> other alternative would be to have a modifier of some sort that would >> change the interpretation of the existing minimum width to be a >> fixed/maximum width. But since I really want both of those (fixed and >> maximum width), then you have to have two modifiers so that you can >> interpret the length as min, max or fixed. So having "min:max" works >> out well (and "fixed" is just the case of having the same, non-zero, >> min and max). > >What realistic usage cases would not be accommodated by a flag character >which, if present, would cause the system to handle the case where a field >was wider than the specified width by replace a field with asterisks rather >than outputting more data than specified? I suppose one might also want to >combine the above with a "no-padding" option, but I tend to be a fan of the >"don't repeat yourself" principle. If the most common usage case for a >maximum-width specifier would have the minimum width be the same, such a >case really shouldn't require specifying the width twice. There are three cases: a minimum width (what's supported now by the width specification on non-string items), a maximum length, and a fixed size. As I said, one option would be to have two modifiers to select max or fixed behavior instead of the default min. A possibly modification to the scheme being discussed would be to interpret a width specified as ":12" as "12:12" (and require "0:12" to be coded explicity, if desired), to handle the common (fixed width) case.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-27 16:00 -0700 |
| Message-ID | <34af2a35-94cf-420a-bbec-01a4f4302050@googlegroups.com> |
| In reply to | #107224 |
On Monday, March 27, 2017 at 5:22:23 PM UTC-5, Bart wrote:
> Yes, one way is to write an entirely new C library, then it doesn't
> matter how it's done. But there are some problems:
>
> (1) It's a huge amount of work
>
> (2) It will likely be tied to one OS, so I might need one for each target OS
That would depend upon how similar the target platforms are, and upon what
trade-offs you make between speed and portability.
> (3) I don't know if there are going to be clashes when my code using its
> own library interacts with functions in external shared libraries using
> a more standard one.
If you want to exchange pointers to FILE with existing code that uses some
library that defines such a type, then use that library.
> (4) I don't want to do it and hadn't planned to. There are perfectly
> good existing libraries, which already exist on my target OSes, and this
> is what I'd intended to use. (Actually my interpreted stuff already
> makes use of them.)
> > If one wants to use a C implementation to do the equivalent of
> > fprintf(stdout, "hello"); one should write a compilation unit like:
> >
> > #include <stdarg.h>
> > #include <stdio.h>
> > int do_fprintf(FILE *f, char const *restrict fmt, ...)
> > {
> > va_list vp;
> > va_start(va, fmt);
> > vfprintf(f, fmt, va);
> > va_end(vp);
> > }
> > FILE *get_stdout(void)
> > {
> > return stdout;
> > }
> >
> > which will export two functions which can be invoked from within assembly
> > language.
>
> Imagine if the C language didn't exist. But you still have a binary API
> that works remarkably similarly to the current C library. How could you
> call such functions?
In whatever function is defined by the API.
> And in fact the fprintf example wasn't concerned with variadic
> arguments, but getting access to the stdout used by the shared library.
>
> This is surprisingly difficult to obtain (outside of just using C).
> Sometimes you can get a file handle which does the same job, but it's
> not stdout. So if you passed it to a function which /did/ have access to
> the real thing, then f==stdout would be false.
The difficulty is that there is no defined way in C for code to export any
symbol which isn't the direct result of a compile-time-constant-size
allocation, but some implementations may define stdout in a fashion that
yields a link-time constant address which has some particular relation to
other such addresses, and the only way to do that is via macro.
> > C implementations may omit library code which is not used within
> > a C file, or may select from among different implementations of things like
> > fprintf() based upon the ways they see it invoked. If a C implementation
> > sees that none of the printf functions receive any format specifier more
> > complicated that %d or %u, it may link in an implementation that omits other
> > specifiers. If a machine-code function tries to call printf with other kinds
> > of format specifiers, the linked implementation might not work. If code
> > chains to vfprintf from an exported function, however, the implementation
> > would know that it would need to include an "fprintf" that could handle
> > anything.
>
> Well, hopefully I won't be implementing any printf functions!
The same principle applies with other functions as well.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-03-28 13:24 +0100 |
| Message-ID | <WBsCA.693042$Pm3.275418@fx42.am4> |
| In reply to | #107227 |
On 28/03/2017 00:00, supercat@casperkitty.com wrote:
> On Monday, March 27, 2017 at 5:22:23 PM UTC-5, Bart wrote:
>> Yes, one way is to write an entirely new C library, then it doesn't
>> matter how it's done. But there are some problems:
>>
>> (1) It's a huge amount of work
>>
>> (2) It will likely be tied to one OS, so I might need one for each target OS
>
> That would depend upon how similar the target platforms are, and upon what
> trade-offs you make between speed and portability.
One will be Win32, the other will be Linux.
On Win32, the file API is easy to recognise (CreateFile() etc, all a
pain to use, but only needs to be done once).
On Linux, I actually don't know. Is it POSIX and functions such as
open() instead of fopen()? The first example I looked at started with
#include <stdio.h> which presumably contains fopen as well.
Another source says the "C Standard Library ('libc') provides ... open,
read and write." Really, they are C standard functions?
This is why I keep saying it's difficult to split up what's part of
Linux, and what is part of C (sometimes I say it is Linux and gcc that
are hard to split; certainly Linux, C and gcc seem very cosy).
As for the relationship between Linux and Unix and whether any Linux
stuff will work on the latter, I've no idea.
Anyway, the Windows and Linux platforms are quite different. I would
expect to write libraries in other areas that need to work on both, but
not for things already covered by the standard C library.
>> This is surprisingly difficult to obtain (outside of just using C).
>> Sometimes you can get a file handle which does the same job, but it's
>> not stdout. So if you passed it to a function which /did/ have access to
>> the real thing, then f==stdout would be false.
>
> The difficulty is that there is no defined way in C for code to export any
> symbol which isn't the direct result of a compile-time-constant-size
> allocation, but some implementations may define stdout in a fashion that
> yields a link-time constant address which has some particular relation to
> other such addresses, and the only way to do that is via macro.
CLOCKS_PER_SECOND is another tricky one. I just assumed it was 1000 on
Windows and 1000000 on Linux, but a recent test seemed to indicate it
was 1000 on Linux too (despite bits/time.h suggesting it should be 1000000).
It's a ridiculous thing to be a stumbling block. But then it always is.
(In my own languages, the equivalent of STDIN and STDOUT is just the
constant 0. Thats a little bit easier than all this malarky necessary
with C.)
--
Bartc
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-28 15:20 +0200 |
| Message-ID | <obdnpa$fae$1@dont-email.me> |
| In reply to | #107254 |
On 28/03/17 14:24, bartc wrote:
> On 28/03/2017 00:00, supercat@casperkitty.com wrote:
>> On Monday, March 27, 2017 at 5:22:23 PM UTC-5, Bart wrote:
>>> Yes, one way is to write an entirely new C library, then it doesn't
>>> matter how it's done. But there are some problems:
>>>
>>> (1) It's a huge amount of work
>>>
>>> (2) It will likely be tied to one OS, so I might need one for each
>>> target OS
>>
>> That would depend upon how similar the target platforms are, and upon
>> what
>> trade-offs you make between speed and portability.
>
> One will be Win32, the other will be Linux.
>
> On Win32, the file API is easy to recognise (CreateFile() etc, all a
> pain to use, but only needs to be done once).
>
> On Linux, I actually don't know. Is it POSIX and functions such as
> open() instead of fopen()? The first example I looked at started with
> #include <stdio.h> which presumably contains fopen as well.
>
> Another source says the "C Standard Library ('libc') provides ... open,
> read and write." Really, they are C standard functions?
>
> This is why I keep saying it's difficult to split up what's part of
> Linux, and what is part of C (sometimes I say it is Linux and gcc that
> are hard to split; certainly Linux, C and gcc seem very cosy).
>
> As for the relationship between Linux and Unix and whether any Linux
> stuff will work on the latter, I've no idea.
>
> Anyway, the Windows and Linux platforms are quite different. I would
> expect to write libraries in other areas that need to work on both, but
> not for things already covered by the standard C library.
>
>>> This is surprisingly difficult to obtain (outside of just using C).
>>> Sometimes you can get a file handle which does the same job, but it's
>>> not stdout. So if you passed it to a function which /did/ have access to
>>> the real thing, then f==stdout would be false.
>>
>> The difficulty is that there is no defined way in C for code to export
>> any
>> symbol which isn't the direct result of a compile-time-constant-size
>> allocation, but some implementations may define stdout in a fashion that
>> yields a link-time constant address which has some particular relation to
>> other such addresses, and the only way to do that is via macro.
>
> CLOCKS_PER_SECOND is another tricky one. I just assumed it was 1000 on
> Windows and 1000000 on Linux, but a recent test seemed to indicate it
> was 1000 on Linux too (despite bits/time.h suggesting it should be
> 1000000).
CLOCKS_PER_SECOND is 1000000 on Linux - it is a requirement of POSIX.
If your "recent test" indicated that it was 1000 on Linux, then your
recent test was incorrect - or you misunderstood what CLOCKS_PER_SECOND is.
It is common on Linux to have a "jiffies" rate of 1000 - that's the rate
of the main system timers for multi-tasking. But the value can differ
from system to system - sometimes a server build of the kernel will have
lower values for lower overhead, while a system designed for multimedia
or real-time work might have a kernel with a higher jiffie rate. And
that is precisely why CLOCKS_PER_SECOND is made constant for all POSIX
systems, so that you can get the same timing information regardless of
the actual rate of the internal timers.
>
> It's a ridiculous thing to be a stumbling block. But then it always is.
Of course it is a ridiculous thing to stumble on - so why are you
stumbling on it?
>
> (In my own languages, the equivalent of STDIN and STDOUT is just the
> constant 0. Thats a little bit easier than all this malarky necessary
> with C.)
>
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-28 16:50 +0100 |
| Message-ID | <obe0ir$fcu$1@dont-email.me> |
| In reply to | #107258 |
On 28/03/2017 14:20, David Brown wrote: > On 28/03/17 14:24, bartc wrote: >> CLOCKS_PER_SECOND is another tricky one. I just assumed it was 1000 on >> Windows and 1000000 on Linux, but a recent test seemed to indicate it >> was 1000 on Linux too (despite bits/time.h suggesting it should be >> 1000000). > > CLOCKS_PER_SECOND is 1000000 on Linux - it is a requirement of POSIX. > If your "recent test" indicated that it was 1000 on Linux, then your > recent test was incorrect - or you misunderstood what CLOCKS_PER_SECOND is. Probably, I'll have to get back to it. (This was the reason I need that couple of seconds delay a couple of weeks back, so that I could see whether my os_clock routine (a wrapper around clock()) returned ~2000 (msec) rather than 2 or 2000000.) > It is common on Linux to have a "jiffies" rate of 1000 - that's the rate > of the main system timers for multi-tasking. But the value can differ > from system to system - sometimes a server build of the kernel will have > lower values for lower overhead, while a system designed for multimedia > or real-time work might have a kernel with a higher jiffie rate. And > that is precisely why CLOCKS_PER_SECOND is made constant for all POSIX > systems, so that you can get the same timing information regardless of > the actual rate of the internal timers. > >> >> It's a ridiculous thing to be a stumbling block. But then it always is. > > Of course it is a ridiculous thing to stumble on - so why are you > stumbling on it? What is the purpose of defining CLOCKS_PER_SEC (not SECOND according to Keith) if it always 1000000? Well, if you start coding in slightly more adventurous waters where you don't have access to time.h (because of using a different language, or one language compiles and executes another, neither of which is C, etc) then these little details /can/ be obstacles if you're trying to use an exported clock() function. -- bart
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-28 09:28 -0700 |
| Message-ID | <lnh92d5pt6.fsf@kst-u.example.com> |
| In reply to | #107272 |
BartC <bc@freeuk.com> writes:
[...]
> What is the purpose of defining CLOCKS_PER_SEC (not SECOND according to
> Keith) if it always 1000000?
You know, rather than qualifying that with "according to Keith",
you could always check the C standard, which is exactly what I did.
You have a copy of n1570.pdf and a way to view it, yes? You have a
tendency to guess when it's completely unnecessary. Just look it up.
(I'm not criticizing you for getting the name wrong originally;
mistakes happen, and I've made plenty of them.)
Who says it's *always* 1000000? It's always 1000000 on systems
that conform to POSIX (and apparently on Windows systems as well),
but the C standard covers *all* conforming C implementations, not
just that subset. And even if it were always 10000000, having a
name for it is much more legible and less error-prone than using
a magic number.
You probably didn't even notice the extra 0 I snuck into the
previous paragraph.
> Well, if you start coding in slightly more adventurous waters where you
> don't have access to time.h (because of using a different language, or
> one language compiles and executes another, neither of which is C, etc)
> then these little details /can/ be obstacles if you're trying to use an
> exported clock() function.
Yes, some of what you're trying to do is difficult.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-28 19:45 +0100 |
| Message-ID | <obear5$kik$1@dont-email.me> |
| In reply to | #107279 |
On 28/03/2017 17:28, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> Well, if you start coding in slightly more adventurous waters ...
> Yes, some of what you're trying to do is difficult.
Thanks. According to David Brown, /nothing/ is ever difficult, nothing
is too complicated, and no tool is too slow!
Here's another example of a minor problem I had to solve this morning,
although only tangentially connected to C.
Usually a program invoked from the command line picks up all the
following parameters:
> program A B C
The three parameters are A B C (ignore the issue with Linux where
parameters involving * and ? can expand to any number).
But the program I'm writing, call it X, takes /some/ of the parameters,
and creates another program Y which runs under X. Y thinks it's a
command line program and itself expects to read some command line
parameters. The issue is this, given:
program A B C D E F
which of those parameters belong X, and which should be left over to be
consumed by Y? (And in fact, Y can itself create a third program Z,
still running under the original process, which might need input too.)
I looked at a few options, such as restricting the parameters for X,
bracketing them, but for the time being settled for an explicit
delimiter, to keep things flexible for all programs:
program A B : D E F
A,B are passed to X; D,E,F are available for Y. (But things like > need
to be shared, and ":" is not available as input to either program.)
A really silly little problem but it needed to be solved. Like
CLOCKS_PER_SEC and stdout.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-28 12:06 -0700 |
| Message-ID | <lnshlx43wr.fsf@kst-u.example.com> |
| In reply to | #107299 |
BartC <bc@freeuk.com> writes:
> On 28/03/2017 17:28, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> Well, if you start coding in slightly more adventurous waters ...
>
>> Yes, some of what you're trying to do is difficult.
>
> Thanks. According to David Brown, /nothing/ is ever difficult, nothing
> is too complicated, and no tool is too slow!
And there goes your credibility.
[...]
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-28 20:14 +0100 |
| Message-ID | <obech3$qgj$2@dont-email.me> |
| In reply to | #107308 |
On 28/03/17 20:06, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 28/03/2017 17:28, Keith Thompson wrote: >>> BartC <bc@freeuk.com> writes: >> >>>> Well, if you start coding in slightly more adventurous waters ... >> >>> Yes, some of what you're trying to do is difficult. >> >> Thanks. According to David Brown, /nothing/ is ever difficult, nothing >> is too complicated, and no tool is too slow! > > And there goes your credibility. No, that went a long time ago. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-28 20:24 +0100 |
| Message-ID | <obed3i$sqf$1@dont-email.me> |
| In reply to | #107308 |
On 28/03/2017 20:06, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 28/03/2017 17:28, Keith Thompson wrote: >>> BartC <bc@freeuk.com> writes: >> >>>> Well, if you start coding in slightly more adventurous waters ... >> >>> Yes, some of what you're trying to do is difficult. >> >> Thanks. According to David Brown, /nothing/ is ever difficult, nothing >> is too complicated, and no tool is too slow! > > And there goes your credibility. But has he ever admitted any of that? Even the last post from David Brown says as much: > A small 128 bit type with a few operations should be a great deal simpler. (I'm not sure what a /small/ 128-bit type is compared with a regular-sized one!) -- bart
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-28 21:33 +0200 |
| Message-ID | <obedks$unj$1@dont-email.me> |
| In reply to | #107314 |
On 28/03/17 21:24, BartC wrote: > On 28/03/2017 20:06, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: >>> On 28/03/2017 17:28, Keith Thompson wrote: >>>> BartC <bc@freeuk.com> writes: >>> >>>>> Well, if you start coding in slightly more adventurous waters ... >>> >>>> Yes, some of what you're trying to do is difficult. >>> >>> Thanks. According to David Brown, /nothing/ is ever difficult, nothing >>> is too complicated, and no tool is too slow! >> >> And there goes your credibility. > > But has he ever admitted any of that? > > Even the last post from David Brown says as much: > >> A small 128 bit type with a few operations should be a great deal > simpler. > > (I'm not sure what a /small/ 128-bit type is compared with a > regular-sized one!) > I meant a small implementation of a 128-bit type, or a implementation of a small number of operations for a 128-bit type. The request was for a 128-bit type with basic comparisons ==, < and >, along with the rather useful information that you have int64_t and uint64_t (and therefore a neat two's complement system with no odd sizes to worry about). And yes, implementing this is a simple matter, and vastly easier than creating a full 128-bit integer type integrated into a compiler (which is what the comparison referred to).
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-28 13:10 -0700 |
| Message-ID | <59e50218-350c-4bd0-8a11-b9ab7606a443@googlegroups.com> |
| In reply to | #107316 |
On Tuesday, March 28, 2017 at 2:33:40 PM UTC-5, David Brown wrote: > I meant a small implementation of a 128-bit type, or a implementation of > a small number of operations for a 128-bit type. The request was for a > 128-bit type with basic comparisons ==, < and >, along with the rather > useful information that you have int64_t and uint64_t (and therefore a > neat two's complement system with no odd sizes to worry about). I'm curious what purposes would be served by a 128-bit type outside of manual chunking optimizations (which would require a means of creating barriers which type-based aliasing analysis would not reach across), capturing the results of 64x64->128 multiplications (on processors that support them), or feeding dividends to 128/64->64r64 divisions (likewise). The only other applications that would need numbers that size (e.g. RSA cryptography) would need numbers a lot bigger.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-28 22:15 +0200 |
| Message-ID | <obeg3g$8da$1@dont-email.me> |
| In reply to | #107319 |
On 28/03/17 22:10, supercat@casperkitty.com wrote: > On Tuesday, March 28, 2017 at 2:33:40 PM UTC-5, David Brown wrote: >> I meant a small implementation of a 128-bit type, or a implementation of >> a small number of operations for a 128-bit type. The request was for a >> 128-bit type with basic comparisons ==, < and >, along with the rather >> useful information that you have int64_t and uint64_t (and therefore a >> neat two's complement system with no odd sizes to worry about). > > I'm curious what purposes would be served by a 128-bit type outside of > manual chunking optimizations (which would require a means of creating > barriers which type-based aliasing analysis would not reach across), > capturing the results of 64x64->128 multiplications (on processors that > support them), or feeding dividends to 128/64->64r64 divisions (likewise). > The only other applications that would need numbers that size (e.g. RSA > cryptography) would need numbers a lot bigger. > There are not many situations where you need a 128 bit integer. Cryptography is, as you say, a major use. And you get them as intermediary types - if you have scaled integers stored as 64-bit types and multiply them. You might also find them handy to store unique identification numbers of some sort, or for other sorts of non-numerical data. But in this case, you would have to ask the OP of the 128-bit integer thread.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-29 13:23 +0000 |
| Message-ID | <NzOCA.259403$IM7.109756@fx39.iad> |
| In reply to | #107319 |
supercat@casperkitty.com writes: >On Tuesday, March 28, 2017 at 2:33:40 PM UTC-5, David Brown wrote: >> I meant a small implementation of a 128-bit type, or a implementation of >> a small number of operations for a 128-bit type. The request was for a >> 128-bit type with basic comparisons ==, < and >, along with the rather >> useful information that you have int64_t and uint64_t (and therefore a >> neat two's complement system with no odd sizes to worry about). > >I'm curious what purposes would be served by a 128-bit type outside of How about in simulation? For example, simulation of a processor that has 128-bit SIMD registers...
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-28 21:29 +0200 |
| Message-ID | <obeddq$to3$1@dont-email.me> |
| In reply to | #107299 |
On 28/03/17 20:45, BartC wrote: > On 28/03/2017 17:28, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: > >>> Well, if you start coding in slightly more adventurous waters ... > >> Yes, some of what you're trying to do is difficult. > > Thanks. According to David Brown, /nothing/ is ever difficult, nothing > is too complicated, and no tool is too slow! I am fairly sure I have said no such thing. I have said that the speed of a tool is rarely the only important feature - and that a tool can be fast enough for speed not to be an issue, even if there are alternative tools that are faster. Maybe that was confusing you? And I certainly think a good proportion of the things you find extraordinarily difficult, complex or obtuse are not difficult at all. You have an extraordinary ability to wander into the fields, find little molehills, built them up into mountains of your imagination, and then stumble over them. And then you complain here as though it were somehow the fault of people who use Linux and/or gcc, conspiring to make your life difficult. But there are plenty of other things in programming that /are/ hard. That includes many things in cross-platform development - that's why for serious work, most people use toolkits or libraries where another group has done the work already.
[toc] | [prev] | [next] | [standalone]
Page 4 of 15 — ← Prev page 1 2 3 [4] 5 6 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web