Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #28006 > unrolled thread
| Started by | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| First post | 2014-01-22 13:52 -0800 |
| Last post | 2014-01-26 01:59 +0100 |
| Articles | 20 on this page of 412 — 34 participants |
Back to article view | Back to comp.lang.forth
CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-22 13:52 -0800
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-22 21:57 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-22 14:10 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-22 14:11 -0800
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-23 00:14 +0100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-22 14:28 -1000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-23 20:22 +1100
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-23 12:34 +0100
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-25 22:44 +1100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-25 08:49 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-25 19:40 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-26 23:01 +1100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 03:43 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-23 10:10 +0000
Re: CASE mis-understanding? "gareth" <no.spam@thank.you.invalid> - 2014-01-23 10:31 +0000
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-23 11:35 +0000
Re: CASE mis-understanding? "gareth" <no.spam@thank.you.invalid> - 2014-01-23 13:27 +0000
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-23 05:52 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-23 15:50 +0100
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 01:51 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:00 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:08 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:26 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 14:23 +0100
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 05:41 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-26 00:49 +1100
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-26 03:01 -0800
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-23 05:52 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 08:21 -0600
Re: CASE mis-understanding? BF <foxaudioresearch@gmail.com> - 2014-01-23 06:54 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-01-23 16:00 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-23 20:21 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-23 20:33 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 04:33 -0500
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-10 23:14 +0000
Re: CASE mis-understanding? Ron Aaron <rambamist@gmail.com> - 2014-01-24 10:49 +0200
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-24 03:26 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 04:25 -0500
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-27 22:09 +1100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-28 22:38 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-01-23 03:22 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 06:52 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-23 16:03 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 10:14 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-23 17:42 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-01-23 10:42 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 15:01 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-23 17:21 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 12:16 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-24 09:25 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-24 07:16 -0600
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 05:43 -0800
Re: CASE mis-understanding? mhx@iae.nl - 2014-01-24 10:57 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-25 03:58 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 17:24 +0000
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-27 19:25 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-28 03:34 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 14:50 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 17:15 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-24 21:00 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-25 20:47 -0800
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-10 23:36 +0000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-01-24 00:44 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-24 09:20 +0000
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-23 10:02 +0000
Re: CASE mis-understanding? Elizabeth D Rather <erather@forth.com> - 2014-01-23 09:05 -1000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-27 00:43 +1100
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-26 18:04 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-01-26 11:27 -0800
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-26 22:09 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-26 15:35 -0600
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-29 01:57 +1100
Re: CASE mis-understanding? mhx@iae.nl - 2014-01-28 13:46 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-28 12:12 -1000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-30 17:19 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-01 00:40 +1100
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-31 06:33 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-31 12:13 -0600
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-31 08:36 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-01 00:06 -0800
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-31 15:34 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-03 16:18 +1100
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-01 03:17 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-02 13:10 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-02 16:06 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-02 10:43 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-02 18:39 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-03 14:18 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-02 18:49 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-03 09:35 +0000
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-02-03 09:56 +0000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-03 02:50 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-02-03 03:17 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-03 14:31 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-03 19:17 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-04 12:23 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-03 19:26 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-04 08:05 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-02 19:07 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-30 15:59 +0000
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-31 02:34 +0100
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-31 02:38 +0100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-30 15:51 -1000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-03 14:58 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-03 12:06 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-09 15:04 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-09 10:56 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-10 15:58 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-10 12:06 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-11 11:22 +0000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-11 05:23 -0800
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-12 10:54 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-10 18:12 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 05:13 -0600
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-10 15:44 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 10:40 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-10 17:47 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-10 16:34 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 11:09 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-10 17:20 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 12:14 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-10 22:38 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-11 03:46 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-11 10:30 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-11 18:24 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-12 15:02 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-12 11:23 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 09:25 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 04:54 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 13:41 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-13 14:14 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 08:41 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 15:29 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 12:07 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-15 16:14 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-15 13:22 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-17 12:28 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-17 14:05 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-17 09:49 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-17 19:06 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-17 12:52 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-17 22:51 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 04:36 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 09:34 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 05:01 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 14:19 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-18 08:28 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 17:14 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-18 11:46 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-18 18:20 -0500
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-19 17:10 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-19 23:17 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-20 09:55 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-21 20:15 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-22 12:08 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-22 14:45 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 02:29 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-22 21:29 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 22:33 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 22:13 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-24 17:30 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-24 14:38 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-26 12:59 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-26 20:12 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 04:54 -0600
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-02-27 12:56 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 06:30 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 05:29 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 15:48 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 08:13 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-27 16:23 -0500
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-28 11:21 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-28 16:20 -0500
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-01 01:51 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-28 23:36 -0500
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-01 12:45 +0000
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-03-01 13:59 +0100
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-01 13:03 +0000
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-03-01 07:53 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:12 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 08:46 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:56 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 10:08 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 11:01 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-27 08:12 -1000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-27 16:23 -0500
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-02-27 19:53 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 07:48 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 16:05 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 08:27 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:45 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 20:51 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-01 08:46 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-03-01 16:53 -0500
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-03-01 15:06 -1000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 01:50 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-03 17:18 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 02:51 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-04 03:20 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-04 19:12 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-05 03:51 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-04 10:11 +0000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-05 14:09 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 11:20 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-01 15:43 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 22:16 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-02 04:56 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-02 14:07 +0000
Re: CASE mis-understanding? Mark Wills <markwills1970@gmail.com> - 2014-03-03 00:59 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-02 08:20 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-03 03:03 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-06 18:09 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-06 17:26 -0600
WITHIN (was: CASE mis-understanding?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 12:51 +0000
Re: WITHIN Paul Rubin <no.email@nospam.invalid> - 2014-03-07 12:13 -0800
Re: WITHIN mhx@iae.nl - 2014-03-08 05:07 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-08 15:43 +0000
Re: WITHIN mhx@iae.nl - 2014-03-08 08:23 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-08 16:37 +0000
Re: WITHIN mhx@iae.nl - 2014-03-08 10:18 -0800
Re: WITHIN mhx@iae.nl - 2014-03-08 10:48 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-08 16:02 +0000
Re: WITHIN Paul Rubin <no.email@nospam.invalid> - 2014-03-09 01:24 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-09 18:16 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-06 21:46 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-07 09:22 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 12:28 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-07 19:36 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-06 18:25 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-06 23:52 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 10:15 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-07 08:38 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-07 09:36 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-03-02 20:16 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-27 08:18 -1000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 13:21 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-07 08:26 -0600
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:37 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 11:31 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 13:18 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-07 11:17 -0800
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-03-09 20:49 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-27 16:22 -0500
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-28 15:22 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-28 18:32 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 03:39 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 02:19 +0100
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 13:03 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-24 01:25 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-24 03:36 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-24 02:04 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 01:15 +0100
Re: CASE mis-understanding? Julian Fondren <julian.fondren@gmail.com> - 2014-02-22 21:09 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-22 21:55 -0800
Re: CASE mis-understanding? Julian Fondren <julian.fondren@gmail.com> - 2014-02-23 00:47 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 01:45 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-20 17:07 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-20 16:03 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-21 04:11 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-21 10:59 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-21 03:26 -0800
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-21 10:34 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-21 05:49 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-22 13:52 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 09:13 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-22 10:45 -0500
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-21 20:18 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-22 15:24 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-22 10:37 -0500
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 03:20 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-11 16:15 -0400
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-12 00:10 -0700
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-22 13:28 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 08:56 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 01:27 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-23 04:33 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 08:11 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 21:44 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 22:48 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 02:23 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-24 16:05 +0000
Re: CASE mis-understanding? Tristan Plumb <firth@trstn.net> - 2014-02-24 18:15 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-24 18:45 +0000
Re: CASE mis-understanding? Tristan Plumb <firth@trstn.net> - 2014-02-24 19:18 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-26 12:40 +0000
Re: CASE mis-understanding? Tristan Plumb <st@trstn.net> - 2014-02-26 15:27 +0000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 01:31 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-04 16:30 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-05 11:48 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-22 18:28 -0800
Re: CASE mis-understanding? Gary Bergstrom <forthprgrmr@gmail.com> - 2014-02-24 08:39 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-24 21:29 -0800
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 00:44 +0000
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 00:45 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-23 04:35 -0600
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 12:31 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-18 18:19 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 11:06 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-18 12:51 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 14:40 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 08:17 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 04:48 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 13:56 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 11:15 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-18 18:24 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-19 03:46 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-21 15:52 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 09:10 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-18 13:09 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 15:03 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 15:53 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-14 00:39 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-14 06:38 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-15 15:37 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-15 13:33 -0600
Re: CASE mis-understanding? Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-02-11 10:50 +0100
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-11 10:57 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-11 02:35 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-11 11:47 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-11 13:08 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-11 18:42 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-12 10:54 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-12 05:31 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-12 15:52 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-12 10:41 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 09:27 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 04:49 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 13:54 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-03 12:26 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-07 13:41 +1100
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-07 01:08 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:56 +1100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-07 12:15 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-01 00:39 +1100
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-01-31 07:29 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-04 23:45 +1100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-31 16:31 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-03 12:35 +1100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-03 09:32 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:31 +1100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-08 11:22 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-03 13:54 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-31 08:40 -1000
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-26 22:03 -0800
Re: CASE mis-understanding? julian.fondren@gmail.com - 2014-01-29 17:19 -0800
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-30 11:15 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 13:57 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-28 14:01 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-28 14:49 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-29 10:07 +1100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-28 21:54 -0800
Re: CASE mis-understanding? Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-01-29 00:33 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-29 03:37 -0600
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-30 21:51 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-31 18:44 -0500
Re: CASE mis-understanding? David Thompson <dave.thompson2@verizon.net> - 2014-02-09 00:34 -0500
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-09 22:14 -0500
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 01:25 +0000
Re: CASE mis-understanding? Julian Fondren <julian.fondren@gmail.com> - 2014-01-31 17:44 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-31 16:03 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-01 01:55 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-01 11:34 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-01 08:11 -1000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-02 14:28 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-02 18:28 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-07 13:34 +1100
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-07 03:52 +0100
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:41 +1100
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-07 18:33 -0500
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-02-08 00:31 +0100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-08 11:21 +0000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-08 15:03 +0100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-08 19:58 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-09 08:33 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-09 19:50 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-10 08:42 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 16:32 -0800
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-02-14 02:36 +0100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 23:04 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 23:40 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-14 04:37 -0500
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-14 09:42 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-15 16:52 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-16 07:46 -0500
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-16 08:11 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-16 16:15 -0800
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-02-17 09:03 +0100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-16 22:12 -1000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-17 02:29 -0800
Re: CASE mis-understanding? Alex McDonald <blog@rivadpm.com> - 2014-02-17 04:27 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-17 09:36 -1000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-17 09:22 -1000
Re: CASE mis-understanding? Alex McDonald <blog@rivadpm.com> - 2014-02-17 12:06 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-17 20:18 -0800
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 01:48 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-11 16:10 -0400
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-14 13:54 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-06 17:03 -1000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:39 +1100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-07 20:12 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-09 21:33 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:38 -0800
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-01-24 16:17 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 08:54 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 09:25 -1000
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-01-24 20:34 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 11:13 -1000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 17:39 -0500
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 16:05 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-25 11:46 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-25 16:15 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-26 01:59 +0100
Page 13 of 21 — ← Prev page 1 … 11 12 [13] 14 15 … 21 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-03-07 11:17 -0800 |
| Message-ID | <7xha797r8a.fsf@ruckus.brouhaha.com> |
| In reply to | #28955 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>I notice that http://soton.mpeforth.com/flag/anstests/index.html >>(based on Hayes tests) doesn't have any tests for WITHIN. > > Here are my tests: ... Thanks. It would be nice if those got added to anstests.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2014-03-09 20:49 +0000 |
| Message-ID | <lfik4k$825$1@dont-email.me> |
| In reply to | #28963 |
On 07/03/2014 19:17, Paul Rubin wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>> I notice that http://soton.mpeforth.com/flag/anstests/index.html >>> (based on Hayes tests) doesn't have any tests for WITHIN. >> >> Here are my tests: ... > > Thanks. It would be nice if those got added to anstests. > Yes, good idea and will do when time permits as I have a few other things that can be added as well. Anton's tests are GForth specific and will need changing to fit in with the Hayes tester. Also locals shouldn't be used as they are in an optional word set. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-02-27 16:22 -0500 |
| Message-ID | <op.xbylokds5zc71u@localhost> |
| In reply to | #28796 |
On Thu, 27 Feb 2014 05:54:10 -0500, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Paul Rubin <no.email@nospam.invalid> wrote: >> These days the very existence of null pointers should be seen as a >> language wart. Tony Hoare wrote in 2009: [claims worst mistake ever] > > Umm, how would you represent the end of a linked list? By a node > pointing to itself, maybe ... but that seems a bit kludgy and carries > its own problems. 1) You'd create your own NULL or NIL, by using a sentinel value or magic number, such as zero or all bits set, etc. 2) You'd use a flag, initially zero, which gets set to non-zero when a pointer is initialized with a value. This would produce an immense amount of additional code. So much so, it could be claimed that the NULL pointer, despite all it's inherent problems, is the better solution. http://en.wikipedia.org/wiki/Sentinel_value http://en.wikipedia.org/wiki/Magic_number_(programming) Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-28 15:22 +0000 |
| Message-ID | <2014Feb28.162213@mips.complang.tuwien.ac.at> |
| In reply to | #28793 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> The standard does not say that you have to miscompile "undefined
>> behaviour", it just does not define it, and compilers that compile the
>> code as intended by the programmer are compliant.
>
>And the compiler is supposed to divine the programmer's intentions
>exactly how?
There is no need to "divine" the intentions, if the optimizer is
really just an optimizer, i.e., if it does not change the behaviour.
> If you search for "integer overflow vulnerability", there
>are many many examples of programs getting hosed by wraparound. So I'd
>say the programmer's intention in at least those cases didn't involve
>twos complement.
That may be the case for these cases. But assuming that an integer
overflow does not happen and changing the behaviour in arbitrary ways
based on that assumption does not help these cases. Indeed, it may
create a vulnerability.
>> So it's the choice of the compiler: Do they want to implement the
>> language that the programs are written in,
>
>Unless you can point to an old version of the GCC manual documenting the
>wraparound behavior you describe for regular ints, I don't believe it
>was part of the language.
My experience with the GCC manual is that the GCC maintainers don't
give a damn about it. Examples:
1) They did not implement long long as documented, and when this was
reported as bug, they changed the documentation.
2) Statement expressions are a documented GCC extension. A bug in the
implementation is explained away by claiming that the behaviour is
undefined. My guess is that they won't accept any bug report on that
feature (always with the same excuse), except maybe when gcc
miscompiles the exact example given in the documentation; and then
they might deal with that by approach 1).
>It only happened to work by relying on
>undocumented compiler behavior that existed at the time.
Concerning signed overflow, the compiler behaves in the -wrapv way in
all versions by default, as long as it cannot deduce at compile time
that an overflow happens. I.e.,
if (x<x-y) ...
with y=1 works as I intend as long as gcc is unaware that y=1.
>> and that earlier versions of the compiler compiled
>
>I'm on board with the idea that there's enough badly written legacy code
>relying on wrapv that compilers like GCC ought to accomodate it, which
>they do, by offering the -fwrapv option.
There are GCC versions that miscompile "if (x<x-1) ..." and that do
not support the -fwrapv option. So no, GCC in general does not
accomodate it by offering the -fwrapv option.
>You seem to want -fwrapv to be
>the default, which I'm skeptical of (-ftrapv or the AIR proposal both
>seem better at first glance), but it's a reasonable judgment call if
>there's evidence that bugs due to mistaken expectations of wrapping are
>more common than bugs due to unintentional overflow.
The way that gcc miscompiles intentional wraparound does not help
against bugs due to unintentional overflow, so that's not a choice
they made here.
-ftrapv would be a way to report unintentional overflow (as well as
intentional wraparound), but they have not made that the default.
>Specifying well-defined behavior as much as possible is a good idea for
>systems implementation languages in general, but doesn't seem in the
>spirit of the C standardization process, which valued potential
>optimizations above everything else. It seems part and parcel of C
>ideology.
Maybe C standards ideology, and also a relatively recent variation.
The original reason for not standardizing signed overflow was that C
is intended to support several signed number representations.
As for potential optimizations, if everybody restricts themselves to
writing Pascal with C syntax, because everything else is "undefined
behaviour", a lot of techniques for achieving good performance will
not be used. And while the optimizer may be able to achieve a higher
speedup for the optimized Pascal program compared to the unoptimized
Pascal program, the program will still be quite a bit slower than a
classical C program optimized with a proper C compiler (say, a
Stallman-maintained gcc).
E.g., compare the Pascal-style code you wrote for WITHIN with the C
code presented by Andrew Haley. Does any compiler compile the former
into the latter? And even if the compiler heroically manages to
optimize this, will it optimize the next case?
>> For every reported compiler bug, the compiler writer can say that the
>> program was not standard-conforming and therefore the compiler can do
>> anything; mark the report as not-a-bug, saves a lot of work
>
>In the case of 2's complement arithmetic, the answer is to use -fwrapv.
>If wrapv doesn't work properly, then there is a bug that I'd expect a
>fix for.
I doubt that they will fix the compiler versions that don't support
-fwrapv, and even if they did, these compilers are out there, and
fixing them upstream won't get them fixed.
>>> SWAP DEPTH IF thing1 ELSE thing2 THEN
>
>> The code may be non-standard, but that does not make it buggy.
>> If someone writes such code, they presumably have an intent,
>
>What intent do you think they have?
I don't know, I did not write the code. That's why I would take the
conservative route and would not asssume that DEPTH cannot be 0,
unless my compiler generates code that traps DEPTH<2 at the SWAP.
> The only intent that makes any
>sense to me is that they intend that there are two or more elements on
>the stack when the SWAP runs.
Given that there is DPETH IF afterwards, your divination is doubtful.
>> If the compiler prevents the DEPTH IF from ever being reached with
>> depth 0, then it can optimize the ELSE part away,
>
>How can it be reached with depth 0, if the only way to reach it is
>through the SWAP?
By SWAP not checking the stack depth in any way. If SWAP checks and
produces an exception (like gforth (non-fast) does), it cannot, and
the DEPTH IF can be optimized.
> Maybe there is some Forth subtlety going on here that
>I don't understand, but I'd have thought there was no way. And I'd
>think that a SWAP at depth 0 is 100% buggy
Maybe, but that does not give the compiler license to do anything it
likes. Either the compiler generates code that prevents the stack
underflow, and then it can optimize; or it does not and then it
cannot. But letting the SWAP not check and still optimizing based on
the assumption that DEPTH>=2 is like having your cake, and eating it,
too.
>Probably wise, though you're still vulnerable to (e.g.) subscript
>errors, that always have been unsafe/undefined, and tons of other
>things.
Sure, but the difference is that these things don't work reliably with
optimization off, either.
>The problem is with C itself, not with a particular
>optimization.
You may have a problem with C itself, I don't.
>>>Well, the broken code still passes tests,
>> The code works, and yet you say it's "broken" and contains "endless
>> bugs".
>
>No, the code doesn't work. It was buggy. It dereferenced null
>pointers, which is always a bug.
Apparently you know more about the program (which we only talked about
in very abstract terms up to now) than I do. And just because you
think that dereferencing a null pointer is a bug does not make it so.
>These days the very existence of null pointers should be seen as a
>language wart.
So you don't like C. There are lots of other languages to choose
from. No need to ruin C for those of us who use it productively.
>>>Even in systems code, though, the amount of code that uses intentional
>>>wraparounds is tiny.
>> Proof?
>
>(IOC) https://www.cs.utah.edu/~regehr/papers/overflow12.pdf
The abstract says:
|Although many overflows are intentional, a large number of accidental
|overflows also occur. Orthogonal to programmers' intent, overflows are
|found in both well- defined and undefined flavors.
>(AIR) http://resources.sei.cmu.edu/asset_files/TechnicalNote/2009_004_001_15074.pdf
This seems to have only been applied to one program.
>> Yes, somebody suggested code for the "if (x<x-1)" case that uses casts
>> to do an unsigned subtraction and a signed comparison,
>
>Why do you want to do that with a signed int in the first place?
It's a parameter to a signed division. Dividing the smallest integer
by -1 produces an overflow, and gforth (non-fast) produces an
exception for that. So if I write, e.g.,
n = n1/n2;
if (CHECK_DIVISION_SW && n2 == 0)
throw(BALL_DIVZERO);
if (CHECK_DIVISION_SW && n2 == -1 && n1<n1-1)
throw(BALL_RESULTRANGE);
...
and gcc "optimizes" the second check away, some division overflows may
be unreported. Looking at this again, and following the discussion,
my guess is that the division overflow is "undefined behaviour", and
gcc might use that to "optimize" the check away even if the check
itself is written in a way that gcc does not see as undefined
behaviour. It did not do this when I tested it, but it might do so in
a later version. Great! So much for your belief that optimizing on
"undefined behaviour" help catching bugs.
>> and he claimed that his code is standard.
>
>Well is it?
Probably not. It had more than one token in it, so a C standards
lawyer is almost certain to find some "undefined behaviour" or
somesuch in it. But since I am not a C standards lawyer, I did not
find that.
>> Unfortunately at least one GCC version miscompiles this code.
>
>Given that you persistently use "miscompile" to mean "the compiler did
>what I said instead of what I meant" (which is what computers always
>do)
Straw man alarm! I explained what I mean with "miscompile", which has
something to do with intent; and the compiler is allowed to do what I
meant, so "do what I said" does not come into play here.
>I'd need more specifics to know if the compiler actually made a
>mistake.
I did not find the specifics in 5 minutes of searching, sorry. But if
you want to reproduce it, I tested gcc versions starting with 2.95.
>>>WITHIN is so confusing...
>> As for your cop-out: I have no problem understanding what it does and
>> implementing it. Why do you?
>
>There was about half a page of obfuscation in the ANS document about
>that function, with no plain English description of how to use it, no
>examples or test vectors showing the edge cases, and a bunch of cautions
>about how implementations can get it wrong, so it sounded easy to make
>subtle errors.
Hmm, the specification is a few lines, and is written in a way that
avoids overflow, so it should appeal to you.
>The simplest C version would use a separate function for each signature:
>
> #include <stdbool.h>
> bool within_s(int n, int lower, int upper) {
> return (lower <= n && n < upper);
> }
> bool within_u(unsigned int n, unsigned int lower, unsigned int upper) {
> return (lower <= n && n < upper);
> }
>
>A decent optimizing compiler should generate good inlined code for all
>of these.
I would like to see a compiler that generates as good code for (a
corrected version of) this code as for Andrew Haley's wraparound-based
implementation.
>> And if you have a problem with that, why do you think you can make any
>> judgement about code that uses wraparound?
>
>There is no need to use wraparound for that function.
Maybe not, but if the goal is to get the fastest code possible, there
is; maybe not in theory, but unless you can name a compiler that
produces the same code, in practice there is.
- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-28 18:32 +0000 |
| Message-ID | <2014Feb28.193258@mips.complang.tuwien.ac.at> |
| In reply to | #28831 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Paul Rubin <no.email@nospam.invalid> writes:
>>I'd need more specifics to know if the compiler actually made a
>>mistake.
>
>I did not find the specifics in 5 minutes of searching, sorry. But if
>you want to reproduce it, I tested gcc versions starting with 2.95.
I have found the specifics: From
<2011Apr26.112307@mips.complang.tuwien.ac.at>:
|Now a language lawyer told me that I could write
|
|n < (long)(((unsigned long)n)-1)
|
|instead to get the C compiler to produce the code I want while
|"satisfying the letter of the law". So I try this with the devil's
|implementation and find: gcc 2.95, 3.3 and 3.4 all produce 0 with -O
|for both code variants and produce the intended code (apart from quite
|a bit of inefficiency) without -O for both variants of the code. Only
|gcc 4.1 (among the gcc versions I tested) works as the language lawyer
|promised.
- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-03-01 03:39 -0800 |
| Message-ID | <7x8usub10y.fsf@ruckus.brouhaha.com> |
| In reply to | #28831 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>And the compiler is supposed to divine the programmer's intentions
>>exactly how?
> There is no need to "divine" the intentions, if the optimizer is
> really just an optimizer, i.e., if it does not change the behaviour.
The behavior is undefined both before and after the optimizer runs. If
all you want is for the behavior to be the same both ways, that sounds
like you'd be ok with (say) trapv or saturation both before and after
optimization. Is that right?
I see now (in the gcc 4.4 man page) that undefined overflow is
controlled by the -fstrict-overflow option, and that the option is is
enabled at optimization levels -O2, -O3, and -Os. So maybe you should
stay with -O1. The higher levels would seem to correspond to people
turning off safety checks on purpose.
You can also use the -Wstrict-overflow option to get a warning message
if the compiler optimizes on the assumption of no overflow. This option
has 5 levels (the higher ones produce more false positives) and -Wall
sets it to 1, which supposedly flags the x+1 > x example under
discussion. Is there some reason you're not using -Wall?
>> If you search for "integer overflow vulnerability"
> But assuming that an integer overflow does not happen and changing the
> behaviour in arbitrary ways based on that assumption does not help
> these cases.
The programs already behave in arbitrary ways on overflow, even when the
compiler generates wraparound arithmetic, since the programs weren't
expecting wraparound and they reach states where their arithmetic no
longer follows the laws of mathematics that the code relied on (such as:
x+1>x for all x). That's where the vulnerabilities come from. If you
want well-defined arithmetic anyway, the two sensible choices are wrapv
(occasionally used on purpose, but mathematically wrong the rest of the
time) or trapping (maybe with AIR which I haven't really examined).
Which choice will prevent more vulnerabilities? I'm open to evidence
for wrapv, but from what I've seen so far, I'd currently pick trapping.
> Indeed, it may create a vulnerability.
The programs are already buggy, so it would have been better to use
trapv so the traps would at least have stopped the program from going
out of control.
> My experience with the GCC manual is that the GCC maintainers don't
> give a damn about it.
That's unfortunate; I'd be interested in seeing the bug reports if they
are online. But it means if you really want to be able to hold compiler
writers to something written in a document, the document you want is the
ANS standard. So we're back to "talk to the standards committee".
> if (x<x-y) ...
> with y=1 works as I intend as long as gcc is unaware that y=1.
With y=1 and -Wall you should get a warning message to fix your code.
The bug is sneaky enough that maybe the warning should always be
reported, but if you weren't using -Wall you really shouldn't be
complaining about not getting warnings.
> There are GCC versions that miscompile "if (x<x-1) ..." and that do
> not support the -fwrapv option.
It looks like -fwrapv was introduced in gcc 3.4 (per
http://www.gossamer-threads.com/lists/linux/kernel/1049126 ). Are you
complaining that compilers older than that didn't get somehow
retroactively upgraded? That's a bit much to expect.
> -ftrapv would be a way to report unintentional overflow (as well as
> intentional wraparound), but they have not made that the default.
I will probably start using it myself, at least for test builds. I
understand that the runtime costs might be too high for optimized builds
of production code that's supposedly debugged. Critical code where
traps are intolerable should be analyzed with model checkers to make
sure there is no overflow, if possible.
> The original reason for not standardizing signed overflow was that C
> is intended to support several signed number representations.
That's possible but I'd like to see evidence before I'm convinced.
Regehr writes ( http://blog.regehr.org/archives/213 in section
titled "Why Is Undefined Behavior Good?"):
Similarly, when compiling a loop that increments a signed integer,
the C compiler does not need to worry about the case where the
variable overflows and becomes negative: this facilitates several
loop optimizations. I've heard that certain tight loops speed up by
30%-50% when the compiler is permitted to take advantage of the
undefined nature of signed overflow. Similarly, there have been C
compilers that optionally give undefined semantics to unsigned
overflow to speed up other loops.
Between that and the interaction I've had with the C standards guys, I'd
guess they wanted those optimizations at least as much as they cared
about multiple representations. Otherwise they'd have said
"unspecified" instead of "undefined".
> the optimized Pascal program... will still be quite a bit slower than
> a classical C program optimized with a proper C compiler (say, a
> Stallman-maintained gcc).
I'd like to see some measurements of that for real programs.
> E.g., compare the Pascal-style code you wrote for WITHIN with the C
> code presented by Andrew Haley. Does any compiler compile the former
> into the latter?
If you mean the C++ generic version I posted, it implements the spec
very directly and it works for signed and unsigned ints at all widths,
chars, floats, doubles, and anything else that supports the comparison
operators. I believe that is impossible in Pascal. I don't know about
Ada generics.
Yes it does generate worse int code at gcc -O3, but on the other hand it
expresses the specification in a very direct way that's hard to get
wrong. As mentioned it's possible to add micro-optimized versions for
specific types. I'd consider that to be premature optimization unless
there was profile info, or at least a persuasive use case, that said
WITHIN was going to use a significant amount of cpu time in the program.
> And even if the compiler heroically manages to optimize this, will it
> optimize the next case?
It seems to me that some fancy superoptimizers might be able to do stuff
of this (relatively small) complexity automatically, but yes, it seems
beyond the reach of current GCC.
>>>> SWAP DEPTH IF thing1 ELSE thing2 THEN
> I don't know, I did not write the code. That's why I would take the
> conservative route and would not asssume that DEPTH cannot be 0,
> unless my compiler generates code that traps DEPTH<2 at the SWAP.
I don't understand this. If DEPTH=0 at the swap and the runtime doesn't
trap it, then it probably has swapped two words outside the stack
region, and the program can be treated as trashed (e.g. maybe the words
swapped were actually in the return stack, maybe one of them was a stack
depth counter so DEPTH itself returns the wrong thing, etc). Why does
the compiler have any further responsibility for what happens next, if
the programmer has asked for maximum optimization?
>>The only intent that makes any sense to me is that they intend that
>>there are two or more elements on the stack when the SWAP runs.
> Given that there is DEPTH IF afterwards, your divination is doubtful.
DEPTH IF could have come from a macro or template expansion, or been
generated by another program, or have been handwritten for clarity as
part of a bunch of slightly differing fragments, etc. It's like if I
write
seconds = days * 24 * 60 * 60;
I expect compile-time constant folding, rather than three
multiplications at runtime. I've written inefficient-looking code for
human consumption. There's not an "intent" of three multiplications
unless I've used volatile variables and separate operations.
> By SWAP not checking the stack depth in any way. If SWAP checks and
> produces an exception (like gforth (non-fast) does), it cannot, and
> the DEPTH IF can be optimized.
If the stack is empty SWAP doesn't check it, how does the program still
have any meaning after the unchecked SWAP has executed?
> But letting the SWAP not check and still optimizing based on the
> assumption that DEPTH>=2 is like having your cake, and eating it, too.
SWAP is not supposed to work if DEPTH < 2. If the programmer has turned
off the checks, they are saying they know that DEPTH>=2 with enough
certainty that they don't need the checks. If they turn out to be
wrong, the code will probably write to out-of-range addresses, with the
usual unpredictable consequences of doing that with no safety checks.
I can see the case for a compile-time warning message based on belief
analysis ( http://stanford.edu/~engler/deviant-sosp-01.pdf ) due to the
DEPTH IF, but leaving out the optimization seems to go against what the
programmer intended by turning off the checks. Compile-time warning
messages on the other hand seem to go against Forth ideology, so whatever.
> So you don't like C. There are lots of other languages to choose
> from. No need to ruin C for those of us who use it productively.
C just seems like a lost cause: look at the non-standard extensions like
labels-as-values that you use in gforth, or gyrations like x+1<x,
because C is not low-level enough. On the other hand, for most programs
of any size, C is too low-level. It's probably better to write most
code in HLL's, with occasional calls to some lower-than-C but still
machine-independent language like C-- or your own PAF or whatever. The
most heavily optimized stuff still has to be in architecture-dependent
and maybe microarchitecture-specific assembly language. I was
interested in Potential for this ( http://potential-lang.org/ ) but the
project seems to have stopped.
Even C++ seems like an improvement over C, in the sense that it adds a
lot of stuff to C, some good and some bad, and it's relatively easy to
ignore the bad. I understand the notion that C++ is too complicated to
be safe, but on the other hand I've lately been messing with a C++
program that's accreted crappy code from a lot of non-experts, yet it
still works because you gain some safety from stuff like the STL
containers. I think if it was in C it would have collapsed long ago.
>>(IOC) https://www.cs.utah.edu/~regehr/papers/overflow12.pdf
> The abstract says:
> |Although many overflows are intentional, a large number of accidental
> |overflows also occur. Orthogonal to programmers' intent, overflows are
> |found in both well- defined and undefined flavors.
Yes, in the errors they found, there was IIRC just one "type IV" where
signed wraparound was expected. The vast majority of signed ints that
I've ever seen in real code don't use intentional wraparound. They
expect to just stay in range, and when they don't, we see "integer
overflow vulnerability" or just plain bugs (like gzip reporting wrong
file sizes due to a 32 bit size field). We rarely (by comparison with
overflow bugs) see bugs from wraparound being expected.
>>(AIR) http://resources.sei.cmu.edu/asset_files/TechnicalNote/2009_004_001_15074.pdf
> This seems to have only been applied to one program.
Yeah, that's unfortunate. I thought it was interesting that there was
just 5% or so slowdown from the extra code, though.
> Dividing the smallest integer by -1 produces an overflow, and gforth
> (non-fast) produces an exception for that.
I got a division by zero exception from both gforth and gforth-fast, if
that matters.
> So if I write, e.g.,
> n = n1/n2;
I wonder what this is supposed to do even with -fwrapv enabled.
-INT_MIN is simply not a valid number in 2's complement. I think I'd
want a runtime trap.
> if (CHECK_DIVISION_SW && n2 == 0)
> throw(BALL_DIVZERO);
> if (CHECK_DIVISION_SW && n2 == -1 && n1<n1-1)
> throw(BALL_RESULTRANGE);
> ...
> and gcc "optimizes" the second check away, some division overflows may
> be unreported.
1. If you use -Wall you should get a warning message about the
optimization, as mentioned above. In that sense the overflows were
reported at compile time.
2. You might not even run any of the tests, since at least on the x86,
the division overflow is supposed to raise an overflow exception. I
don't know about other processors. If you're going to do these tests at
all, you should do them before attempting the divison. I think it's
better to trap the exception, if there's a reliable way to do that.
> Looking at this again, and following the discussion, my guess is that
> the division overflow is "undefined behaviour", and gcc might use that
> to "optimize" the check away even if the check itself is written in a
> way that gcc does not see as undefined behaviour.
It looks like buggy code to me, as described above.
>>> and he claimed that his code is standard.
>>Well is it?
> Probably not. It had more than one token in it...
Maybe I'll try to install KCC and test it.
> Straw man alarm! I explained what I mean with "miscompile",
You are not in charge of the dictionary and you're not entitled to be
taken seriously when you make up your own definitions of words like
"miscompile".
> which has something to do with intent; and the compiler is allowed to
> do what I meant, so "do what I said" does not come into play here.
If "what you said" is undefined behavior, the compiler is allowed to do
whatever it wants, including what you meant. The trouble is expecting
the compiler to be able to guess what you meant.
> Hmm, the specification is a few lines, and is written in a way that
> avoids overflow, so it should appeal to you.
The descriptions in the Gforth and MPE manuals are both written in
slightly confusing ways, though not incorrect. Looking at
dpans6.htm#6.2.2440 the wording is a bit cumbersome but (in retrospect)
it's precise. I had mostly looked at the glossary, which obscured the
situation a lot, and then the Gforth and MPE docs. I'd have described
it somewhat differently.
> I would like to see a compiler that generates as good code for (a
> corrected version of) this code as for Andrew Haley's wraparound-based
> implementation.
The wraparound-based version IMHO falls into the "cute but hacky
optimizations" department and in application code I'd prefer the direct
generic version, unless there was evidence that it was consuming enough
cycles to care about. For example, the floating point version looks
like it might be useful for interval arithmetic:
http://en.wikipedia.org/wiki/Real_projective_line
http://mathworld.wolfram.com/ProjectivelyExtendedRealNumbers.html
(see last paragraph of Wolfram article for interval arithmetic mention).
> if the goal is to get the fastest code possible... unless you can name
> a compiler that produces the same code, in practice there is.
I'd still like to know the real-world use cases of that function--in
particular, how often it's not known in advance which of the endpoints
is bigger. In cases where it's known, you can use that info to get rid
of the arithmetic, and just do straightforward comparisons that might be
even faster than the wraparound version.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-03-04 02:19 +0100 |
| Message-ID | <lf39n7$s7o$1@online.de> |
| In reply to | #28841 |
Paul Rubin wrote: >>>>>SWAP DEPTH IF thing1 ELSE thing2 THEN >> I don't know, I did not write the code. That's why I would take the >> conservative route and would not asssume that DEPTH cannot be 0, >> unless my compiler generates code that traps DEPTH<2 at the SWAP. > > I don't understand this. If DEPTH=0 at the swap and the runtime doesn't > trap it, then it probably has swapped two words outside the stack > region, and the program can be treated as trashed (e.g. maybe the words > swapped were actually in the return stack, maybe one of them was a stack > depth counter so DEPTH itself returns the wrong thing, etc). Why does > the compiler have any further responsibility for what happens next, if > the programmer has asked for maximum optimization? Considder gforth-fast. It has 8 otherwise unused elements underneath depth 0, and if you drop more than those 8, you'll trap. This is because it does some clever optimizations to remove stack accesses, by caching a variable amount of stack elements. So stop doing unfounded worst-case assumptions: > gforth-fast Gforth 0.7.9_20140119, Copyright (C) 1995-2013 Free Software Foundation, Inc. Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license' Type `bye' to exit : foo swap depth if ." swapped" else ." should have crashed" then ; ok foo should have crashed ok > gforth Gforth 0.7.9_20140119, Copyright (C) 1995-2013 Free Software Foundation, Inc. Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license' Type `bye' to exit : foo swap depth if ." swapped" else ." should have crashed" then ; ok foo :2: error: Stack underflow >>>foo<<< Backtrace: $7F4890C11820 swap The program is indeed buggy, but the way it will behave on gforth-fast is well-defined: it will reach the "should have crashed" part. It is well- defined, because the implementer of gforth-fast choose to add another 8 dummy memory elements underneath the bottom of stack. So the assumption that the program is buggy may even be completely wrong: What if the author wrote the program deliberately for gforth-fast, and added that check because he wouldn't get an exception from gforth-fast? -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-02-27 13:03 +0000 |
| Message-ID | <530f3799$0$24955$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #28786 |
In article <2014Feb26.135958@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >Paul Rubin <no.email@nospam.invalid> writes: >>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>> Even GCC and LLVM exercise undefined behaviour, >> >>Even now? I know Regehr and others reported a lot of those bugs, that >>got fixed. > >I don't follow this stuff, so I would not know. Do they guarantee >that they have reported every possible occurrence of an "undefined >behaviour", and are they all "fixed"? If not, then it's likely that >they still do. > >>> So we can expect that, apart from a few example programs for standard >>> C code, there are no C programs around that actually comply with the >>> standard in every respect. >> >>Well that would either a) say that something was wrong with the >>standard, or b) confirm the Forther attitude that all C programs are >>full of bugs. Either way, I don't see how the compilers are to blame >>for implementing what the standard says. > >The standard does not say that you have to miscompile "undefined >behaviour", it just does not define it, and compilers that compile the >code as intended by the programmer are compliant. So it's the choice As is the compiler that treats undefined behaviour as a programming error and demands it fixed. What the gcc people do apparently is annoying the programmers in order to get it fixed, this is somewhat dubious. >- anton -- 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 | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-02-24 01:25 -0500 |
| Message-ID | <op.xbrv37tz5zc71u@localhost> |
| In reply to | #28720 |
On Sun, 23 Feb 2014 16:33:02 -0500, Bernd Paysan <bernd.paysan@gmx.de>
wrote:
> Just yesterday, Apple issued an update to their SSL bug. The culprit is
> just what we are discussion here: They rendered the final check on an SSL
> connection setup into dead code, by having duplicated line in a
> statement:
>
> if(err = somecheck(...))
> goto fail;
> goto fail;
> if(err = finalcheck(...))
> goto fail;
>
> ...
>
> So the final check never was done. Optimizing it away, even though that
> was by C's semantics the expressed intention of the programmer, was very
> harmful.
>
The problem here was the failure to use braces {} to delimit the body of
each if statement. If they had done so, the mistake:
1) would've been obvious, or
2) wouldn't have had any effect
Not requiring braces for all blocks is another of C's design mistakes.
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-24 03:36 -0600 |
| Message-ID | <CJGdne0Tlsgrj5bOnZ2dnUVZ_sSdnZ2d@supernews.com> |
| In reply to | #28720 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > > Just yesterday, Apple issued an update to their SSL bug. The culprit is > just what we are discussion here: They rendered the final check on an SSL > connection setup into dead code, by having duplicated line in a statement: > > if(err = somecheck(...)) > goto fail; > goto fail; > if(err = finalcheck(...)) > goto fail; > > ... > > So the final check never was done. Optimizing it away, even though > that was by C's semantics the expressed intention of the programmer, > was very harmful. Optimizing it away made no difference. The code was jumped around, no it does not matter if the compiler emitted it or not. > Yes. A lot of code depends on it, so much that the GCC maintainers had > added a -fwrapv flag to support it. IIRC -frapv was added for Java. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-02-24 02:04 -0800 |
| Message-ID | <7x38j8su6c.fsf@ruckus.brouhaha.com> |
| In reply to | #28732 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> goto fail; >> goto fail; > Optimizing it away made no difference. The code was jumped around, no > it does not matter if the compiler emitted it or not. I think Bernd was basically asking for the compiler to print a warning message on the dead code elimination.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-03-04 01:15 +0100 |
| Message-ID | <lf35vh$jff$1@online.de> |
| In reply to | #28733 |
Paul Rubin wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> goto fail; >>> goto fail; >> Optimizing it away made no difference. The code was jumped around, no >> it does not matter if the compiler emitted it or not. > > I think Bernd was basically asking for the compiler to print a warning > message on the dead code elimination. Indeed. GCC did print this warning message, but a few years ago, the NSA mole decided to permanently disable that warning, because it requires optimization to be turned on to be calculated. Thus the warning was "unreliable". What is apparently way better than an unreliable warning is no warning at all. The llvm/clang people are not much better (which is why that turned into a problem; Apple doesn't use GCC anymore): They still have the warning, but it is not in the -W -Wall -Wextra set. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2014-02-22 21:09 -0800 |
| Message-ID | <500884a3-1fdd-47b7-b43a-f0a9a0a5b70a@googlegroups.com> |
| In reply to | #28696 |
On Saturday, February 22, 2014 4:45:41 PM UTC-6, Paul Rubin wrote: > That code is already broken. The way math works, adding two > positive integers always results in another positive integer. I though you were deliberately avoiding that embarrassing example. But you actually agree with it? Because of "the way math works"? x>x+1 can be false for all C integers: eventually you run out of bit for x+1. It will also be false for all C floats: eventually you run out of, well, bits again, and have floats where '1' is too infinitesimal an increment to represent, so x==x+1 becomes true. So this test should only ever be optimized away when you can prove that x will only ever have values for which the result of the test is always true (or false). Since such a proof would require knowledge about the specific representations of the types involved, probably these "the way math works" contributors to GCC will never get around to that, so it should never be optimized away. What kind of an 'optimization' breaks any C program that it's ever actually applied to, and which only makes sense for numbers that C doesn't have? -- Julian
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-02-22 21:55 -0800 |
| Message-ID | <7xtxbq74pv.fsf@ruckus.brouhaha.com> |
| In reply to | #28703 |
Julian Fondren <julian.fondren@gmail.com> writes: > x>x+1 can be false for all C integers: eventually you run out of > bit for x+1. Not sure what you mean by this: x>x+1 is false for all mathematical integers, and wraparound behavior of overflowed machine integers is a frequent source of bugs in real-world C programs. Safe treatment involves trapping the overflow, not wrapping around. > It will also be false for all C floats: eventually you run out of, > well, bits again, and have floats where '1' is too infinitesimal That's is kind of different: there's an entire branch of mathematics called numerical analysis, which deals with the weird behaviors of machine floats and how they are different from the mathematical reals. Any serious numerical program takes these issues into account. By contrast, C programs using ints usually treat the ints as if they were mathematical integers, and don't handle overflow. > So this test should only ever be optimized away when you can prove > that x will only ever have values for which the result of the test > is always true (or false). Yes, the idea is that you have such a proof, even if the proof is informal reasoning that's not inferrable from the program text. It's just like writing "a[i]" implies that you have reasoned (proved) for yourself that the subscript is within range. Safer languages than C will check the subscript, but C will throw you under the bus if you got it wrong. If you chose C in the first place, that is presumably the behavior that you wanted. We now know that int overflow is another way to get thrown under the bus, whether by undefined behavior or by wrapping around. Another comparable situation: imagine a Forth like the GA144's where the data stack is a circular array, so it wraps around instead of underflowing if you try to pop too much stuff. That is deterministic and you can write programs that somehow make use of the behavior. But in much more likelihood, underflowing the stack is a bug and the wraparound stack implementation will still send your program into the weeds. The safe but slow behavior of trapping underflow, and the optimized behavior of assuming the absence of underflow once the programmer asserts that the code is debugged, both make more sense than the wraparound stack. Better still of course would be a zero-overhead hardware trap, for stack underflow and for int overflow. > What kind of an 'optimization' breaks any C program that it's ever > actually applied to, We see from Regehr et al's IOC tool that those programs are broken even without the optimization. Perhaps compiling with optimization off should always enable trapv. Running a full system like that would find a lot of bugs in a hurry.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2014-02-23 00:47 -0800 |
| Message-ID | <f782fe71-abc9-4e35-bb6f-daf89b7521be@googlegroups.com> |
| In reply to | #28705 |
On Saturday, February 22, 2014 11:55:40 PM UTC-6, Paul Rubin wrote: > Any serious numerical program takes these issues into account. By > contrast, C programs using ints usually treat the ints as if they were > mathematical integers, and don't handle overflow. So in addition to "how math works", we have "what Paul Rubin thinks C programmers are thinking" and "you shouldn't ever have overflow anyway!" as justifications for 'optimizations' that only ever break programs. *Actually* break them, as in make them not do what they were written to do. "They're broken anyway" is how a kid would justify breaking something. "You didn't want that plate anyway." Proper responses to this kind of argumentation vary from spanking to swearing. C programs usually don't handle overflow and "treat ints as if they were mathematical integers" because the programmers don't care about what happens when they stop behaving like mathematical integers. This is how gets() even exists, and how Unix filters exist(ed) with line-length limitations of a few tens of bytes. The program works for the environment and circumstances it was built for and if someone breaks it that person is blamed rather than the program. C programs do not ignore overflow and "treat ints as if they were mathematical integers" because C programmers ever think that ints are mathematical integers. Yeah, this is "what Julian Fondren thinks", but we're past argumentation. Leave GCC to people who don't break programs or have bloody stupid ideas about what its users are thinking and go work on GHC instead. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-02-23 01:45 -0800 |
| Message-ID | <7xbnxyupqu.fsf@ruckus.brouhaha.com> |
| In reply to | #28706 |
Julian Fondren <julian.fondren@gmail.com> writes: > So in addition to "how math works", we have "what Paul Rubin thinks > C programmers are thinking" and "you shouldn't ever have overflow > anyway!" as justifications for 'optimizations' that only ever break > programs. *Actually* break them, as in make them not do what they > were written to do. Do you ever look at CERT notices? Integer wraparound errors happen all the time even without that optimization. The programs are broken, they don't do what they are intended to do, they have remote exploits galore. It does look to me from the IOC paper[1] that a bunch of the errors reported by that tool aren't from wraparound, but some of them are. As for what C programmers are thinking or what they want the language to do: there is already a document codifying all that, namely the standard. It seems to me that the compiler writers interpret it as reflecting a consensus of what users want. If the true consensus is actually something different, then the document that's in error is the standard, so that's the place to apply a fix. > This is how gets() even exists, and how Unix filters exist(ed) with > line-length limitations of a few tens of bytes. The program works > for the environment and circumstances it was built for and if > someone breaks it that person is blamed rather than the program. I'm having a hard time seeing how to turn that into a prescription for compilers, but in any case it doesn't speak well of those programs if they were used for more than throwaway purposes. These days, throwaway programs are usually written in scripting languages without such limits. > Leave GCC to people who don't break programs I haven't been involved with GCC since the 20th century, and I rarely write C code these days. C is an unsafe language because that's what C programmers apparently want. For most code I touch, I prefer languages that use bignums by default, so overflow issues generally don't apply. But this is usually application code rather than low level systems stuff. > and go work on GHC instead. GHC has a similar problem (the Int type wraps around). ML gets it right, from what I understand. ======== [1] http://www.cs.utah.edu/~regehr/papers/overflow12.pdf
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-20 17:07 +0000 |
| Message-ID | <2014Feb20.180722@mips.complang.tuwien.ac.at> |
| In reply to | #28537 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> |Optimization-unstable code (unstable code for short) is an emerging
>> |class of software bugs
>>
>> Where does it emerge from? It emerges from the fashion of some
>> compiler writers (especially in the C world) to turn their compilers
>> into miscompilers.
>
>The C standard has two classes of unspecified behavior: "implementation
>dependent" where the compiler writer gets to choose what semantics they
>want, but then they have to stick to it consistently; and "undefined"
>where consistency is not required. I think you're saying that various
>program constructs should be treated as as implementation dependent
>(i.e. consistently) even when the standards committee chose to allow
>inconsistency. You may be right, but the problem would seem to be with
>the C language (as defined by the standard), not with implementations
>doing what the standard says.
The C standard does not require C compilers to miscompile.
GCC used to compile and optimize fine, and it complied with the C
standard; recent versions miscompile. That's a choice the GCC
maintainers made, so they are to blame, not the C standard. Maybe
they would have made better choices if the C standard was better, but
it was still their choice and therefore their responsibility.
As for "implementation-defined" vs. "undefined" behaviour, I don't
care much about how the C standard labels the features it does not
standardize.
>From http://blog.regehr.org/archives/970 :
>
> Compilers are getting smarter all the time, causing code that
> previously worked to break. A sufficiently advanced compiler is
> indistinguishable from an adversary.
>
>I would think robust code should be written to withstand adversarial
>compilation.
I think that robust compilers should be supportive, not adverserial,
at least not by default. Or, if the compiler really is intended to be
an adversary by default, it should have a -supportive option.
Writing code that is robust against adversarial compilers may be an
attractive puzzle-solving exercise, like writing programs in esoteric
languages like Brainfuck, but for productive programming it's a waste
of time. It's much better to choose a programming language and
compiler that are supportive instead of adversarial.
The problem of course is that C compilers started out as supporters
(otherwise C would have lost against the competition), and now that
they have a captive market, they are turning into adversaries, little
by little. I guess this will eventually lead to projects switching
away from C, and new projects avoiding C, but it will take a long
time, and it's a totally unnecessary waste of effort.
Of course, there is now a market opportunity for a supportive C
compiler. If the option is to find and fix whatever undefined
behaviours caused gcc or llvm to miscompile your program, and then do
it again in the next compiler version, or to just drop in the
supportive C compiler and have your program work, people will switch
to the supportive C compiler. The main competition is the established
compilers without optimization (but there is some miscompilation even
there).
> http://blog.regehr.org/archives/761
That's a good one. I have claimed quite some time ago that there are
no practical C-standard-complying programs around, but I had no
empirical data. But given that even in the center of C standards
bigotry, in GCC and LLVM, my claim holds true, it's probably true for
almost all practical C programs.
|IOC tells us that these compilers execute undefined behaviors even
|when compiling an empty C or C++ program with optimizations turned
|off.
- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-02-20 16:03 -0800 |
| Message-ID | <7xa9dls56m.fsf@ruckus.brouhaha.com> |
| In reply to | #28614 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > GCC used to compile and optimize fine, and it complied with the C > standard; recent versions miscompile. Miscompile. You keep using that word. I don't think it means what you think it means. > That's a choice the GCC maintainers made, so they are to blame, not > the C standard. I think it is in the spirit of C as it's been treated since the beginning of the standardization process: the programmers who drove the standardization seemed to want corrext code to run as fast as possible, and in pursuit of that goal, they chose to allow compilers to treat buggy code in crazy and unpredictable ways. OOB array access causing stuff like remote execution exploits is a now-well-understood example that C programmers understand is part of what you deal with if you choose to program in C. These days, more speedups for correct code have been found, that also send buggy code into the weeds. You seem to want more predictable treatment of buggy code, at the expense of slowing down correct code. That's a reasonable thing to desire but it's in conflict with the goals pursued by the standardizers. It's understandable that the compiler writers did what the standardizers wanted. > Maybe they would have made better choices if the C standard was better Well it wasn't a random choice that they could have made the other way with no cost. The other choice would have slowed correct code down by performing unnecessary checks. The standards process was geared towards maximizing the speed of correct code, and that's the ideology that you're opposing. I don't think that ideology is particularly driven by compiler writers. It was (I believe) originally driven by supercomputer users, and the standardizers and compiler writers gave them what they wanted. So I still see your complaint as better directed towards either the standardizers (who listened too much to the supercomputer users) or to the supercomputer users (for wanting the wrong thing). > if the compiler really is intended to be an adversary by default, it > should have a -supportive option. The compiler should not be adversarial by default since that would slow the code down too much. But having an adversarial option could be a valuable testing tool. By adversarial I mean something like KCC, which generates explicit runtime checks for every possible undefined behavior, so your program crashes with an error message if it reaches such a state. Of course this type of adversary is in another sense actually supportive. > Writing code that is robust against adversarial compilers may be an > attractive puzzle-solving exercise... It's much better to choose a > programming language and compiler that are supportive instead of > adversarial. Probably true most of the time, but you won't get the fastest possible code if you do that. The C users who drove standardization consciously chose to pursue fast code at the expense of "supportiveness". In retrospect, we can see that this has caused a huge mess, but a lot of ego-oriented programmers in the 1990's thought they were too smart to make the errors that their code is actually riddled with. We hear similar things from Forthers in statements like "Forth is an amplifier". Moving large-scale programming away from C is indeed a good response. It may be less of a problem in Forth, since Forth programs are usually not large, and Forth compilers are less aggressive. > C compilers ... are turning into adversaries, little by little. I > guess this will eventually lead to projects switching away from C, and > new projects avoiding C, but it will take a long time, and it's a > totally unnecessary waste of effort. Nah, C has been a dangerous and generally terrible language (except for some niche purposes) from the beginning. New projects generally do avoid C. I remember having trouble thinking of any big, widely used C programs other than Git that started development in the current century. > If the option is to ... just drop in the supportive C compiler and > have your program work, people will switch to the supportive C > compiler. Aren't their some flags like -fwrapv that make existing compilers "supportive"? What you really seem to want is a dialect of C where there is no undefined behavior, or at least there is a lot less of it. I think that is a great idea, but it means specifying everything, not relying on handwaving terms like "supportive". It was before my time but I think this argument already happened 50 years ago, when Algol-60 specified everything much more precisely than its predecessors like Fortran did. That well-definedness was considered a big win, so maybe we could view C as having repeated the mistakes of early Fortran. > I have claimed quite some time ago that there are no practical > C-standard-complying programs around. Probably true. I like the quote (I don't remember who said it) "the last good thing written in C was Schubert's Ninth Symphony". There was a huge thread in sci.crypt several years ago, where a guy from the C standards committee kept claiming that a proper design and review process should result in C code with no bugs, and claimed to have developed large systems that way, to the skepticism of sci.crypt regulars who were used to endless C exploits. It would have been interesting to run some of that guy's code through something like KCC or even a fuzz tester, but naturally he was unwilling to release any code for such scrutiny.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-21 04:11 -0600 |
| Message-ID | <L--dnQD4eLjwu5rOnZ2dnUVZ_sudnZ2d@supernews.com> |
| In reply to | #28631 |
Paul Rubin <no.email@nospam.invalid> wrote: > >> If the option is to ... just drop in the supportive C compiler and >> have your program work, people will switch to the supportive C >> compiler. > > Aren't their some flags like -fwrapv that make existing compilers > "supportive"? What you really seem to want is a dialect of C where > there is no undefined behavior, or at least there is a lot less of it. > > I think that is a great idea, but it means specifying everything, not > relying on handwaving terms like "supportive". It was before my time > but I think this argument already happened 50 years ago, when Algol-60 > specified everything much more precisely than its predecessors like > Fortran did. That well-definedness was considered a big win, Considered a big win by whom? Algol 60 lost out almost entirely to Fortran, perhaps in no small part due to Fortran generating much faster code. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-02-21 10:59 +0000 |
| Message-ID | <5307318a$0$25286$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #28642 |
In article <L--dnQD4eLjwu5rOnZ2dnUVZ_sudnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Paul Rubin <no.email@nospam.invalid> wrote: >> >>> If the option is to ... just drop in the supportive C compiler and >>> have your program work, people will switch to the supportive C >>> compiler. >> >> Aren't their some flags like -fwrapv that make existing compilers >> "supportive"? What you really seem to want is a dialect of C where >> there is no undefined behavior, or at least there is a lot less of it. >> >> I think that is a great idea, but it means specifying everything, not >> relying on handwaving terms like "supportive". It was before my time >> but I think this argument already happened 50 years ago, when Algol-60 >> specified everything much more precisely than its predecessors like >> Fortran did. That well-definedness was considered a big win, > >Considered a big win by whom? Algol 60 lost out almost entirely to >Fortran, perhaps in no small part due to Fortran generating much >faster code. Algol60 is still with us in the guise of Ada and Pascal. The difference between FORTRAN IV and present-day FORTRAN are at least as big as those between Algol60 and Ada. > >Andrew. -- 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]
Page 13 of 21 — ← Prev page 1 … 11 12 [13] 14 15 … 21 Next page →
Back to top | Article view | comp.lang.forth
csiph-web