13 Dec
2005
13 Dec
'05
11:09 p.m.
I remember when I first used this piece of low-budget software 12 years
ago that it had some interesting bugs, most of which surfaced when you
used 'clever' features of C++, such as pure virtuals, destructors, etc.
I've been using it to do a small TCP/IP implementation for a PCjr and
have been sticking to vanilla C. After a few weeks of coding I've hit a
bug that has just bewildered me.
Take the following code:
#include <stdio.h>
#include "IP.h"
IpAddr_t MyIpAddr;
char *Ip::formatAddress( const IpAddr_t a, char *buffer ) {
char bogus[] = "";
sprintf( buffer, "%d.%d.%d.%d", a[0], a[1], a[2], a[3] );
return buffer;
}
If I *dont* have the 'char bogus[]' line in there, the call to sprintf
always returns zero. If I have that extra line in there, the call to
sprintf works as expected.
Another work-around is to not use the 'char bogus[]' trick, and just
repeat the call to sprintf. The second one will work.
Yet another trick is to move the function to the end of the file ...
After a few hours of wrestling with this I am fairly sure it is a bug in
the linker, and it has to do with the string constant on the sprintf.
If it is the first string constant in the file, it doesn't work. If I
do anything that adds another string constant before that one, it works,
even if the other string constant is never referenced or used.
Has anybody run into something similar to this? I'm using tdump
(supplied with the compiler), the linker's map file, and debug to try to
figure out the code gen and the suspected fixup error, but I can't see
anything obviously wrong. Hints on tracking this would be appreciated.
Mike
14 Dec
14 Dec
12:02 a.m.
It was thus said that the Great Michael B. Brutman once stated:
I remember when I first used this piece of low-budget software 12 years
ago that it had some interesting bugs, most of which surfaced when you
used 'clever' features of C++, such as pure virtuals, destructors, etc.
I've been using it to do a small TCP/IP implementation for a PCjr and
have been sticking to vanilla C. After a few weeks of coding I've hit a
bug that has just bewildered me.
Take the following code:
Which isn't vanilla C (but may be vanilla C++) ...
[ snip ]
After a few hours of wrestling with this I am fairly
sure it is a bug in
the linker, and it has to do with the string constant on the sprintf.
If it is the first string constant in the file, it doesn't work. If I
do anything that adds another string constant before that one, it works,
even if the other string constant is never referenced or used.
Sounds like a fixup problem. If it's the first constant string, then it
sounds like it's at offset 0 of some segment, and the linker may be thinking
it's a NULL value (easy to see how this could happen actually). And it may
be that that implementation of sprintf() checks for a NULL string, and if
so, "does the right thing" (not print anything, and return 0 characters
written).
Has anybody run into something similar to this?
I'm using tdump
(supplied with the compiler), the linker's map file, and debug to try to
figure out the code gen and the suspected fixup error, but I can't see
anything obviously wrong. Hints on tracking this would be appreciated.
Can you produce Microsoft .obj files and link with LINK.EXE?
-spc (Either that, or just forget C++ and use C ... )
10:22 a.m.
Quoting Sean 'Captain Napalm' Conner <spc at conman.org>:
Which isn't vanilla C (but may be vanilla C++) ...
Except for the function name, a C compiler would be pretty happy with it. The
compiler is bad, but not that bad!
Sounds like a fixup problem. If it's the first
constant string, then it
sounds like it's at offset 0 of some segment, and the linker may be thinking
it's a NULL value (easy to see how this could happen actually). And it may
be that that implementation of sprintf() checks for a NULL string, and if
so, "does the right thing" (not print anything, and return 0 characters
written).
I'm guessing this too, but I can't figure out the difference. When the extra
constant is not there a 0x0004 gets loaded into AX. When the extra constant is
there, a 0x0005 gets loaded into AX. I might be looking at the wrong register
before the call, but I never see a case of 0x0 or 0x1 being moved in - I think
the 0x0004 and 0x0005 are the correct offsets.
Now I'm wondering if sprintf is buggered, and just doesn't like 0x0004 as input
on the call.
Changing the constant string in sprintf to different things or changing the
length didn't help.
Can you produce Microsoft .obj files and link with LINK.EXE?
-spc (Either that, or just forget C++ and use C ... )
It is producing OBJ files, but I'm not sure who's format it is. Historically
I've been scared of using linkers directly, but I guess now it's time. :-)
Another path I went down was searching for Turbo C++ 3.0 erratta on the web, but
I wasn't able to find any lists. And Borland's site doesn't cover the old
stuff, except for the downloads in the museum part.
2:31 p.m.
It was thus said that the Great mbbrutman-cctalk at brutman.com once stated:
Quoting Sean 'Captain Napalm' Conner <spc at conman.org>:
The problem may be happening at the linking stage, not the runtime stage
(although that's there the anomalous behavior is seen). A sequence like:
printf("%d %s",23,"hello");
Produces code like:
segment data
text1 db '%d %s',0
text2 db 'hello',0
segment code
pushl offset text2
pushl 23
pushl offset text1
call printf
But the object code produces an output like:
data_blob
text1: db '%d %s',0
text2: db 'hello',0
code_blob
line1: pushl 0
line2: pushl 23
line3: pushl 0
line4: call 0
fixup_data
in code_blob @ line1 byte offset 1 change to address of
data_blob line 2
in code_blob @ line 3 byte offset 1 change to address of
data_blob line 1
in code_blob @ line4 byte offset 1 change to address of
external_code_blob printf
It may be that because the offset of text1 is at offset 0 of the data
segment (as stored in the data_blob) the linker may think it's actually NULL
and do something different. It's not a compiler error, so running the
resulting code under a debugger won't find it---it's a linking error.
-spc (has found compiler errors, but never a linker error ... )
Which isn't vanilla C (but may be vanilla C++) ...
Except for the function name, a C compiler would be pretty happy with it. The
compiler is bad, but not that bad!
Sounds like a fixup problem. If it's the
first constant string, then it
sounds like it's at offset 0 of some segment, and the linker may be thinking
it's a NULL value (easy to see how this could happen actually). And it may
be that that implementation of sprintf() checks for a NULL string, and if
so, "does the right thing" (not print anything, and return 0 characters
written).
I'm guessing this too, but I can't figure out the difference. When the extra
constant is not there a 0x0004 gets loaded into AX. When the extra constant is
there, a 0x0005 gets loaded into AX. I might be looking at the wrong register
before the call, but I never see a case of 0x0 or 0x1 being moved in - I think
the 0x0004 and 0x0005 are the correct offsets. 
1:20 a.m.
I met a problem in Watcom C 11.0. I uses wcl which makes 8086 code.
The code is running on a 386. I got wired result with
printf("%x %x %x ",inportb(H_ADDR2), inportb(H_ADDR1), inportb(H_ADDR0));
but the following code worked as expected,
printf("%x ", inportb(H_ADDR2));
printf("%x ",inportb(H_ADDR1));
printf("%x ", inportb(H_ADDR0));
The hardware is straightforward and unlikely to have problem. I don't
have time to determine the real source of this problem, though.
vax, 9000
1:43 a.m.
9000 VAX wrote:
I met a problem in Watcom C 11.0. I uses wcl which
makes 8086 code.
The code is running on a 386. I got wired result with
printf("%x %x %x ",inportb(H_ADDR2), inportb(H_ADDR1), inportb(H_ADDR0));
but the following code worked as expected,
printf("%x ", inportb(H_ADDR2));
printf("%x ",inportb(H_ADDR1));
printf("%x ", inportb(H_ADDR0));
The hardware is straightforward and unlikely to have problem. I don't
have time to determine the real source of this problem, though.
Would 'volatile' help in this case?
vax, 9000
.
2:11 a.m.
> I met a problem in Watcom C 11.0. I uses wcl which
makes 8086 code.
> The code is running on a 386. I got wired result with
> printf("%x %x %x ",inportb(H_ADDR2), inportb(H_ADDR1), inportb(H_ADDR0));
> but the following code worked as expected,
> printf("%x ", inportb(H_ADDR2));
> printf("%x ",inportb(H_ADDR1));
> printf("%x ", inportb(H_ADDR0));
This is a bug in the former code.
C has never guaranteed anything about the order of evaluation of the
arguments to a multi-argument call like printf; indeed, it is possible
(though unlikely in this case) that their evaluation can be overlapped.
Code that, like the single-call code, depends on that order of
evaluation is *broken*, pure and simple. (Unless it is intended
specifically for use with a specific compiler, in which case some
degree of knowing how that compiler will compile it is not unwarranted,
though (to steal a phrase) I would call it unwarranted chumminess with
the compiler.)
Would 'volatile' help in this case?
Unlikely. Even if it did, it would be a very wrong answer; depending
on this kind of compiler-specific detail is the sort of thing you
should never do until you *thoroughly* know the rules. That the
original poster needed to ask the question at all indicates that sie
does not yet know the rules thoroughly enough to know when it's OK to
break them. (The rule in this case is "thou shalt not depend on
implementation-defined or undefined behaviour".)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
5:16 a.m.
woodelf wrote:
9000 VAX wrote:
> I met a problem in Watcom C 11.0. I uses wcl which makes 8086 code.
> The code is running on a 386. I got wired result with
> printf("%x %x %x ",inportb(H_ADDR2), inportb(H_ADDR1), inportb(H_ADDR0));
>
> but the following code worked as expected,
> printf("%x ", inportb(H_ADDR2));
> printf("%x ",inportb(H_ADDR1));
> printf("%x ", inportb(H_ADDR0));
The order of evaluation of arguments to functions is
undefined in C. A compiler may evaluate left-to-right,
or right-to-left or in some other sequence, you just
can't control it. The second example forces the
compiled code to evaluate the 'inportb' expressions
in sequence. Could the order of the reads from the
port make a difference?
Would 'volatile' help in this case?
No, I don't think so.
--
John Honniball
coredump at gifford.co.uk
7:46 a.m.
woodelf wrote:
9000 VAX wrote:
The problem
has to do with the evaluation order of function arguments.
Typically, in C this is right to left, i.e.
expect an inportb(H_ADDR0) to be executed first, second the H_ADDR1,
third the H_ADDR2.
If no the reading of H_ADDR0 influences the result on port H_ADDR1 and
or H_ADDR2, then you get
different results compared to the triple printf. However, the compiler
is free to evaluate subexpressions in any
order, provided they are evaluated before the final function is called.
Thus, it is technically undefined what is
printed for instance for printf("%d %d %d", i++,i--,i -= 3);
The compiler has all rights to produce code that yields different
results for both code fragments.
Holger
I met a problem in Watcom C 11.0. I uses wcl
which makes 8086 code.
The code is running on a 386. I got wired result with
printf("%x %x %x ",inportb(H_ADDR2), inportb(H_ADDR1),
inportb(H_ADDR0));
but the following code worked as expected,
printf("%x ", inportb(H_ADDR2));
printf("%x ",inportb(H_ADDR1));
printf("%x ", inportb(H_ADDR0));
The hardware is straightforward and unlikely to have problem. I don't
have time to determine the real source of this problem, though.
15 Dec
15 Dec
11:21 a.m.
On 12/14/05, Holger Veit <holger.veit at ais.fraunhofer.de> wrote:
Thus, it is technically undefined what is
printed for instance for printf("%d %d %d", i++,i--,i -= 3);
The compiler has all rights to produce code that yields different
results for both code fragments.
It's not only undefined what this code prints, it is undefined as to
whether the code prints anything. The compiler is free to start a
game of tetris when it encounters the above code. This is definitely
one of the nasal demon cases.
Eric
14 Dec
14 Dec
10:24 a.m.
Quoting 9000 VAX <vax9000 at gmail.com>:
I met a problem in Watcom C 11.0. I uses wcl which
makes 8086 code.
The code is running on a 386. I got wired result with
printf("%x %x %x ",inportb(H_ADDR2), inportb(H_ADDR1), inportb(H_ADDR0));
but the following code worked as expected,
printf("%x ", inportb(H_ADDR2));
printf("%x ",inportb(H_ADDR1));
printf("%x ", inportb(H_ADDR0));
The hardware is straightforward and unlikely to have problem. I don't
have time to determine the real source of this problem, though.
vax, 9000
In general, how is Watcom C 11.0 compared to Turbo C++ 3.0? Am I hurting myself
unnecessarily using Turbo C++?
Mike
11:09 a.m.
mbbrutman-cctalk at brutman.com wrote:
In general, how is Watcom C 11.0 compared to Turbo C++
3.0? Am I hurting myself
unnecessarily using Turbo C++?
It's the bomb, but you can't use it for your project because Watcom v11 is
386+ protected mode only.
--
Jim Leonard (trixter at oldskool.org)
World's largest electronic gaming project: http://www.MobyGames.com/
A delicious slice of the demoscene: http://www.MindCandyDVD.com/
Various oldskool PC rants and ramblings: http://www.oldskool.org/
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.13.13/198 - Release Date: 12/12/2005
12:14 p.m.
On 12/14/05, Jim Leonard <trixter at oldskool.org> wrote:
mbbrutman-cctalk at brutman.com wrote:
The compiler is protected mode only. The 8086 executable can run on a 8086 PC.
In general, how is Watcom C 11.0 compared to
Turbo C++ 3.0? Am I hurting myself
unnecessarily using Turbo C++?
It's the bomb, but you can't use it for your project because Watcom v11 is
386+ protected mode only. --
Jim Leonard (trixter at oldskool.org)
World's largest electronic gaming project: http://www.MobyGames.com/
A delicious slice of the demoscene: http://www.MindCandyDVD.com/
Various oldskool PC rants and ramblings: http://www.oldskool.org/
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.13.13/198 - Release Date: 12/12/2005
12:59 p.m.
On 12/14/05, Jim Leonard <trixter at oldskool.org> wrote:
mbbrutman-cctalk at brutman.com wrote:
Has anyone tried real mode development with the Digital Mars C++ compiler?
It claims to build 8088 code....
Eric
In general, how is Watcom C 11.0 compared to
Turbo C++ 3.0? Am I
hurting myself
unnecessarily using Turbo C++?
It's the bomb, but you can't use it for your project because Watcom v11 is
386+ protected mode only.
12:13 p.m.
On 12/14/05, mbbrutman-cctalk at brutman.com <mbbrutman-cctalk at brutman.com>
wrote:
Quoting 9000 VAX <vax9000 at gmail.com>:
Faster, more compact code; can produce both 8086 executable and 80386
executable. I used it to run SIMH(386 mode) and now I use it's 8086
mode to compile software derived from SIMH. The only problem is that I
don't have software to make EPROM image that supports Watcom file
format.
I use Watcom C 11 because it is open and free. TC2.01 is free (price)
but it can't handle // style comments or 64 bit long word. TC has a
more convenient IDE. I use TC2.01 to write short test programs.
vax, 9000
I met a problem in Watcom C 11.0. I uses wcl
which makes 8086 code.
The code is running on a 386. I got wired result with
printf("%x %x %x ",inportb(H_ADDR2), inportb(H_ADDR1), inportb(H_ADDR0));
but the following code worked as expected,
printf("%x ", inportb(H_ADDR2));
printf("%x ",inportb(H_ADDR1));
printf("%x ", inportb(H_ADDR0));
The hardware is straightforward and unlikely to have problem. I don't
have time to determine the real source of this problem, though.
vax, 9000
In general, how is Watcom C 11.0 compared to Turbo C++ 3.0? Am I hurting myself
unnecessarily using Turbo C++?
Mike
2:16 p.m.
It was thus said that the Great 9000 VAX once stated:
I met a problem in Watcom C 11.0. I uses wcl which makes 8086 code.
The code is running on a 386. I got wired result with
printf("%x %x %x ",inportb(H_ADDR2), inportb(H_ADDR1), inportb(H_ADDR0));
but the following code worked as expected,
printf("%x ", inportb(H_ADDR2));
printf("%x ",inportb(H_ADDR1));
printf("%x ", inportb(H_ADDR0));
The hardware is straightforward and unlikely to have problem. I don't
have time to determine the real source of this problem, though.
Did you need to read the ports in the sequence H_ADDR2, H_ADDR1 and
H_ADDR0, or could they be read in any sequence? Because in C, parameters
are evaluated right to left ...
-spc (rarely is it an issue though ... )
2:45 p.m.
On 12/14/05, Sean 'Captain Napalm' Conner <spc at conman.org> wrote:
Did you need to read the ports in the sequence
H_ADDR2, H_ADDR1 and
H_ADDR0, or could they be read in any sequence? Because in C, parameters
are evaluated right to left ...
No, The order is not important. But I have a clue now. It might be
that Watcom C treats printf() function differently from other
functions. I think the compiler tends to delay the execution of
printf(), given that variables to be printed have not yet updated by
the program. But this trick (to execute printf() with other printf()'s
for speed?) does not work well if the program needs to read hardware
inside of printf(). I actually observed the "delayed printf()"
phenomenon and its effect here is my guess.
vax, 9000
-spc (rarely is it an issue though ... )
3:25 p.m.
On 12/14/2005 at 2:45 PM 9000 VAX wrote:
No, The order is not important. But I have a clue now. It might be
that Watcom C treats printf() function differently from other
functions. I think the compiler tends to delay the execution of
printf(), given that variables to be printed have not yet updated by
the program. But this trick (to execute printf() with other printf()'s
for speed?) does not work well if the program needs to read hardware
inside of printf(). I actually observed the "delayed printf()"
phenomenon and its effect here is my guess.
Well, printf() does write to a buffered stream, doesn't it, so it will be
delayed unless you also issue a fflush(stdout) immediately thereafter.
When I'm debugging my own code, I use my own unbuffered printf(); it's
smaller, faster and doesn't require that I include all of the stdio streams
library if I don't need it otherwise. I believe that MS C provides a
similar facility with _cprintf().
Cheers,
Chuck
3:31 p.m.
It was thus said that the Great Chuck Guzis once stated:
On 12/14/2005 at 2:45 PM 9000 VAX wrote:
Or you call setvbuf(). You can turn off buffering on stdout by:
setvbuf(stdout,NULL,_IONBF,0);
But I'll stop here before turning this into a C support list 8-)
-spc (Who ended up writing my own IO routines in C anyway ... )
No, The order is not important. But I have a clue now. It might be
that Watcom C treats printf() function differently from other
functions. I think the compiler tends to delay the execution of
printf(), given that variables to be printed have not yet updated by
the program. But this trick (to execute printf() with other printf()'s
for speed?) does not work well if the program needs to read hardware
inside of printf(). I actually observed the "delayed printf()"
phenomenon and its effect here is my guess.
Well, printf() does write to a buffered stream, doesn't it, so it will be
delayed unless you also issue a fflush(stdout) immediately thereafter. 
3:39 p.m.
So what is the best C++ for DOS and for Windows 3.1 platforms? I am thinking
about picking something up for use on my 386/40.
4:24 p.m.
On 12/14/2005 at 3:39 PM Teo Zenios wrote:
So what is the best C++ for DOS and for Windows 3.1
platforms? I am
thinking about picking something up for use on my 386/40.
That's a really tough question (although some may disagree).
When I was writing code for commercial sale, I stayed with Microsoft C++
for the simple reason that it was what Microsoft expected me to use and
what they wrote their reference manuals and other documentation for.
Borland Turbo C++ was also popular, but it has the danger of speaking the
Queen's English in the Bronx--most of what you say will be understood, but
as a friend discovered who called the front desk at her hotel to ask them
to "knock her up" at 7:30 the next morning, it's not guaranteed.
If I were doing this for my own amusement, I'd stick with the DJGPP C++
32-bit platform. None of the 16-bit nonsense to bother you.
Cheers,
Chuck
5:07 p.m.
Teo Zenios wrote:
So what is the best C++ for DOS and for Windows 3.1
platforms? I am thinking
about picking something up for use on my 386/40.
For a 386/40, I'd say Watcom. Watcom performs some optimizations I'm too lazy
to do myself, such as warming the cache and using floating point registers in
interesting ways.
Of course, it completely depends on your target requirements. If you're
developing for an IBM PCjr like Mike Brutman is, you might want a compiler that
favors size over speed, or at least has that as a compiler option. If
portability with the OSS community is paramount, stick with gcc. If you want a
fancy IDE and symbolic debugger, go with Borland C and/or Turbo C. So, like
most answers, "it depends."
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Want to help an ambitious games project? http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
5:55 p.m.
It was thus said that the Great Tony Duell once stated:
I always thought they were, but then again, I know enough about C to avoid
the areas that are undefined or implementation dependent; I might have
gotten the parameter passing convention mixed up with that, because under
Pascal, parameters, as they appear on the stack, go left to right
(rightmost ends up at the top of the stack) whereas in C, it's right to left
(leftmost ends up at the top of the stack).
-spc (So C can have functions that have an unspecified number of
parameters, whereas Pascal can't ... )
Did you need to read the ports in the sequence
H_ADDR2, H_ADDR1 and
H_ADDR0, or could they be read in any sequence? Because in C, parameters
are evaluated right to left ...
Are they? That's news to me. I thought they could be evaluated in any
order (or even in parallel).
6:42 p.m.
[...]? Because in C, parameters are evaluated right
to left ...
No. In some implementations of C, they are. In C - as distinct from
any implementation of C - parameter evaluation order is unspecified and
indeed may be ill-defined (evaluation of different parameters may be
intertwined if the compiler finds it convenient).
But it sounds as though evaluation order is not the issue here.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
3:09 a.m.
Michael B. Brutman wrote:
Another work-around is to not use the 'char
bogus[]' trick, and just
repeat the call to sprintf. The second one will work.
I hate to mention the obvious, but have you tried tracing through the code in a
debugger to see what is actually happening? If the first call fails but the
second call works, that is (in my experience) something very easy to determine
the cause of in a debugger.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Want to help an ambitious games project? http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
3:14 a.m.
Jim Leonard wrote:
I hate to mention the obvious, but have you tried
tracing through the
code in a debugger to see what is actually happening? If the first call
fails but the second call works, that is (in my experience) something
very easy to determine the cause of in a debugger.
(I forgot to clarify in my post that I meant a low-level debugger, stepping
through assembler instructions, etc. -- not a C++ source symbolic debugger)
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Want to help an ambitious games project? http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
10:14 a.m.
Quoting Jim Leonard <trixter at oldskool.org>:
I hate to mention the obvious, but have you tried
tracing through the code in
a
debugger to see what is actually happening? If the first call fails but the
second call works, that is (in my experience) something very easy to
determine
the cause of in a debugger.
No debugger .. while I'm a fan of debuggers (and I did a lot of work to
implement the one on the BlueGene supercomputer), adding the extra symbols
changes too much stuff. And in particular, the debugger in this IDE is
attrocious. :-) If I had the stand-alone Turbo Debugger I might try it.
What I really need is good listing and disassembly tools ... working with
straight debug sucks.
4:32 p.m.
I remember when I first used this piece of low-budget software 12 years
ago that it had some interesting bugs, most of which surfaced when you
used 'clever' features of C++, such as pure virtuals, destructors, etc.
I found some interesting 'bugs' in the plain C part. In particular
malloc() would return pointers to areas of memory that definitely were
not free. That made for some interesting results.
I remember calling Borland's so-called support about this. They told me
that if I wanted to use malloc(), I should be using C and not C++. I then
asked them what product I should buy to compile C programs under MS-DOS,
They told me Borland C for MS-DOS version <foo>. I asked them where to
get it and how much, they then told be it was discontinued, and that the
replacement was Turbo C++ v3.0. At this point I realised that commercial
software was simply not worth bothering with, I went over to open source
stuff and have never had any more problems....
-tony
6867
days inactive
6868
days old
29 comments
12 participants
participants (12)
-
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
coredump＠gifford.co.uk -
holger.veit＠ais.fraunhofer.de -
korpela＠ssl.berkeley.edu -
mbbrutman-cctalk＠brutman.com -
mouse＠Rodents.Montreal.QC.CA -
spc＠conman.org -
teoz＠neo.rr.com -
trixter＠oldskool.org -
vax9000＠gmail.com