C Interview Questions

[dhruvaraj]

Interview Questions :
http://www.dhruvaraj.com/interview/cncpp/index.html
online books http://www.dhruvaraj.com

[David Wade]

<dh*******@gmail.comwrote in message
news:11*********************@m7g2000cwm.googlegrou ps.com...

Interview Questions :
http://www.dhruvaraj.com/interview/cncpp/index.html
online books http://www.dhruvaraj.com

Must remember to cross those off my list...

[Richard Heathfield]

dh*******@gmail.com said:

Interview Questions :
http://www.dhruvaraj.com/interview/cncpp/index.html

"C and C++ Basic Questians" didn't inspire a lot of confidence. Still, let's
see:

1. What is the function of ceil(X) defined in math.h do?

Since ceil is not defined in math.h, this is a tricky one to answer!

2. When do you say that a digraph is acyclic

What has this to do with C?

5. Which of the Following [functions] is not defined in string.h?

All of them, obviously.

6. .Identify the correct argument for the function call fflush() in ANSI C:

None of the candidate answers is uniquely correct. Three are wrong, and
stdout is only /one/ correct argument for fflush.

7. Which of the Following will define a type NODE that is a node in a Linked
list?

None of the candidate answers is correct.

10. Look at the Code: ... What will be the output?

Since the code won't compile, the question is moot.

....and so on and so on. These are really just edited lowlights.

online books http://www.dhruvaraj.com

Thanks. I've notified Prentice Hall.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Adrian]

Richard Heathfield wrote:

dh*******@gmail.com said:

6. .Identify the correct argument for the function call fflush() in ANSI C:

None of the candidate answers is uniquely correct. Three are wrong, and
stdout is only /one/ correct argument for fflush.

Richard, could you tell me why all three are wrong. I thought stdin, stdout,
stderr where all macros to FILE * for the 3 streams. Now the standard does say
for buffered streams, are they not buffered?

Also the standard says you can pass NULL to fflush to flush all open streams.

Thanks

Adrian

[J. J. Farrell]

Richard Heathfield wrote:

dh*******@gmail.com said:

Interview Questions :
http://www.dhruvaraj.com/interview/cncpp/index.html

"C and C++ Basic Questians" didn't inspire a lot of confidence. Still, let's
see:

2. When do you say that a digraph is acyclic

What has this to do with C?

C99 has digraphs, and I'd say they're always acyclic.

5. Which of the Following [functions] is not defined in string.h?

All of them, obviously.

Implementation specific, perhaps? Does anything prevent an
implementation defining them in the header if it chooses to?

...
...and so on and so on. These are really just edited lowlights.

Indeed.

[Keith Thompson]

"J. J. Farrell" <jj*@bcs.org.ukwrites:

Richard Heathfield wrote:

>dh*******@gmail.com said:

Interview Questions :
http://www.dhruvaraj.com/interview/cncpp/index.html

"C and C++ Basic Questians" didn't inspire a lot of confidence. Still, let's
see:

2. When do you say that a digraph is acyclic

What has this to do with C?

C99 has digraphs, and I'd say they're always acyclic.

The digraphs are:

<: :<% %%: %:%:

Four of them include percent signs which include little circles. So
only "<:" and ":>" are acyclic.

>5. Which of the Following [functions] is not defined in string.h?

All of them, obviously.

Implementation specific, perhaps? Does anything prevent an
implementation defining them in the header if it chooses to?

[...]

If a header contains a function definition, and that header is
included in two or more translation units in the same program, Bad
Things Could Happen. (I'm too lazy to figure out whether it's
undefined behavior, a constraint violation, or whatever.)

Then again, the predefined functions can also be defined as macros.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Old Wolf]

Keith Thompson wrote:

>
If a header contains a function definition, and that header is
included in two or more translation units in the same program, Bad
Things Could Happen. (I'm too lazy to figure out whether it's
undefined behavior, a constraint violation, or whatever.)

Bad things don't happen if the function definitions are static,
or if it is C99 and they are inline

[Richard Heathfield]

Adrian said:

Richard Heathfield wrote:

>dh*******@gmail.com said:

6. .Identify the correct argument for the function call fflush() in ANSI
C:

None of the candidate answers is uniquely correct. Three are wrong, and
stdout is only /one/ correct argument for fflush.

Richard, could you tell me why all three are wrong.

Um, make that two. :-) (And neither of the other two is uniquely correct,
so it's still a big deal from a getting-the-right-answer perspective.)
While there isn't much point in fflushing stderr, it's legal. But fflush is
only well-defined for streams open for update or output, which stdin is
not. So the answer cannot be A, because that would suggest C is wrong,
cannot be B because it's wrong, cannot be C because that would suggest A is
wrong, and cannot be D because B is wrong.

Also the standard says you can pass NULL to fflush to flush all open
streams.

Indeed, which is another reason that there is no such thing as *the* correct
argument to fflush.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

J. J. Farrell said:

>
Richard Heathfield wrote:

>>
2. When do you say that a digraph is acyclic

What has this to do with C?

C99 has digraphs, and I'd say they're always acyclic.

Bad dog! No biscuit! :-)

>5. Which of the Following [functions] is not defined in string.h?

All of them, obviously.

Implementation specific, perhaps? Does anything prevent an
implementation defining them in the header if it chooses to?

I can find no licence in the Standard that allows it. The most relevant
paragraph appears to be:

4.1.2 Standard headers

Each library function is declared in a header, /81/ whose contents
are made available by the #include preprocessing directive. The
header declares a set of related functions, plus any necessary types
and additional macros needed to facilitate their use. Each header
declares and defines only those identifiers listed in its associated
section. All external identifiers declared in any of the headers are
reserved, whether or not the associated header is included. All
external identifiers that begin with an underscore are reserved. All
other identifiers that begin with an underscore and either an
upper-case letter or another underscore are reserved. If the program
defines an external identifier with the same name as a reserved
external identifier, even in a semantically equivalent form, the
behavior is undefined./82/

It seems to me that this does not give permission for implementations to
define standard library functions in standard headers, although it does
mandate that they be declared therein.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Harald van Dijk]

Richard Heathfield wrote:

J. J. Farrell said:

Richard Heathfield wrote:

5. Which of the Following [functions] is not defined in string.h?

All of them, obviously.

Implementation specific, perhaps? Does anything prevent an
implementation defining them in the header if it chooses to?

I can find no licence in the Standard that allows it.

If there is no way for an otherwise strictly conforming program to tell
the difference, there doesn't have to be any explicit licence that
allows it.

[Richard Heathfield]

Harald van D?k said:

Richard Heathfield wrote:

>J. J. Farrell said:

Richard Heathfield wrote:
5. Which of the Following [functions] is not defined in string.h?

All of them, obviously.

Implementation specific, perhaps? Does anything prevent an
implementation defining them in the header if it chooses to?

I can find no licence in the Standard that allows it.

If there is no way for an otherwise strictly conforming program to tell
the difference, there doesn't have to be any explicit licence that
allows it.

Although I don't claim to have thought it through, I can't help wondering
about standard library functions that use static buffers. There may be a
way for strictly conforming programs to detect that, in two different
modules of the program, different static buffers are being used. (And yes,
okay, perhaps the library could be organised to get around this, by using
buffers with external linkage, but it's getting very messy.)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Simon Biber]

Richard Heathfield wrote:

Adrian said:

>Also the standard says you can pass NULL to fflush to flush all open
streams.

Indeed, which is another reason that there is no such thing as *the* correct
argument to fflush.

Q: Which is the integer?
A: 23
B: 52.3
C: 22.1
D: -99.1

Obviously 23 is the integer. It's not the only integer in the universe,
but it's the integer in the list following. That's how English works.

--
Simon.

[Richard Heathfield]

Simon Biber said:

Richard Heathfield wrote:

>Adrian said:

>>Also the standard says you can pass NULL to fflush to flush all open
streams.

Indeed, which is another reason that there is no such thing as *the*
correct argument to fflush.

Q: Which is the integer?
A: 23
B: 52.3
C: 22.1
D: -99.1

Obviously 23 is the integer.

It's not the only integer in the universe,
but it's the integer in the list following. That's how English works.

Point taken. Now, which is the correct argument to fflush?

a) stdout
b) stdin
c) stderr
d) All the above

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[William Hughes]

Richard Heathfield wrote:

Harald van D?k said:

Richard Heathfield wrote:

J. J. Farrell said:
Richard Heathfield wrote:
5. Which of the Following [functions] is not defined in string.h?

All of them, obviously.

Implementation specific, perhaps? Does anything prevent an
implementation defining them in the header if it chooses to?

I can find no licence in the Standard that allows it.

If there is no way for an otherwise strictly conforming program to tell
the difference, there doesn't have to be any explicit licence that
allows it.

Although I don't claim to have thought it through, I can't help wondering
about standard library functions that use static buffers. There may be a
way for strictly conforming programs to detect that, in two different
modules of the program, different static buffers are being used. (And yes,
okay, perhaps the library could be organised to get around this, by using
buffers with external linkage, but it's getting very messy.)

How about not all functions are defined in the header, in particular
no function that uses a static buffer? I.e. could some functions
be defined static in the header (e.g. to simplify inlining)?. As
different
modules would have different versions of the function, this could be
detected by taking function addresses and comparing. But is there
anything in the standard that prevents this?

(Linker magic may be possible, (e.g. for some library functions (even
when declared
static) first resolve the name by looking in a library, and only if it
is not found
there resolve the name using the object file). Do not report name
conflicts
for these library functions. Yech! But is it possible? )

- William Hughes

[Bart]

Simon Biber wrote:

Richard Heathfield wrote:

Adrian said:

Also the standard says you can pass NULL to fflush to flush all open
streams.

Indeed, which is another reason that there is no such thing as *the* correct
argument to fflush.

Q: Which is the integer?
A: 23
B: 52.3
C: 22.1
D: -99.1

Obviously 23 is the integer. It's not the only integer in the universe,
but it's the integer in the list following. That's how English works.

I thought 42 is *the* integer. ;)
Regards,
Bart.

[Richard Bos]

"Bart" <ba***********@gmail.comwrote:

Simon Biber wrote:

Q: Which is the integer?
A: 23
B: 52.3
C: 22.1
D: -99.1

Obviously 23 is the integer. It's not the only integer in the universe,
but it's the integer in the list following. That's how English works.

I thought 42 is *the* integer. ;)

BTW, I've discovered what TQOLTUAE is.

It's "What is the total value of all balls on a snooker table?"

Richard

[james of tucson]

Richard Bos wrote:

BTW, I've discovered what TQOLTUAE is.

It's "What is the total value of all balls on a snooker table?"

$2.50 per hour; $1.00 with student ID?

[Richard Bos]

james of tucson <jmcgill@[go_ahead_and_spam_me].arizona.eduwrote:

Richard Bos wrote:

BTW, I've discovered what TQOLTUAE is.

It's "What is the total value of all balls on a snooker table?"

$2.50 per hour; $1.00 with student ID?

No, that's the cost.

Richard

[Adrian]

Richard Heathfield wrote:

Um, make that two. :-) (And neither of the other two is uniquely correct,
so it's still a big deal from a getting-the-right-answer perspective.)
While there isn't much point in fflushing stderr, it's legal. But fflush is
only well-defined for streams open for update or output, which stdin is
not. So the answer cannot be A, because that would suggest C is wrong,
cannot be B because it's wrong, cannot be C because that would suggest A is
wrong, and cannot be D because B is wrong.

>Also the standard says you can pass NULL to fflush to flush all open
streams.

Indeed, which is another reason that there is no such thing as *the* correct
argument to fflush.

Thanks, I thought you were saying there was some reason you couldn't pass those
to fflush. Got you now.
Adrian

[Eric Sosman]

Richard Heathfield wrote On 10/31/06 07:43,:

Simon Biber said:

>>Richard Heathfield wrote:

>>>Adrian said:

Also the standard says you can pass NULL to fflush to flush all open
streams.

Indeed, which is another reason that there is no such thing as *the*
correct argument to fflush.

Q: Which is the integer?
A: 23
B: 52.3
C: 22.1
D: -99.1

Obviously 23 is the integer.

>>It's not the only integer in the universe,
but it's the integer in the list following. That's how English works.

Point taken. Now, which is the correct argument to fflush?

a) stdout
b) stdin
c) stderr
d) All the above

#include <stdio.h>
int main(void) {
fputs ("The correct answer is\n", stdout);
fflush (stdout);
if (freopen(NULL, "w", stdin) == NULL) {
fputs ("indeterminate.\n", stderr);
fflush (stderr);
}
else {
fputs ("d: all of the above!\n", stdin);
fflush (stdin); /* 100% legal! */
}
return 0;
}

--
Er*********@sun.com

[Richard Heathfield]

Eric Sosman said:

<snip>

#include <stdio.h>
int main(void) {
fputs ("The correct answer is\n", stdout);
fflush (stdout);
if (freopen(NULL, "w", stdin) == NULL) {
fputs ("indeterminate.\n", stderr);
fflush (stderr);
}
else {
fputs ("d: all of the above!\n", stdin);
fflush (stdin); /* 100% legal! */
}
return 0;
}

Ah, you cooked it. Well done.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Eric Sosman]

Richard Heathfield wrote On 10/31/06 12:33,:

Eric Sosman said:

<snip>

>>#include <stdio.h>
int main(void) {
fputs ("The correct answer is\n", stdout);
fflush (stdout);
if (freopen(NULL, "w", stdin) == NULL) {
fputs ("indeterminate.\n", stderr);
fflush (stderr);
}
else {
fputs ("d: all of the above!\n", stdin);
fflush (stdin); /* 100% legal! */
}
return 0;
}

Ah, you cooked it. Well done.

Dishes like this are better when they're "very rare."

--
Er*********@sun.com

[Jordan Abel]

2006-10-31 <Ib******************************@bt.com>,
Richard Heathfield wrote:

Simon Biber said:

>Richard Heathfield wrote:

>>Adrian said:
Also the standard says you can pass NULL to fflush to flush all open
streams.

Indeed, which is another reason that there is no such thing as *the*
correct argument to fflush.

Q: Which is the integer?
A: 23
B: 52.3
C: 22.1
D: -99.1

Obviously 23 is the integer.

>It's not the only integer in the universe,
but it's the integer in the list following. That's how English works.

Point taken. Now, which is the correct argument to fflush?

a) stdout
b) stdin
c) stderr
d) All the above

e) A and C only

[Keith Thompson]

Jordan Abel <ra****@random.yi.orgwrites:

2006-10-31 <Ib******************************@bt.com>,
Richard Heathfield wrote:

[...]

>Point taken. Now, which is the correct argument to fflush?

a) stdout
b) stdin
c) stderr
d) All the above

e) A and C only

Depends on what you mean by "correct". fflush(stderr) is legal, but
not likely to be useful. fflush(stdin) does not violate any
constraint, and may be useful in some implementations.

Consider this:

fflush(stderr);
if (0) {
fflush(stdin);
}

Both calls are safe but useless (for different reasons). The second
one might even be useful in a compiler conformance test.

The question is so simple that only an expert could get it wrong.
8-)}

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Walter Roberson]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>fflush(stdin) does not violate any
constraint, and may be useful in some implementations.

Depends what you mean by "constraint": according to the standard
the behaviour is undefined. Not "unspecified" but "undefined".
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes

[Jordan Abel]

2006-10-31 <ei**********@canopus.cc.umanitoba.ca>,
Walter Roberson wrote:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>>fflush(stdin) does not violate any
constraint, and may be useful in some implementations.

Depends what you mean by "constraint": according to the standard
the behaviour is undefined. Not "unspecified" but "undefined".

Well, I would assume "does not violate any constraint" means "is not
a constraint violation" which IIRC is a term defined by the standard.

The point was - a compiler is required to accept it. Undefined behavior
only happens if the call actually happens. And then, as has been pointed
out, only if stdin is not open for writing or updating.

[Keith Thompson]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>>fflush(stdin) does not violate any
constraint, and may be useful in some implementations.

Depends what you mean by "constraint": according to the standard
the behaviour is undefined. Not "unspecified" but "undefined".

What I mean by "constraint" is "constraint", as the standard uses the
term. In particular, 5.1.1.3p1 says:

A conforming implementation shall produce at least one
diagnostic message (identified in an implementation-defined
manner) if a preprocessing translation unit or translation unit
contains a violation of any syntax rule or constraint, even
if the behavior is also explicitly specified as undefined or
implementation-defined. Diagnostic messages need not be produced
in other circumstances.

There are explicit "Constraints" sections throughout the standard.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ben Pfaff]

Keith Thompson <ks***@mib.orgwrites:

fflush(stderr) is legal, but not likely to be useful.

Quite useful, in fact, in loops like this, at least in "filters"
that already use stdout for something else:

for (;;) {
/* Make sure user can see we're doing something,
even if stderr is line-buffered. */
putc('.', stderr);
fflush(stderr);

/* Do something that takes a while. */
do_something();
}
--
"Programmers have the right to be ignorant of many details of your code
and still make reasonable changes."
--Kernighan and Plauger, _Software Tools_

[Jordan Abel]

2006-10-31 <87************@blp.benpfaff.org>,
Ben Pfaff wrote:

Keith Thompson <ks***@mib.orgwrites:

>fflush(stderr) is legal, but not likely to be useful.

Quite useful, in fact, in loops like this, at least in "filters"
that already use stdout for something else:

for (;;) {
/* Make sure user can see we're doing something,
even if stderr is line-buffered. */

/* stderr will never be line-buffered. */

[Richard Heathfield]

Jordan Abel said:

2006-10-31 <87************@blp.benpfaff.org>,
Ben Pfaff wrote:

>Keith Thompson <ks***@mib.orgwrites:

>>fflush(stderr) is legal, but not likely to be useful.

Quite useful, in fact, in loops like this, at least in "filters"
that already use stdout for something else:

for (;;) {
/* Make sure user can see we're doing something,
even if stderr is line-buffered. */

/* stderr will never be line-buffered. */

C&V, please.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Ben Pfaff]

Jordan Abel <ra****@random.yi.orgwrites:

2006-10-31 <87************@blp.benpfaff.org>,
Ben Pfaff wrote:

>Keith Thompson <ks***@mib.orgwrites:

>>fflush(stderr) is legal, but not likely to be useful.

Quite useful, in fact, in loops like this, at least in "filters"
that already use stdout for something else:

for (;;) {
/* Make sure user can see we're doing something,
even if stderr is line-buffered. */

/* stderr will never be line-buffered. */

Why not? All I see in C99 is that it will never be fully
buffered:

As initially opened, the standard error stream is not fully
buffered; the standard input and standard output streams are
fully buffered if and only if the stream can be determined
not to refer to an interactive device.
--
"In My Egotistical Opinion, most people's C programs should be indented six
feet downward and covered with dirt." -- Blair P. Houghton

[Eric Sosman]

Jordan Abel wrote On 10/31/06 17:04,:

2006-10-31 <87************@blp.benpfaff.org>,
Ben Pfaff wrote:

>>Keith Thompson <ks***@mib.orgwrites:

>>>fflush(stderr) is legal, but not likely to be useful.

Quite useful, in fact, in loops like this, at least in "filters"
that already use stdout for something else:

for (;;) {
/* Make sure user can see we're doing something,
even if stderr is line-buffered. */

/* stderr will never be line-buffered. */

#include <stdio.h>
int main(void) {
setvbuf (stderr, NULL, _IOLBF, BUFSIZ);
/* Now what? */

--
Er*********@sun.com

[Chris Torek]

>Keith Thompson <ks***@mib.orgwrites:

>>fflush(stderr) is legal, but not likely to be useful.

>2006-10-31 <87************@blp.benpfaff.org>,
Ben Pfaff wrote:

>Quite useful, in fact, in loops like this, at least in "filters"
that already use stdout for something else:

for (;;) {
/* Make sure user can see we're doing something,
even if stderr is line-buffered. */

In article <sl*******************@rlaptop.random.yi.org>
Jordan Abel <ra*******@gmail.comwrote:

>/* stderr will never be line-buffered. */

Not even if main() starts with:

setvbuf(stderr, NULL, _IOLBF, 0);

? (Or, use _IOFBF to make stderr fully-buffered.)

(I sped up the 4.xBSD "tar" program enormously by setting its stderr
to a buffered mode, once. I have forgotten the exact details; I
think this was before I wrote my stdio library, which has some
sneaky hacks for "pseudo-buffering" stderr in fprintf() calls.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Kenneth Brody]

Richard Heathfield wrote:

>
dh*******@gmail.com said:

Interview Questions :
http://www.dhruvaraj.com/interview/cncpp/index.html

"C and C++ Basic Questians" didn't inspire a lot of confidence. Still, let's
see:

[...]

Well, I get a different set of questions when I click on "C and C++
Basic Questians Set 1":

0. What is the output of printf("%d")

Nasal demons.

1. What will happen if I say delete this

Syntax error during compile.

2. Difference between "C structure" and "C++ structure".

Dunno. Perhaps clc++ would know?

3. Diffrence between a "assignment operator" and a "copy constructor"

I didn't think that C had "copy constructor"s.

4. What is the difference between "overloading" and "overridding"?

C doesn't have "overloading".

5. Explain the need for "Virtual Destructor".

Again, no such thing in C.

6. Can we have "Virtual Constructors"?

And again.

7. What are the different types of polymorphism?

And yet again.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Vos]

Hey,

Happened to see some good collection over here
http://www.freebookzone.com . Its well arranged, but i could see only
ebooks over there. So far, for interview questions an such stuff still
dhruvaraj.com rocks

Vosamo

dh*******@gmail.com wrote:

Interview Questions :
http://www.dhruvaraj.com/interview/cncpp/index.html
online books http://www.dhruvaraj.com

[Richard Heathfield]

Vos said:

Hey,

Happened to see some good collection over here
http://www.<piracyURL>.com .

Thanks. It's been reported to Prentice Hall.

So far, for interview questions an such stuff still
dhruvaraj.com rocks

No, it doesn't. We discussed that already.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)