Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #29282 > unrolled thread
| Started by | Jason Damisch <jasondamisch@yahoo.com> |
|---|---|
| First post | 2014-04-04 10:26 -0700 |
| Last post | 2014-04-29 22:52 -0700 |
| Articles | 20 on this page of 374 — 32 participants |
Back to article view | Back to comp.lang.forth
Epic Fail Jason Damisch <jasondamisch@yahoo.com> - 2014-04-04 10:26 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-04 12:42 -0500
Re: Epic Fail forthisit@gmail.com - 2014-04-04 11:09 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-04 22:09 +0100
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-04 21:44 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 09:42 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 10:47 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-05 15:25 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 17:29 +0000
Re: Epic Fail Assad Ebrahim <assadebrahim2000@gmail.com> - 2014-04-07 12:35 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-08 15:54 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-08 12:43 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-09 16:16 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-09 13:00 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-09 21:08 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-09 15:17 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 00:17 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-09 22:42 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-10 00:06 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-10 16:00 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 22:35 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-10 17:51 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-10 21:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-11 23:10 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 06:18 -0400
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 06:23 -0400
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-12 10:52 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-12 20:14 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 19:21 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-13 12:25 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-13 20:33 -0400
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 16:12 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-12 09:48 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-12 10:23 -0700
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 19:51 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-12 13:00 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-12 10:29 -0700
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 19:56 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 00:25 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-13 10:50 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 16:53 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-14 02:32 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 17:59 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-14 02:00 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 18:30 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-13 14:21 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 21:12 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-23 12:49 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-28 21:02 -0700
Automatic scoping of locals (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 14:49 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 03:04 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-11 17:23 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 21:42 +0200
Re: Epic Fail Spam@ControlQ.com - 2014-04-11 16:13 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 22:15 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-13 16:10 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-13 18:42 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-13 23:44 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-13 20:33 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-14 04:05 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-14 09:57 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-14 11:56 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-14 14:53 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 07:26 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-14 21:21 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-15 04:07 -0500
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-14 09:55 -0700
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-14 22:04 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-15 04:10 -0400
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 02:40 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-15 06:41 -0400
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 06:20 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-15 12:21 +0000
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 06:30 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-15 20:04 -0700
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 23:50 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-15 21:31 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 05:55 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-16 14:50 +0100
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-16 06:06 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-19 17:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-20 11:35 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 00:19 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 05:29 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-16 22:45 -0400
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-14 09:49 +0000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-23 13:07 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-23 20:16 -0400
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-23 14:41 -1000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-24 17:10 +0000
Re: Epic Fail Spam@ControlQ.com - 2014-04-24 15:14 -0400
@ and optimization (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 08:40 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-25 06:13 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 15:26 +0000
Re: @ and optimization Paul Rubin <no.email@nospam.invalid> - 2014-04-25 09:03 -0700
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 17:45 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-25 11:15 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 17:22 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 04:38 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 11:38 +0000
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 14:35 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 09:59 -0500
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:14 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 15:30 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:05 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:27 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:39 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 18:07 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:24 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 13:00 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 11:18 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-28 15:12 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 03:52 -0500
Re: @ and optimization Mark Wills <markwills1970@gmail.com> - 2014-04-29 03:09 -0700
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 09:24 -0500
Re: @ and optimization "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 08:36 -1000
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 14:38 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 10:21 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 15:41 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 12:26 -0500
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 20:17 +0200
Re: @ and optimization stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-29 19:21 +0000
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 23:20 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-30 03:02 -0500
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 20:55 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:28 -0500
Re: @ and optimization albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-27 13:31 +0000
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-28 15:27 +0000
Re: @ and optimization albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-27 13:23 +0000
Re: @ and optimization hughaguilar96@yahoo.com - 2014-04-28 21:32 -0700
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 08:50 -0400
Re: @ and optimization "Alex McDonald" <blog@rivadpm.com> - 2014-04-26 22:52 +0100
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 20:33 -0400
Re: @ and optimization "Alex McDonald" <blog@rivadpm.com> - 2014-04-27 11:53 +0100
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 01:05 -0400
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-25 21:34 +0100
Re: @ and optimization Paul Rubin <no.email@nospam.invalid> - 2014-04-25 13:37 -0700
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-25 22:03 +0100
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 15:38 +0000
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:24 +0100
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 04:48 -0500
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 11:09 +0100
Re: @ and optimization (was: Epic Fail) hughaguilar96@yahoo.com - 2014-04-28 21:24 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-24 19:17 +0000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 08:27 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-25 23:44 +0200
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-26 14:37 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 15:04 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 09:58 +0100
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 10:16 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 05:06 -0500
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 11:16 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-26 03:43 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 14:24 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 23:58 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 12:46 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 00:41 -0400
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-28 21:54 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:17 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:08 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 13:44 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 09:11 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:12 -0500
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:00 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:08 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 23:41 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:06 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:45 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:52 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 21:52 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:31 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-27 13:48 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 12:02 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 22:19 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 10:28 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-14 22:02 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 18:57 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-15 05:05 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 22:53 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-13 12:34 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-14 13:22 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-14 10:08 -0500
Re: Epic Fail Spam@ControlQ.com - 2014-04-14 11:59 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-17 16:56 +0000
Re: Epic Fail Spam@ControlQ.com - 2014-04-17 15:16 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-17 23:59 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-18 04:38 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-18 09:17 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 11:44 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-18 17:06 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 11:41 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-18 16:55 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-18 19:20 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 14:52 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 12:21 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 14:36 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-20 08:17 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 11:35 -0500
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-21 10:51 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-21 19:54 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-22 17:40 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-22 20:47 +0200
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-19 11:34 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-19 16:05 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 12:38 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 11:42 -0500
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 12:11 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-20 17:23 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-20 11:58 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-21 10:21 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 04:58 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-22 17:05 +0000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-20 17:12 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-20 19:47 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 05:03 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-22 11:51 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 08:28 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-22 15:02 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 13:23 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-22 19:19 +0200
Re: Epic Fail Todd Hughes <noemail@dontemailme.org> - 2014-04-10 11:24 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 06:55 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-10 15:50 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 11:02 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 22:31 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-11 03:55 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-10 19:08 -0400
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-10 19:03 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 17:45 +0100
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-11 17:16 +0000
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 18:59 +0100
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 19:11 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-11 12:05 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-11 22:03 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 20:18 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-11 21:44 -0400
Re: Epic Fail visualforth@rocketmail.com - 2014-04-11 14:00 -0700
Re: Epic Fail Matthias Trute <matthias.trute@gmail.com> - 2014-04-12 01:04 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-09 16:12 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-04 23:20 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 17:40 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 00:52 +0200
Re: Epic Fail Assad Ebrahim <assadebrahim2000@gmail.com> - 2014-04-07 16:13 -0700
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-08 06:37 +0300
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-09 01:12 +0200
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-08 10:16 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-04 17:41 -0400
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-05 02:49 +0200
Re: Epic Fail Hannu Vuolasaho <vuokkosetae@gmail.com> - 2014-04-04 17:46 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-04 21:59 -1000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-05 08:51 +0000
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-05 14:45 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-05 16:01 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 19:22 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-06 10:46 +0100
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-06 13:20 +0200
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-06 19:58 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 12:28 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-06 16:40 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-06 22:04 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-06 23:25 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-06 23:48 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:17 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:08 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:34 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:29 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:01 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:58 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:29 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 01:33 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 01:58 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 19:33 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 04:40 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 04:25 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 20:19 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 11:23 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 03:24 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 11:18 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 05:20 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 14:49 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 08:43 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 20:27 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 02:57 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 10:00 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 16:10 +0200
Re: Epic Fail m.a.m.hendrix@tue.nl - 2014-04-07 07:54 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:59 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 15:07 -0700
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 15:13 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 00:40 +0200
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-07 01:02 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 10:49 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 19:01 +0100
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-08 08:13 -1000
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-08 20:34 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 12:04 -0700
[OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 00:42 +0200
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:14 -0700
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:15 -0700
Re: [OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:10 +0200
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:35 -0700
Re: [OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:17 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-06 16:48 -0500
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:30 -0700
Re: Epic Fail Lars Brinkhoff <lars.spam@nocrew.org> - 2014-04-07 11:26 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 05:21 -0500
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-07 17:54 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 12:14 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 16:49 +0000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 09:37 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 08:43 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 12:53 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-06 00:09 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-06 13:12 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-06 07:55 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 10:18 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 08:21 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 08:30 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-06 22:12 +0200
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-06 12:08 -1000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 22:03 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-07 01:29 -0700
locals in nested definitions (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 16:57 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-07 11:48 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:54 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 00:04 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 14:12 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 21:23 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-07 19:33 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-07 23:52 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-08 09:07 +0100
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 12:35 +0100
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-08 16:21 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-08 16:33 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 23:41 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 22:47 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-08 10:43 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 07:22 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-08 10:12 -0500
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 08:58 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-08 08:02 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 23:07 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-08 10:21 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 15:32 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-08 17:46 -0400
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 01:06 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:06 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 02:56 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:17 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:24 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-09 02:22 -0400
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-09 17:07 +0300
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-09 03:48 -0700
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-07 07:17 +0300
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:52 +0200
Re: Epic Fail Mark Wills <markwills1970@gmail.com> - 2014-04-07 03:53 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-08 16:24 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-08 16:45 -0700
Re: Epic Fail kerdezixe@gmail.com - 2014-04-29 11:15 -0700
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 11:21 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 20:46 +0200
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 12:27 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 23:13 +0200
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-30 00:04 -0700
Re: Epic Fail Mark Wills <markwills1970@gmail.com> - 2014-04-30 00:54 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-30 03:08 -0500
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-30 02:30 -0700
Re: Epic Fail AKK <akk@nospam.org> - 2014-04-29 20:48 +0200
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-29 19:09 +0000
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 09:23 -1000
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 12:43 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 11:23 -1000
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 22:52 -0700
Page 12 of 19 — ← Prev page 1 … 10 11 [12] 13 14 … 19 Next page →
| From | Todd Hughes <noemail@dontemailme.org> |
|---|---|
| Date | 2014-04-10 11:24 +0000 |
| Message-ID | <li5v1u$3ed$1@speranza.aioe.org> |
| In reply to | #29498 |
It's remarkable that most posters in c.l.f seem to understand what most posters in c.l.c don't: C is more of a worldview and possibly a VM than it is a language. It is no longer helpful to understand the hardware if you want to use C. Actually, it's probably harmful. C has its own abstract view of the hardware and to use C you have to share that view, and of course be aware of all the broken beer bottles, banana peels and oil slicks left on the road by C. Especially gcc. Forget whatever else you know and put aside any expectations you may have. You will be ASSimilated. I have never understood the reason why people who are so insistent on compiling only conforming code and work so hard at miscompiling non-conforming code scream at the idea that lint should be built into every C compiler. Empirically we see we can't have it both ways. The only safe and reasonable default is warning about anything that isn't conforming. It's not safe to miscompile something and say nothing about it. We shouldn't have to specify 180 characters of warning options to get gcc to tell us what it knows. Just say it. The only remotely portable assembler is gas... Todd
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-10 06:55 -0500 |
| Message-ID | <wPydnRZ83aUKG9vOnZ2dnUVZ_qadnZ2d@supernews.com> |
| In reply to | #29506 |
Todd Hughes <noemail@dontemailme.org> wrote: > The only safe and reasonable default is warning about anything that > isn't conforming. It's not safe to miscompile something and say > nothing about it. There is no general way to know at compile time if a program is conforming or not. The best you can do is warn about problems that you see, and many compilers do so. Also, many warnings have a significant false positive rate, and IMHO no warning that generates false positives should be on by default. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-10 15:50 +0000 |
| Message-ID | <5346bdd1$0$25039$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #29507 |
In article <wPydnRZ83aUKG9vOnZ2dnUVZ_qadnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Todd Hughes <noemail@dontemailme.org> wrote: > >> The only safe and reasonable default is warning about anything that >> isn't conforming. It's not safe to miscompile something and say >> nothing about it. > >There is no general way to know at compile time if a program is >conforming or not. The best you can do is warn about problems that >you see, and many compilers do so. Also, many warnings have a >significant false positive rate, and IMHO no warning that generates >false positives should be on by default. On the contrary. Deciding whether a program conforms to a language specification is the only thing a compiler can do. E.g. a Pascal program can factorize infinite precision numbers. How much precision a number can have doesn't belong to the Pascal language specification and need not stick out anywhere in the Pascal program. A particular Pascal program has to give up on some integers, because they are too large. This has nothing to do with the program itself. Remember, the Pascal program can be valid or not without ever being compiled into a running program. Since 1980 it can handle more numbers, since Turbo Pascal is replaced by a 32 bit, then a 64 bit compiler. Comes C. They make a programmer aware that some numbers are 16 bits, and that you need double precision numbers to specify length for disk files. This kind of practicality makes C into a portable assembler. It also makes C a not-so-high level language. You're confused by the undecidability of whether a program ever stops, or ever divides by zero. The Pascal snippet x:=0 ; y := 1/x; is perfectly conforming, but will/should end in a run time error. Using Ulam sequence you can also construct more interesting examples where it is unsure, or even undecidable whether there will ever be an array out of bounds error. (Which translated into c-jargon is a "segmentation fault"). > >Andrew. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-10 11:02 -0500 |
| Message-ID | <ENKdnXp0wN0FXdvOnZ2dnUVZ_q-dnZ2d@supernews.com> |
| In reply to | #29509 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <wPydnRZ83aUKG9vOnZ2dnUVZ_qadnZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >>Todd Hughes <noemail@dontemailme.org> wrote: >> >>> The only safe and reasonable default is warning about anything that >>> isn't conforming. It's not safe to miscompile something and say >>> nothing about it. >> >>There is no general way to know at compile time if a program is >>conforming or not. The best you can do is warn about problems that >>you see, and many compilers do so. Also, many warnings have a >>significant false positive rate, and IMHO no warning that generates >>false positives should be on by default. > > On the contrary. > Deciding whether a program conforms to a language specification is the only > thing a compiler can do. Is this post supposed to mean anything? A compiler can determine if a program is syntactically correct, but that's a very different thing. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-10 22:31 +0200 |
| Message-ID | <li6v2l$hp3$1@online.de> |
| In reply to | #29507 |
Andrew Haley wrote: > Todd Hughes <noemail@dontemailme.org> wrote: > >> The only safe and reasonable default is warning about anything that >> isn't conforming. It's not safe to miscompile something and say >> nothing about it. > > There is no general way to know at compile time if a program is > conforming or not. In general, yes. However, with this particular if(n>n+1) stuff, the compiler maintainer decided that it is non-conforming, and after a while decided to drop the warning message for removing the code after the if. That were two unrelated decisions: the dead code warning was in GCC for ages, but it worked only with optimization, because without, the analysis for dead code wasn't even performed (fair enough - in this case, the code is there, and executes as expected, because it isn't dead). However, the GCC maintainers decided to remove this warning completely, because it is not "reliable", i.e. you need to turn optimization on to see it. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-11 03:55 -0500 |
| Message-ID | <39Cdnb_qnJGIM9rOnZ2dnUVZ_rOdnZ2d@supernews.com> |
| In reply to | #29512 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: > >> Todd Hughes <noemail@dontemailme.org> wrote: >> >>> The only safe and reasonable default is warning about anything that >>> isn't conforming. It's not safe to miscompile something and say >>> nothing about it. >> >> There is no general way to know at compile time if a program is >> conforming or not. > > In general, yes. However, with this particular if(n>n+1) stuff, the > compiler maintainer decided that it is non-conforming, and after a while > decided to drop the warning message for removing the code after the if. It worked for me today: t.cc:38:13: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Wstrict-overflow] if (n > n+1) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-10 19:08 -0400 |
| Message-ID | <op.xd4ikyyo6zenlw@localhost> |
| In reply to | #29507 |
On Thu, 10 Apr 2014 07:55:03 -0400, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > [...] IMHO no warning that generates false positives should > be on by default. Then, there would likely be no warnings at all. If the first warning is actually a problem, then you are have to fix it before proceeding, or it will create additional warnings and errors. You should never attempt to fix later warnings or errors until the prior ones are fixed, sequentially, from the start. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-10 19:03 -0400 |
| Message-ID | <op.xd4ibdjg6zenlw@localhost> |
| In reply to | #29506 |
On Thu, 10 Apr 2014 07:24:46 -0400, Todd Hughes <noemail@dontemailme.org> wrote: > It's remarkable that most posters in c.l.f seem to understand what most > posters in c.l.c don't: C is more of a worldview and possibly a VM than > it is a language. That's a strange perspective, but an acceptable one. > It is no longer helpful to understand the hardware if you want to use C. Did anyone ever need to understand the hardware to use C? ... > C has its own abstract view of the hardware and to use C you have to > share that view, [...] C works best on the microprocessor model of computing hardware. Memory is contiguous, bytes are 8-bits, all pointers have a single size, integers and pointers are an integer multiple of the size of a byte, two's complement arithmetic, etc. Of course, C was implemented on a variety of hardware that didn't conform to that model, e.g., 16-bit bytes but 9-bit characters, differently sized pointers, no ability to access small integers as needed for characters, etc. These "other", mostly obsolete, mainframe/corporate platforms like Crays, DECs, Burroughs, IBMs, etc is what creates all the "undefined" behavior for C. C is superb for microprocessors where the useful behaviors are usually implemented. > The only safe and reasonable default is warning about anything that isn't > conforming. Everything of value in C is non-conforming. C was standardized for multiple different computing platforms with different architectures. Only 30% of C's code is truly portable, in the sense that the code performs exactly the same way on all hardware. Another 30% or so appears to be portable, because the same result can be implemented on most hardware, albeit differently. The rest is simply not portable. It has to be adjusted for different platforms. While the C language is almost entirely independent of the host, the C libraries aren't. Minimal C libraries need about twenty host specific functions. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-11 17:45 +0100 |
| Message-ID | <li9678$u25$1@dont-email.me> |
| In reply to | #29514 |
on 11/04/2014 00:03:01, "Rod Pemberton" wrote: > > C works best on the microprocessor model of computing hardware. Proof please. > Memory is contiguous, bytes are 8-bits, all pointers have a single > size, integers and pointers are an integer multiple of the size of a > byte, two's complement arithmetic, etc. Of course, C was implemented > on a variety of hardware that didn't conform to that model, e.g., C started life on a system that didn't conform to your ideal model for C. > 16-bit bytes but 9-bit characters, differently sized pointers, no > ability to access small integers as needed for characters, etc. These > "other", mostly obsolete, > mainframe/corporate platforms like Crays, DECs, Burroughs, IBMs, etc > is what creates all the "undefined" behavior for C. As opposed to the undefined behaviour on 8bit byte, pointers single size, 2s complement etc? > C is superb for > microprocessors where the useful behaviors are usually implemented. The above is a "let's rewrite history" or (as we call it in my business) rubbish.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-11 17:16 +0000 |
| Message-ID | <2014Apr11.191612@mips.complang.tuwien.ac.at> |
| In reply to | #29526 |
"Alex McDonald" <blog@rivadpm.com> writes:
>on 11/04/2014 00:03:01, "Rod Pemberton" wrote:
>> Memory is contiguous, bytes are 8-bits, all pointers have a single
>> size, integers and pointers are an integer multiple of the size of a
>> byte, two's complement arithmetic, etc. Of course, C was implemented
>> on a variety of hardware that didn't conform to that model, e.g.,
>
>C started life on a system that didn't conform to your ideal model for C.
C started life on the PDP-11, and it has all the properties given
above.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-11 18:59 +0100 |
| Message-ID | <li9aho$vrd$1@dont-email.me> |
| In reply to | #29527 |
on 11/04/2014 18:16:07, wrote: > "Alex McDonald" <blog@rivadpm.com> writes: >>on 11/04/2014 00:03:01, "Rod Pemberton" wrote: >>> Memory is contiguous, bytes are 8-bits, all pointers have a single >>> size, integers and pointers are an integer multiple of the size of a >>> byte, two's complement arithmetic, etc. Of course, C was implemented >>> on a variety of hardware that didn't conform to that model, e.g., >> >>C started life on a system that didn't conform to your ideal model for C. > > C started life on the PDP-11, and it has all the properties given > above. > > - anton My bad, I spat out a reply in haste. The rest of my complaint stands, including the spurious claim that the list below "creates all the "undefined" behavior for C" Crays (supercomputer vector machines which were never programmed in C). DECs (included "Pemberton model" PDP-11, VAXen etc for which there were C compilers). Burroughs (large systems ran Algol-based languages that predated C, and there were no C compilers -- or assemblers). In other words, "undefined" C behavior has nothing to do with these platforms. Where there is a C compiler, they are "Pemberton model".
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-11 19:11 +0100 |
| Message-ID | <li9b8h$613$1@dont-email.me> |
| In reply to | #29531 |
on 11/04/2014 18:59:19, "Alex McDonald" wrote: > on 11/04/2014 18:16:07, wrote: >> "Alex McDonald" <blog@rivadpm.com> writes: >>>on 11/04/2014 00:03:01, "Rod Pemberton" wrote: >>>> Memory is contiguous, bytes are 8-bits, all pointers have a single >>>> size, integers and pointers are an integer multiple of the size of a >>>> byte, two's complement arithmetic, etc. Of course, C was implemented >>>> on a variety of hardware that didn't conform to that model, e.g., >>> >>>C started life on a system that didn't conform to your ideal model for C. >> >> C started life on the PDP-11, and it has all the properties given >> above. >> >> - anton > > My bad, I spat out a reply in haste. > > The rest of my complaint stands, including the spurious claim that the > list below "creates all the "undefined" behavior for C" > > Crays (supercomputer vector machines which were never programmed in > C). > > DECs (included "Pemberton model" PDP-11, VAXen etc for which there > were C compilers). > > Burroughs (large systems ran Algol-based languages that predated C, > and there were no C compilers -- or assemblers). > > In other words, "undefined" C behavior has nothing to do with these > platforms. Where there is a C compiler, they are "Pemberton model". > For some reason, the IBM mainframe entry got chopped. It is a "Pemberton model" and might be considered the poster child for how we got to where we are today; 8 bit byte, 32 bit (4 byte) address, contiguous memory, two's complement arithmetic and so on. These machines had early C compilers too.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-11 12:05 -0700 |
| Message-ID | <7xob07g00j.fsf@ruckus.brouhaha.com> |
| In reply to | #29531 |
"Alex McDonald" <blog@rivadpm.com> writes: > Crays (supercomputer vector machines which were never programmed in C). https://en.wikipedia.org/wiki/UNICOS
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-11 22:03 -0400 |
| Message-ID | <op.xd6lbvvy6zenlw@localhost> |
| In reply to | #29531 |
On Fri, 11 Apr 2014 13:59:19 -0400, Alex McDonald <blog@rivadpm.com> wrote:
> The rest of my complaint stands, including the spurious claim that the
> list below "creates all the "undefined" behavior for C"
No, it doesn't.
> Crays (supercomputer vector machines which were never programmed in C).
>
> DECs (included "Pemberton model" PDP-11, VAXen etc for which there were C
> compilers).
>
> Burroughs (large systems ran Algol-based languages that predated C, and
> there were no C compilers -- or assemblers).
>
> In other words, "undefined" C behavior has nothing to do with these
> platforms. Where there is a C compiler, they are "Pemberton model".
>
> [inserted]
> For some reason, the IBM mainframe entry got chopped. It is a "Pemberton
> model" and might be considered the poster child for how we got to where
> we are today; 8 bit byte, 32 bit (4 byte) address, contiguous memory,
> two's complement arithmetic and so on. These machines had early C
> compilers too.
You clearly don't know what you're talking about.
You previously stated things like ... There was no such language as PL/1.
Yet, that's exactly what Stratus names their early standard PL/I language
to differentiate it from IBM's PL/I.
There are two aspects of this:
1) the machines where C was implemented, and
2) the machine architecture.
This is going to get really long.
Part 1)
Let's start with the early machines where C was ported:
PDP-11 (DMR,J&R)
Honeywell 635 (DMR)
IBM 360/370 (DMR,J&R)
Interdata 8/32 (DMR,J&R)
DEC VAX 11/780 (DMR,J&R)
Honeywell 6000 (J&R)
SEL86 (J&R)
Data General Nova (J&R)
Eclipse (J&R)
Cray X-MP/24 (DM2)
AT&T 3B20S minicomputer (BHKRS)
AT&T 3B5 minicomputer (BHKRS)
UNIVAC 1100 series (BHKRS)
DMR - "The Development of the C Language", Dennis M. Ritchie
J&R - "Portability of C Programs and the UNIX System, S.C. Johnson & D.M.
Ritchie
DM2 - "Experience with Unicos on the Cray X-MP", Dennis Ritchie
BHKRS - "UNIX Operating System Porting Experiences", D.E. Bodenstab, T.F.
Houghton, K.A. Kelleman, G. Ronkin, E.P. Schan
As you can see, there are the Crays, DECs, IBMs, which I mentioned.
What did you say about Cray never having been programmed in C?
E.g., DM2 says:
"Cray's C compiler, which is an instance of Johnson's PCC [1]."
As for the Burroughs, it used linked activation records to create
a stack, did have ALGOL implemented, but some have issues with
creating pointers. This would be a difficult machine to put C
onto. Supposedly, Steve Bartels implemented a C compiler for
Burroughs. I don't know what generation of machine that's for
or when that was done. He apparently worked on 6800/7800 series
machines at least at one point in time. Supposedly, his Burroughs
C compiler added an extra word to all malloc'd memory causing a
NULL deference if accessed via a pointer scan. The Burroughs
machines and their linked activation records are also rumored
to be the reason that C doesn't explictly require a stack for
procedures. I don't have anything that is "authoritative."
Part 2)
Let's cover the machine architecture issues of C:
"The machines on which we first used BCPL and then B were
word-addressed, and these languages' single data type, the
`cell,' comfortably equated with the hardware machine word.
The advent of the PDP-11 exposed several inadequacies of B's
semantic model. First, its character-handling mechanisms,
inherited with few changes from BCPL, were clumsy: [...]"
-"The Development of the C Language", Dennis M. Ritchie
"A major problem will occur when the computer's natural word
size is not a multiple of its natural byte size."
-"C: A Reference Manual", Harbison and Steele, 3rd Ed., pg 153.
"Computers that were able to deal just with numbers evolved into
computers with byte-addressable memory, flat address spaces, and
pointers. This was a natural evolution reflecting the growing set
of problems that people were solving. C, reflecting the genius of
Dennis Ritchie, provided a minimal model of the computer that had
evolved over 30 years. C was not a quick hack. As computers evolved
to handle all kinds of problems, C, being the minimal model of such
a computer, became a very powerful language to solve all kinds of
problems in different domains very effectively. This is the secret
of C's portability: it is the best representation of an abstract
computer that we have. Of course, the abstraction is done over the
set of real computers, not some imaginary computational devices."
-"Al Stevens Interviews Alex Stepanov",
by Al Stevens, Dr. Dobb's Journal
- Alex Stepanov is the C++ STL creator
So, the C machine model will fail for a variety of reasons:
1) for a machine "word size not a multiple of byte size" (H&S)
2) for "integer of any kind" that is not "divisible evenly into bytes"
(J&R)
3) for a word size being an odd multiple of char size (J&R)
4) for a "word-addressed machine that lacks any natural
representation of a character pointer" (J&R)
5) when an object can't "be walked using a byte pointer derived from
any kind of pointer into the object." (DAG)
6) when an object isn't represented as required by the C model of
"[suitably] aligned byte arrays with additional properties
(such as value interpretation) impressed upon them by the
type system." (DAG)
7) when a char is less than 8-bits per byte (J&R)
8) when a short is less than 16-bits or a long is less than 32-bits (J&R)
The C model fails in part on numerous early machines:
1) Cray's (H&S) (early were 16-bit word aligned)
2) unnamed 36-bit word, 7-bit char (e.g., IBM-705, PDP-10) (H&S)
3) PDP-11 due to 16-bit word alignment (R)
4) PDP-10 36-bit word using 7-bit char instead of 9-bit char (J&R)
Sources:
H&S "C: A Reference Manual", Harbison and Steele, 3rd, 1991
J&R "Portability of C Programs and the UNIX System" Johnson, Ritchie,
1978
DAG various usenet posts by Douglas A. Gwyn
R "C Reference Manual" Dennis Ritchie, 1975
It appears that the PDP-7 would fail due to architecture too, since
it has a 16-bit word and 6-bit char. Also, C requires 8-bits or more
for a char. Albeit, that's an arbitrary constraint.
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-11 20:18 +0200 |
| Message-ID | <li9bll$6ah$1@online.de> |
| In reply to | #29527 |
Anton Ertl wrote: > "Alex McDonald" <blog@rivadpm.com> writes: >>on 11/04/2014 00:03:01, "Rod Pemberton" wrote: >>> Memory is contiguous, bytes are 8-bits, all pointers have a single >>> size, integers and pointers are an integer multiple of the size of a >>> byte, two's complement arithmetic, etc. Of course, C was implemented >>> on a variety of hardware that didn't conform to that model, e.g., >> >>C started life on a system that didn't conform to your ideal model for C. > > C started life on the PDP-11, and it has all the properties given > above. There were also "IBMs" mentioned, but *the* architecture which made 8-bit- bytes and characters, power-of-two bytes integers, single, non-segmented address space, two's complement, and so on popular, was the IBM /360. The only two things that didn't last were EBCDIC, and big endian (today, little endian is way more often used). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-11 21:44 -0400 |
| Message-ID | <op.xd6kgcct6zenlw@localhost> |
| In reply to | #29526 |
On Fri, 11 Apr 2014 12:45:26 -0400, Alex McDonald <blog@rivadpm.com> wrote: > on 11/04/2014 00:03:01, "Rod Pemberton" wrote: >> C works best on the microprocessor model of computing hardware. > > Proof please. > History. >> Memory is contiguous, bytes are 8-bits, all pointers have a single >> size, integers and pointers are an integer multiple of the size of a >> byte, two's complement arithmetic, etc. Of course, C was implemented >> on a variety of hardware that didn't conform to that model, e.g., > > C started life on a system that didn't conform to your ideal model for C. > True. It also failed to work on most other platforms until it was heavily reworked to fit them. You can read Johnson's, Kernighan's, and Ritchie's early papers yourself where they describe the problems they ran into. >> 16-bit bytes but 9-bit characters, differently sized pointers, no >> ability to access small integers as needed for characters, etc. These >> "other", mostly obsolete, mainframe/corporate platforms like Crays, >> DECs, Burroughs, IBMs, etc is what creates all the "undefined" >> behavior for C. > > As opposed to the undefined behaviour on 8bit byte, pointers single size, > 2s complement etc? > Is this a blatant failure to read? "These 'other', mostly obsolete, mainframe/corporate platforms like Crays, DECs, Burroughs, IBMs, etc is what creates all the 'undefined' behavior for C." and I said, "Of course, C was implemented on a variety of hardware that didn't conform to that model, [...]" Let me explain that since you didn't comprehend. If only the microprocessor model was used, there wouldn't be undefined behavior in C. I.e., the need for compatibility with multiple architectures are what created undefined behavior. I should additionally clarify that for you. I'm referring to microprocessors 1974 or later which standardized on such a model. It took a few years for such a model to become standard. And, I never said some of those characteristics weren't present in mainframes. They are. Most mainframes didn't have all of those features though, but a couple did. You can look at the Wikpedia computer word page to see them: http://en.wikipedia.org/wiki/Word_(computer_architecture) >> C is superb for microprocessors where the useful behaviors are usually >> implemented. > > The above is a "let's rewrite history" or (as we call it in my business) > rubbish. > The above is accurate. Your comments are ignorant. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2014-04-11 14:00 -0700 |
| Message-ID | <f2c167fa-14da-42a8-a715-d567a6200284@googlegroups.com> |
| In reply to | #29514 |
On Thursday, April 10, 2014 7:03:03 PM UTC-4, Rod Pemberton wrote: > > C was standardized for multiple > different computing platforms with different architectures. Only 30% > of C's code is truly portable, in the sense that the code performs exactly > the same way on all hardware. Another 30% or so appears to be portable, > because the same result can be implemented on most hardware, albeit > differently. > The rest is simply not portable. It has to be adjusted for different > platforms. > > While the C language is almost entirely independent of the host, the C > libraries > aren't. Minimal C libraries need about twenty host specific functions. Isn't Forth inherently much better? It should be possible to have a Forth for different microprocessor architectures which should allow to run the same programs, because a microprocessor Forth could have words like ADC@ or PWM! or the like to make programs compatible with different I/O. There may be a diversity of additional words like ADC8@, ADC10@, ADC12@ if this is needed. This is a great advantage of Forth. Of course each of these Forth compilations have to be made for each of these specific microprocessor, but it will be possible to run the same Forth user program on each of these specific microprocessors.
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2014-04-12 01:04 -0700 |
| Message-ID | <4e4e16ad-8e59-4f64-b1b7-09e554dff384@googlegroups.com> |
| In reply to | #29543 |
> Isn't Forth inherently much better? It could be, but it isn't IMHO. > It should be possible to have a Forth for different microprocessor > architectures which should allow to run the same programs, because a > microprocessor Forth could have words like ADC@ or PWM! or the like to make > programs compatible with different I/O. There may be a diversity of > additional words like ADC8@, ADC10@, ADC12@ if this is needed. This is a > great advantage of Forth. There is/was a forth 200x proposal at http://www.forth200x.org/memory-2010-06-26.txt which could be used: <size-information><@/!><address-segment> In amforth I use this pattern (to some degree): c@spi (gets a single byte via SPI) or n!spi (sends a memory block via SPI) Something like c@adc or w!pwm could simplify the use of forth code across different controllers (and different forth's). They all do this kind of stuff and all do it subtly different ways. Bonding the users to their system (or family of forth's from the same vendor). I'd go as far as e.g. b!1wire as well (send a single bit to a 1-wire bus). Lowlevel code for it exist for all controllers. That would allow a portable 1-wire lib in forth. Matthias
[toc] | [prev] | [next] | [standalone]
| From | the_gavino_himself <visphatesjava@gmail.com> |
|---|---|
| Date | 2014-04-09 16:12 -0700 |
| Message-ID | <bc273e5a-20a7-4680-b984-3a4e194b0dc8@googlegroups.com> |
| In reply to | #29496 |
On Wednesday, April 9, 2014 12:08:18 PM UTC-7, Bernd Paysan wrote: > Andrew Haley wrote: > > > > >> C was a portable assembly language for a long time after 1977. > > > > > > C was, I suppose, more or less infix PDP-11 assembly language until > > > C90. At that point C acquired an abstract definition and the simple > > > mapping from C to instructions was gone. Simple C compilers which > > > maintained that pre-C90 mapping continued to exist for a while, but > > > over time it has gone. > > > > Fortunately, an ASCII version of the C90 standard is online: > > > > flash-gordon.me.uk/ansi.c.txt > > > > and you can see if that's true. What's true is that, like Forth-94, C90 > > takes a lot of different implementation into account. There are 127 search > > results for "implementation-defined". For example, like in Forth-94, > > division can be floored or symmetric: > > > > "When integers are divided and the division is inexact, if both > > operands are positive the result of the / operator is the largest > > integer less than the algebraic quotient and the result of the % > > operator is positive. If either operand is negative, whether the > > result of the / operator is the largest integer less than the > > algebraic quotient or the smallest integer greater than the algebraic > > quotient is implementation-defined, as is the sign of the result of > > the % operator. If the quotient a/b is representable, the expression > > (a/b)*b + a%b shall equal a ." > > > > All these "implementation-defined" places have exactly the same message: > > Here, the language designer (the standard committee) shifts the > > responsibility to the compiler maintainer. Therefore, as compiler > > maintainer, you, as stated in 1.7, are obliged to "An implementation shall > > be accompanied by a document that defines all implementation-defined > > characteristics and all extensions." This is a "shall", i.e. it is > > nominative. > > > > When reading through the standard, it becomes obvious that a number of these > > "implementation-defined" things arise from different signed number > > representations: C90 ints can be either one's or two's complement, or signed > > magnitude. This affects shifts, additions and conversions to unsigned. > > This does not mean that by the standard this stuff is "undefined": It is > > "implementation-defined", you as compiler maintainer have the duty to define > > it. > > > > Of course, the C90 standard has also "undefined" behavior. E.g. integer > > overflow. There, you are not obliged to document what you do, but you are > > allowed to: > > > > "* Undefined behavior --- behavior, upon use of a nonportable or > > erroneous program construct, of erroneous data, or of > > indeterminately-valued objects, for which the Standard imposes no > > requirements. Permissible undefined behavior ranges from ignoring the > > situation completely with unpredictable results, to behaving during > > translation or program execution in a documented manner characteristic > > of the environment (with or without the issuance of a diagnostic > > message), to terminating a translation or execution (with the issuance > > of a diagnostic message)." > > > > I'd say that on typical workstation processors, which use two's complement > > on integers, and don't trap on overflow, -fwrapv would be the "program > > execution in a documented manner characteristic of the environment". > > Whether you produce an unpredictable result or choose to document what you > > do and produce a predictable result, is up to you as compiler maintainer. > > Thus it's a quality of implementation issue. You can always argue that you > > don't care about the quality of your work, but if you say so in public, it > > means that everybody who cares about the quality of the compiler should look > > for another maintainer. > > > > I see lots of things in common with C90 and Forth-94: Both are no longer > > specifying an implementation, but are more abstract, and therefore giving > > the implementers more responsibility - both reflect the diversity which was > > caused by implementing C/Forth on many different machines; especially the > > weird pre-90s machines. However, the big difference between the C90 > > community and the Forth-94 community is that the latter IMHO used that > > responsibility better. E.g. return stack manipulation beyond what the > > program has put on the return stack. Yes, it's non-standard, yes, it's non- > > portable, and yes, maybe it's evil, but a lot of systems still support it. > > Even systems like VFX, where it actually is work to support it. This is a > > deliberate decision of the maintainers of VFX, in order to not break their > > customer's programs. > > > > Not breaking existing programs is considered a "high quality of > > implementation" feature in the Forth community. We always take that into > > account when adding new features, and not breaking existing programs is > > always a valid argument e.g. to rename a introduced word. > > > > So as maintainer of a compiler, you have the three duties to achieve a > > quality implementation: > > > > a) to specify the implementation-defined behavior > > b) to choose wisely what to do for undefined behavior > > c) not to break existing programs > > > > I don't see GCC as a "quality implementation" any longer, because especially > > the attitude at b+c (and sometimes even a) is clearly unprofessional. > > > > -- > > Bernd Paysan > > "If you want it done right, you have to do it yourself" > > http://bernd-paysan.de/ tcc? tcc does 64 bit now
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-04 23:20 +0200 |
| Message-ID | <lhn7mi$r6h$1@online.de> |
| In reply to | #29282 |
Jason Damisch wrote: > How bad did we fail? Well, out of the Billions and Billions of > cellphones which have ever been produced, not a single one has been > programmed in Forth or uses Forth as an operating system! 99.99% of them > are programmed in Java? Why? I mean I had a $15 cell phone. The > hardware is probably more powerful than my old Atari ST. It has a faster > processor and more RAM. There are only about 5 games for it, and they are > all programmed in Java. Truth be known, these games are so slow as to be > nearly unplayable. It would be undoable to put Llamatron on the thing, > not because of the small screen size, but because it just couldn't use a > Java library to push around a sufficient number of sprites very well. I > know that all of you I.T. people in here are just going to say buy a more > expensive phone, but that's not my point. MPE did some games for cheap cellphones, in Forth of course. I don't know how fast they were, but AFAIK they got the job, because the Java games were too slow ;-). So why does Java win so many developers? There are several things, and the first one is marketing. Java was and is hyped a lot. What's interesting is that Sun, at the time Java was invented, had two success stories for Forth-like languages: One was Display Postscript, the other was OpenFirmware. Given Sun's marketing power, even OpenFirmware can be considered quite a success: IBM did choose it for its POWER processors, so it even endet up as Apple's BIOS. Intel had its huge NIH syndrome, and ignored OpenFirmware, giving us UEFI (and the vendors nightmares). However, with Algol-like languages in the mainstream, creating a better version of C++ was filling a demand, and Sun could just do that. There were two other companies who could do that: Borland (with Delphi), and Microsoft (with VisualBasic; later hiring the key developer from Borland, and creating C#). The mainstream programming world is moving slowly. If we had all the money and PR to create 9 million Forth programmers, how would we do it? We would have to teach them all; that requires a lot of teachers. I.e. we have to teach the teachers. Teaching a teacher is difficult: They already know everything. And even the teachers who know Forth: Can they teach it? Anton Ertl uses Forth in his compiler course. There's one student who actually picked up Forth. Anton is now trying to teach Forth to beginners, because they have some known deficits, they don't understand recursion and memory (which also means "bits and bytes" and number representation). Forth can be a tool to make them understand it. The most difficult part in Forth is the stack. There are two approaches at it, and IMHO, the vertical approach with stack comments all over a definition is going to fail. Computer languages are strange and follow an alien logic, so programmers excessively comment their programs, in plain text, and the reader then reads the comments, not the program - because that's easier. Don't. Read the language. Then your brain will find a way how to quickly extract stack effects. However, this takes time. Our grammar engine is flexible enough to build rules for computer language grammars, and it is powerful enough to track stacks (up to a certain depth). Long interwinded German sentences prove that fact. But our grammar engine needs a lot of training: it is not conscient, it picks up things when repeated often enough. However, all the other mainstream languages have a different grammar, one already taught at school. Yes, it was hard to learn (mathematical infix notation), but it is taught to prepub children. They take that kind of stuff five times faster. It takes them years to learn. It is probably way harder than the stack and postfix. But it is done early, and then it sticks. Note that Gosling wrote NeWS before he started Java. NeWS is using PostScript with a lot of other Forth-like features like cooperative multi- tasking (and object oriented stuff, which is not very Forth-like), and was a way more sophisticated way to drive a display than X10/X11. Despite it has been technically way ahead of the competition, it lost. And Gosling wrote a mainstream language. Which had about the same feature set, with the exception of not being able to send code around (NeWS could, Java can't). I think that's rather telling. The success of a programming system is not about capabilities, it is about acceptance. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
Page 12 of 19 — ← Prev page 1 … 10 11 [12] 13 14 … 19 Next page →
Back to top | Article view | comp.lang.forth
csiph-web