Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #96073 > unrolled thread
| Started by | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| First post | 2016-11-08 22:17 +0800 |
| Last post | 2016-11-08 18:25 -0800 |
| Articles | 20 on this page of 296 — 29 participants |
Back to article view | Back to comp.lang.c
Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-08 22:17 +0800
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-08 14:25 +0000
[OI] chat "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-08 22:26 +0800
Re: Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-08 22:29 +0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-08 20:48 +0100
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 11:51 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-08 21:12 +0100
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-08 20:43 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 13:20 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:04 +0100
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:04 +0100
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-08 14:30 -0800
Re: Compiler design in C? Noob <root@127.0.0.1> - 2016-11-12 01:25 +0100
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-11 17:08 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-12 07:52 +0000
Re: Compiler design in C? Noob <root@127.0.0.1> - 2016-11-12 15:18 +0100
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:00 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-08 22:33 +0000
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-08 22:56 +0000
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-08 23:40 +0000
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-09 19:54 +0000
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:47 -0600
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:46 +0000
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 07:19 -0500
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 06:46 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-08 23:00 +0000
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 11:30 +0100
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 11:14 +0000
Re: Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-09 19:15 +0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 13:59 +0100
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 03:15 -0800
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 05:44 -0600
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 03:57 -0800
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:19 -0600
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 07:59 -0500
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 13:13 +0000
Re: Compiler design in C? Robert Spanjaard <spamtrap@arumes.com> - 2016-11-09 14:06 +0000
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 14:46 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-09 08:33 -0800
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 17:28 +0000
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:22 -0600
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 10:55 -0500
Re: Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-10 00:01 +0800
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 17:11 +0000
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 13:37 -0500
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:16 -0600
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 22:36 -0500
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 23:40 -0600
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-10 08:49 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 14:02 +0100
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 05:40 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 15:47 +0100
Re: Compiler design in C? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-11-09 19:32 +0300
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:34 -0600
Re: Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-10 00:43 +0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-09 20:00 +0000
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-09 13:25 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 11:18 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-09 19:57 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 12:10 -0800
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-09 20:32 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 22:56 +0100
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-09 22:04 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 23:16 +0100
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-09 22:18 +0000
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:29 +0000
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 21:35 +0100
Re: Compiler design in C? Melzzzzz <mel@zzzzz.com> - 2016-11-09 21:55 +0100
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:49 -0600
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 11:31 +0100
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 10:42 +0000
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 13:03 +0100
Re: Compiler design in C? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-11-10 15:37 +0300
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 08:13 -0800
Re: Compiler design in C? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-11-10 20:22 +0300
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-10 12:29 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 16:02 +0000
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 20:24 +0100
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-10 12:18 +0000
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-10 12:36 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 04:43 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 16:18 +0000
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-09 21:06 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 23:12 +0100
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-09 22:18 +0000
Re: Compiler design in C? luser droog <luser.droog@gmail.com> - 2016-11-09 14:35 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 13:10 +0100
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 21:28 +0000
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-09 21:32 +0000
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:36 +0000
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 07:10 +0000
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-10 20:32 +1300
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 08:05 +0000
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 08:06 +0000
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 08:14 +0000
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 08:33 +0000
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 09:20 +0000
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 02:15 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 10:29 +0000
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 02:58 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 11:09 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 03:25 -0800
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 06:35 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 16:29 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 21:59 +0100
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-11 10:10 +1300
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 22:27 +0100
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 22:42 +0100
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-11 10:46 +1300
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-10 16:27 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 22:47 +0100
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-10 19:29 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-11 09:17 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 13:45 -0800
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 06:58 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 16:31 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 21:41 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 20:57 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 22:16 +0100
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-10 13:35 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 22:43 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 21:58 +0000
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-10 14:28 -0800
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 14:47 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 22:51 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-11 00:27 +0100
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-10 15:57 -0800
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-11 10:38 +1300
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 22:46 +0100
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-11 10:51 +1300
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 22:04 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-11 00:18 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-11 05:45 +0000
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-14 00:27 -0600
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-14 21:24 +1300
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-14 09:45 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 21:54 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-11 00:19 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-11 05:47 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-11 00:22 +0100
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 07:01 -0500
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 06:49 -0800
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 03:02 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 11:10 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 03:17 -0800
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 06:56 -0500
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 04:05 -0800
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 08:09 -0500
Re: Compiler design in C? jameskuyper@verizon.net - 2016-11-11 16:56 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 07:37 +0000
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 08:07 +0000
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-10 22:43 +1300
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 09:50 +0000
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-10 11:43 +0000
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 06:36 -0800
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-10 15:05 +0000
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 16:25 +0100
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 13:14 +0100
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 04:23 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 23:01 +0100
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 13:35 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 08:08 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 20:30 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 12:20 -0800
Re: Compiler design in C? me <crisdunbar@gmail.com> - 2016-11-10 13:48 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 22:53 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 14:38 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-11 09:52 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-11 06:09 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-11 21:54 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-11 14:10 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-12 14:17 +0100
Re: Compiler design in C? supercat <flatfinger@casperkitty.com> - 2016-11-12 10:42 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-12 19:04 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-12 16:13 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-13 00:28 +0000
Re: Compiler design in C? supercat <flatfinger@casperkitty.com> - 2016-11-12 17:36 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-13 10:20 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-13 14:37 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-13 22:42 +0000
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-13 18:26 -0500
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-14 07:08 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-13 15:52 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-14 07:10 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-14 07:33 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-14 18:42 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-14 11:42 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-14 19:49 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-14 12:24 -0800
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-14 12:32 -0800
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-16 08:18 -0800
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-16 08:50 -0800
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-17 12:02 -0800
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-17 12:22 -0800
Re: Compiler design in C? Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-16 10:35 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-13 10:52 +0000
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-12 14:28 -0800
Re: Compiler design in C? jameskuyper@verizon.net - 2016-11-09 13:27 -0800
Re: Compiler design in C? Robert Spanjaard <spamtrap@arumes.com> - 2016-11-09 23:43 +0100
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-10 17:57 +1300
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 21:26 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:39 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 22:54 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-09 15:08 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:50 +0000
Re: Compiler design in C? John Bode <jfbode1029@gmail.com> - 2016-11-08 13:44 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:07 +0100
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 14:15 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:26 +0100
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 14:44 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 14:48 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 15:34 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 15:57 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 16:17 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 16:18 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 16:24 -0800
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-08 19:59 -0500
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-09 15:44 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 00:51 +0100
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-09 15:59 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-10 16:08 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-11 14:41 +0000
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-11 15:55 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-11 15:21 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-11 15:32 -0800
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-11 16:11 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-12 11:12 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-12 20:03 +0000
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-12 20:21 +0000
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 15:30 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-12 21:51 +0100
Re: Compiler design in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-12 13:16 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-12 23:04 +0100
Re: Compiler design in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-12 14:12 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 15:05 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 14:43 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 14:49 -0800
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-12 14:33 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-12 22:45 +0000
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-12 18:14 -0500
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-13 00:12 +0000
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-13 11:38 -0500
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-14 00:44 +0000
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-14 11:45 -0500
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-14 09:42 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 14:14 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-14 22:59 +0000
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 15:15 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-14 19:11 +0000
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-14 15:40 -0500
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-14 20:45 +0000
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-12 17:20 -0800
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-09 19:49 -0500
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-10 16:14 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-11 15:28 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-12 00:45 +0000
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-12 11:40 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-12 11:42 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-12 20:18 +0000
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 15:23 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-13 11:46 +0100
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-10 16:22 -0800
Re: Compiler design in C? jameskuyper@verizon.net - 2016-11-11 16:52 -0800
Re: Compiler design in C? John Bode <jfbode1029@gmail.com> - 2016-11-08 14:57 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 00:13 +0100
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-08 15:46 -0800
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-08 20:04 -0500
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 03:23 -0800
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 08:01 -0500
Re: Compiler design in C? John Bode <jfbode1029@gmail.com> - 2016-11-09 12:27 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 22:32 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:43 +0000
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-10 20:30 +1300
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 07:35 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 03:12 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 11:19 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 03:46 -0800
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 04:01 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-11 16:04 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-11 08:36 -0800
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 17:41 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 13:58 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-09 08:10 -0800
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-09 10:35 -0800
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-08 14:21 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:28 +0100
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-08 22:47 +0000
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-10 09:52 +0000
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 07:33 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 14:03 +0100
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 08:15 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 14:47 +0100
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 22:55 +0100
Re: Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-09 19:44 +0800
Re: Compiler design in C? luser droog <luser.droog@gmail.com> - 2016-11-08 18:18 -0800
Re: Compiler design in C? luser droog <luser.droog@gmail.com> - 2016-11-08 18:25 -0800
Page 12 of 15 — ← Prev page 1 … 10 11 [12] 13 14 15 Next page →
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-11-10 16:08 -0800 |
| Message-ID | <o0324a$ndp$1@dont-email.me> |
| In reply to | #96249 |
On 11/9/2016 3:51 PM, jacobnavia wrote:
> Le 10/11/2016 à 00:44, Chris M. Thomasson a écrit :
>> On 11/8/2016 4:59 PM, James R. Kuyper wrote:
>>> On 11/08/2016 06:57 PM, Chris M. Thomasson wrote:
[...]
>>>> It does NOT like that I am assigning argc, and argv in brackets! The
>>>
>
> Yes, this is an evil bug sorry.
>
> But I am doing a arm64 version right now and do not have time to fix
> that immediately.
>
> Sorry about this.
>
>>> How did it indicate it's dislike of that construct? Was a diagnostic
>>> message printed? If so, the text of that message would be helpful.
>
> A bug doesn't emit diagnostics, well, at least not normally...
>
> :-)
I forgot to tell you that I got some odd warnings when I compile the code:
_______________________________________________
Wedit output window build: Thu Nov 10 15:56:19 2016
Warning c:\testing_123\testing_123.c: 606 printf argument mismatch for
format f. Expected struct long double _Complex got double
Warning c:\testing_123\testing_123.c: 606 printf argument mismatch for
format f. Expected struct long double _Complex got double
Warning c:\testing_123\testing_123.c: 606 printf argument mismatch for
format f. Expected struct long double _Complex got double
Warning c:\testing_123\testing_123.c: 606 printf argument mismatch for
format f. Expected struct long double _Complex got double
Compilation + link time:1.2 sec, Return code: 0
_______________________________________________
The odd thing is that I am not using the and c99 _Complex numbers. The
complete function that contains like 606 is defined as:
_______________________________________________
int
ffe_sys_calc_salt(
struct ffe_cipher* cipher,
size_t in_file_size
) {
cipher->dims = (size_t)(sqrt(in_file_size) + 1);
cipher->in_file_size = in_file_size;
cipher->salt.axes.xmin = cipher->skey->axes.xmin -
cipher->salt.axes.xmin;
cipher->salt.axes.xmax = cipher->skey->axes.xmax +
cipher->salt.axes.xmax;
cipher->salt.axes.ymin = cipher->skey->axes.ymin -
cipher->salt.axes.ymin;
cipher->salt.axes.ymax = cipher->skey->axes.ymax +
cipher->salt.axes.ymax;
printf(
"Processing %lu bytes...\r\n"
"____________________________________________\r\n"
"axes:(" FFE_PREC ", " FFE_PREC "\r\n "
FFE_PREC ", " FFE_PREC ")\r\n\r\n",
(unsigned long)in_file_size,
cipher->salt.axes.xmin, cipher->salt.axes.xmax,
cipher->salt.axes.ymin, cipher->salt.axes.ymax);
return 0;
}
_______________________________________________
where the macro FFE_PREC is defined as:
#define FFE_PREC "%.13lf"
The struct for cipher->salt.axes is defined as:
_______________________________________________
struct ffe_axes
{
double xmin;
double xmax;
double ymin;
double ymax;
};
_______________________________________________
This is baffling me. BTW, I still cannot get it to run the
encrypt/decrypt cycle, however I can get it to create the default secret
key.
I will have a couple of hours of free time tomorrow to see whats going
on here. I really want to compare the speed of the encrypt/decrypt
compared to other compilers. FWIW, when I compile this with -Wall and
-pedantic in GCC, well, there are no warnings.
Its okay if this is another bug in the compiler. Shi% happens Jacob.
I really like that you took the time to create one in the first place.
Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-11 14:41 +0000 |
| Message-ID | <878tsqoz7v.fsf@bsb.me.uk> |
| In reply to | #96363 |
"Chris M. Thomasson" <invalid@invalid.invalid> writes:
<snip>
> I forgot to tell you that I got some odd warnings when I compile the code:
> _______________________________________________
> Wedit output window build: Thu Nov 10 15:56:19 2016
> Warning c:\testing_123\testing_123.c: 606 printf argument mismatch
> for format f. Expected struct long double _Complex got double
This seems to be just a rogue warning from lcc-win64. You seem to need
the %lu preceding the %f format. A minimal example that provokes it:
#include <stdio.h>
int main(void)
{
size_t s = 1;
double d = 2;
printf("%lu %f\n", s, d);
}
If you use the correct format for size_t (%zu) it goes away.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-11-11 15:55 -0800 |
| Message-ID | <o05lp6$g1m$1@dont-email.me> |
| In reply to | #96382 |
On 11/11/2016 6:41 AM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <invalid@invalid.invalid> writes:
> <snip>
>> I forgot to tell you that I got some odd warnings when I compile the code:
>> _______________________________________________
>> Wedit output window build: Thu Nov 10 15:56:19 2016
>> Warning c:\testing_123\testing_123.c: 606 printf argument mismatch
>> for format f. Expected struct long double _Complex got double
>
> This seems to be just a rogue warning from lcc-win64. You seem to need
> the %lu preceding the %f format. A minimal example that provokes it:
>
> #include <stdio.h>
>
> int main(void)
> {
> size_t s = 1;
> double d = 2;
> printf("%lu %f\n", s, d);
> }
>
> If you use the correct format for size_t (%zu) it goes away.
Thank you. I am casting size_t to unsigned long in me code, but using
%zu does made it go away wrt your example code Ben. This just might be
the problem in my codes call to fscanf. Will investigate.
:^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-11-11 15:21 -0800 |
| Message-ID | <o05jo6$a7n$1@dont-email.me> |
| In reply to | #96249 |
On 11/9/2016 3:51 PM, jacobnavia wrote:
> Le 10/11/2016 à 00:44, Chris M. Thomasson a écrit :
[...]
> A bug doesn't emit diagnostics, well, at least not normally...
[...]
I figured out why I cannot run the encrypt/decrypt cycle. The call to
scanf in the following code returns -1, when it should not. This all
works in GCC and MSVC, but returns -1 in yours using the exact same
command line arguments in the same environment:
_______________________________________________
int
ffe_secret_key_parse_from_file(
struct ffe_secret_key* const self,
FILE* in_file
) {
printf("ffe_secret_key_parse_from_file.0\n");
int ret = fscanf(
in_file,
"iters:%u\r\n"
"scale:(%lf, %lf)\r\n"
"julia0:(%lf, %lf)\r\n"
"julia1:(%lf, %lf)\r\n"
"julia2:(%lf, %lf)\r\n"
"axes:(%lf, %lf, %lf, %lf)",
&self->iters,
&self->scale.x, &self->scale.y,
&self->julia[0].x, &self->julia[0].y,
&self->julia[1].x, &self->julia[1].y,
&self->julia[2].x, &self->julia[2].y,
&self->axes.xmin, &self->axes.xmax,
&self->axes.ymin, &self->axes.ymax
);
printf("ffe_secret_key_parse_from_file.1::fscanf::ret = %d\n", ret);
if (ret == FFE_SECRET_KEY_ARGS)
{
return 0;
}
return FFE_ERROR;
}
_______________________________________________
FWIW, the extra printf's are an attempt for me to try to get it to work,
as as a debugging layer.
BTW, can anybody else run the encrypt/decrypt cycle on a file in GCC? It
always works for me. Even in cygwin...
;^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-11-11 15:32 -0800 |
| Message-ID | <o05kd0$bfi$2@dont-email.me> |
| In reply to | #96395 |
On 11/11/2016 3:21 PM, Chris M. Thomasson wrote:
> On 11/9/2016 3:51 PM, jacobnavia wrote:
>> Le 10/11/2016 à 00:44, Chris M. Thomasson a écrit :
> [...]
>> A bug doesn't emit diagnostics, well, at least not normally...
> [...]
>
> I figured out why I cannot run the encrypt/decrypt cycle. The call to
> scanf
^^^^^^^^^^^^^^^^
UMMM!!! I meant fscanf !!!
;^O
Sorry bout that non-sense.
> in the following code returns -1, when it should not. This all
> works in GCC and MSVC, but returns -1 in yours using the exact same
> command line arguments in the same environment:
> _______________________________________________
> int
> ffe_secret_key_parse_from_file(
> struct ffe_secret_key* const self,
> FILE* in_file
> ) {
> printf("ffe_secret_key_parse_from_file.0\n");
>
> int ret = fscanf(
> in_file,
> "iters:%u\r\n"
> "scale:(%lf, %lf)\r\n"
> "julia0:(%lf, %lf)\r\n"
> "julia1:(%lf, %lf)\r\n"
> "julia2:(%lf, %lf)\r\n"
> "axes:(%lf, %lf, %lf, %lf)",
> &self->iters,
> &self->scale.x, &self->scale.y,
> &self->julia[0].x, &self->julia[0].y,
> &self->julia[1].x, &self->julia[1].y,
> &self->julia[2].x, &self->julia[2].y,
> &self->axes.xmin, &self->axes.xmax,
> &self->axes.ymin, &self->axes.ymax
> );
>
> printf("ffe_secret_key_parse_from_file.1::fscanf::ret = %d\n", ret);
>
> if (ret == FFE_SECRET_KEY_ARGS)
> {
> return 0;
> }
>
> return FFE_ERROR;
> }
> _______________________________________________
>
>
> FWIW, the extra printf's are an attempt for me to try to get it to work,
> as as a debugging layer.
>
> BTW, can anybody else run the encrypt/decrypt cycle on a file in GCC? It
> always works for me. Even in cygwin...
>
> ;^)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-11 16:11 -0800 |
| Message-ID | <lnoa1lmuad.fsf@kst-u.example.com> |
| In reply to | #96395 |
"Chris M. Thomasson" <invalid@invalid.invalid> writes:
> On 11/9/2016 3:51 PM, jacobnavia wrote:
>> Le 10/11/2016 á 00:44, Chris M. Thomasson a écrit :
> [...]
>> A bug doesn't emit diagnostics, well, at least not normally...
> [...]
>
> I figured out why I cannot run the encrypt/decrypt cycle. The call to
> scanf in the following code returns -1, when it should not. This all
> works in GCC and MSVC, but returns -1 in yours using the exact same
> command line arguments in the same environment:
> _______________________________________________
> int
> ffe_secret_key_parse_from_file(
> struct ffe_secret_key* const self,
> FILE* in_file
> ) {
> printf("ffe_secret_key_parse_from_file.0\n");
>
> int ret = fscanf(
> in_file,
> "iters:%u\r\n"
> "scale:(%lf, %lf)\r\n"
> "julia0:(%lf, %lf)\r\n"
> "julia1:(%lf, %lf)\r\n"
> "julia2:(%lf, %lf)\r\n"
> "axes:(%lf, %lf, %lf, %lf)",
> &self->iters,
> &self->scale.x, &self->scale.y,
> &self->julia[0].x, &self->julia[0].y,
> &self->julia[1].x, &self->julia[1].y,
> &self->julia[2].x, &self->julia[2].y,
> &self->axes.xmin, &self->axes.xmax,
> &self->axes.ymin, &self->axes.ymax
> );
[snip]
The use of "\r\n" suggests a misunderstanding about how the *scanf()
functions work.
N1570 7.21.6.2p5:
A directive composed of white-space character(s) is executed
by reading input up to the first non-white-space character
(which remains unread), or until no more characters can be
read. The directive never fails.
Both '\r' and '\n' are white-space characters. So a '\r' tells fscanf
to skip any leading white-space, and a following '\n' tells it to do
exactly the same thing (which, given that it's already been skipped,
does nothing).
I think you're assuming that input lines will be terminated by "\r\n".
In fact they generally aren't on Unix-like systems, and even on Windows
systems where they are, the "\r\n" end-of-line marker is translated to
"\n" on input for text streams. It's only because "\r\n" doesn't work
the way you think it does that this isn't causing problems.
And you're not enforcing line endings. You could have
iters:42 scale:(1.2, 3.4)
on one line, and the "\r\n" would just consume the blank.
If you really want to force specific white-space characters, such as
'\n', you can use "%[\n]".
I don't think that's the cause of the problem you're asking about. (I
can imagine a bug where scanf doesn't treat '\r' as white-space, but I
don't think that's plausible.)
fscanf returns EOF (typically -1) only if "an input failure occurs
before the first conversion (if any) has completed".
Are you sure that in_file has been opened correctly?
--
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 | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-11-12 11:12 -0800 |
| Message-ID | <o07pid$hur$1@dont-email.me> |
| In reply to | #96399 |
On 11/11/2016 4:11 PM, Keith Thompson wrote:
> "Chris M. Thomasson" <invalid@invalid.invalid> writes:
>> On 11/9/2016 3:51 PM, jacobnavia wrote:
>>> Le 10/11/2016 á 00:44, Chris M. Thomasson a écrit :
>> [...]
>>> A bug doesn't emit diagnostics, well, at least not normally...
>> [...]
>>
>> I figured out why I cannot run the encrypt/decrypt cycle. The call to
>> scanf in the following code returns -1, when it should not. This all
>> works in GCC and MSVC, but returns -1 in yours using the exact same
>> command line arguments in the same environment:
>> _______________________________________________
>> int
>> ffe_secret_key_parse_from_file(
>> struct ffe_secret_key* const self,
>> FILE* in_file
>> ) {
>> printf("ffe_secret_key_parse_from_file.0\n");
>>
>> int ret = fscanf(
>> in_file,
>> "iters:%u\r\n"
>> "scale:(%lf, %lf)\r\n"
>> "julia0:(%lf, %lf)\r\n"
>> "julia1:(%lf, %lf)\r\n"
>> "julia2:(%lf, %lf)\r\n"
>> "axes:(%lf, %lf, %lf, %lf)",
>> &self->iters,
>> &self->scale.x, &self->scale.y,
>> &self->julia[0].x, &self->julia[0].y,
>> &self->julia[1].x, &self->julia[1].y,
>> &self->julia[2].x, &self->julia[2].y,
>> &self->axes.xmin, &self->axes.xmax,
>> &self->axes.ymin, &self->axes.ymax
>> );
> [snip]
>
> The use of "\r\n" suggests a misunderstanding about how the *scanf()
> functions work.
The only reason why I used "\r\n" in fscanf to parse the secret key file
is to mirror the fprintf that creates them here:
_____________________________________________
int
ffe_secret_key_store_to_file(
struct ffe_secret_key const* const self,
FILE* out_file
){
int ret = fprintf(
out_file,
"iters:%u\r\n"
"scale:(" FFE_PREC ", " FFE_PREC ")\r\n"
"julia0:(" FFE_PREC ", " FFE_PREC ")\r\n"
"julia1:(" FFE_PREC ", " FFE_PREC ")\r\n"
"julia2:(" FFE_PREC ", " FFE_PREC ")\r\n"
"axes:(" FFE_PREC ", " FFE_PREC ", "
FFE_PREC ", " FFE_PREC ")",
self->iters,
self->scale.x, self->scale.y,
self->julia[0].x, self->julia[0].y,
self->julia[1].x, self->julia[1].y,
self->julia[2].x, self->julia[2].y,
self->axes.xmin, self->axes.xmax,
self->axes.ymin, self->axes.ymax
);
if (ret > 0)
{
return 0;
}
return FFE_ERROR;
}
_____________________________________________
The macro FFE_PREC is defined as:
#define FFE_PREC "%.13lf"
The entire code can be found here:
http://pastebin.com/D7N4vBWa
>
> N1570 7.21.6.2p5:
>
> A directive composed of white-space character(s) is executed
> by reading input up to the first non-white-space character
> (which remains unread), or until no more characters can be
> read. The directive never fails.
>
> Both '\r' and '\n' are white-space characters. So a '\r' tells fscanf
> to skip any leading white-space, and a following '\n' tells it to do
> exactly the same thing (which, given that it's already been skipped,
> does nothing).
>
> I think you're assuming that input lines will be terminated by "\r\n".
> In fact they generally aren't on Unix-like systems, and even on Windows
> systems where they are, the "\r\n" end-of-line marker is translated to
> "\n" on input for text streams. It's only because "\r\n" doesn't work
> the way you think it does that this isn't causing problems.
>
> And you're not enforcing line endings. You could have
> iters:42 scale:(1.2, 3.4)
> on one line, and the "\r\n" would just consume the blank.
>
> If you really want to force specific white-space characters, such as
> '\n', you can use "%[\n]".
>
> I don't think that's the cause of the problem you're asking about. (I
> can imagine a bug where scanf doesn't treat '\r' as white-space, but I
> don't think that's plausible.)
>
> fscanf returns EOF (typically -1) only if "an input failure occurs
> before the first conversion (if any) has completed".
Right. My code checks the number of conversions made and only reports
success if it is equal to FFE_SECRET_KEY_ARGS, defined as:
#define FFE_SECRET_KEY_ARGS 13
FWIW, here is the entire function that parses secret key files, and uses
fscanf:
_____________________________________________
int
ffe_secret_key_parse_from_file(
struct ffe_secret_key* const self,
FILE* in_file
){
int ret = fscanf(
in_file,
"iters:%u\r\n"
"scale:(%lf, %lf)\r\n"
"julia0:(%lf, %lf)\r\n"
"julia1:(%lf, %lf)\r\n"
"julia2:(%lf, %lf)\r\n"
"axes:(%lf, %lf, %lf, %lf)",
&self->iters,
&self->scale.x, &self->scale.y,
&self->julia[0].x, &self->julia[0].y,
&self->julia[1].x, &self->julia[1].y,
&self->julia[2].x, &self->julia[2].y,
&self->axes.xmin, &self->axes.xmax,
&self->axes.ymin, &self->axes.ymax
);
if (ret == FFE_SECRET_KEY_ARGS)
{
return 0;
}
return FFE_ERROR;
}
_____________________________________________
This should tell me that FFE_SECRET_KEY_ARGS conversions were made, if
not, and error is returned instead of success.
> Are you sure that in_file has been opened correctly?
Yes. The code would have never got to the point where it wanted to parse
it if the in_file was not opened. That code can be found in the
ffe_cmdline_app_create function here:
_____________________________________________
int
ffe_cmdline_app_create(
struct ffe_cmdline_app* const self,
struct ffe_cmdline_args const* cmdargs
) {
printf(
"Funny Fractal Encryption ver:(0.0.0) pre-alpha\r\n"
"by: Chris M. Thomasson\r\n"
"==================================================\r\n\r\n");
self->cmdargs = *cmdargs;
self->in_file = self->out_file = NULL;
srand((unsigned int)time(NULL));
if (self->cmdargs.argc < 2)
{
return FFE_ERROR;
}
self->flags = 0;
if (ffe_cnv_uint_from_buffer(self->cmdargs.argv[1], &self->flags))
{
return FFE_ERROR;
}
if (self->flags == 0)
{
return 0;
}
else if (self->cmdargs.argc == FFE_CMDLINE_ARGS + 1)
{
// Read the secret key
const char* skey_fname = self->cmdargs.argv[2];
FILE* skey_file = fopen(skey_fname, "rb");
if (skey_file)
{
if (!ffe_secret_key_parse_from_file(&self->skey, skey_file))
{
[...]
_____________________________________________
It checks skey_file for NULL, and then passes it over to the
ffe_secret_key_parse_from_file function as the in_file parameter. But,
lcc returns -1 in the fscanf function, and my program sees that and does
not work by reporting an error.
I am kind of at a loss about what to do about it.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-12 20:03 +0000 |
| Message-ID | <87lgwompop.fsf@bsb.me.uk> |
| In reply to | #96419 |
"Chris M. Thomasson" <invalid@invalid.invalid> writes:
<snip>
> http://pastebin.com/D7N4vBWa
It might help to post the data file too. Maybe there's a problem with
it. It you can't put it online, post a hex dump of it or something
similar.
<snip>
> It checks skey_file for NULL, and then passes it over to the
> ffe_secret_key_parse_from_file function as the in_file parameter. But,
> lcc returns -1 in the fscanf function, and my program sees that and
> does not work by reporting an error.
>
> I am kind of at a loss about what to do about it.
I can't re-create the problem you are seeing. I took the code and
corrected the two issues you know about (%zu and the {argc, argv}
initialiser and compiled with lcc-win (64-bit). The program corectly
read a a key file I made up -- i.e. the fscanf call returned 13, not -1.
It went wrong later, but the input was successful.
A couple of things... For text files you should not print \r\n. A plain
\n will do. stdout is a text file so almost all of your printf calls
can be improved by removing the \r.
The key file is a text file so you should really open it in mode "r"
rather than "rb". Ditto for when you write it (I think the program can
do that too).
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-12 20:21 +0000 |
| Message-ID | <87a8d4mour.fsf@bsb.me.uk> |
| In reply to | #96423 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > "Chris M. Thomasson" <invalid@invalid.invalid> writes: > <snip> > >> http://pastebin.com/D7N4vBWa <snip> >> It checks skey_file for NULL, and then passes it over to the >> ffe_secret_key_parse_from_file function as the in_file parameter. But, >> lcc returns -1 in the fscanf function, and my program sees that and >> does not work by reporting an error. >> >> I am kind of at a loss about what to do about it. > > I can't re-create the problem you are seeing. Now that you've posted the key file, I was able to re-create the problem and I've posted a fix in my other reply. Ignore this one... <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-11-14 15:30 -0800 |
| Message-ID | <o0dhcr$n7m$2@dont-email.me> |
| In reply to | #96423 |
On 11/12/2016 12:03 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <invalid@invalid.invalid> writes:
> <snip>
>
>> http://pastebin.com/D7N4vBWa
>
> It might help to post the data file too. Maybe there's a problem with
> it. It you can't put it online, post a hex dump of it or something
> similar.
>
> <snip>
>> It checks skey_file for NULL, and then passes it over to the
>> ffe_secret_key_parse_from_file function as the in_file parameter. But,
>> lcc returns -1 in the fscanf function, and my program sees that and
>> does not work by reporting an error.
>>
>> I am kind of at a loss about what to do about it.
>
> I can't re-create the problem you are seeing. I took the code and
> corrected the two issues you know about (%zu and the {argc, argv}
> initialiser and compiled with lcc-win (64-bit). The program corectly
> read a a key file I made up -- i.e. the fscanf call returned 13, not -1.
>
> It went wrong later, but the input was successful.
>
> A couple of things... For text files you should not print \r\n. A plain
> \n will do. stdout is a text file so almost all of your printf calls
> can be improved by removing the \r.
Will do all of this in the rewrite to get it to conform to my little
tutorial.
Thanks.
> The key file is a text file so you should really open it in mode "r"
> rather than "rb". Ditto for when you write it (I think the program can
> do that too).
>
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-12 21:51 +0100 |
| Message-ID | <o07vcg$66t$1@dont-email.me> |
| In reply to | #96419 |
Le 12/11/2016 à 20:12, Chris M. Thomasson a écrit : > > It checks skey_file for NULL, and then passes it over to the > ffe_secret_key_parse_from_file function as the in_file parameter. But, > lcc returns -1 in the fscanf function, and my program sees that and does > not work by reporting an error. > > I am kind of at a loss about what to do about it. Can I send you the source code of fscanf? I can't fix it right now. It must have some slight incompatibility somewhere.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-12 13:16 -0800 |
| Message-ID | <948bccd2-6863-4254-8bd6-c94e33138c00@googlegroups.com> |
| In reply to | #96427 |
jacobnavia wrote: > Can I send you the source code of fscanf? I can't fix > it right now. It must have some slight incompatibility > somewhere. Is there a link to source code for lcc-win? Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-12 23:04 +0100 |
| Message-ID | <o083ji$kdr$1@dont-email.me> |
| In reply to | #96428 |
Le 12/11/2016 à 22:16, Rick C. Hodgin a écrit : > Is there a link to source code for lcc-win? I decide to whom I give my code.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-12 14:12 -0800 |
| Message-ID | <7c82c0ce-3a45-4d60-92a6-5a0927de9b84@googlegroups.com> |
| In reply to | #96432 |
jacobnavia wrote:
> Le 12/11/2016 à 22:16, Rick C. Hodgin a écrit :
> > Is there a link to source code for lcc-win?
> I decide to whom I give my code.
Me too. Anyone can download all I have created at this
address, under this license, using the source code for any
purpose:
http://www.github.com/RickCHodgin
http://www.libsf.org/licenses
Enjoy! :-)
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-11-14 15:05 -0800 |
| Message-ID | <o0dfvo$kdo$1@dont-email.me> |
| In reply to | #96435 |
On 11/12/2016 2:12 PM, Rick C. Hodgin wrote: > jacobnavia wrote: >> Le 12/11/2016 à 22:16, Rick C. Hodgin a écrit : >>> Is there a link to source code for lcc-win? >> I decide to whom I give my code. > > Me too. Anyone can download all I have created at this > address, under this license, using the source code for any > purpose: > > http://www.github.com/RickCHodgin > http://www.libsf.org/licenses > > Enjoy! :-) IIRC you use C++ to compile your C code, right? This threw me for a loop. When I accidentally use C++ for C I get a load of warnings/errors. It also makes me want to cast the return value from malloc. Then I think, what! This is all legal in C. Damn. Then I use the correct compiler for the code, and everything is Kosher.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-11-14 14:43 -0800 |
| Message-ID | <o0dele$bso$1@dont-email.me> |
| In reply to | #96427 |
On 11/12/2016 12:51 PM, jacobnavia wrote: > Le 12/11/2016 à 20:12, Chris M. Thomasson a écrit : > >> >> It checks skey_file for NULL, and then passes it over to the >> ffe_secret_key_parse_from_file function as the in_file parameter. But, >> lcc returns -1 in the fscanf function, and my program sees that and does >> not work by reporting an error. >> >> I am kind of at a loss about what to do about it. > > Can I send you the source code of fscanf? I can't fix it right now. It > must have some slight incompatibility somewhere. Sure! You can send it here: chrisXxXx.m.thomassonxXxX.1@Xgmail.xXXxxXcom Remove all the x's, lowercase and uppercase. FWIW, here is my Google plus page so you can see what I am interested in: https://plus.google.com/101799841244447089430 (Basically, a Fractal Nerd...) Oh well... Thanks Jacob. Thank you for trusting me with your code, I will not send/show it to anybody else without _explicit_ _permission_ from you, the creator. ;^) Unfortunately, I have been fairly time constrained with work lately, and am lucky to get some free time. Well, to tell you the truth, I need to rewrite this to conform with a little, highly crude tutorial about how to create an updated version of my cipher I posted here: https://github.com/ChrisMThomasson/fractal_cipher/blob/master/FFE/Pre-Alpha%20Rough%20Draft%20FFE%20Tutorial.pdf (code examples are in Python...) I still need to write a damn description of the idea and algorithm. I have a feeling they might want to shoo% me in the ankles over on sci.crypt. They want a damn paper, and a tutorial is not going to cut it! Well, they are right. But its hard to write a paper on this because its so experimental. And I am time constrained. SHI%! ;^o
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-11-14 14:49 -0800 |
| Message-ID | <o0devu$d0e$1@dont-email.me> |
| In reply to | #96580 |
On 11/14/2016 2:43 PM, Chris M. Thomasson wrote: > On 11/12/2016 12:51 PM, jacobnavia wrote: >> Le 12/11/2016 à 20:12, Chris M. Thomasson a écrit : [...] > Unfortunately, I have been fairly time constrained with work lately, and > am lucky to get some free time. Well, to tell you the truth, I need to > rewrite this to conform with a little, highly crude tutorial about how > to create an updated version of my cipher I posted here: > > https://github.com/ChrisMThomasson/fractal_cipher/blob/master/FFE/Pre-Alpha%20Rough%20Draft%20FFE%20Tutorial.pdf When I rewrite the C code to conform with the crude tutorial, I will be using your compiler along with GCC and MSVC, just to get a feel of doing it from scratch in lcc. I should be able to get it to work in all three. And creating it from nothing will make it easier than trying to get my current code to work. However, Ben has given me great insight into how to get the current C code to work as-is. Thanks Ben!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-12 14:33 -0800 |
| Message-ID | <lny40ol44v.fsf@kst-u.example.com> |
| In reply to | #96419 |
"Chris M. Thomasson" <invalid@invalid.invalid> writes:
> On 11/11/2016 4:11 PM, Keith Thompson wrote:
[...]
>> The use of "\r\n" suggests a misunderstanding about how the *scanf()
>> functions work.
>
> The only reason why I used "\r\n" in fscanf to parse the secret key file
> is to mirror the fprintf that creates them here:
[snip]
Whatever the reason, it's misleading.
And why are you using "\r\n" in printf? On a Unix-like system, it will
print "\r\n"; on Windows, it will probably print "\r\r\n". Unless
out_file is opened in binary mode. Is it?
[...]
>> fscanf returns EOF (typically -1) only if "an input failure occurs
>> before the first conversion (if any) has completed".
>
> Right. My code checks the number of conversions made and only reports
> success if it is equal to FFE_SECRET_KEY_ARGS, defined as:
>
> #define FFE_SECRET_KEY_ARGS 13
>
> FWIW, here is the entire function that parses secret key files, and uses
> fscanf:
[snip]
>> Are you sure that in_file has been opened correctly?
>
> Yes. The code would have never got to the point where it wanted to parse
> it if the in_file was not opened. That code can be found in the
> ffe_cmdline_app_create function here:
[snip]
> It checks skey_file for NULL, and then passes it over to the
> ffe_secret_key_parse_from_file function as the in_file parameter. But,
> lcc returns -1 in the fscanf function, and my program sees that and does
> not work by reporting an error.
>
> I am kind of at a loss about what to do about it.
Well, you're going to need to figure out why fscanf() is failing. Try
setting errno to 0 before the call and checking its value after (fscanf
isn't required to set errno, but in many implementations it does). Try
replacing the fscanf call with a much simpler one; if that succeeds, try
doing a binary search to narrow down why your call fails and the simpler
one doesn't.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-12 22:45 +0000 |
| Message-ID | <87y40ol3lq.fsf@bsb.me.uk> |
| In reply to | #96438 |
Keith Thompson <kst-u@mib.org> writes:
> "Chris M. Thomasson" <invalid@invalid.invalid> writes:
<snip>
>> But, lcc returns -1 in the fscanf function, and my program sees that and does
>> not work by reporting an error.
>>
>> I am kind of at a loss about what to do about it.
>
> Well, you're going to need to figure out why fscanf() is failing.
Here's a minimal test case:
#include <stdio.h>
int main(void)
{
int d;
printf("%d\n", scanf("%d", &d));
}
When the input consists of digits only (and no training newlines, spaces
etc) lcc-win's scanf returns -1. Maybe not technically a bug (since an
implementation can insist on a text file having a properly terminated
final line), but almost certainly not what was intended.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-11-12 18:14 -0500 |
| Message-ID | <98529082-11cc-b9a6-148f-70249943b502@verizon.net> |
| In reply to | #96438 |
On 11/12/2016 05:33 PM, Keith Thompson wrote: > "Chris M. Thomasson" <invalid@invalid.invalid> writes: ... >> The only reason why I used "\r\n" in fscanf to parse the secret key file >> is to mirror the fprintf that creates them here: > [snip] > > Whatever the reason, it's misleading. > > And why are you using "\r\n" in printf? On a Unix-like system, it will > print "\r\n"; on Windows, it will probably print "\r\r\n". Unless > out_file is opened in binary mode. Is it? Look at the source code: everything is opened in binary mode. Since the code contains a number of calls to fread() and fwrite(), and the purpose of the program is encryption/decryption, it might have even been appropriate to do so if the buffers being written by those calls contain any non-printing characters other than horizontal tab and new-line (I haven't bothered checking to determine whether this might be the case) - such characters would invalidate the guarantees that 7.21.2p2 provide for text streams.
[toc] | [prev] | [next] | [standalone]
Page 12 of 15 — ← Prev page 1 … 10 11 [12] 13 14 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web