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 14 of 15 — ← Prev page 1 … 12 13 [14] 15 Next page →
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-13 11:46 +0100 |
| Message-ID | <o09g9j$l80$1@dont-email.me> |
| In reply to | #96396 |
Le 12/11/2016 à 00:28, Chris M. Thomasson a écrit : > 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. Pleaase tell me where do I send you the source of scanf Thanks for taking a look
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-11-10 16:22 -0800 |
| Message-ID | <o032ui$pnq$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: [...] >> 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? Well, I actually do not know. I am using the IDE created by Jacob. So far, I have not used his compiler directly from the command line. I am doing this in my spare time. I should have some more time tomorrow to dig into the details. However, I like that a member of this group created a compiler. That is just neat to me. :^)
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-11-11 16:52 -0800 |
| Message-ID | <1a7b297c-5ff7-42da-8307-cb8c547ee196@googlegroups.com> |
| In reply to | #96365 |
On Thursday, November 10, 2016 at 7:22:14 PM UTC-5, 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: > [...] > >> 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? > > Well, I actually do not know. I am using the IDE created by Jacob. As a general rule, what command-line compilers handle with command line options are handled by IDEs with configuration menus. In principle, I'm therefore asking you which settings you chose on all of your configuration menus. In practice, most of those settings aren't relevant to this question - but if you're not very familiar with this particular IDE, it might be difficult to identify the ones that are.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-11-08 14:57 -0800 |
| Message-ID | <0aeb9981-9b6c-48e2-82d0-6a322032fcd1@googlegroups.com> |
| In reply to | #96150 |
On Tuesday, November 8, 2016 at 4:26:32 PM UTC-6, jacobnavia wrote: > Le 08/11/2016 à 23:15, Chris M. Thomasson a écrit : > > Holy shi%! So, when I write C, the C committee might think I am crazy!? > > Their opinion is more "subtle" than that. > > C should not be used for new developments and the task of the committee > is to guarantee that the legacy code that has been written in C still runs > > Nothing else. > Then how in the *hell* do they explain adding the damned threading library and changing the language of the standard to accomodate it? That was a *major* enhancement for just supporting legacy code. I mean, I can understand the sentiment of not using C for new, mission- critical systems. The cyberattacks of the last couple of decades have pretty much proven that it is *hard*, if not impossible, to deploy secure C code. And to pre-empt the inevitable "it's not the language, it's the programmers" response - if the human is the *strong* link in your chain, then you are well and truly screwed. Yes, the problem is the language, not the people writing it. But by that same token, if they're going to add a goddamned threading library to the language (that I *don't* remember a great hue and cry for), then they must expect C to be used for new development going forward. Is it just that they don't want to deal with generics?
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-09 00:13 +0100 |
| Message-ID | <nvtm58$o9u$1@dont-email.me> |
| In reply to | #96158 |
Le 08/11/2016 à 23:57, John Bode a écrit : > Then how in the *hell* do they explain adding the damned threading library > and changing the language of the standard to accomodate it? That was a > *major* enhancement for just supporting legacy code. The threading library was based on a product of Mr Plaugher, one of the members of the committee. There was an outcry from the POSIX people that have been working on the pthreads standard for ages. The C committee did not care and published it anyway.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-08 15:46 -0800 |
| Message-ID | <lnvavxpma6.fsf@kst-u.example.com> |
| In reply to | #96160 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 08/11/2016 à 23:57, John Bode a écrit :
>> Then how in the *hell* do they explain adding the damned threading library
>> and changing the language of the standard to accomodate it? That was a
>> *major* enhancement for just supporting legacy code.
>
> The threading library was based on a product of Mr Plaugher, one of the
> members of the committee. There was an outcry from the POSIX people that
> have been working on the pthreads standard for ages. The C committee did
> not care and published it anyway.
I don't recall hearing about such an outcry. Do you have a citation?
(Not doubting you, just asking.)
--
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 | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-11-08 20:04 -0500 |
| Message-ID | <nvtsmp$buq$1@jstuckle.eternal-september.org> |
| In reply to | #96158 |
On 11/8/2016 5:57 PM, John Bode wrote: > On Tuesday, November 8, 2016 at 4:26:32 PM UTC-6, jacobnavia wrote: >> Le 08/11/2016 à 23:15, Chris M. Thomasson a écrit : >>> Holy shi%! So, when I write C, the C committee might think I am crazy!? >> >> Their opinion is more "subtle" than that. >> >> C should not be used for new developments and the task of the committee >> is to guarantee that the legacy code that has been written in C still runs >> >> Nothing else. >> > > Then how in the *hell* do they explain adding the damned threading library > and changing the language of the standard to accomodate it? That was a > *major* enhancement for just supporting legacy code. > > I mean, I can understand the sentiment of not using C for new, mission- > critical systems. The cyberattacks of the last couple of decades have > pretty much proven that it is *hard*, if not impossible, to deploy > secure C code. And to pre-empt the inevitable "it's not the language, > it's the programmers" response - if the human is the *strong* link in your > chain, then you are well and truly screwed. Yes, the problem is the > language, not the people writing it. > > But by that same token, if they're going to add a goddamned threading > library to the language (that I *don't* remember a great hue and cry for), > then they must expect C to be used for new development going forward. > > Is it just that they don't want to deal with generics? > It's no harder to deploy secure C code than it is in any other language. Security is not an attribute of the language; it is the competence of the programmer. I know a lot of good programmers who write secure C code. I also know a lot of programmers who write insecure code - in C as well as other languages. Competent programmers can write secure code in *any* language they are proficient in. Incompetent programmers can't write secure code in any language. But they blame the language for their failings. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-11-09 03:23 -0800 |
| Message-ID | <d22b80eb-444a-4f63-a3e9-67a4062c6dae@googlegroups.com> |
| In reply to | #96170 |
On Tuesday, November 8, 2016 at 11:05:04 PM UTC-2, Jerry Stuckle wrote: > On 11/8/2016 5:57 PM, John Bode wrote: > > On Tuesday, November 8, 2016 at 4:26:32 PM UTC-6, jacobnavia wrote: > >> Le 08/11/2016 à 23:15, Chris M. Thomasson a écrit : > >>> Holy shi%! So, when I write C, the C committee might think I am crazy!? > >> > >> Their opinion is more "subtle" than that. > >> > >> C should not be used for new developments and the task of the committee > >> is to guarantee that the legacy code that has been written in C still runs > >> > >> Nothing else. > >> > > > > Then how in the *hell* do they explain adding the damned threading library > > and changing the language of the standard to accomodate it? That was a > > *major* enhancement for just supporting legacy code. > > > > I mean, I can understand the sentiment of not using C for new, mission- > > critical systems. The cyberattacks of the last couple of decades have > > pretty much proven that it is *hard*, if not impossible, to deploy > > secure C code. And to pre-empt the inevitable "it's not the language, > > it's the programmers" response - if the human is the *strong* link in your > > chain, then you are well and truly screwed. Yes, the problem is the > > language, not the people writing it. > > > > But by that same token, if they're going to add a goddamned threading > > library to the language (that I *don't* remember a great hue and cry for), > > then they must expect C to be used for new development going forward. > > > > Is it just that they don't want to deal with generics? > > > > It's no harder to deploy secure C code than it is in any other language. > Security is not an attribute of the language; it is the competence of > the programmer. Mission critic code is done in C. When C++ is allowed, generally is has so many restrictions that it looks like C with classes (constructor/destructor). http://sdtimes.com/nasas-10-rules-developing-safety-critical-code/ "The rules were specifically written with the C language in mind (a language NASA recommended for safety-critical code due to its long history and extensive tool support), though the rules can be generalized for coding in any programming language. http://www.programmingresearch.com/coding-standards/misra/
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-11-09 08:01 -0500 |
| Message-ID | <nvv6mu$3fn$2@jstuckle.eternal-september.org> |
| In reply to | #96180 |
On 11/9/2016 6:23 AM, Thiago Adams wrote: > On Tuesday, November 8, 2016 at 11:05:04 PM UTC-2, Jerry Stuckle wrote: >> On 11/8/2016 5:57 PM, John Bode wrote: >>> On Tuesday, November 8, 2016 at 4:26:32 PM UTC-6, jacobnavia wrote: >>>> Le 08/11/2016 à 23:15, Chris M. Thomasson a écrit : >>>>> Holy shi%! So, when I write C, the C committee might think I am crazy!? >>>> >>>> Their opinion is more "subtle" than that. >>>> >>>> C should not be used for new developments and the task of the committee >>>> is to guarantee that the legacy code that has been written in C still runs >>>> >>>> Nothing else. >>>> >>> >>> Then how in the *hell* do they explain adding the damned threading library >>> and changing the language of the standard to accomodate it? That was a >>> *major* enhancement for just supporting legacy code. >>> >>> I mean, I can understand the sentiment of not using C for new, mission- >>> critical systems. The cyberattacks of the last couple of decades have >>> pretty much proven that it is *hard*, if not impossible, to deploy >>> secure C code. And to pre-empt the inevitable "it's not the language, >>> it's the programmers" response - if the human is the *strong* link in your >>> chain, then you are well and truly screwed. Yes, the problem is the >>> language, not the people writing it. >>> >>> But by that same token, if they're going to add a goddamned threading >>> library to the language (that I *don't* remember a great hue and cry for), >>> then they must expect C to be used for new development going forward. >>> >>> Is it just that they don't want to deal with generics? >>> >> >> It's no harder to deploy secure C code than it is in any other language. >> Security is not an attribute of the language; it is the competence of >> the programmer. > > Mission critic code is done in C. > When C++ is allowed, generally is has so many restrictions that it looks like C with classes (constructor/destructor). > > Mission critical code is done in other languages, also. > > > http://sdtimes.com/nasas-10-rules-developing-safety-critical-code/ > > "The rules were specifically written with the C language in mind (a language NASA recommended for safety-critical code due to its long history and extensive tool support), though the rules can be generalized for coding in any programming language. > Yes, these are rules for writing critical code in C. It does not mean C is the only language being used. > > http://www.programmingresearch.com/coding-standards/misra/ > Much of which a several great C programmers I know disagree with. Including ones who work on mission critical systems. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-11-09 12:27 -0800 |
| Message-ID | <db05cb5c-0262-45cb-8373-5f281927db78@googlegroups.com> |
| In reply to | #96170 |
On Tuesday, November 8, 2016 at 7:05:04 PM UTC-6, Jerry Stuckle wrote: > On 11/8/2016 5:57 PM, John Bode wrote: > > On Tuesday, November 8, 2016 at 4:26:32 PM UTC-6, jacobnavia wrote: > >> Le 08/11/2016 à 23:15, Chris M. Thomasson a écrit : > >>> Holy shi%! So, when I write C, the C committee might think I am crazy!? > >> > >> Their opinion is more "subtle" than that. > >> > >> C should not be used for new developments and the task of the committee > >> is to guarantee that the legacy code that has been written in C still runs > >> > >> Nothing else. > >> > > > > Then how in the *hell* do they explain adding the damned threading library > > and changing the language of the standard to accomodate it? That was a > > *major* enhancement for just supporting legacy code. > > > > I mean, I can understand the sentiment of not using C for new, mission- > > critical systems. The cyberattacks of the last couple of decades have > > pretty much proven that it is *hard*, if not impossible, to deploy > > secure C code. And to pre-empt the inevitable "it's not the language, > > it's the programmers" response - if the human is the *strong* link in your > > chain, then you are well and truly screwed. Yes, the problem is the > > language, not the people writing it. > > > > But by that same token, if they're going to add a goddamned threading > > library to the language (that I *don't* remember a great hue and cry for), > > then they must expect C to be used for new development going forward. > > > > Is it just that they don't want to deal with generics? > > > > It's no harder to deploy secure C code than it is in any other language. > Security is not an attribute of the language; it is the competence of > the programmer. > To repeat myself - if the human is the strong link in the chain, you are screwed. Even expert programmers make mistakes. And as far as competence goes, C programmers (and programmers in general) fall on the bell curve just like everyone else. Most are average, a few are excellent, a few...should be doing something else for a living. You have to account for the average case. > I know a lot of good programmers who write secure C code. I also know a > lot of programmers who write insecure code - in C as well as other > languages. > > Competent programmers can write secure code in *any* language they are > proficient in. Incompetent programmers can't write secure code in any > language. But they blame the language for their failings. > My point is that it's easier, by a long shot, to write insecure code in C than most other languages.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-09 22:32 +0100 |
| Message-ID | <o004kp$uq9$1@dont-email.me> |
| In reply to | #96220 |
Le 09/11/2016 à 21:27, John Bode a écrit : > > My point is that it's easier, by a long shot, to write insecure code in C > than most other languages. > Of course you are right. It is easier to write insecure code in C because it is easier to write things in C. !!! With reasonable libraries, that take out the accounting out of the equation, robust C code is not very difficult to write. But when I propose precisely that, there is no answer. C is no longer being developed, neither by the committee, nor by the computer media, nor by anyone. So everyone is happy. The nagging facts remain however: Do we need really the huge complications of C++? C++ has become so complicated that it is unreadable unless you have the compiler to parse it. What is being called here? Who knows? There are so many complex files around and so many confusing and contradicting rules that it is an impossible task for an unaided human brain to follow C++. In face of such problems I think simpler solutions are possible and even better than C++: The C language. Let's simplify.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-10 06:43 +0000 |
| Message-ID | <87d1i3zvfw.fsf@gmail.com> |
| In reply to | #96232 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > C++ has become so complicated that it is unreadable unless you have > the compiler to parse it. What is being called here? Who knows? You keep repeating this as if it were ae fact. If your C++ is notably less clear than your C, it is because you are a bad C++ programmer, not because C++ is a bad language. One can certainly write incomprehensible code in C++. But have you seen Duff's Device? How about the RCU or filesystem layer code in the linux kernel? Does the simplicity of C make that easy for the human brain to understand? > There are so many complex files around and so many confusing and > contradicting rules that it is an impossible task for an unaided human > brain to follow C++. My experience differs.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-11-10 20:30 +1300 |
| Message-ID | <e8im10Fl834U1@mid.individual.net> |
| In reply to | #96232 |
On 11/10/16 10:32 AM, jacobnavia wrote: > > In face of such problems I think simpler solutions are possible and even > better than C++: > > The C language. Let's simplify. Once C can do RAII, I might agree :) -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-10 07:35 +0000 |
| Message-ID | <877f8bss69.fsf@gmail.com> |
| In reply to | #96264 |
Ian Collins <ian-news@hotmail.com> writes: > On 11/10/16 10:32 AM, jacobnavia wrote: >> >> In face of such problems I think simpler solutions are possible and even >> better than C++: >> >> The C language. Let's simplify. > > Once C can do RAII, I might agree :) So might I, and in any other week that would be considered a terrible omen of the apocalypse.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-11-10 03:12 -0800 |
| Message-ID | <12dd74d6-7d87-4603-8bdd-677f07395e81@googlegroups.com> |
| In reply to | #96264 |
On Thursday, November 10, 2016 at 5:30:49 AM UTC-2, Ian Collins wrote: > On 11/10/16 10:32 AM, jacobnavia wrote: > > > > In face of such problems I think simpler solutions are possible and even > > better than C++: > > > > The C language. Let's simplify. > > Once C can do RAII, I might agree :) > > -- > Ian Why not think and implement something about that in C?
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2016-11-10 11:19 +0000 |
| Message-ID | <o01l4m$20c$8@news.albasani.net> |
| In reply to | #96286 |
On 2016-11-10, Thiago Adams <thiago.adams@gmail.com> wrote: > On Thursday, November 10, 2016 at 5:30:49 AM UTC-2, Ian Collins wrote: >> On 11/10/16 10:32 AM, jacobnavia wrote: >> > >> > In face of such problems I think simpler solutions are possible and even >> > better than C++: >> > >> > The C language. Let's simplify. >> >> Once C can do RAII, I might agree :) >> >> -- >> Ian > > Why not think and implement something about that in C? > > > RAII is pointless without destructor functions. Implementing automatic call to destructors requires code generation and of course you have to somehow bind parameters. Golang solved that by using `defer` keyword and call to function syntax. -- press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-11-10 03:46 -0800 |
| Message-ID | <715e9766-7ea8-46f3-9671-54919ef91df2@googlegroups.com> |
| In reply to | #96288 |
On Thursday, November 10, 2016 at 9:19:56 AM UTC-2, Melzzzzz wrote:
> On 2016-11-10, Thiago Adams wrote:
> > On Thursday, November 10, 2016 at 5:30:49 AM UTC-2, Ian Collins wrote:
> >> On 11/10/16 10:32 AM, jacobnavia wrote:
> >> >
> >> > In face of such problems I think simpler solutions are possible and even
> >> > better than C++:
> >> >
> >> > The C language. Let's simplify.
> >>
> >> Once C can do RAII, I might agree :)
> >>
> >> --
> >> Ian
> >
> > Why not think and implement something about that in C?
> >
> >
> >
> RAII is pointless without destructor functions.
There are many options to add the destructor information to C.
These options need to be analyzed and tested.
My thoughts:
I think an general concept could be added that is "type members"
I think the only type information currently available in C is sizeof.
sizeof is a kind of template function in C, because you can give the typename and it returns it's size.
So, the size is something associated with the type.
I think we could generalize this concept, in a way I could add my own information and some other standard ones.
The one standard could be destructors.
How this could possible works?
struct X
{
int X; // <-- this is part of instance of type X
//this is user custom information added to the type X
//you can ask for this. (this is not added to the instance of X)
inline int type = X_ID;
//Nowadays, you can do this job with macros.IDOF(X)
//This is the default destructor for type X
inline ~ = X_Destroy;
}
int main()
{
struct X x;
} //if the default destructor of struct X is present then it will be called.
int main()
{
typedef char * String {inline ~ = free; };
String p = malloc(..);
} //free called
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-11-10 04:01 -0800 |
| Message-ID | <759263b4-f760-4fc1-b6c6-1ace91370529@googlegroups.com> |
| In reply to | #96291 |
On Thursday, November 10, 2016 at 9:46:49 AM UTC-2, Thiago Adams wrote:
> On Thursday, November 10, 2016 at 9:19:56 AM UTC-2, Melzzzzz wrote:
> > On 2016-11-10, Thiago Adams wrote:
> > > On Thursday, November 10, 2016 at 5:30:49 AM UTC-2, Ian Collins wrote:
> > >> On 11/10/16 10:32 AM, jacobnavia wrote:
> > >> >
> > >> > In face of such problems I think simpler solutions are possible and even
> > >> > better than C++:
> > >> >
> > >> > The C language. Let's simplify.
> > >>
> > >> Once C can do RAII, I might agree :)
> > >>
> > >> --
> > >> Ian
> > >
> > > Why not think and implement something about that in C?
> > >
> > >
> > >
> > RAII is pointless without destructor functions.
> There are many options to add the destructor information to C.
> These options need to be analyzed and tested.
>
> My thoughts:
>
> I think an general concept could be added that is "type members"
>
> I think the only type information currently available in C is sizeof.
> sizeof is a kind of template function in C, because you can give the typename and it returns it's size.
>
> So, the size is something associated with the type.
>
> I think we could generalize this concept, in a way I could add my own information and some other standard ones.
>
> The one standard could be destructors.
>
> How this could possible works?
I think the other topic (Experimental languages/features for C or similar would be better)?
More samples:
typedef char *
{
inline ~ = void String_Destroy(String*);
} String = NULL;
This typedef defines the type String.
The information about the "destructor" function was added to the String type. Note that his information will NOT be part of the size of String.
The destruct was added with declaration.
Also, the initial value was given. (default constructor)
typedef struct
{
int a = 1;
int b = 2;
inline ~ = void X_Destroy(X*);
} X;
This is for structs/unions. The default value is given inside for a and b.
typedef enum {
A = 1,
B = 2
} E = {A};
int main()
{
String s;
E e;
}
Exceptions are not required because the default constructor does only static initialization.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2016-11-11 16:04 +0000 |
| Message-ID | <o04q6s$luq$1@news.albasani.net> |
| In reply to | #96291 |
On 2016-11-10, Thiago Adams <thiago.adams@gmail.com> wrote:
> On Thursday, November 10, 2016 at 9:19:56 AM UTC-2, Melzzzzz wrote:
>> On 2016-11-10, Thiago Adams wrote:
>> > On Thursday, November 10, 2016 at 5:30:49 AM UTC-2, Ian Collins wrote:
>> >> On 11/10/16 10:32 AM, jacobnavia wrote:
>> >> >
>> >> > In face of such problems I think simpler solutions are possible and even
>> >> > better than C++:
>> >> >
>> >> > The C language. Let's simplify.
>> >>
>> >> Once C can do RAII, I might agree :)
>> >>
>> >> --
>> >> Ian
>> >
>> > Why not think and implement something about that in C?
>> >
>> >
>> >
>> RAII is pointless without destructor functions.
> There are many options to add the destructor information to C.
> These options need to be analyzed and tested.
>
> My thoughts:
>
> I think an general concept could be added that is "type members"
>
> I think the only type information currently available in C is sizeof.
> sizeof is a kind of template function in C, because you can give the
> typename and it returns it's size.
>
> So, the size is something associated with the type.
>
> I think we could generalize this concept, in a way I could add my own
> information and some other standard ones.
>
> The one standard could be destructors.
>
> How this could possible works?
>
> struct X
> {
> int X; // <-- this is part of instance of type X
>
>
> //this is user custom information added to the type X
> //you can ask for this. (this is not added to the instance of X)
>
> inline int type = X_ID;
> //Nowadays, you can do this job with macros.IDOF(X)
>
> //This is the default destructor for type X
> inline ~ = X_Destroy;
> }
>
> int main()
> {
> struct X x;
>
> } //if the default destructor of struct X is present then it will be called.
>
>
> int main()
> {
> typedef char * String {inline ~ = free; };
> String p = malloc(..);
>
> } //free called
>
>
>
Oh, I think that Golang approach is far simpler.
void time_me(time_t start) {
printf("elapsed %d\n",(int)(time(NULL)-start));
}
int main(int argc,char*argv[]) {
char* p = malloc(32);
defer free(p); // called at and of scope
defer time_me(time(NULL));
if (argc>1){
sleep(10);
return 1; // both free(p) and time_me called
}
else {
sleep(1);
return 2; // both free(p) and time_me called
}
}
--
press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-11-11 08:36 -0800 |
| Message-ID | <499f082f-fa8d-450d-a11b-14340070ff24@googlegroups.com> |
| In reply to | #96384 |
On Friday, November 11, 2016 at 2:04:51 PM UTC-2, Melzzzzz wrote:
> On 2016-11-10, Thiago Adams wrote:
> > On Thursday, November 10, 2016 at 9:19:56 AM UTC-2, Melzzzzz wrote:
> >> On 2016-11-10, Thiago Adams wrote:
> >> > On Thursday, November 10, 2016 at 5:30:49 AM UTC-2, Ian Collins wrote:
> >> >> On 11/10/16 10:32 AM, jacobnavia wrote:
> >> >> >
> >> >> > In face of such problems I think simpler solutions are possible and even
> >> >> > better than C++:
> >> >> >
> >> >> > The C language. Let's simplify.
> >> >>
> >> >> Once C can do RAII, I might agree :)
> >> >>
> >> >> --
> >> >> Ian
> >> >
> >> > Why not think and implement something about that in C?
> >> >
> >> >
> >> >
> >> RAII is pointless without destructor functions.
> > There are many options to add the destructor information to C.
> > These options need to be analyzed and tested.
> >
> > My thoughts:
> >
> > I think an general concept could be added that is "type members"
> >
> > I think the only type information currently available in C is sizeof.
> > sizeof is a kind of template function in C, because you can give the
> > typename and it returns it's size.
> >
> > So, the size is something associated with the type.
> >
> > I think we could generalize this concept, in a way I could add my own
> > information and some other standard ones.
> >
> > The one standard could be destructors.
> >
> > How this could possible works?
> >
> > struct X
> > {
> > int X; // <-- this is part of instance of type X
> >
> >
> > //this is user custom information added to the type X
> > //you can ask for this. (this is not added to the instance of X)
> >
> > inline int type = X_ID;
> > //Nowadays, you can do this job with macros.IDOF(X)
> >
> > //This is the default destructor for type X
> > inline ~ = X_Destroy;
> > }
> >
> > int main()
> > {
> > struct X x;
> >
> > } //if the default destructor of struct X is present then it will be called.
> >
> >
> > int main()
> > {
> > typedef char * String {inline ~ = free; };
> > String p = malloc(..);
> >
> > } //free called
> >
> >
> >
> Oh, I think that Golang approach is far simpler.
> void time_me(time_t start) {
> printf("elapsed %d\n",(int)(time(NULL)-start));
> }
> int main(int argc,char*argv[]) {
> char* p = malloc(32);
> defer free(p); // called at and of scope
> defer time_me(time(NULL));
> if (argc>1){
> sleep(10);
> return 1; // both free(p) and time_me called
> }
> else {
> sleep(1);
> return 2; // both free(p) and time_me called
> }
> }
>
It's an different approach.
The defer is not something related with the type, but with the code. I think defer is useful also.
The information associated with the type can be useful in other situations.
struct X
{
inline ~= X_Destroy; //Destructor for X
inline ~*= X_Delete; //Destructor for X*
};
struct Y
{
X x;
own X* p;
};
int main()
{
Y y;
} //X_Destroy(&y.x) and X_Delete(&y.p) are called
Well, I agree with someone thinking at this moment "but this is C++!"
Almost..
What else whe could do?
* Destructor for simple types (char *)
* Destructor for pointers ;
* Destructor is a type modifier that you can change at declaration (like const). You can enable /disable . For instance with own etc
* Object lifetime check
How to organize these things are not clear.
But the target would be the static checked resource management, and auto end-lifetime by scope.
int F(X * p)
{
//normal X*
} //X_Delete not called.
int main()
{
own X * p = X_Create();
} //X_Delete called
"own" can enable the X* Delete;
[toc] | [prev] | [next] | [standalone]
Page 14 of 15 — ← Prev page 1 … 12 13 [14] 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web