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 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-13 00:12 +0000 |
| Message-ID | <87shqwkzks.fsf@bsb.me.uk> |
| In reply to | #96442 |
"James R. Kuyper" <jameskuyper@verizon.net> writes: > 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. Keith referred to printf. stdout is not reopened in binary mode -- it's a text stream as per the standard. Widening it to fprintf, there are five calls only two of which don't end up printing to stdout. In those two cases that \r might be reasonable, but even there I'd argue against it but for reasons to do with the intended purpose. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-11-13 11:38 -0500 |
| Message-ID | <d56116b8-906a-b3e6-897a-83e9ec983094@verizon.net> |
| In reply to | #96443 |
On 11/12/2016 07:12 PM, Ben Bacarisse wrote: > "James R. Kuyper" <jameskuyper@verizon.net> writes: > >> On 11/12/2016 05:33 PM, Keith Thompson wrote: ... >>> 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. > > Keith referred to printf. stdout is not reopened in binary mode -- it's > a text stream as per the standard. He also referred to out_file, which is why I wasn't thinking of stdout when I wrote my answer. > Widening it to fprintf, there are five calls only two of which don't end > up printing to stdout. In those two cases that \r might be > reasonable, but even there I'd argue against it but for reasons to do > with the intended purpose. Following the link to pastebin that he posted earlier, I count 5 calls to fprintf(out_file, ...), every one of which has arguments that included "\r\n": lines 154, 216, 256, 383, and 912. There were also several direct and indirect calls to fwrite(..., out_file).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-14 00:44 +0000 |
| Message-ID | <87bmxikhzc.fsf@bsb.me.uk> |
| In reply to | #96494 |
"James R. Kuyper" <jameskuyper@verizon.net> writes: > On 11/12/2016 07:12 PM, Ben Bacarisse wrote: >> "James R. Kuyper" <jameskuyper@verizon.net> writes: >> >>> On 11/12/2016 05:33 PM, Keith Thompson wrote: > ... >>>> 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. >> >> Keith referred to printf. stdout is not reopened in binary mode -- it's >> a text stream as per the standard. > > He also referred to out_file, which is why I wasn't thinking of stdout > when I wrote my answer. > >> Widening it to fprintf, there are five calls only two of which don't end >> up printing to stdout. In those two cases that \r might be >> reasonable, but even there I'd argue against it but for reasons to do >> with the intended purpose. > > Following the link to pastebin that he posted earlier, I count 5 calls > to fprintf(out_file, ...), every one of which has arguments that > included "\r\n": lines 154, 216, 256, 383, and 912. There were also > several direct and indirect calls to fwrite(..., out_file). Yes. What's your point? I think I'm missing it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-11-14 11:45 -0500 |
| Message-ID | <4b37ce62-b8b8-2503-c3b0-72e7d50b19fa@verizon.net> |
| In reply to | #96520 |
On 11/13/2016 07:44 PM, Ben Bacarisse wrote: > "James R. Kuyper" <jameskuyper@verizon.net> writes: > >> On 11/12/2016 07:12 PM, Ben Bacarisse wrote: >>> "James R. Kuyper" <jameskuyper@verizon.net> writes: >>> >>>> On 11/12/2016 05:33 PM, Keith Thompson wrote: >> ... >>>>> 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. >>> >>> Keith referred to printf. stdout is not reopened in binary mode -- it's >>> a text stream as per the standard. >> >> He also referred to out_file, which is why I wasn't thinking of stdout >> when I wrote my answer. >> >>> Widening it to fprintf, there are five calls only two of which don't end >>> up printing to stdout. In those two cases that \r might be >>> reasonable, but even there I'd argue against it but for reasons to do >>> with the intended purpose. >> >> Following the link to pastebin that he posted earlier, I count 5 calls >> to fprintf(out_file, ...), every one of which has arguments that >> included "\r\n": lines 154, 216, 256, 383, and 912. There were also >> several direct and indirect calls to fwrite(..., out_file). > > Yes. What's your point? I think I'm missing it. Well, partly that our counts differ, suggesting that we're probably looking at different code. I guess you're looking at the code he posted in his messages, while I'm looking at the code that he put in pastebin. My main point is that the code I'm looking at contains a number of cases where Keith's objection to the use of "\r\n" in connection with out_file don't apply because out_file was opened in binary mode, and that it might be reasonable to open that file in binary mode because it has some sections that were created by passing encrypted data to fwrite().
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-14 09:42 -0800 |
| Message-ID | <lnoa1ij6us.fsf@kst-u.example.com> |
| In reply to | #96541 |
"James R. Kuyper" <jameskuyper@verizon.net> writes:
[...]
> My main point is that the code I'm looking at contains a number of cases
> where Keith's objection to the use of "\r\n" in connection with out_file
> don't apply because out_file was opened in binary mode, and that it
> might be reasonable to open that file in binary mode because it has some
> sections that were created by passing encrypted data to fwrite().
And I suggest that, while using fprintf on a binary stream is perfectly
valid, it's unusual enough that it should be clearly commented -- along
with the reason for writing "\r\n" to the file. (I haven't looked at
the full code; perhaps it's already documented.)
--
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-14 14:14 -0800 |
| Message-ID | <o0dcun$65f$1@dont-email.me> |
| In reply to | #96547 |
On 11/14/2016 9:42 AM, Keith Thompson wrote: > "James R. Kuyper" <jameskuyper@verizon.net> writes: > [...] >> My main point is that the code I'm looking at contains a number of cases >> where Keith's objection to the use of "\r\n" in connection with out_file >> don't apply because out_file was opened in binary mode, and that it >> might be reasonable to open that file in binary mode because it has some >> sections that were created by passing encrypted data to fwrite(). > > And I suggest that, while using fprintf on a binary stream is perfectly > valid, it's unusual enough that it should be clearly commented -- along > with the reason for writing "\r\n" to the file. (I haven't looked at > the full code; perhaps it's already documented.) FWIW, the actual main reason why I used "\r\n" is because I had HTML on my mind because I was thinking of adding an option to dump a highly verbose log to HTML files. I did not document this at all: Sorry for the confusion I caused; that was very sloppy on my part. I guess a little, tiny, perhaps kind of redeeming factor is that this is a pre-alpha version (0.0.0) code. I was creating this C version concurrently with a JavaScript online version of the cipher: http://funwithfractals.atspace.cc/ffe Here is some ciphertext using the default key on that page: __________________________________________ 0.36598503250134756 0.32307641020291766 0.09048203020315787 0.14228232836305024 9D F4 5B C3 0D B7 83 A4 92 CC 03 E0 16 4B 0D 1D 40 54 42 54 B5 3A 30 0E 6D B0 AC 62 54 F6 28 DF 56 7E 61 CE AC 14 0C 9D CA 9E 8B ED B2 CE 0F FC 3C 32 04 4F 28 D8 E6 61 40 95 06 71 A1 39 D0 3B 66 2D 90 52 99 4A 30 9E A1 F2 14 01 E8 61 8C 28 DA A6 AA 8A FB 93 85 53 3F 77 EA 8C B4 62 09 69 C6 DE E6 3B C8 95 0E D4 B7 9A 52 BC F8 D8 FF 71 0C DB F0 E7 8A D2 90 C5 72 D2 6C 2F D9 0A 83 42 01 2E 0E 19 E6 F7 1A D5 0C 1C AA 6F C8 E0 7C 0A AC 4E D4 DD 26 17 05 76 3E B1 6E A9 92 5D D1 95 B9 FA EA F9 4F 6E 04 AB 77 7C AF 38 2E 93 59 F0 58 C0 14 63 22 9C 3D 79 90 0E 93 82 B3 4C AF B0 68 3B B9 3F 8E F1 3E 18 6E 3C CD 58 70 4F 2F 04 97 8F 65 A6 4F 12 D5 F5 3B C0 00 04 A8 9C F3 C6 79 24 0C 19 00 4C CB E2 40 0D 61 1C A2 E9 43 7E 0F 9D 69 44 53 D2 77 D1 82 AC 25 59 57 FC 53 EF 9C A3 AE 4D 31 26 66 0D 94 A6 18 76 4E B6 36 68 E7 8C 0F D9 C2 58 CB C8 7F DA BF 3E 48 24 4F 0B C0 CA 29 __________________________________________ One can decrypt that by going to the page and copy-and-paste the text between the lines above into the Cipher Text textarea. Then click the Decrypt button. One should see the following appear in the Plain Text textarea: __________________________________________ This is a pre-alpha version of my experimental cipher. Please do not use this for anything serious yet! I hope, God willing, that I can get it to that point. BTW, the Funny part of the name is due to the fact that it uses floating point, and can act funny sometimes. Well, shi% happens! ;^o __________________________________________ I just had "\r\n" on the mind. I really do apologize for that Keith, and everybody else. Sorry. Yikes! ;^o
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-14 22:59 +0000 |
| Message-ID | <87wpg5ekh1.fsf@bsb.me.uk> |
| In reply to | #96579 |
"Chris M. Thomasson" <invalid@invalid.invalid> writes: > On 11/14/2016 9:42 AM, Keith Thompson wrote: >> "James R. Kuyper" <jameskuyper@verizon.net> writes: >> [...] >>> My main point is that the code I'm looking at contains a number of cases >>> where Keith's objection to the use of "\r\n" in connection with out_file >>> don't apply because out_file was opened in binary mode, and that it >>> might be reasonable to open that file in binary mode because it has some >>> sections that were created by passing encrypted data to fwrite(). >> >> And I suggest that, while using fprintf on a binary stream is perfectly >> valid, it's unusual enough that it should be clearly commented -- along >> with the reason for writing "\r\n" to the file. (I haven't looked at >> the full code; perhaps it's already documented.) > > FWIW, the actual main reason why I used "\r\n" is because I had HTML > on my mind because I was thinking of adding an option to dump a highly > verbose log to HTML files. I did not document this at all: Sorry for > the confusion I caused; that was very sloppy on my part. Documenting that would not really help. Do you see why it's wrong? It sounds as if you think people are saying it's wrong because they did not know about your intended output destination, but it wrong of entirely different reasons that are not altered by whether or not you will eventually send the output to an HTML document. As it happens, the only case where it is not wrong (when the output stream is a binary one) is the only case where the output is never going to go to an HTML document! You write out some data (the axes) in a header before the encrypted text, but you are entirely in charge of choosing that format and \r\n is not a particularly good marker to use (though there is nothing much wrong about it). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-11-14 15:15 -0800 |
| Message-ID | <o0dggo$m8a$1@dont-email.me> |
| In reply to | #96582 |
On 11/14/2016 2:59 PM, Ben Bacarisse wrote: > "Chris M. Thomasson" <invalid@invalid.invalid> writes: > >> On 11/14/2016 9:42 AM, Keith Thompson wrote: >>> "James R. Kuyper" <jameskuyper@verizon.net> writes: >>> [...] >>>> My main point is that the code I'm looking at contains a number of cases >>>> where Keith's objection to the use of "\r\n" in connection with out_file >>>> don't apply because out_file was opened in binary mode, and that it >>>> might be reasonable to open that file in binary mode because it has some >>>> sections that were created by passing encrypted data to fwrite(). >>> >>> And I suggest that, while using fprintf on a binary stream is perfectly >>> valid, it's unusual enough that it should be clearly commented -- along >>> with the reason for writing "\r\n" to the file. (I haven't looked at >>> the full code; perhaps it's already documented.) >> >> FWIW, the actual main reason why I used "\r\n" is because I had HTML >> on my mind because I was thinking of adding an option to dump a highly >> verbose log to HTML files. I did not document this at all: Sorry for >> the confusion I caused; that was very sloppy on my part. > > Documenting that would not really help. Do you see why it's wrong? It > sounds as if you think people are saying it's wrong because they did not > know about your intended output destination, but it wrong of entirely > different reasons that are not altered by whether or not you will > eventually send the output to an HTML document. > > As it happens, the only case where it is not wrong (when the output > stream is a binary one) is the only case where the output is never going > to go to an HTML document! You write out some data (the axes) in a > header before the encrypted text, but you are entirely in charge of > choosing that format and \r\n is not a particularly good marker to use > (though there is nothing much wrong about it). Agreed. stdout is text, and I am treating it like something else wrt passing it interchangeably with functions that deal with binary streams. Bad. As for the marker separating the axes from the ciphertext, well I had "\r\n" engrained in my brain then. Sorry.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-14 19:11 +0000 |
| Message-ID | <87lgwlg9lu.fsf@bsb.me.uk> |
| In reply to | #96541 |
"James R. Kuyper" <jameskuyper@verizon.net> writes: > On 11/13/2016 07:44 PM, Ben Bacarisse wrote: >> "James R. Kuyper" <jameskuyper@verizon.net> writes: >> >>> On 11/12/2016 07:12 PM, Ben Bacarisse wrote: >>>> "James R. Kuyper" <jameskuyper@verizon.net> writes: >>>> >>>>> On 11/12/2016 05:33 PM, Keith Thompson wrote: >>> ... >>>>>> 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. >>>> >>>> Keith referred to printf. stdout is not reopened in binary mode -- it's >>>> a text stream as per the standard. >>> >>> He also referred to out_file, which is why I wasn't thinking of stdout >>> when I wrote my answer. >>> >>>> Widening it to fprintf, there are five calls only two of which don't end >>>> up printing to stdout. In those two cases that \r might be >>>> reasonable, but even there I'd argue against it but for reasons to do >>>> with the intended purpose. >>> >>> Following the link to pastebin that he posted earlier, I count 5 calls >>> to fprintf(out_file, ...), every one of which has arguments that >>> included "\r\n": lines 154, 216, 256, 383, and 912. There were also >>> several direct and indirect calls to fwrite(..., out_file). >> >> Yes. What's your point? I think I'm missing it. > > Well, partly that our counts differ, suggesting that we're probably > looking at different code. What counts? I counted 5 fprintf calls and so did you. I said only two don't end up printing to stdout, but you don't give a count for that so I'm not sure where you think the difference is. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-11-14 15:40 -0500 |
| Message-ID | <dfdeb117-bf04-e7be-186c-39cc106b8596@verizon.net> |
| In reply to | #96562 |
On 11/14/2016 02:11 PM, Ben Bacarisse wrote: > "James R. Kuyper" <jameskuyper@verizon.net> writes: > >> On 11/13/2016 07:44 PM, Ben Bacarisse wrote: >>> "James R. Kuyper" <jameskuyper@verizon.net> writes: >>> >>>> On 11/12/2016 07:12 PM, Ben Bacarisse wrote: ... >>>>> Widening it to fprintf, there are five calls only two of which don't end >>>>> up printing to stdout. ... ... >>>> Following the link to pastebin that he posted earlier, I count 5 calls >>>> to fprintf(out_file, ...), every one of which has arguments that >>>> included "\r\n": lines 154, 216, 256, 383, and 912. ... ... >>> Yes. What's your point? I think I'm missing it. >> >> Well, partly that our counts differ, suggesting that we're probably >> looking at different code. > > What counts? I counted 5 fprintf calls and so did you. I said only two > don't end up printing to stdout, but you don't give a count for that so > I'm not sure where you think the difference is. I counted five that didn't go to stdout, you counted two that didn't go to stdout. However, I've figured out the reason for that discrepancy: I included every call to fprintf(out_file, ...) in my count, without looking at how out_file gets it's value. In three of those cases (presumably, the ones that I counted but which you didn't count) out_file is a function parameter, and every call to the relevant function passes stdout as the corresponding argument. You presumably noticed that, while I didn't bother checking. Those functions really shouldn't take a FILE* parameter if the only value that parameter is ever expected to have is stdout; they should just use stdout directly. However, it might be that he plans to pass other values to those functions in future versions of the code.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-14 20:45 +0000 |
| Message-ID | <87fumtg59d.fsf@bsb.me.uk> |
| In reply to | #96574 |
"James R. Kuyper" <jameskuyper@verizon.net> writes: > On 11/14/2016 02:11 PM, Ben Bacarisse wrote: >> "James R. Kuyper" <jameskuyper@verizon.net> writes: >> >>> On 11/13/2016 07:44 PM, Ben Bacarisse wrote: >>>> "James R. Kuyper" <jameskuyper@verizon.net> writes: >>>> >>>>> On 11/12/2016 07:12 PM, Ben Bacarisse wrote: > ... >>>>>> Widening it to fprintf, there are five calls only two of which don't end >>>>>> up printing to stdout. ... > ... >>>>> Following the link to pastebin that he posted earlier, I count 5 calls >>>>> to fprintf(out_file, ...), every one of which has arguments that >>>>> included "\r\n": lines 154, 216, 256, 383, and 912. ... > ... >>>> Yes. What's your point? I think I'm missing it. >>> >>> Well, partly that our counts differ, suggesting that we're probably >>> looking at different code. >> >> What counts? I counted 5 fprintf calls and so did you. I said only two >> don't end up printing to stdout, but you don't give a count for that so >> I'm not sure where you think the difference is. > > I counted five that didn't go to stdout, you counted two that didn't > go to stdout. > > However, I've figured out the reason for that discrepancy: I included > every call to fprintf(out_file, ...) in my count, without looking at > how out_file gets it's value. In three of those cases (presumably, the > ones that I counted but which you didn't count) out_file is a function > parameter, and every call to the relevant function passes stdout as > the corresponding argument. You presumably noticed that, while I > didn't bother checking. Yes. Only two fptintf calls (and no printf calls, of course) have anything to do with binary files. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-12 17:20 -0800 |
| Message-ID | <lnh97ckwfz.fsf@kst-u.example.com> |
| In reply to | #96442 |
"James R. Kuyper" <jameskuyper@verizon.net> writes:
> 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.
Ok, then that *could* make sense. It's unusual to use fprintf to write
to a binary stream (or fwrite to write to a text stream), but it's
perfectly valid.
Except that, as Ben pointed out, printf writes to stdout, which is a
text stream (unless you do something funny with freopen).
[...]
--
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 | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-11-09 19:49 -0500 |
| Message-ID | <33c9b21f-76d1-f2f9-8d99-67638a79fef3@verizon.net> |
| In reply to | #96248 |
On 11/09/2016 06:44 PM, Chris M. Thomasson wrote:
...
> It also works fine with MSVC. However, with Jacob's compiler, it does
> does not work with the dynamic bracket assignment.
> ___________________________________________
> main(int argc, char **argv)
> {
> struct ffe_cmdline_app self;
> struct ffe_cmdline_args cmdargs = { argc, argv };
> [...]
> ___________________________________________
>
> After this, cmdargs.argc == 0. Not good for my program. However, if I
> change the code to:
>
> ___________________________________________
> int
> main(int argc, char **argv)
> {
> struct ffe_cmdline_app self;
> struct ffe_cmdline_args cmdargs;// = { argc, argv };
>
> cmdargs.argc = argc;
> cmdargs.argv = argv;
> ___________________________________________
>
>
> and it does assign the correct values. Note the comment style of //...
> This works, which makes me think its in c99 mode.
That doesn't follow. In it's default mode, like most other compilers
(including gcc, clang, and MSVC++), lcc-win implements it's own unique
language that is similar to C but does not fully conform to any
particular version of the C standard.
In a mode fully conforming to C90, the // comments are syntax errors and
the use of non-constant initializers are constraint violations, so at
least one diagnostic should be generated by such code. In a mode fully
conforming to C99 neither of those should be a problem, and the
initializers should work as you would expect them to. In lcc-win's
default mode, I have no idea what should happen, but jacob should know.
...
>> Is the compiler you're using operating in C90 mode, C99, or C2011, or is
>> it in it's default mode? Most compilers don't fully conform to ANY
>> version of the standard in their default mode.
>
> I do not know, for this is my first experience with Jacob's compiler. I
> think its C99. Not sure though. I need to study it, and learn how to use
> it correctly. However, I think I can get it to work.
What command line options did you use to build this program?
> BTW, can you compile it and run it. It has usage information built into
> the program.
The issue is how it compiles with lcc-win64. I don't have (and don't
want to have) a copy of lcc-win64 to compile it with. I have no Windows
system to test it on even if I did want to install it. I've found
references to an lcc-linux version that I probably could install, but
I've been unable to locate that version. The documentation for the
windows version appears to be in the form of Windows executables that I
can't execute*, so I can't look at the user's manual - but presumably
you can, so pleat take a look at them. Which command line options are
needed to ensure full conformance with C99?
* I do have wine set up on my home machine, which might allow me to
execute those Windows executables, but I won't be near that machine any
time soon.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-11-10 16:14 -0800 |
| Message-ID | <o032fm$ogm$1@dont-email.me> |
| In reply to | #96251 |
On 11/9/2016 4:49 PM, James R. Kuyper wrote:
> On 11/09/2016 06:44 PM, Chris M. Thomasson wrote:
> ...
>> It also works fine with MSVC. However, with Jacob's compiler, it does
>> does not work with the dynamic bracket assignment.
>> ___________________________________________
>> main(int argc, char **argv)
>> {
>> struct ffe_cmdline_app self;
>> struct ffe_cmdline_args cmdargs = { argc, argv };
>> [...]
>> ___________________________________________
>>
>> After this, cmdargs.argc == 0. Not good for my program. However, if I
>> change the code to:
>>
>> ___________________________________________
>> int
>> main(int argc, char **argv)
>> {
>> struct ffe_cmdline_app self;
>> struct ffe_cmdline_args cmdargs;// = { argc, argv };
>>
>> cmdargs.argc = argc;
>> cmdargs.argv = argv;
>> ___________________________________________
>>
>>
>> and it does assign the correct values. Note the comment style of //...
>> This works, which makes me think its in c99 mode.
>
> That doesn't follow. In it's default mode, like most other compilers
> (including gcc, clang, and MSVC++), lcc-win implements it's own unique
> language that is similar to C but does not fully conform to any
> particular version of the C standard.
Well, it works in default mode for GCC and MSVC for me. As for lcc-win,
I am a total newb because its my first experience. I like the challenge
to see how I can get my cipher code to work with it, as is.
> In a mode fully conforming to C90, the // comments are syntax errors and
> the use of non-constant initializers are constraint violations, so at
> least one diagnostic should be generated by such code.
Agreed.
> In a mode fully
> conforming to C99 neither of those should be a problem, and the
> initializers should work as you would expect them to. In lcc-win's
> default mode, I have no idea what should happen, but jacob should know.
I agree. Although, IMVHO, its nice to be able to converse with the
compiler creator! I respect Jacob.
> ...
>>> Is the compiler you're using operating in C90 mode, C99, or C2011, or is
>>> it in it's default mode? Most compilers don't fully conform to ANY
>>> version of the standard in their default mode.
>>
>> I do not know, for this is my first experience with Jacob's compiler. I
>> think its C99. Not sure though. I need to study it, and learn how to use
>> it correctly. However, I think I can get it to work.
>
> What command line options did you use to build this program?
>
>> BTW, can you compile it and run it. It has usage information built into
>> the program.
>
> The issue is how it compiles with lcc-win64. I don't have (and don't
> want to have) a copy of lcc-win64 to compile it with. I have no Windows
> system to test it on even if I did want to install it.
Fair enough.
> I've found
> references to an lcc-linux version that I probably could install, but
> I've been unable to locate that version. The documentation for the
> windows version appears to be in the form of Windows executables that I
> can't execute*, so I can't look at the user's manual - but presumably
> you can, so pleat take a look at them. Which command line options are
> needed to ensure full conformance with C99?
>
> * I do have wine set up on my home machine, which might allow me to
> execute those Windows executables, but I won't be near that machine any
> time soon.
Well, yeah. No need to install wine just to try it. I agree.
FWIW, I use several operating systems, and Windows is one of them. So,
well... Oh well...
;^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-11-11 15:28 -0800 |
| Message-ID | <o05k5p$bfi$1@dont-email.me> |
| In reply to | #96364 |
On 11/10/2016 4:14 PM, Chris M. Thomasson wrote:
> On 11/9/2016 4:49 PM, James R. Kuyper wrote:
>> On 11/09/2016 06:44 PM, Chris M. Thomasson wrote:
>> ...
>>> It also works fine with MSVC. However, with Jacob's compiler, it does
>>> does not work with the dynamic bracket assignment.
>>> ___________________________________________
>>> main(int argc, char **argv)
>>> {
>>> struct ffe_cmdline_app self;
>>> struct ffe_cmdline_args cmdargs = { argc, argv };
>>> [...]
>>> ___________________________________________
>>>
>>> After this, cmdargs.argc == 0. Not good for my program. However, if I
>>> change the code to:
>>>
>>> ___________________________________________
>>> int
>>> main(int argc, char **argv)
>>> {
>>> struct ffe_cmdline_app self;
>>> struct ffe_cmdline_args cmdargs;// = { argc, argv };
>>>
>>> cmdargs.argc = argc;
>>> cmdargs.argv = argv;
>>> ___________________________________________
>>>
>>>
>>> and it does assign the correct values. Note the comment style of //...
>>> This works, which makes me think its in c99 mode.
>>
>> That doesn't follow. In it's default mode, like most other compilers
>> (including gcc, clang, and MSVC++), lcc-win implements it's own unique
>> language that is similar to C but does not fully conform to any
>> particular version of the C standard.
>
> Well, it works in default mode for GCC and MSVC for me. As for lcc-win,
> I am a total newb because its my first experience. I like the challenge
> to see how I can get my cipher code to work with it, as is.
I have hit a road block for I got a failure in fscanf wrt lcc, with
valid file and valid command lines to my program, and other compilers
that work with these settings, command lines, ect.
I cannot get past this without the source to lcc.
[...]
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-12 00:45 +0000 |
| Message-ID | <87bmxlo7a3.fsf@bsb.me.uk> |
| In reply to | #96396 |
"Chris M. Thomasson" <invalid@invalid.invalid> writes: <snip> > I have hit a road block for I got a failure in fscanf wrt lcc, with > valid file and valid command lines to my program, and other compilers > that work with these settings, command lines, ect. Have you posted all the code and all the data? Without that, it's hard to help out. I've taken your fscanf calling function and put it input a small program and it works fine, so I suspect an error somewhere else. > I cannot get past this without the source to lcc. That's rather extreme. You need to rule out every other source of potential problems first. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-11-12 11:40 -0800 |
| Message-ID | <o07r7a$ntq$1@dont-email.me> |
| In reply to | #96401 |
On 11/11/2016 4:45 PM, Ben Bacarisse wrote: > "Chris M. Thomasson" <invalid@invalid.invalid> writes: > <snip> > >> I have hit a road block for I got a failure in fscanf wrt lcc, with >> valid file and valid command lines to my program, and other compilers >> that work with these settings, command lines, ect. > > Have you posted all the code and all the data? Here is all the code http://pastebin.com/D7N4vBWa As for the data, I am trying to use a movie file. But, here is a simple text file I will work with from now on containing the following test between the lines: _________________________________________ This is plaintext _________________________________________ to get us all on the same page. BTW, the secret key file I am using is the default one created by the following command line to my program: ffe 0 skey and produces the following text file: _________________________________________ iters:314 scale:(1.0000000000000, 0.0000000000000) julia0:(0.3600000000000, 0.0000000000000) julia1:(-0.7500000000000, 0.1000000000000) julia2:(0.3500000000000, 0.1000000000000) axes:(-0.7000000000000, 0.3000000000000, -0.2000000000000, 0.8000000000000) _________________________________________ with "\r\n" line endings. I should just put this all up on github, including the default secret key and the sample plaintext file above. > Without that, it's hard > to help out. I've taken your fscanf calling function and put it input a > small program and it works fine, so I suspect an error somewhere else. I cannot see an error somewhere else as of now because it works so well with other compilers. >> I cannot get past this without the source to lcc. > > That's rather extreme. You need to rule out every other source of > potential problems first. Touche! :^o
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-11-12 11:42 -0800 |
| Message-ID | <o07rak$ntq$2@dont-email.me> |
| In reply to | #96421 |
On 11/12/2016 11:40 AM, Chris M. Thomasson wrote:
> On 11/11/2016 4:45 PM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <invalid@invalid.invalid> writes:
>> <snip>
>>
>>> I have hit a road block for I got a failure in fscanf wrt lcc, with
>>> valid file and valid command lines to my program, and other compilers
>>> that work with these settings, command lines, ect.
>>
>> Have you posted all the code and all the data?
>
> Here is all the code http://pastebin.com/D7N4vBWa
[...]
FWIW, here is the code, which is an older version of my cipher, just in
case one does not like pastebin:
________________________________________________________________
#include <stdlib.h>
#include <stdio.h>
#include <stddef.h>
#include <stdint.h>
#include <limits.h>
#include <math.h>
#include <time.h>
/* Defines/Macros
_____________________________________________________________*/
#define FFE_AXES_ARGS 4
#define FFE_SECRET_KEY_ARGS 13
#define FFE_CMDLINE_ARGS 4
#define FFE_JULIA_N 3
#define FFE_BUFSZ (1024 * 1024 * 4)
#define FFE_ERROR 0x1
#define FFE_BYTESZ (UCHAR_MAX + 1)
#define FFE_PREC "%.13lf"
#define FFE_MIN(mp_n0, mp_n1) \
((mp_n0) < (mp_n1) ? (mp_n0) : (mp_n1))
#define RN ffe_util_random
/* Conversions
_____________________________________________________________*/
int
ffe_cnv_uint_from_buffer(
const char* buf,
unsigned int* pret
){
unsigned int ret = 0;
if (sscanf(buf, "%u", &ret) == 1)
{
*pret = ret;
return 0;
}
return FFE_ERROR;
}
int
ffe_cnv_double_to_string_to_double(
double n,
double* pret
){
char nbuf[UCHAR_MAX + 1] = { '\0' };
if (sprintf(nbuf, FFE_PREC, n))
{
if (sscanf(nbuf, "%lf", pret) == 1)
{
return 0;
}
}
return FFE_ERROR;
}
/* Utility
_____________________________________________________________*/
size_t
ffe_util_cantor_packing(
size_t n0,
size_t n1
){
size_t ret = (size_t)(0.5 * (n0 + n1) * (n0 + n1 + 1) + n1);
return ret;
}
double
ffe_util_random(void)
{
return (rand() / (RAND_MAX - 1.0));
}
double
ffe_util_random_sign(double n)
{
return (ffe_util_random() < 0.5) ? (n) : (-n);
}
/* A 2d point
_____________________________________________________________*/
struct ffe_point
{
double x;
double y;
};
struct ffe_point
ffe_complex_add(
struct ffe_point n0,
struct ffe_point n1
){
struct ffe_point ret = { n0.x + n1.x, n0.y + n1.y };
return ret;
}
struct ffe_point
ffe_complex_mul(
struct ffe_point n0,
struct ffe_point n1
){
struct ffe_point ret = {
n0.x * n1.x - n0.y * n1.y,
n0.x * n1.y + n0.y * n1.x
};
return ret;
}
/* Axes describing a 2d plane
_____________________________________________________________*/
struct ffe_axes
{
double xmin;
double xmax;
double ymin;
double ymax;
};
/* The Secret Key
_____________________________________________________________*/
struct ffe_secret_key
{
unsigned int iters;
struct ffe_point scale;
struct ffe_point julia[FFE_JULIA_N];
struct ffe_axes axes;
};
int
ffe_secret_key_output_status(
struct ffe_secret_key const* const self,
FILE* out_file
){
if (fprintf(out_file,
"Secret Key:\r\n"
"____________________________________________\r\n"
"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 "\r\n "
FFE_PREC ", " FFE_PREC ")\r\n"
"____________________________________________\r\n\r\n",
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
) > 0)
{
return 0;
}
return FFE_ERROR;
}
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;
}
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 Salt
_____________________________________________________________*/
struct ffe_salt
{
struct ffe_axes axes;
};
int
ffe_salt_output_status(
struct ffe_salt* const self,
FILE* out_file
){
if (fprintf(out_file,
"Salt:\r\n"
"____________________________________________\r\n"
"xmin = " FFE_PREC "\r\n"
"xmax = " FFE_PREC "\r\n"
"ymin = " FFE_PREC "\r\n"
"ymax = " FFE_PREC "\r\n"
"____________________________________________\r\n\r\n",
self->axes.xmin, self->axes.xmax,
self->axes.ymin, self->axes.ymax) > 0)
{
return 0;
}
return FFE_ERROR;
}
int
ffe_salt_parse_from_file(
struct ffe_salt* const self,
FILE* in_file,
unsigned char* buf,
size_t bufsz,
size_t* pin_file_size
){
int ret = fscanf(
in_file,
"axes:(%lf, %lf, %lf, %lf)\r\n",
&self->axes.xmin, &self->axes.xmax,
&self->axes.ymin, &self->axes.ymax
);
if (ret == FFE_AXES_ARGS)
{
size_t size = 0;
size_t rbytes = 0;
long offset = ftell(in_file);
if (offset > 0)
{
while ((rbytes = fread(buf, 1, bufsz, in_file)))
{
size += rbytes;
printf("Parsing salt %lu bytes...\r", (unsigned long)size);
}
printf("\r\n\r\n");
*pin_file_size = size;
if (! fseek(in_file, offset, SEEK_SET))
{
if (pin_file_size)
{
return 0;
}
}
}
}
return FFE_ERROR;
}
int
ffe_salt_generate_from_file(
struct ffe_salt* const self,
FILE* in_file,
unsigned char* buf,
size_t bufsz,
size_t* pin_file_size
){
size_t size = 0;
size_t rbytes = 0;
size_t pack = 0;
while ((rbytes = fread(buf, 1, bufsz, in_file)))
{
size += rbytes;
for (size_t i = 0; i < rbytes; ++i)
{
pack = (pack + ffe_util_cantor_packing(pack, buf[i])) %
SIZE_MAX;
}
printf("Generating salt %lu bytes...\r", (unsigned long)size);
}
printf("\r\n\r\n");
*pin_file_size = size;
rewind(in_file);
if (! ferror(in_file))
{
if (pin_file_size)
{
double pack_m[4] = {
fmod(pow(pack, RN() * 0.3 + 0.3), 0.3 + RN() * 0.6),
fmod(pow(pack, RN() * 0.3 + 0.3), 0.3 + RN() * 0.6),
fmod(pow(pack, RN() * 0.3 + 0.3), 0.3 + RN() * 0.6),
fmod(pow(pack, RN() * 0.3 + 0.3), 0.3 + RN() * 0.6)
};
ffe_cnv_double_to_string_to_double(pack_m[0], &pack_m[0]);
ffe_cnv_double_to_string_to_double(pack_m[1], &pack_m[1]);
ffe_cnv_double_to_string_to_double(pack_m[2], &pack_m[2]);
ffe_cnv_double_to_string_to_double(pack_m[3], &pack_m[3]);
self->axes.xmin = pack_m[0];
self->axes.xmax = pack_m[1];
self->axes.ymin = pack_m[2];
self->axes.ymax = pack_m[3];
return 0;
}
}
return FFE_ERROR;
}
int
ffe_salt_store_to_file(
struct ffe_salt const* const self,
FILE* out_file
){
int ret = fprintf(
out_file,
"axes:(" FFE_PREC ", " FFE_PREC ", "
FFE_PREC ", " FFE_PREC ")\r\n",
self->axes.xmin, self->axes.xmax,
self->axes.ymin, self->axes.ymax
);
if (ret > 1)
{
if (! ferror(out_file))
{
return 0;
}
}
return FFE_ERROR;
}
/* Funny Fractal Encryption
_____________________________________________________________*/
struct ffe
{
unsigned char* buf;
size_t bufsz;
};
struct ffe_cipher
{
size_t in_file_size;
unsigned int dims;
struct ffe_secret_key const* skey;
struct ffe_salt salt;
};
struct ffe_mutator
{
unsigned int iters;
struct ffe_point z;
double min_orbit_trap;
};
int
ffe_create(
struct ffe* const self,
size_t bufsz
){
self->buf = malloc(bufsz);
if (self->buf)
{
self->bufsz = bufsz;
return 0;
}
return FFE_ERROR;
}
void
ffe_destroy(
struct ffe* const self
){
free(self->buf);
}
int
ffe_cipher_iterate_point(
struct ffe_cipher const* const cipher,
struct ffe_point const* c,
struct ffe_mutator* mutator
){
struct ffe_point z = *c;
double min_orbit_trap = 99999999999999.0;
double orbit_escape = 2.0 + (
fabs(cipher->skey->julia[0].x) + fabs(cipher->skey->julia[0].y) +
fabs(cipher->skey->julia[1].x) + fabs(cipher->skey->julia[1].y) +
fabs(cipher->skey->julia[2].x) + fabs(cipher->skey->julia[2].y)
);
for (size_t i = 0; i < cipher->skey->iters; ++i)
{
z = ffe_complex_mul(z, z);
z = ffe_complex_add(z, cipher->skey->julia[i % FFE_JULIA_N]);
z = ffe_complex_mul(z, cipher->skey->scale);
double orbit_dis = sqrt(z.x * z.x + z.y * z.y);
min_orbit_trap = FFE_MIN(min_orbit_trap, orbit_dis);
if (orbit_dis > orbit_escape)
{
mutator->iters = i + 1;
mutator->min_orbit_trap = min_orbit_trap;
mutator->z = z;
return 0;
}
}
mutator->iters = cipher->skey->iters + 1;
mutator->min_orbit_trap = min_orbit_trap;
mutator->z = z;
return 1;
}
int
ffe_cipher_buffer_inplace(
struct ffe* const self,
struct ffe_cipher const* const cipher,
unsigned char* buf,
size_t bufsz,
size_t n,
unsigned int flags
){
double xstep = (cipher->salt.axes.xmax -
cipher->salt.axes.xmin) / (cipher->dims - 1);
double ystep = (cipher->salt.axes.ymax -
cipher->salt.axes.ymin) / (cipher->dims - 1);
struct ffe_mutator mutator = { 0, { 0.0, 0.0 }, 0.0 };
for (size_t i = 0; i < bufsz; ++i, ++n)
{
unsigned int vpx = n % cipher->dims;
unsigned int vpy = n / cipher->dims;
struct ffe_point c = {
cipher->salt.axes.xmin + vpx * xstep,
cipher->salt.axes.ymax - vpy * ystep
};
int iret = ffe_cipher_iterate_point(cipher, &c, &mutator);
double cmutator_real = mutator.iters * mutator.min_orbit_trap *
(mutator.min_orbit_trap + mutator.z.x + mutator.z.y);
cmutator_real += cos((mutator.min_orbit_trap +
mutator.z.x + mutator.z.y) * 1304) * 256;
if (! iret)
{
cmutator_real *= 17273;
}
else
{
cmutator_real *= 115237;
}
unsigned int cmutator_uint = ((size_t)fabs(cmutator_real)) %
FFE_BYTESZ;
int cmutated_byte = 0;
if (flags == 0x1)
{
// Encrypt
cmutated_byte = (buf[i] + cmutator_uint) % FFE_BYTESZ;
}
else
{
// Decrypt
cmutated_byte = buf[i] - cmutator_uint;
if (cmutated_byte < 0)
{
cmutated_byte = abs((buf[i] + FFE_BYTESZ) - cmutator_uint);
}
}
buf[i] = cmutated_byte;
if (! (n % 8192))
{
unsigned int per = (unsigned int)ceil((n /
(double)cipher->in_file_size) * 100.0);
if (flags == 0x1) printf("Encrypted %lu bytes: %u%%
complete...\r", (unsigned long)n, per);
else printf("Decrypted %lu bytes: %u%% complete...\r",
(unsigned long)n, per);
}
}
unsigned int per = (unsigned int)ceil((n /
(double)cipher->in_file_size) * 100.0);
if (flags == 0x1) printf("Encrypted %lu bytes: %u%% complete...\r",
(unsigned long)n, per);
else printf("Decrypted %lu bytes: %u%% complete...\r",
(unsigned long)n, per);
return 0;
}
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;
}
int
ffe_encrypt(
struct ffe* const self,
struct ffe_secret_key const* skey,
FILE* in_file,
FILE* out_file
){
size_t in_file_size = 0;
struct ffe_cipher cipher = {
0, 0, skey, { { 0.0, 0.0, 0.0, 0.0 } }
};
if (! ffe_salt_generate_from_file(
&cipher.salt,
in_file,
self->buf,
self->bufsz,
&in_file_size))
{
ffe_salt_output_status(&cipher.salt, stdout);
if (! ffe_salt_store_to_file(&cipher.salt, out_file))
{
size_t size = 0;
size_t rbytes = 0;
ffe_sys_calc_salt(&cipher, in_file_size);
while ((rbytes = fread(self->buf, 1, self->bufsz, in_file)))
{
if (ffe_cipher_buffer_inplace(
self,
&cipher,
self->buf,
rbytes,
size,
0x1))
{
return FFE_ERROR;
}
if (fwrite(self->buf, 1, rbytes, out_file) != rbytes)
{
return FFE_ERROR;
}
size += rbytes;
}
if (in_file_size == size)
{
return 0;
}
}
}
return FFE_ERROR;
}
int
ffe_decrypt(
struct ffe* const self,
struct ffe_secret_key const* skey,
FILE* in_file,
FILE* out_file
){
size_t in_file_size = 0;
struct ffe_cipher cipher = {
0, 0, skey, { { 0.0, 0.0, 0.0, 0.0 } }
};
if (! ffe_salt_parse_from_file(
&cipher.salt,
in_file,
self->buf,
self->bufsz,
&in_file_size))
{
size_t size = 0;
size_t rbytes = 0;
ffe_salt_output_status(&cipher.salt, stdout);
ffe_sys_calc_salt(&cipher, in_file_size);
while ((rbytes = fread(self->buf, 1, self->bufsz, in_file)))
{
if (ffe_cipher_buffer_inplace(
self,
&cipher,
self->buf,
rbytes,
size,
0x2))
{
return FFE_ERROR;
}
if (fwrite(self->buf, 1, rbytes, out_file) != rbytes)
{
return FFE_ERROR;
}
size += rbytes;
}
if (in_file_size == size)
{
return 0;
}
}
return FFE_ERROR;
}
/* Funny Fractal Encryption Test Command Line App
_____________________________________________________________*/
struct ffe_cmdline_args
{
int argc;
char **argv;
};
struct ffe_cmdline_app
{
struct ffe_cmdline_args cmdargs;
struct ffe cipher;
struct ffe_secret_key skey;
unsigned int flags;
FILE* in_file;
FILE* out_file;
};
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))
{
if (! fclose(skey_file))
{
if (! ffe_create(&self->cipher, FFE_BUFSZ))
{
if (self->flags == 1)
{
printf(
"secret key: %s\r\n"
"in file: %s\r\n"
"out file: %s\r\n\r\n",
self->cmdargs.argv[2],
self->cmdargs.argv[3],
self->cmdargs.argv[4]
);
}
else if (self->flags == 2)
{
printf(
"secret key: %s\r\n"
"in file: %s\r\n"
"out file: %s\r\n\r\n",
self->cmdargs.argv[2],
self->cmdargs.argv[4],
self->cmdargs.argv[3]
);
}
ffe_secret_key_output_status(&self->skey, stdout);
return 0;
}
}
}
else
{
fclose(skey_file);
}
}
}
return FFE_ERROR;
}
int
ffe_cmdline_sys_create_default_skey(
struct ffe_cmdline_app* const self
){
struct ffe_secret_key const skey = {
314,
{ 1.0, 0.0 },
{ { 0.36, 0.0 }, { -0.75, 0.1 }, { 0.35, 0.1 } },
{ -0.7, 0.3, -0.2, 0.8 }
};
if (! self->out_file)
{
self->out_file = fopen(self->cmdargs.argv[2], "wb");
if (! self->out_file) return FFE_ERROR;
}
if (! ffe_secret_key_store_to_file(&skey, self->out_file))
{
printf("out file: %s\r\n"
"default secret key created!\r\n\r\n",
self->cmdargs.argv[2]);
ffe_secret_key_output_status(&skey, stdout);
return 0;
}
return FFE_ERROR;
}
int
ffe_cmdline_sys_encrypt(
struct ffe_cmdline_app* const self
){
if (! self->out_file)
{
self->in_file = fopen(self->cmdargs.argv[3], "rb");
self->out_file = fopen(self->cmdargs.argv[4], "wb");
if (! self->in_file || ! self->out_file) return FFE_ERROR;
}
if (! ffe_encrypt(
&self->cipher,
&self->skey,
self->in_file,
self->out_file))
{
printf("\r\n____________________________________________\r\n\r\n");
return 0;
}
return FFE_ERROR;
}
int
ffe_cmdline_sys_decrypt(
struct ffe_cmdline_app* const self
){
if (! self->out_file)
{
self->in_file = fopen(self->cmdargs.argv[4], "rb");
self->out_file = fopen(self->cmdargs.argv[3], "wb");
if (! self->in_file || ! self->out_file) return FFE_ERROR;
}
if (! ffe_decrypt(
&self->cipher,
&self->skey,
self->in_file,
self->out_file))
{
printf("\r\n____________________________________________\r\n\r\n");
return 0;
}
return FFE_ERROR;
}
void
ffe_cmdline_display_help(
FILE* out_file
){
fprintf(out_file,
"\r\n\r\nProgram Usage:\r\n"
"___________________________________________\r\n"
"The command line for creating a default secret key file that
can\r\n"
"be changed with a text editor has two arguments:\r\n\r\n"
"ffe 0 <secret_key_filename>\r\n\r\n\r\n"
"The encryption command line will encrypt a plaintext into a
ciphertext\r\n"
"using a secret key, and has 4 arguments:\r\n\r\n"
"ffe 1 <secret_key_filename> <plaintext_filename>
<ciphertext_filename>\r\n\r\n\r\n"
"The decryption command line will decrypt a ciphertext into a
plaintext\r\n"
"using a secret key, and has 4 arguments:\r\n\r\n"
"ffe 2 <secret_key_filename> <plaintext_filename>
<ciphertext_filename>\r\n\r\n\r\n"
"The command line for displaying this usage information has no
arguments:\r\n"
"ffe\r\n\r\n\r\n"
"Enjoy!\r\n"
"___________________________________________\r\n\r\n"
);
}
int
ffe_cmdline_app_run(
struct ffe_cmdline_app* const self
){
int ret = FFE_ERROR;
if (self->flags == 0x0)
{
ret = ffe_cmdline_sys_create_default_skey(self);
}
else if (self->flags == 0x1)
{
ret = ffe_cmdline_sys_encrypt(self);
}
else if (self->flags == 0x2)
{
ret = ffe_cmdline_sys_decrypt(self);
}
return ret;
}
int
ffe_cmdline_app_destroy(
struct ffe_cmdline_app* const self
){
int ret = 0;
if ((self->in_file && fclose(self->in_file)) ||
(self->out_file && fclose(self->out_file)))
{
ret = FFE_ERROR;
}
if (self->flags != 0)
{
ffe_destroy(&self->cipher);
}
return ret;
}
int
main(int argc, char **argv)
{
struct ffe_cmdline_app self;
struct ffe_cmdline_args cmdargs = { argc, argv };
if (! ffe_cmdline_app_create(&self, &cmdargs))
{
if (! ffe_cmdline_app_run(&self))
{
if (! ffe_cmdline_app_destroy(&self))
{
puts("\r\n\r\nProgram Completed!");
getchar();
return EXIT_SUCCESS;
}
}
else
{
ffe_cmdline_app_destroy(&self);
}
}
ffe_cmdline_display_help(stdout);
puts("\r\n\r\nProgram Failed!");
getchar();
return EXIT_FAILURE;
}
________________________________________________________________
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-12 20:18 +0000 |
| Message-ID | <87fumwmoys.fsf@bsb.me.uk> |
| In reply to | #96421 |
"Chris M. Thomasson" <invalid@invalid.invalid> writes: > On 11/11/2016 4:45 PM, Ben Bacarisse wrote: >> "Chris M. Thomasson" <invalid@invalid.invalid> writes: >> <snip> >> >>> I have hit a road block for I got a failure in fscanf wrt lcc, with >>> valid file and valid command lines to my program, and other compilers >>> that work with these settings, command lines, ect. >> >> Have you posted all the code and all the data? > > Here is all the code http://pastebin.com/D7N4vBWa > > As for the data, I am trying to use a movie file. But, here is a > simple text file I will work with from now on containing the following > test between the lines: > _________________________________________ > This is plaintext > _________________________________________ > > to get us all on the same page. BTW, the secret key file I am using is > the default one created by the following command line to my program: > > ffe 0 skey > > and produces the following text file: > _________________________________________ > iters:314 > scale:(1.0000000000000, 0.0000000000000) > julia0:(0.3600000000000, 0.0000000000000) > julia1:(-0.7500000000000, 0.1000000000000) > julia2:(0.3500000000000, 0.1000000000000) > axes:(-0.7000000000000, 0.3000000000000, -0.2000000000000, 0.8000000000000) > _________________________________________ > > with "\r\n" line endings. Except on the last line and that is the problem. I can now re-create the problem you are seeing but only by removing the line ending (exactly which one does not matter) on the last line. With a property terminated last line, the fscanf call returns 13. This looks like a bug in lcc-win's library but an easy one to work round. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-11-14 15:23 -0800 |
| Message-ID | <o0dh0c$n7m$1@dont-email.me> |
| In reply to | #96424 |
On 11/12/2016 12:18 PM, Ben Bacarisse wrote: > "Chris M. Thomasson" <invalid@invalid.invalid> writes: > >> On 11/11/2016 4:45 PM, Ben Bacarisse wrote: >>> "Chris M. Thomasson" <invalid@invalid.invalid> writes: >>> <snip> >>> >>>> I have hit a road block for I got a failure in fscanf wrt lcc, with >>>> valid file and valid command lines to my program, and other compilers >>>> that work with these settings, command lines, ect. >>> >>> Have you posted all the code and all the data? >> >> Here is all the code http://pastebin.com/D7N4vBWa >> >> As for the data, I am trying to use a movie file. But, here is a >> simple text file I will work with from now on containing the following >> test between the lines: >> _________________________________________ >> This is plaintext >> _________________________________________ >> >> to get us all on the same page. BTW, the secret key file I am using is >> the default one created by the following command line to my program: >> >> ffe 0 skey >> >> and produces the following text file: >> _________________________________________ >> iters:314 >> scale:(1.0000000000000, 0.0000000000000) >> julia0:(0.3600000000000, 0.0000000000000) >> julia1:(-0.7500000000000, 0.1000000000000) >> julia2:(0.3500000000000, 0.1000000000000) >> axes:(-0.7000000000000, 0.3000000000000, -0.2000000000000, 0.8000000000000) >> _________________________________________ >> >> with "\r\n" line endings. > > Except on the last line and that is the problem. ARGH!!!!!! > > I can now re-create the problem you are seeing but only by removing the > line ending (exactly which one does not matter) on the last line. With > a property terminated last line, the fscanf call returns 13. > > This looks like a bug in lcc-win's library but an easy one to work round. > > <snip> >
[toc] | [prev] | [next] | [standalone]
Page 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web