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 3 of 15 — ← Prev page 1 2 [3] 4 5 … 15 Next page →
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-04-21 21:01 +0200 |
| Message-ID | <oddkoh$o6u$1@dont-email.me> |
| In reply to | #108191 |
Le 17/04/2017 à 04:09, Tim Rentsch a écrit : > jacobnavia <jacob@jacob.remcomp.fr> writes: > >> [...] >> >> I did implement printf since there is no compiler around that will >> understand 480 bit floats, or 128 bit integers, etc. > > I'm curious - did you implement the POSIX positional extensions? > ????? Whats that?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-21 12:33 -0700 |
| Message-ID | <lnd1c5r1x3.fsf@kst-u.example.com> |
| In reply to | #108316 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 17/04/2017 á 04:09, Tim Rentsch a écrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>
>>> [...]
>>>
>>> I did implement printf since there is no compiler around that will
>>> understand 480 bit floats, or 128 bit integers, etc.
>>
>> I'm curious - did you implement the POSIX positional extensions?
>>
>
> ?????
>
> Whats that?
http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html
Conversions can be applied to the nth argument after the format
in the argument list, rather than to the next unused argument. In
this case, the conversion specifier character % (see below) is
replaced by the sequence "%n$", where n is a decimal integer in
the range [1,{NL_ARGMAX}], giving the position of the argument
in the argument list. This feature provides for the definition
of format strings that select arguments in an order appropriate
to specific languages (see the EXAMPLES section).
For example
printf("%2$s, %1$s\n", "world", "hello");
prints
hello, world
in an implementation that supports the extension.
--
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-04-21 21:44 +0200 |
| Message-ID | <oddn8s$1qf$1@dont-email.me> |
| In reply to | #108317 |
Le 21/04/2017 à 21:33, Keith Thompson a écrit :
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> Le 17/04/2017 á 04:09, Tim Rentsch a écrit :
>>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>>
>>>> [...]
>>>>
>>>> I did implement printf since there is no compiler around that will
>>>> understand 480 bit floats, or 128 bit integers, etc.
>>>
>>> I'm curious - did you implement the POSIX positional extensions?
>>>
>>
>> ?????
>>
>> Whats that?
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html
>
> Conversions can be applied to the nth argument after the format
> in the argument list, rather than to the next unused argument. In
> this case, the conversion specifier character % (see below) is
> replaced by the sequence "%n$", where n is a decimal integer in
> the range [1,{NL_ARGMAX}], giving the position of the argument
> in the argument list. This feature provides for the definition
> of format strings that select arguments in an order appropriate
> to specific languages (see the EXAMPLES section).
>
> For example
> printf("%2$s, %1$s\n", "world", "hello");
> prints
> hello, world
> in an implementation that supports the extension.
>
Yes, I think I implemented that back then. But what has that to do with
qfloats?
By the way, my printf accepts qfloats with the "q" qualifier.
jacob
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-21 13:37 -0700 |
| Message-ID | <ln4lxhqyxp.fsf@kst-u.example.com> |
| In reply to | #108318 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 21/04/2017 à 21:33, Keith Thompson a écrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>> Le 17/04/2017 á 04:09, Tim Rentsch a écrit :
>>>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>>>
>>>>> [...]
>>>>>
>>>>> I did implement printf since there is no compiler around that will
>>>>> understand 480 bit floats, or 128 bit integers, etc.
>>>>
>>>> I'm curious - did you implement the POSIX positional extensions?
>>>>
>>>
>>> ?????
>>>
>>> Whats that?
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html
>>
[snip]
>>
>> For example
>> printf("%2$s, %1$s\n", "world", "hello");
>> prints
>> hello, world
>> in an implementation that supports the extension.
>>
>
> Yes, I think I implemented that back then. But what has that to do
> with qfloats?
As far as I can tell, nothing. Tim's question didn't appear to me to be
a response to your remarks about qfloats. I think he was curious simply
because you said you had implemented printf. (Of course I can't speak
for Tim, but his posting can be sporadic so I thought I'd offer my
interpretation.)
> By the way, my printf accepts qfloats with the "q" qualifier.
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-04-27 13:03 -0700 |
| Message-ID | <kfnvapp39ee.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #108318 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 21/04/2017 at 21:33, Keith Thompson a ecrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>> Le 17/04/2017 <<E1>> 04:09, Tim Rentsch a ecrit :
>>>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>>>
>>>>> [...]
>>>>>
>>>>> I did implement printf since there is no compiler around that will
>>>>> understand 480 bit floats, or 128 bit integers, etc.
>>>>
>>>> I'm curious - did you implement the POSIX positional extensions?
>>>
>>> ?????
>>>
>>> Whats that?
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html
>>
>> Conversions can be applied to the nth argument after the format
>> in the argument list, rather than to the next unused argument. In
>> this case, the conversion specifier character % (see below) is
>> replaced by the sequence "%n$", where n is a decimal integer in
>> the range [1,{NL_ARGMAX}], giving the position of the argument
>> in the argument list. This feature provides for the definition
>> of format strings that select arguments in an order appropriate
>> to specific languages (see the EXAMPLES section).
>>
>> For example
>> printf("%2$s, %1$s\n", "world", "hello");
>> prints
>> hello, world
>> in an implementation that supports the extension.
>
> Yes, I think I implemented that back then. But what has that to do
> with qfloats?
>
> By the way, my printf accepts qfloats with the "q" qualifier.
The accepting of qfloats, etc, is peripheral to my question.
Implementing printf() as it is in the ISO standard seems
relatively straightforward, if a bit tedious. The POSIX
positional format items look a bit harder; not impossible
of course just a bit harder, and I was curious what your
experience with that was.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-21 13:15 -0700 |
| Message-ID | <18c5460e-d14a-4989-a03a-fb3317d7038b@googlegroups.com> |
| In reply to | #108317 |
On Friday, April 21, 2017 at 2:33:37 PM UTC-5, Keith Thompson wrote:
> >> I'm curious - did you implement the POSIX positional extensions?
> >>
> >
> > ?????
> >
> > Whats that?
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html
>
> Conversions can be applied to the nth argument after the format
> in the argument list, rather than to the next unused argument. In
> this case, the conversion specifier character % (see below) is
> replaced by the sequence "%n$", where n is a decimal integer in
> the range [1,{NL_ARGMAX}], giving the position of the argument
> in the argument list. This feature provides for the definition
> of format strings that select arguments in an order appropriate
> to specific languages (see the EXAMPLES section).
>
> For example
> printf("%2$s, %1$s\n", "world", "hello");
> prints
> hello, world
> in an implementation that supports the extension.
If a format string requests the 5th argument, must it also do something
somewhere with the first four, or is there some format specifier that says,
e.g. "the third argument is a "long long" but there's no need to do anything
with its value"? Many platforms have no way to get the Nth argument without
knowing the types of all the previous arguments, and it's not clear how an
implementation could get that information. Did POSIX just abandon systems
which use varying amounts of stack space for different argument types, or
how were they expecting the new feature should work on such systems?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-21 13:35 -0700 |
| Message-ID | <ln8tmtqz1k.fsf@kst-u.example.com> |
| In reply to | #108319 |
supercat@casperkitty.com writes:
> On Friday, April 21, 2017 at 2:33:37 PM UTC-5, Keith Thompson wrote:
>> >> I'm curious - did you implement the POSIX positional extensions?
>> >>
>> >
>> > ?????
>> >
>> > Whats that?
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html
>>
>> Conversions can be applied to the nth argument after the format
>> in the argument list, rather than to the next unused argument. In
>> this case, the conversion specifier character % (see below) is
>> replaced by the sequence "%n$", where n is a decimal integer in
>> the range [1,{NL_ARGMAX}], giving the position of the argument
>> in the argument list. This feature provides for the definition
>> of format strings that select arguments in an order appropriate
>> to specific languages (see the EXAMPLES section).
>>
>> For example
>> printf("%2$s, %1$s\n", "world", "hello");
>> prints
>> hello, world
>> in an implementation that supports the extension.
>
> If a format string requests the 5th argument, must it also do something
> somewhere with the first four, or is there some format specifier that says,
> e.g. "the third argument is a "long long" but there's no need to do anything
> with its value"? Many platforms have no way to get the Nth argument without
> knowing the types of all the previous arguments, and it's not clear how an
> implementation could get that information. Did POSIX just abandon systems
> which use varying amounts of stack space for different argument types, or
> how were they expecting the new feature should work on such systems?
Quoting from the web page I cited:
The format can contain either numbered argument conversion
specifications (that is, "%n$" and "*m$"), or unnumbered argument
conversion specifications (that is, % and * ), but not both. The
only exception to this is that %% can be mixed with the "%n$"
form. The results of mixing numbered and unnumbered argument
specifications in a format string are undefined. When numbered
argument specifications are used, specifying the Nth argument
requires that all the leading arguments, from the first to the
(N-1)th, are specified in the format string.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-21 15:30 -0700 |
| Message-ID | <90fc9bf0-4d59-4908-baef-eca0b670b603@googlegroups.com> |
| In reply to | #108320 |
On Friday, April 21, 2017 at 3:35:42 PM UTC-5, Keith Thompson wrote: > > If a format string requests the 5th argument, must it also do something > > somewhere with the first four, or is there some format specifier that says, > > e.g. "the third argument is a "long long" but there's no need to do anything > > with its value"? Many platforms have no way to get the Nth argument without > > knowing the types of all the previous arguments, and it's not clear how an > > implementation could get that information. Did POSIX just abandon systems > > which use varying amounts of stack space for different argument types, or > > how were they expecting the new feature should work on such systems? > > Quoting from the web page I cited: > > The format can contain either numbered argument conversion > specifications (that is, "%n$" and "*m$"), or unnumbered argument > conversion specifications (that is, % and * ), but not both. The > only exception to this is that %% can be mixed with the "%n$" > form. The results of mixing numbered and unnumbered argument > specifications in a format string are undefined. When numbered > argument specifications are used, specifying the Nth argument > requires that all the leading arguments, from the first to the > (N-1)th, are specified in the format string. Thanks. I should have noticed that. I'm curious, though: what must one do if one wants the fourth argument to appear in the output but doesn't want the first three to appear, and the first three arguments are of type "double" or "long"? If the arguments were of type "int" one could make provision to gobble them by including an empty string argument and outputting that three times with precision specified by each of the three unwanted "int" arguments. If the arguments were of type "char*" one could make provision to gobble them by including string format conversions with a precision of zero. I don't see any way to gobble arguments of type "long" or "double" without producing output, however.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-04-21 18:44 -0500 |
| Message-ID | <r55lfc5vnmrg06r50krq35ohn29lvfaju6@4ax.com> |
| In reply to | #108322 |
On Fri, 21 Apr 2017 15:30:26 -0700 (PDT), supercat@casperkitty.com wrote: >On Friday, April 21, 2017 at 3:35:42 PM UTC-5, Keith Thompson wrote: >> > If a format string requests the 5th argument, must it also do something >> > somewhere with the first four, or is there some format specifier that says, >> > e.g. "the third argument is a "long long" but there's no need to do anything >> > with its value"? Many platforms have no way to get the Nth argument without >> > knowing the types of all the previous arguments, and it's not clear how an >> > implementation could get that information. Did POSIX just abandon systems >> > which use varying amounts of stack space for different argument types, or >> > how were they expecting the new feature should work on such systems? >> >> Quoting from the web page I cited: >> >> The format can contain either numbered argument conversion >> specifications (that is, "%n$" and "*m$"), or unnumbered argument >> conversion specifications (that is, % and * ), but not both. The >> only exception to this is that %% can be mixed with the "%n$" >> form. The results of mixing numbered and unnumbered argument >> specifications in a format string are undefined. When numbered >> argument specifications are used, specifying the Nth argument >> requires that all the leading arguments, from the first to the >> (N-1)th, are specified in the format string. > >Thanks. I should have noticed that. I'm curious, though: what must one >do if one wants the fourth argument to appear in the output but doesn't >want the first three to appear, and the first three arguments are of >type "double" or "long"? If the arguments were of type "int" one could >make provision to gobble them by including an empty string argument and >outputting that three times with precision specified by each of the three >unwanted "int" arguments. If the arguments were of type "char*" one could >make provision to gobble them by including string format conversions with >a precision of zero. I don't see any way to gobble arguments of type "long" >or "double" without producing output, however. I don't really see that as a common case: usually you'd use this sort of thing for internationalization, and then you'd not usually code a printf with any unneeded parameters. Why would the (say) French version of a message omit one of the data items in the message? I can see a handful of use cases, but not many. OTOH, 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), (something similar to what you can do in Perl), and being able to specify a zero width for that would provide for a suppression function, as well as a conditional suppression function if you allow the "*" syntax for the maximum width. *Other than for strings, where you can do that already.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-04-22 21:08 +0000 |
| Message-ID | <58fbc5d9.47089921@news.xs4all.nl> |
| In reply to | #108326 |
Robert Wessel <robertwessel2@yahoo.com> wrote: > I don't really see that as a common case: usually you'd use this sort > of thing for internationalization, and then you'd not usually code a > printf with any unneeded parameters. Why would the (say) French > version of a message omit one of the data items in the message? I can > see a handful of use cases, but not many. Because some languages have different linguistic constructs than others, and there is often no way to translate, e.g., grammatical gender into a language which doesn't have it. Mind you, in those cases where this matters it is likely that you'll be working with strings, and you can just pass "" in lieu of asking for an element not to be printed; but still, it would have been nice if there were an option to skip an element. Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-23 10:26 -0700 |
| Message-ID | <4de6ee87-6707-4f61-942a-d0cb1f19eaa8@googlegroups.com> |
| In reply to | #108326 |
On Friday, April 21, 2017 at 6:44:54 PM UTC-5, robert...@yahoo.com wrote:
> I don't really see that as a common case: usually you'd use this sort
> of thing for internationalization, and then you'd not usually code a
> printf with any unneeded parameters. Why would the (say) French
> version of a message omit one of the data items in the message? I can
> see a handful of use cases, but not many.
Normal printf would allow something like:
printf(format, hours, minutes, seconds, tenths, hundredths);
to output a time with a selectable degree of precision by changing the
format string. I can't think of many situations which would benefit
from the ability to permute arguments that wouldn't benefit more from the
additional ability to suppress them. If a flag were added to suppress all
output from a conversion, the only additional feature that would be needed
to allow rearrangement of arguments would be a "rewind" function. If a
! flag meant "suppress output" and a %^ flag would rewind the argument list
before processing the argument, then
printf(format, century, year, month, day);
could be made to output a date in the form day-month-year with a format of
"%!d%!d%!d%02d-%^!d%!d%02d-%^!d%02d"--a bit verbose, but the only new
features needed for printf would be a va_copy at the start, the "suppress
output" option, and a switch case to va_copy the starting point to the
current va_list.
An extension which would reduce verbosity without appreciably increasing the
storage requirement would be to add two more flag characters to set a
"bookmark" before conversion, or revert to the previously-set bookmark. That
would cut the format string to: "%!d%!d%!>d%02d-%<02d-%^!d%02d".
For more complicated situations, I would think that it would be useful to
define a signature for "produce output" and "output formatter" functions,
and use a compound literal rather than va_args. The formatting function
could be given an array of double-indirect pointers to a formatting function
that would accept a void* and a double-indirect pointer to an output
function. User code could then look something like:
strformat( destStr, destLength, formatString,
(FORMAT_ITEM[]) {
'Y',&FMT_ZPAD_INT(theYear / 100, 2),
'y',&FMT_ZPAD_INT(theYear % 100, 2),
'n',&FMT_MONTH_ABBR(theMonth, EnglishMonths),
'M',&FMT_ZPAD_INT(theMonth, 2),
'm',&FMT_INT(theMonth),
'D',&FMT_ZPAD_INT(theDay, 2),
'd',&FMT_INT(theDay),
0,0
});
and the formatting function could ensure that behavior would be defined for
all possible format strings, since the function would receive an array of
fixed-sized items, and the array would include a fixed end marker.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-23 19:08 +0100 |
| Message-ID | <E46LA.442337$Iy2.108664@fx28.am4> |
| In reply to | #108368 |
! If a flag were added to suppress all > output from a conversion, the only additional feature that would be needed > to allow rearrangement of arguments would be a "rewind" function. If a > ! flag meant "suppress output" and a %^ flag would rewind the argument list > before processing the argument, then > > printf(format, century, year, month, day); > > could be made to output a date in the form day-month-year with a format of > "%!d%!d%!d%02d-%^!d%!d%02d-%^!d%02d"--a bit verbose, but the only new > features needed for printf would be a va_copy at the start, the "suppress > output" option, and a switch case to va_copy the starting point to the > current va_list. > > An extension which would reduce verbosity without appreciably increasing the > storage requirement would be to add two more flag characters to set a > "bookmark" before conversion, or revert to the previously-set bookmark. That > would cut the format string to: "%!d%!d%!>d%02d-%<02d-%^!d%02d". Yet another little language that someone needs to know to understand what is purportedly C! (On top of the CPP, makefiles, compiler options for defining your own dialect, and miscellaneous external scripts). That might be a compact way of achieving a certain result, but it's hard to read and maintain. I would use straightforward means to do this even if long-winded: char* dest; *dest=0; dest += sprintf(dest, "(%d)", A); dest += sprintf(dest, "/%f ", B); and so on. Actually I don't know what you are trying to do above, which isn't a good sign (but is the input, and what is the output you're trying to achieve?). Adding custom user functions for this is fine, but I don't know about adding even more functionality to printf(), which already requires special features in a language. (When I pass a float argument to printf() on x64, I have to pass it in both an integer register and a floating point one. But only for variadic functions. But other stuff am I going to need to do?) > For more complicated situations, I would think that it would be useful to > define a signature for "produce output" and "output formatter" functions, > and use a compound literal rather than va_args. For even more complicated examples, I wouldn't want to have to read your code! I think the functionality needed to turn custom types into strings ought to be separate from sending those strings to some output via the printf family. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-23 14:26 -0700 |
| Message-ID | <81979333-35cc-4103-95c3-289150ac81c3@googlegroups.com> |
| In reply to | #108369 |
On Sunday, April 23, 2017 at 1:08:43 PM UTC-5, Bart wrote: > ! If a flag were added to suppress all > > output from a conversion, the only additional feature that would be needed > > to allow rearrangement of arguments would be a "rewind" function. If a > > ! flag meant "suppress output" and a %^ flag would rewind the argument list > > before processing the argument... > Yet another little language that someone needs to know to understand > what is purportedly C! (On top of the CPP, makefiles, compiler options > for defining your own dialect, and miscellaneous external scripts). > > That might be a compact way of achieving a certain result, but it's hard > to read and maintain. The "Positional features" of POSIX effectively define a different language for printf specifiers which is incompatible with the normal one, since printf format strings which use any positional arguments cannot use any non-positional arguments. By contrast, what I describe would merely add two flags to printf format specifiers while leaving everything else about them compatible with the existing ones; unlike the positional notation of POSIX, the new features could be combined with normal printf format strings. > I would use straightforward means to do this even if long-winded: > > char* dest; > *dest=0; > dest += sprintf(dest, "(%d)", A); > dest += sprintf(dest, "/%f ", B); > > and so on. > Actually I don't know what you are trying to do above, which isn't a > good sign (but is the input, and what is the output you're trying to > achieve?). The version with the custom formatter would be directed toward situations where it may be necessary to have a program assemble a string from a template which could have different components in arbitrary order, which seems to be the intended purpose of the POSIX positional notation. In many cases where such a thing would be desired, there would be a wide range of components that could be included in the string. While it might be possible to format all such components into strings without regard or whether a given template actually uses them, it would generally be more efficient to have a means of performing formatting of the various items if and when they actually get used within the template string, rather than formatting all of them in case they happen to be needed.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-23 16:52 -0700 |
| Message-ID | <lnfugyptqx.fsf@kst-u.example.com> |
| In reply to | #108375 |
supercat@casperkitty.com writes:
> On Sunday, April 23, 2017 at 1:08:43 PM UTC-5, Bart wrote:
>> > ! If a flag were added to suppress all output from a conversion,
>> > the only additional feature that would be needed to allow
>> > rearrangement of arguments would be a "rewind" function. If a !
>> > flag meant "suppress output" and a %^ flag would rewind the
>> > argument list before processing the argument...
>
>> Yet another little language that someone needs to know to understand
>> what is purportedly C! (On top of the CPP, makefiles, compiler options
>> for defining your own dialect, and miscellaneous external scripts).
>>
>> That might be a compact way of achieving a certain result, but it's
>> hard to read and maintain.
>
> The "Positional features" of POSIX effectively define a different
> language for printf specifiers which is incompatible with the normal
> one,
I don't believe it's incompatible.
> since printf format strings which use any positional arguments cannot
> use any non-positional arguments.
Standard format strings can't use positional arguments at all.
Perhaps you meant something different by "incompatible", but I believe
the POSIX extension applies meanings only to strings that would cause
printf to have undefined behavior in ISO C.
[...]
You format your posts with lines up to 80 columns, which means when I
quote you I often have to reformat to avoid warnings. Can you please
format to, say, 72 or so columns to allow for quoting?
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-23 16:31 -0700 |
| Message-ID | <lnshkypup8.fsf@kst-u.example.com> |
| In reply to | #108368 |
supercat@casperkitty.com writes:
> On Friday, April 21, 2017 at 6:44:54 PM UTC-5, robert...@yahoo.com wrote:
>> I don't really see that as a common case: usually you'd use this sort
>> of thing for internationalization, and then you'd not usually code a
>> printf with any unneeded parameters. Why would the (say) French
>> version of a message omit one of the data items in the message? I can
>> see a handful of use cases, but not many.
>
> Normal printf would allow something like:
>
> printf(format, hours, minutes, seconds, tenths, hundredths);
>
> to output a time with a selectable degree of precision by changing the
> format string. I can't think of many situations which would benefit
> from the ability to permute arguments that wouldn't benefit more from the
> additional ability to suppress them.
I can. I think the most common use for the POSIX positional
extensions is for localization. The format string is selected
depending on the current language, with the ability to show arguments
in different orders depending on the language syntax. That's a
very common requirement. I don't think I've ever encountered a
case where suppressing some items would be useful.
But if you think it's useful, I encourage you to implement it so
there's something to cite as existing practice.
[...]
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-23 20:42 -0700 |
| Message-ID | <18e723f9-df44-4165-8578-4daa9253b17e@googlegroups.com> |
| In reply to | #108378 |
On Sunday, April 23, 2017 at 6:31:37 PM UTC-5, Keith Thompson wrote: > I can. I think the most common use for the POSIX positional > extensions is for localization. The format string is selected > depending on the current language, with the ability to show arguments > in different orders depending on the language syntax. That's a > very common requirement. I don't think I've ever encountered a > case where suppressing some items would be useful. If some cultures use 12-hour time format and others use 24-hour time, a time format string would likely need to display either an hour 0-23, or else ((hour+11)%12)+1 and then later display an am/pm indicator. If both styles of hour are passed as arguments, the format string could select one or the other by using the appropriate argument, but that would only work if some arguments could be skipped.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-23 22:32 -0700 |
| Message-ID | <lnbmrmpdzs.fsf@kst-u.example.com> |
| In reply to | #108384 |
supercat@casperkitty.com writes:
> On Sunday, April 23, 2017 at 6:31:37 PM UTC-5, Keith Thompson wrote:
>> I can. I think the most common use for the POSIX positional
>> extensions is for localization. The format string is selected
>> depending on the current language, with the ability to show arguments
>> in different orders depending on the language syntax. That's a
>> very common requirement. I don't think I've ever encountered a
>> case where suppressing some items would be useful.
>
> If some cultures use 12-hour time format and others use 24-hour time, a
> time format string would likely need to display either an hour 0-23, or else
> ((hour+11)%12)+1 and then later display an am/pm indicator. If both styles
> of hour are passed as arguments, the format string could select one or the
> other by using the appropriate argument, but that would only work if some
> arguments could be skipped.
Great, that's one example -- and one that can probably be better
handled using a locale-sensitive time formatting function than by
adding bells and whistles to printf.
When I wrote that "I don't think I've ever encountered a case where
suppressing some items would be useful", I didn't mean to imply
that there are no such cases. My real point is that I don't think
adding such functionality to printf is worthwhile.
But again, if you think it is, I encourage you to create an
implementation and demonstrate that it's useful and popular.
I wouldn't object to adding features to printf, but I think there
should be a high bar to standardizing new features for something
that's already quite complicated.
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-04-24 13:37 +0000 |
| Message-ID | <OcnLA.50005$Ba1.1544@fx37.iad> |
| In reply to | #108368 |
supercat@casperkitty.com writes: >On Friday, April 21, 2017 at 6:44:54 PM UTC-5, robert...@yahoo.com wrote: >> I don't really see that as a common case: usually you'd use this sort >> of thing for internationalization, and then you'd not usually code a >> printf with any unneeded parameters. Why would the (say) French >> version of a message omit one of the data items in the message? I can >> see a handful of use cases, but not many. > >Normal printf would allow something like: > > printf(format, hours, minutes, seconds, tenths, hundredths); > >to output a time with a selectable degree of precision by changing the >format string. I can't think of many situations which would benefit >from the ability to permute arguments that wouldn't benefit more from the >additional ability to suppress them. If a flag were added to suppress all >output from a conversion, the only additional feature that would be needed >to allow rearrangement of arguments would be a "rewind" function. If a >! flag meant "suppress output" and a %^ flag would rewind the argument list >before processing the argument, then > > printf(format, century, year, month, day); Well, for that functionality, POSIX defines strftime and the cognate function strptime. http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-04-27 07:13 -0700 |
| Message-ID | <kfn7f263pmn.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #108326 |
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?
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?
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?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-27 07:54 -0700 |
| Message-ID | <e765c6c6-cc36-425d-8c18-f284113f16ea@googlegroups.com> |
| In reply to | #108603 |
On Thursday, April 27, 2017 at 9:13:26 AM UTC-5, Tim Rentsch wrote:
> 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?
FORTRAN placed a priority on avoiding having wrong output that might be
mistaken for correct output--a philosophy that is still appropriate for
many purposes today. Asterisks may not have been elegant, but they made
clear which fields were erroneous, and they're probably less apt to be
misinterpreted than outputting excess columns.
Incidentally, Turbo Pascal 2.00 had an interesting bug in its printf,
fixed in the next release, which would cause it to sometimes fail to
output an entire floating-point number. If the specified width was
less than the required width, there was at least one digit after the
decimal point, and the number was less than a power of ten but got
rounded to one, the printf would omit the leftmost digit. Thus, for
example, printf("1.2f",999.996); would output 000.00. Having leading
digits get silently omitted because of a specified field width would
be somewhat less ugly than having them get omitted because of a bug,
but except when the output width is zero it's probably better not to
output anything that looks like a number than to output something
wrong.
[toc] | [prev] | [next] | [standalone]
Page 3 of 15 — ← Prev page 1 2 [3] 4 5 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web