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 9 of 21 — ← Prev page 1 … 7 8 [9] 10 11 … 21 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-24 17:30 +0000 |
| Message-ID | <2014Feb24.183059@mips.complang.tuwien.ac.at> |
| In reply to | #28727 |
Paul Rubin <no.email@nospam.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> writes:
>> C was designed to write operating systems and similar
>> close-to-the-machine stuff. You can't compare apples and bananas like
>> this.
>
>I think we heard similar things when C compilers started optimizing
>
> x = *z;
> y = *z;
>
>to copy x to y with a register-register move instead of dereferencing z
>twice ("it's a low level language and z might point to a device
>register"). The volatile keyword was added to deal with that
>possibility but in the normal case the optimization is fine.
Yes, most programs were actually not affected by this. And that's the
difference to the situation we are discussing. Even GCC and LLVM
exercise undefined behaviour, even when compiling an empty program
with optimization turned off. 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.
>> In Forth, we have a lot of "an ambiguous condition exists if bla".
>> All quality implementations try to map these ambiguous conditions to
>> deterministic behavior, usually throwing some exception.
Hmm, well, in some cases. There are various cases such as some of
those exercised by Hans Bezemer's crash suite, where the outcome can
really be anything (e.g., when you write over some memory). But the
difference from what the recent crop of C miscompilers is doing is
that the Forth compilers do not assume that such things can never
happen, and "optimize" based on this assumption.
>Is that the right thing for an optimizing compiler? If the programmer
>says SWAP then they are asserting the stack has at least two items. If
>there aren't, the code is buggy no matter what the compiler does.
>Should the compiler slow the code down by checking anyway, if the
>optimization level is cranked all the way up? I wouldn't have thought
>that was in the Forth spirit.
Forth programmers are used to Forth systems not catching that in every
case. But what these Forth systems do is work as if the stack was a
little deeper than .S shows. They do not delete an IF...THEN based on
the assumption that the stack is at least two items deep, nor do they
"optimize" a finite loop into an infinite loop based on that.
And actually there is at least one Forth system that actually catches
that (given the appropriate OS support): gforth; it costs a little
time (stack items in registers are disabled), and there's gforth-fast,
where the stack is 8 items deeper than what .S or DEPTH shows, and
that is faster (for various reasons, only a small part of which comes
from stack caching). The user has the choice between the nice version
and the fast version.
But gforth and gforth-fast are not very sophisticated. What happens
if we get more sophisticated? For the most part, Forth code actually
has a statically determinable stack effect, and a sophisticated
compiler can compute that. So if we want to check for stack depth, a
sophisticated compiler would have to insert the checks at relatively
few places, so the speed difference between the checking and the
non-checking version would be small.
>Look at all these crashes, and these are
>in interpreters:
>
> http://thebeez.home.xs4all.nl/4tH/crash.htm
And?
>
>> Not for an OS, where the caller of this code is in userland, and
>> therefore potentially malicious.
>
>All the more reason to write the code carefully.
Sure, but not a reason to miscompile it.
>(Though since when
>does userland pass pointers into the kernel).
Lots of system functions pass pointers into the kernel, e.g., read(2).
>> The implementer is in charge for the tradeoffs. Does he want a
>> minimal system on a small controller, or does he want a desktop system
>> which supports million lines of code and mission critical
>> applications?
>
>Unfortunately it's the second user (or one with a megawatt-burning
>server farm) that wants the optimizations cranked to 11.
Really? (whatever "cranked to 11" means).
Anyway, if they really want their programs, which most likely exercise
"undefined behaviour", "optimized" based one the assumption that the
program does not exercise "undefined behaviour", it's fine with me if
they do it, e.g., by using an appropriate option; most likely they
would turn that option off for good once they see that their program
no longer works. But compiling everything with that assumption is a
really bad idea. And the typical reaction at the moment is to disable
optimization completely.
>>> Is an imprecise exception so bad?
Yes.
>> It's the typical benchmark thing: Implementer check what's used frequently,
>> and implement the infrequent stuff less aggressive.
>
>But we keep hearing that CPU designers now have more transistors than
>they know how to use.
These CPU designers probably live in the same world as the users who
"want optimizations cranked to 11".
Meanwhile, in the real world, I have read enough accounts of CPU and
GPU designers who planned to have more units, features, cache, etc.,
and who had to reduce their grandiose plans because otherwise area and
cost would have been too high.
> These checks are important for reliable code
In code that was written for wraparound behaviour, they are an
obstruction to reliable code. But at least they do it out in the
open, not silently miscompiling code.
>>> Was wrapv-by-default actually documented in the GCC manual? Did anyone
>>> depend on it?
>>
>> Yes. A lot of code depends on it,
>
>Do you mean yes it was documented in the manual? Or just that people
>relied on it? The latter is easy to believe but the former is a little
>bit surprising.
There was no need to document it (and, as we learned from the "long
long" experience, it does not help if the manual documents it). And
yes, people just rely on it.
>>> trapv would be better than wrapv
>> No. People have thought in wrapv semantics for decades; everyone with an
>> assembler background knows that by heart.
>
>Trapv would flush out those dependencies pretty quickly during any
>reasonable testing, I'd hope. Then the code could be patched.
That's idiotic. This code needs wraparound for good reason. Trying
to replace it with code that does not wrap around will only lead to
code that's bigger, slower and buggier than the current code. E.g.,
try defining WITHIN without wraparound.
- 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-24 14:38 -0800 |
| Message-ID | <7x38j8rva9.fsf@ruckus.brouhaha.com> |
| In reply to | #28751 |
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.
> 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.
> Forth systems ... do not delete an IF...THEN based on the assumption
> that the stack is at least two items deep...
Are you really saying that if the programmer (maybe through some
metaprogramming gyration) writes
SWAP DEPTH IF thing1 ELSE thing2 THEN
then the compiler is "miscompiling" if it infers from the SWAP that the
depth is positive, and eliminates the IF and the dead branch? That just
sounds to me like the optimizer is doing its job. If the SWAP is
correct then the elimination is perfectly sound, and if the SWAP is
wrong then the code is buggy no matter what the compiler does.
>> http://thebeez.home.xs4all.nl/4tH/crash.htm
> And?
That url shows there is plenty of nondeterministic behavior in Forth
systems.
> Lots of system functions pass pointers into the kernel, e.g., read(2).
Those are userspace pointers that have to be checked before
dereferencing.
>>Unfortunately it's the second user (or one with a megawatt-burning
>>server farm) that wants the optimizations cranked to 11.
> Really? (whatever "cranked to 11" means).
It's an idiom that means increasing something to the maximum. You set
it at the highest level on a scale of 1 to 10, and then turn it up one
more past that. I think it came from here:
http://www.youtube.com/watch?v=4xgx4k83zzc
(famous 49 second clip from parody movie about a rock band with
customized amplifiers). You can actually buy controls like that as a
result:
https://www.sparkfun.com/products/11950
which suggests further opportunities:
http://xkcd.com/670/
> if they really want their programs... "optimized" based one the
> assumption that the program does not exercise "undefined behaviour",
> it's fine with me if they do it, e.g., by using an appropriate option;
My observation based on long discussions with one of the C standards
guys on sci.crypt is that C programmers tend to be egotistical enough
that they WILL use that option. Are you sure you would resist using it?
> most likely they would turn that option off for good once they see
> that their program no longer works.
Well, the broken code still passes tests, so they think everything is
fine. It's only recently that we've gotten tools that detect undefined
behavior more aggressively, and endless bugs (some in very old code) are
surfacing because of that.
> There was no need to document it [wrapv]
In that case the standards committee stuffed up by not standardizing it.
Even in systems code, though, the amount of code that uses intentional
wraparounds is tiny. Almost all ints represent (maybe negative)
quantities, and wrapping around is a bug, like an OOB pointer.
> That's idiotic. This code needs wraparound for good reason. Trying
> to replace it with code that does not wrap around will only lead to
> code that's bigger, slower and buggier than the current code.
The idea isn't to avoid the wraparound, but rather, if you want a
wraparound, to write code that invokes the wraparound behavior
explicitly instead of relying on an undocumented assumption. In C this
is done with unsigned ints, though as mentioned I think it would be
better to introduce a new "wraparound" modifier, similar to the way
"volatile" was introduced.
> E.g., try defining WITHIN without wraparound.
Looking at
http://www.taygeta.com/forth/dpans6.htm#6.2.2440
http://www.taygeta.com/forth/dpansa6.htm#A.6.2.2440
WITHIN is so confusing that I'm terrified to use it or try to implement
with or without wraparound. Some examples would have been helpful. But
again, to implement that in C with wraparound, use unsigned ints.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-26 12:59 +0000 |
| Message-ID | <2014Feb26.135958@mips.complang.tuwien.ac.at> |
| In reply to | #28754 |
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
of the compiler: Do they want to implement the language that the
programs are written in, and that earlier versions of the compiler
compiled (and that the compiler with optimization turned off
compiles), or do they want to compile a language without code base.
And since it is their choice, it's also their responsibility, and I
blame them when they make the wrong choice.
Concerning the "Forther attitude": That's from the same world as the
"CPU designers now have more transistors than they know how to use".
I am a Forther and I don't consider a C program buggy just because
it's not standard-conforming.
That particular attitude seems to be more popular among C compiler
writers. That's understandable, because it is convenient: 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 to the
compiler writer (and probably also produces good answer-time
statistics)! Do that regularly, and the work reduces even more
because people stop reporting bugs (I have).
>> Forth systems ... do not delete an IF...THEN based on the assumption
>> that the stack is at least two items deep...
>
>Are you really saying that if the programmer (maybe through some
>metaprogramming gyration) writes
>
> SWAP DEPTH IF thing1 ELSE thing2 THEN
>
>then the compiler is "miscompiling" if it infers from the SWAP that the
>depth is positive, and eliminates the IF and the dead branch?
Yes.
> That just
>sounds to me like the optimizer is doing its job. If the SWAP is
>correct then the elimination is perfectly sound, and if the SWAP is
>wrong then the code is buggy no matter what the compiler does.
The code may be non-standard, but that does not make it buggy. If
someone writes such code, they presumably have an intent, and the
optimizer must preserve that. That is its job. Miscompiling is the
job of a miscompiler, not an optimizer.
If the compiler prevents the DEPTH IF from ever being reached with
depth 0, then it can optimize the ELSE part away, otherwise not.
>>> http://thebeez.home.xs4all.nl/4tH/crash.htm
>> And?
>
>That url shows there is plenty of nondeterministic behavior in Forth
>systems.
And?
>> Lots of system functions pass pointers into the kernel, e.g., read(2).
>
>Those are userspace pointers that have to be checked before
>dereferencing.
And?
>>>Unfortunately it's the second user (or one with a megawatt-burning
>>>server farm) that wants the optimizations cranked to 11.
>> Really? (whatever "cranked to 11" means).
...
>> if they really want their programs... "optimized" based one the
>> assumption that the program does not exercise "undefined behaviour",
>> it's fine with me if they do it, e.g., by using an appropriate option;
>
>My observation based on long discussions with one of the C standards
>guys on sci.crypt is that C programmers tend to be egotistical enough
>that they WILL use that option. Are you sure you would resist using it?
Knowing what I know now about "undefined behaviour" and what
optimizations are based on it, I would not use it in a production
setting, although I might try it out now and then to have some fodder
for discussions such as this.
>> most likely they would turn that option off for good once they see
>> that their program no longer works.
>
>Well, the broken code still passes tests, so they think everything is
>fine. It's only recently that we've gotten tools that detect undefined
>behavior more aggressively, and endless bugs (some in very old code) are
>surfacing because of that.
The code works, and yet you say it's "broken" and contains "endless
bugs". Sure, if you want to miscompile, you first vilify the code you
will miscompile, in order to justify your miscompilation.
>> There was no need to document it [wrapv]
>
>In that case the standards committee stuffed up by not standardizing it.
Well, they wanted to support 2s-complement, 1's-complement, and
sign-magnitude representations; one may debate whether that was wise,
but once they took this decision, it's no wonder that they did not
standardize the wraparound behaviour. However, when I write my
program for 2s-complement machines, and compile it with a compiler
that targets only 2s-complement machines, I expect 2s-complement
wraparound behaviour.
>Even in systems code, though, the amount of code that uses intentional
>wraparounds is tiny. Almost all ints represent (maybe negative)
>quantities, and wrapping around is a bug, like an OOB pointer.
Proof?
>> That's idiotic. This code needs wraparound for good reason. Trying
>> to replace it with code that does not wrap around will only lead to
>> code that's bigger, slower and buggier than the current code.
>
>The idea isn't to avoid the wraparound, but rather, if you want a
>wraparound, to write code that invokes the wraparound behavior
>explicitly instead of relying on an undocumented assumption. In C this
>is done with unsigned ints,
Yes, somebody suggested code for the "if (x<x-1)" case that uses casts
to do an unsigned subtraction and a signed comparison, and he claimed
that his code is standard. Unfortunately at least one GCC version
miscompiles this code.
>> E.g., try defining WITHIN without wraparound.
>
>Looking at
>
> http://www.taygeta.com/forth/dpans6.htm#6.2.2440
> http://www.taygeta.com/forth/dpansa6.htm#A.6.2.2440
>
>WITHIN is so confusing that I'm terrified to use it or try to implement
>with or without wraparound. Some examples would have been helpful. But
>again, to implement that in C with wraparound, use unsigned ints.
Ok, the WITHIN implementation uses an unsigned comparison, so we might
get lucky, and not run into the same issue as the "if (x<x-1)" case.
But in any case the code that uses wraparound will be smaller and
faster than any variant that avoids it.
As for your cop-out: I have no problem understanding what it does and
implementing it. Why do you? And if you have a problem with that,
why do you think you can make any judgement about code that uses
wraparound?
- 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-26 20:12 -0800 |
| Message-ID | <7xeh2pjisl.fsf@ruckus.brouhaha.com> |
| In reply to | #28786 |
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? 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. They simply expected that their ints were integers,
that would stay within the range covered by the word size.
> 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. It only happened to work by relying on
undocumented compiler behavior that existed at the time.
> 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. 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.
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. The "well-defined" approach is called "Ada".
> 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.
>> 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? 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.
> 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? 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--it should raise a runtime
error if the compiler is generating safe code. What kind of programmer
writes code that intentionally SWAPs at depth 0 and expects the code to
keep running, when it would crash right away if the implementation is
checking for underflow?
> Knowing what I know now about "undefined behaviour" and what
> optimizations are based on it, I would not use it in a production
> setting,
Probably wise, though you're still vulnerable to (e.g.) subscript
errors, that always have been unsafe/undefined, and tons of other
things. The problem is with C itself, not with a particular
optimization.
>>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. It passed its tests because the tests
were insufficient to exercise the bugs, and the language wasn't
conducive to enough static checks to prevent the errors from being
spotted before even attempting to run the tests.
These days the very existence of null pointers should be seen as a
language wart. Tony Hoare wrote in 2009:
I call it my billion-dollar mistake. It was the invention of the
null reference in 1965. At that time, I was designing the first
comprehensive type system for references in an object oriented
language (ALGOL W). My goal was to ensure that all use of references
should be absolutely safe, with checking performed automatically by
the compiler. But I couldn't resist the temptation to put in a null
reference, simply because it was so easy to implement. This has led
to innumerable errors, vulnerabilities, and system crashes, which
have probably caused a billion dollars of pain and damage in the
last forty years. ( http://en.wikipedia.org/wiki/Null_pointer )
C++ necessarily still has pointers, but a lot of the time they can be
avoided by using references instead, which can never be null.
>>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
(AIR) http://resources.sei.cmu.edu/asset_files/TechnicalNote/2009_004_001_15074.pdf
In the IOC paper they ran a modified compiler on a lot of C code to trap
undefined behavior. Most worked ok (ints stayed in range); the caught
errors were a
> 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?
> and he claimed that his code is standard.
Well is it?
> 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), I'd need more specifics to know if the compiler actually made a
mistake.
>>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. There was a reference Forth implementation (useful I
guess) that I suppose could have been compared with a C implementation
but no indication of where the boundary conditions were. On the theory
that the ANS verbiage all actually meant something, I saw it as too
complicated to code reliably without a significant amount of study and
testing.
Since then I found more concise descriptions in the MPE Forth manual and
the Gforth manual, so now I think I understand it. I'd have said the
function has the effect
( n lower upper -- flag )
where the input parameters all must have the same integer type (that can
be signed or unsigned), and the result is true if
lower <= n < upper
using the ordering semantics appropriate for the parameter type. The
ANS description is so complicated BECAUSE it's worrying about stuff like
the bit representation of the numbers, and it's trying to specify what
amounts to a polymorphic function in assembly code using a single
instruction sequence. IMHO the most direct way to express the
function's intention is to spell out the polymorphism directly, if the
language supports it. E.g. with C++ generics:
template <typename T>
bool within(T n, T lower, T upper) {
return (lower <= n && n < upper);
}
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. The programmer need not be concerned with 1's complement, 2's
complement, wraparound, casts, or any other such low level issues.
> 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.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-27 04:54 -0600 |
| Message-ID | <CuWdnUwFeePPhJLOnZ2dnUVZ_tWdnZ2d@supernews.com> |
| In reply to | #28793 |
Paul Rubin <no.email@nospam.invalid> wrote:
> 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?
"I's obvious." :-)
> These days the very existence of null pointers should be seen as a
> language wart. Tony Hoare wrote in 2009:
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. AFAIK the only way to get rid of null pointers is
to get rid of pointers and have abstractions for lists ... but you
have to write the library to do that in some language.
>> 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?
>
>> and he claimed that his code is standard.
>
> Well is it?
Not exactly: it's implementation-defined.
> Since then I found more concise descriptions in the MPE Forth manual
> and the Gforth manual, so now I think I understand it. I'd have
> said the function has the effect
>
> ( n lower upper -- flag )
>
> where the input parameters all must have the same integer type (that can
> be signed or unsigned), and the result is true if
>
> lower <= n < upper
That's not exactly it because WITHIN is explicitly circular, so it
requires unsigned comparisons. The C equivalent is
bool within(unsigned int n, unsigned int lower, unsigned int upper) {
return n-lower < upper-lower;
}
Consider 32-bit
within(2147483647, 10, -10);
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2014-02-27 12:56 +0100 |
| Message-ID | <85ha7kg45j.fsf@junk.nocrew.org> |
| In reply to | #28796 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> These days the very existence of null pointers should be seen as a >> language wart. > Umm, how would you represent the end of a linked list? By pointing to a dedicated end-of-list object. E.g. in Lisp, lists are terminated with NIL (which in some implementations cleverly doubles as both a cons cell and a symbol).
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-27 06:30 -0600 |
| Message-ID | <4P6dnWTTv7tKspLOnZ2dnUVZ_sGdnZ2d@supernews.com> |
| In reply to | #28797 |
Lars Brinkhoff <lars.spam@nocrew.org> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> These days the very existence of null pointers should be seen as a >>> language wart. >> >> Umm, how would you represent the end of a linked list? > > By pointing to a dedicated end-of-list object. E.g. in Lisp, lists > are terminated with NIL (which in some implementations cleverly > doubles as both a cons cell and a symbol). How is that semantically different from a null pointer? Surely NIL is a null pointer, however it is represented. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-02-27 05:29 -0800 |
| Message-ID | <7xlhwwela4.fsf@ruckus.brouhaha.com> |
| In reply to | #28798 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > How is that semantically different from a null pointer? Surely NIL is > a null pointer, however it is represented. Each list node is a discriminated union (member of a sum type) that's either NIL, or a pair consisting of a value and a pointer to the next node. So in the case where it's NIL, that's not a pointer. With a static type system, if the list has a type like List<A>, the NIL for that list would also have that type, and any attempt to dereference it would be caught at compile time.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-02-27 15:48 +0000 |
| Message-ID | <530f5e60$0$25041$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #28800 |
In article <7xlhwwela4.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> How is that semantically different from a null pointer? Surely NIL is >> a null pointer, however it is represented. > >Each list node is a discriminated union (member of a sum type) that's >either NIL, or a pair consisting of a value and a pointer to the next >node. So in the case where it's NIL, that's not a pointer. With a >static type system, if the list has a type like List<A>, the NIL for >that list would also have that type, and any attempt to dereference it >would be caught at compile time. So instead of a runtime system that gives an error: "attempt to derefence a nil pointer" the user is obliged to put some code in to give that error himself. Big advantage -;) Really, on paper and properly implemented, the null pointer in C is a fairly decent nil value. Properly implemented in my book means that an access through the pointer must be trapped. I'm learning LISP now. All this code where something recursive starts with (null? .... ) is supposedly not Politically Correct? Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-02-27 08:13 -0800 |
| Message-ID | <7xy50wmt43.fsf@ruckus.brouhaha.com> |
| In reply to | #28803 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes: > So instead of a runtime system that gives an error: > "attempt to derefence a nil pointer" the user is obliged to put > some code in to give that error himself. Big advantage -;) No, there's no such obligation, the user doesn't deal with that. > I'm learning LISP now. All this code where something recursive > starts with > (null? .... ) > is supposedly not Politically Correct? That is a comparison (against NIL), not a dereference. If you leave it out, you get a runtime error if you use something like CAR or CDR, since they have to check that their arg is a cons node.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-02-27 16:23 -0500 |
| Message-ID | <op.xbylp0b95zc71u@localhost> |
| In reply to | #28803 |
On Thu, 27 Feb 2014 10:48:48 -0500, Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <7xlhwwela4.fsf@ruckus.brouhaha.com>, > Paul Rubin <no.email@nospam.invalid> wrote: >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> How is that semantically different from a null pointer? Surely NIL is >>> a null pointer, however it is represented. >> >> Each list node is a discriminated union (member of a sum type) that's >> either NIL, or a pair consisting of a value and a pointer to the next >> node. So in the case where it's NIL, that's not a pointer. With a >> static type system, if the list has a type like List<A>, the NIL for >> that list would also have that type, and any attempt to dereference it >> would be caught at compile time. > > So instead of a runtime system that gives an error: > "attempt to derefence a nil pointer" the user is obliged to put > some code in to give that error himself. Big advantage -;) > > Really, on paper and properly implemented, the null pointer in C is > a fairly decent nil value. Properly implemented in my book means > that an access through the pointer must be trapped. > AFAIK, there's no requirement in C to prevent reading or writing to the same address as the NULL pointer. AFAIK, there is no requirement to trap accesses to it's location either. The requirement is that no C objects must be located *at* the NULL pointer address. The NULL is for comparing a pointer in C against NULL to determine if the pointer was set or not. I know for a fact that many C compilers implement NULL as zero and also allow reading and writing to address zero via a C pointer. The NULL pointer's address is zero for many C implementations, but can be any location as long as no other C objects are located at that address, i.e., NULL can be non-zero. One of the original authors of the ANSI C specification posted an example of how to do that many years ago. C compilers which allow writing to the same address as NULL is usually because the NULL pointer value is zero *and* there is memory mapped device or data space located there that must be accessable. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-02-28 11:21 +0000 |
| Message-ID | <53107156$0$25040$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #28820 |
In article <op.xbylp0b95zc71u@localhost>, Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote: >On Thu, 27 Feb 2014 10:48:48 -0500, Albert van der Horst ><albert@spenarnc.xs4all.nl> wrote: >> In article <7xlhwwela4.fsf@ruckus.brouhaha.com>, >> Paul Rubin <no.email@nospam.invalid> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >>>> How is that semantically different from a null pointer? Surely NIL is >>>> a null pointer, however it is represented. >>> >>> Each list node is a discriminated union (member of a sum type) that's >>> either NIL, or a pair consisting of a value and a pointer to the next >>> node. So in the case where it's NIL, that's not a pointer. With a >>> static type system, if the list has a type like List<A>, the NIL for >>> that list would also have that type, and any attempt to dereference it >>> would be caught at compile time. >> >> So instead of a runtime system that gives an error: >> "attempt to derefence a nil pointer" the user is obliged to put >> some code in to give that error himself. Big advantage -;) >> >> Really, on paper and properly implemented, the null pointer in C is >> a fairly decent nil value. Properly implemented in my book means >> that an access through the pointer must be trapped. >> > >AFAIK, there's no requirement in C to prevent reading or writing to the >same address as the NULL pointer. AFAIK, there is no requirement to trap >accesses to it's location either. The requirement is that no C objects >must be located *at* the NULL pointer address. The NULL is for comparing >a pointer in C against NULL to determine if the pointer was set or not. >I know for a fact that many C compilers implement NULL as zero and also >allow reading and writing to address zero via a C pointer. The NULL >pointer's address is zero for many C implementations, but can be any >location as long as no other C objects are located at that address, i.e., >NULL can be non-zero. One of the original authors of the ANSI C >specification posted an example of how to do that many years ago. C >compilers which allow writing to the same address as NULL is usually >because the NULL pointer value is zero *and* there is memory mapped >device or data space located there that must be accessable. You have not said that you disagree with me and consider that a proper, high quality implementation. > > >Rod Pemberton Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-02-28 16:20 -0500 |
| Message-ID | <op.xb0f742c5zc71u@localhost> |
| In reply to | #28829 |
On Fri, 28 Feb 2014 06:21:58 -0500, Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <op.xbylp0b95zc71u@localhost>, > Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote: >> On Thu, 27 Feb 2014 10:48:48 -0500, Albert van der Horst >> <albert@spenarnc.xs4all.nl> wrote: >>> In article <7xlhwwela4.fsf@ruckus.brouhaha.com>, >>> Paul Rubin <no.email@nospam.invalid> wrote: >>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>> How is that semantically different from a null pointer? Surely NIL >>>>> is a null pointer, however it is represented. >>>> >>>> Each list node is a discriminated union (member of a sum type) that's >>>> either NIL, or a pair consisting of a value and a pointer to the next >>>> node. So in the case where it's NIL, that's not a pointer. With a >>>> static type system, if the list has a type like List<A>, the NIL for >>>> that list would also have that type, and any attempt to dereference it >>>> would be caught at compile time. >>> >>> So instead of a runtime system that gives an error: >>> "attempt to derefence a nil pointer" the user is obliged to put >>> some code in to give that error himself. Big advantage -;) >>> >>> Really, on paper and properly implemented, the null pointer in C is >>> a fairly decent nil value. Properly implemented in my book means >>> that an access through the pointer must be trapped. >>> >> >> AFAIK, there's no requirement in C to prevent reading or writing to the >> same address as the NULL pointer. AFAIK, there is no requirement to >> trap accesses to it's location either. The requirement is that no C >> objects >> must be located *at* the NULL pointer address. The NULL is for >> comparing >> a pointer in C against NULL to determine if the pointer was set or not. >> [...] > > You have not said that you disagree with me and consider that a > proper, high quality implementation. > Why do you think that a high quality implementation of C needs to trap accesses through a NULL pointer? There are two things that trapping NULL accesses does: 1) prevent accidental usage of an uninitialized pointer 2) prohibit access to a region of memory #1 is generally regarded as a good thing. But, #2 is a serious problem. Most architectures need to access the area of memory where the NULL pointer points (i.e., commonly address zero). So, are you saying the advantages of #1 outweighs the necessity of #2? If the NULL pointer was set to a region where no memory exists or where the operating system prohibits access, then trapping NULL accesses wouldn't interfere with #2. In that case, it would be acceptable to trap. But, most versions of C aren't setup that way. Due to the way most versions of C are setup, I'd have to say it's generally undesirable to trap, but when properly implemented it would be beneficial. To trap accesses without large amounts of additional code, you'd need to be on an architecture which supports hardware paging of memory. I.e., it'd work on modern x86, but probably not on older mainframes or 8-bit micro's. So, you really need to specify the capabilities of the hardware as a constraint as to where a high quality implementation of C could be available. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-03-01 01:51 +0000 |
| Message-ID | <53113d1b$0$25040$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #28835 |
In article <op.xb0f742c5zc71u@localhost>, Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote: >On Fri, 28 Feb 2014 06:21:58 -0500, Albert van der Horst ><albert@spenarnc.xs4all.nl> wrote: >> In article <op.xbylp0b95zc71u@localhost>, >> Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote: >>> On Thu, 27 Feb 2014 10:48:48 -0500, Albert van der Horst >>> <albert@spenarnc.xs4all.nl> wrote: >>>> In article <7xlhwwela4.fsf@ruckus.brouhaha.com>, >>>> Paul Rubin <no.email@nospam.invalid> wrote: >>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >>>>>> How is that semantically different from a null pointer? Surely NIL >>>>>> is a null pointer, however it is represented. >>>>> >>>>> Each list node is a discriminated union (member of a sum type) that's >>>>> either NIL, or a pair consisting of a value and a pointer to the next >>>>> node. So in the case where it's NIL, that's not a pointer. With a >>>>> static type system, if the list has a type like List<A>, the NIL for >>>>> that list would also have that type, and any attempt to dereference it >>>>> would be caught at compile time. >>>> >>>> So instead of a runtime system that gives an error: >>>> "attempt to derefence a nil pointer" the user is obliged to put >>>> some code in to give that error himself. Big advantage -;) >>>> >>>> Really, on paper and properly implemented, the null pointer in C is >>>> a fairly decent nil value. Properly implemented in my book means >>>> that an access through the pointer must be trapped. >>>> >>> >>> AFAIK, there's no requirement in C to prevent reading or writing to the >>> same address as the NULL pointer. AFAIK, there is no requirement to >>> trap accesses to it's location either. The requirement is that no C >>> objects >>> must be located *at* the NULL pointer address. The NULL is for >>> comparing >>> a pointer in C against NULL to determine if the pointer was set or not. >>> [...] >> >> You have not said that you disagree with me and consider that a >> proper, high quality implementation. >> > >Why do you think that a high quality implementation of C needs >to trap accesses through a NULL pointer? > >There are two things that trapping NULL accesses does: >1) prevent accidental usage of an uninitialized pointer >2) prohibit access to a region of memory You are deluded. A proper implementation of c requires that the sentinel value that represents a NULL value doesnot point to an accessible region of memory. There are scores of possible values. E.g. on an early DEC Alpha every value that is not 8-aligned qualifies. That are 16140901064495857657 possibilities, if I'm not mistaken. > > >Rod Pemberton Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-02-28 23:36 -0500 |
| Message-ID | <op.xb00eqip5zc71u@localhost> |
| In reply to | #28837 |
On Fri, 28 Feb 2014 20:51:23 -0500, Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > You are deluded. A proper implementation of C requires that > the sentinel value that represents a NULL value does not > point to an accessible region of memory. > Earlier you used "proper, high quality implementation." It was clear in that context that it was your personal perspective. Is "proper" as used here still your personal definition of proper, or do you mean it's the C specification's definition of proper? ... I'm curious as to why you believe the "sentinel value that represents a NULL value" must not "point to accessible memory" when it's sufficient in C for NULL to simply not point to any valid C objects. *Why* must the memory be _inaccessible_? Clearly, that's not possible on most hardware, but I'll ignore that for discussion. Clearly, many C compilers do allow access there, but I'll ignore that for discussion too. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-03-01 12:45 +0000 |
| Message-ID | <5311d685$0$24923$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #28838 |
In article <op.xb00eqip5zc71u@localhost>, Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote: >On Fri, 28 Feb 2014 20:51:23 -0500, Albert van der Horst ><albert@spenarnc.xs4all.nl> wrote: > >> You are deluded. A proper implementation of C requires that >> the sentinel value that represents a NULL value does not >> point to an accessible region of memory. >> > >Earlier you used "proper, high quality implementation." It >was clear in that context that it was your personal perspective. >Is "proper" as used here still your personal definition of proper, >or do you mean it's the C specification's definition of proper? ... > >I'm curious as to why you believe the "sentinel value that >represents a NULL value" must not "point to accessible memory" >when it's sufficient in C for NULL to simply not point to any valid >C objects. *Why* must the memory be _inaccessible_? Clearly, that's >not possible on most hardware, but I'll ignore that for discussion. >Clearly, many C compilers do allow access there, but I'll ignore >that for discussion too. There are no objects in C. What? > > >Rod Pemberton -- 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 | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2014-03-01 13:59 +0100 |
| Message-ID | <85lhwuaxcy.fsf@junk.nocrew.org> |
| In reply to | #28842 |
Albert van der Horst wrote: > There are no objects in C. What? I only have the C standard document from 1999, but that version frequenctly uses the word "object". Chapter 3 has a definition: 3.14 object - region of data storage in the execution environment, the contents of which can represent values.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-03-01 13:03 +0000 |
| Message-ID | <5311da9b$0$24955$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #28843 |
In article <85lhwuaxcy.fsf@junk.nocrew.org>, Lars Brinkhoff <lars.spam@nocrew.org> wrote: >Albert van der Horst wrote: >> There are no objects in C. What? > >I only have the C standard document from 1999, but that version >frequenctly uses the word "object". Chapter 3 has a definition: > > 3.14 object - region of data storage in the execution environment, > the contents of which can represent values. I know that, accessible memory. But that was *my definition* that Rod objected about (pun intended). Sorry, I forgot the smiley. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-03-01 07:53 +0000 |
| Message-ID | <les3le$qpk$1@dont-email.me> |
| In reply to | #28837 |
on 01/03/2014 01:51:18, wrote: > In article <op.xb0f742c5zc71u@localhost>, > Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote: >>On Fri, 28 Feb 2014 06:21:58 -0500, Albert van der Horst >><albert@spenarnc.xs4all.nl> wrote: >>> In article <op.xbylp0b95zc71u@localhost>, >>> Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote: >>>> On Thu, 27 Feb 2014 10:48:48 -0500, Albert van der Horst >>>> <albert@spenarnc.xs4all.nl> wrote: >>>>> In article <7xlhwwela4.fsf@ruckus.brouhaha.com>, >>>>> Paul Rubin <no.email@nospam.invalid> wrote: >>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> >>>>>>> How is that semantically different from a null pointer? Surely NIL >>>>>>> is a null pointer, however it is represented. >>>>>> >>>>>> Each list node is a discriminated union (member of a sum type) that's >>>>>> either NIL, or a pair consisting of a value and a pointer to the next >>>>>> node. So in the case where it's NIL, that's not a pointer. With a >>>>>> static type system, if the list has a type like List<A>, the NIL for >>>>>> that list would also have that type, and any attempt to dereference it >>>>>> would be caught at compile time. >>>>> >>>>> So instead of a runtime system that gives an error: >>>>> "attempt to derefence a nil pointer" the user is obliged to put >>>>> some code in to give that error himself. Big advantage -;) >>>>> >>>>> Really, on paper and properly implemented, the null pointer in C is >>>>> a fairly decent nil value. Properly implemented in my book means >>>>> that an access through the pointer must be trapped. >>>>> >>>> >>>> AFAIK, there's no requirement in C to prevent reading or writing to the >>>> same address as the NULL pointer. AFAIK, there is no requirement to >>>> trap accesses to it's location either. The requirement is that no C >>>> objects >>>> must be located *at* the NULL pointer address. The NULL is for >>>> comparing >>>> a pointer in C against NULL to determine if the pointer was set or not. >>>> [...] >>> >>> You have not said that you disagree with me and consider that a >>> proper, high quality implementation. >>> >> >>Why do you think that a high quality implementation of C needs >>to trap accesses through a NULL pointer? >> >>There are two things that trapping NULL accesses does: >>1) prevent accidental usage of an uninitialized pointer >>2) prohibit access to a region of memory > > You are deluded. A proper implementation of c requires that > the sentinel value that represents a NULL value doesnot > point to an accessible region of memory. > > There are scores of possible values. E.g. on an early > DEC Alpha every value that is not 8-aligned qualifies. > That are 16140901064495857657 possibilities, if I'm not > mistaken. Interesting; I didn't know that. Any IBM mainframe programmer will recognise 0xDEADBEEF as its oddness makes it an invalid instruction address pointer. Data addresses don't all have this restriction though; it depends on the instruction. System code rarely used zero, as this address is both even and a correct address in system mode. For x86-64 there's the opportunity to use non-canonical addresses as the current address space is 48bits and access causes a machine check. A uniformly usable platform independent NIL or NULL would appear to require support from the language. Whether C mandates such a thing I don't know. > >> >> >>Rod Pemberton > > Groetjes Albert
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-27 10:12 -0600 |
| Message-ID | <zLGdnUqB3rxB_pLOnZ2dnUVZ_tCdnZ2d@supernews.com> |
| In reply to | #28800 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> How is that semantically different from a null pointer? Surely NIL is >> a null pointer, however it is represented. > > Each list node is a discriminated union (member of a sum type) > that's either NIL, or a pair consisting of a value and a pointer to > the next node. So in the case where it's NIL, that's not a pointer. Surely that's a distinction without a difference: it's a node that says "There's nothing to see here." > With a static type system, if the list has a type like List<A>, the > NIL for that list would also have that type, and any attempt to > dereference it would be caught at compile time. I guess that this means that whenever you access a node you have something like a case statement with branches for NIL and non-NIL nodes, so it's impossible to dereference NIL. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 9 of 21 — ← Prev page 1 … 7 8 [9] 10 11 … 21 Next page →
Back to top | Article view | comp.lang.forth
csiph-web