jpotter@falcon.lhup.edu (John Potter) wrote in message news:<3d7d2837.12654875@news.earthlink.net>...
> On Mon, 9 Sep 2002 17:49:08 +0000 (UTC), rmaddox@isicns.com (Randy
> Maddox) wrote:
>
> > I agree with Mr. Potter that the removal does indeed give the
> > impression that a past-the-end iterator, as returned by end(), could
> > be useless since it would appear to be unusable in comparisons.
> > However, I think that this could be taken as possibly a mix-up in the
> > standard in the use of the term singular.
>
> I see your point; however, it is a mix-up in reading.  The standard is
> very clear about what singular means in this clause.  It appears no
> place else in the standard.  A poor choice of words?  We have singular
> as in singularity where a function is not defined.  That is the sense
> in which it is used.  It is not used in the sense of unique value.
>

Isn't this rather like Humpty Dumpty's argument in "Alice In
Wonderland", i.e., "When I use a word it means exactly what I say it
means, nothing more and nothing less"?  And as for the function
example, when does the singularity occur?  When the denominator is
zero, a unique value.  On this basis the standard might just as well
define subtraction to mean addition.  Even used consistently in this
well defined sense, this would contribute little to the readability of
the standard.

See also Alan Stokes follow up to this posting where he suggests
"indeterminate" as a better word choice for this situation.  I fully
support his suggestion.

Randy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

petebecker@acm.org (Pete Becker) wrote in message news:<3D779921.78311EF8@acm.org>...
> Alan Stokes wrote:
> >
> > I don't follow your logic. Not requiring them to be non-singular
> > allows them to be singular.
>
> The C++ standard doesn't say that murder is illegal, but that doesn't
> make it legal.

Wouldn't that be outside the scope (1.1) a bit? ;-)

> Similarly, not saying here that off-the-end iterators
> must be non-singular doesn't mean that they can be singular. It only
> means that this particular paragraph doesn't prohibit it.

That is of course true, but relevant only if the prohibition does in
fact exist somewhere else in standard. I don't believe it does. Would
you care to say where you think it is?

The DR we are discussing is clearly intended to remove the requirement
that past-the-end iterators be non-singular, on the false premise that
null pointers are singular. So if the prohibition exists elsewhere,
the DR failed to achieve its object.

In any case I think you are now arguing that DR 208 had no effect, so
presumably you would have no opposition to it being reversed?

- Alan

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

jpotter@falcon.lhup.edu (John Potter) wrote in message news:<3d7d2837.12654875@news.earthlink.net>...
> So, what is a better word?

How about indeterminate? The standard already uses that term for
non-static variables of POD types that aren't initialised (8.5/9), and
this encompasses uninitialized pointers, which seem to be the most
obvious case of "singular" iterators.

One could then just delete all the sentences referring to singular
iterators in 24.1/5, and change table 74 in 24.1.3 to replace "might
be singular" with "might be indeterminate".

The troublesome sentence "Dereferenceable [and past-the-end] values
are always nonsingular." would also be removed altogether, since it's
fairly obvious they aren't indeterminate.

The rules on testing iterators for equality also then make sense -
equality is an equivalence relation, but obviously testing against an
indeterminate value gives an indeterminate result.

- Alan

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

jpotter@falcon.lhup.edu (John Potter) wrote in message news:<3d792317.8544437@news.earthlink.net>...
> On Fri, 6 Sep 2002 19:15:16 +0000 (UTC), petebecker@acm.org (Pete
> Becker) wrote:
>
> > John Potter wrote:
>
> > > If an end iterator may be singular, it may only be assigned a
> > > non-singular value.  All other operations are undefined behavior.
>
> > The change DOESN'T SAY THAT THE ITERATOR MAY BE SINGULAR. Not
> > prohibiting it in one place doesn't change the rest of the standard.
>
> Let's accept that statement.  Then:
>
> Standard defines singular as assign a new value only.  Null pointers
> are clearly not singular.
>
> Standard said past-the-end values are non-singular.
>
> DR claims that prevents null pointers and it should be removed.
>
> Rational claims that null pointers are singular.
>
> DR removes requirement statement.  Past-the-end values are still
> non-singular via other parts of the standard.
>
> The standard says the same thing that it said before the DR.
>
> Obviously there was no defect in the standard and everything in issue
> 208 from its title to the end is 100% defective.
>
> Removal of that sentence for cause gives the impression that
> past-the-end iterators could be useless.
>
> John
>

I agree with Mr. Potter that the removal does indeed give the
impression that a past-the-end iterator, as returned by end(), could
be useless since it would appear to be unusable in comparisons.
However, I think that this could be taken as possibly a mix-up in the
standard in the use of the term singular.

For example, using pointers:

  T  * p;    // standard says this is singular pointer
  T  * q = 0;

I would say that in this case p is not singular, but rather undefined,
which is exactly why it is dangerous, you don't know what it is
pointing to.  On the other hand, q is well defined, but singular,
i.e., it has been assigned that single value which by convention
indicates an invalid pointer.

What the standard calls a singular iterator is what I would call an
undefined pointer.  What I would call a singular pointer has no
correspondence in the world of iterators.  And therein lies the catch.
 We have defined iterators as an abstraction of pointers, but have
failed to carry over the key concept of a singular pointer.  There is
nothing defined as the singular value of an iterator that would
correspond to a NULL pointer, so we don't really have a singular
iterator, all we can have is an undefined iterator.

Clearing up this confusion over the use of the term singular when,
IMHO, undefined would be a better term for the current situation with
iterators could only help to clarify this discussion.

Randy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 9 Sep 2002 17:49:08 +0000 (UTC), rmaddox@isicns.com (Randy
Maddox) wrote:

> I agree with Mr. Potter that the removal does indeed give the
> impression that a past-the-end iterator, as returned by end(), could
> be useless since it would appear to be unusable in comparisons.
> However, I think that this could be taken as possibly a mix-up in the
> standard in the use of the term singular.

I see your point; however, it is a mix-up in reading.  The standard is
very clear about what singular means in this clause.  It appears no
place else in the standard.  A poor choice of words?  We have singular
as in singularity where a function is not defined.  That is the sense
in which it is used.  It is not used in the sense of unique value.

> For example, using pointers:
>
>   T  * p;    // standard says this is singular pointer
>   T  * q = 0;
>
> I would say that in this case p is not singular, but rather undefined,

But we have undefined behavior not undefined values.

> which is exactly why it is dangerous, you don't know what it is
> pointing to.  On the other hand, q is well defined, but singular,
> i.e., it has been assigned that single value which by convention
> indicates an invalid pointer.

Sorry, p is an invalid pointer which does not point.  It may have a
trap value.  Q is a valid not dereferenceable pointer.

> What the standard calls a singular iterator is what I would call an
> undefined pointer.  What I would call a singular pointer has no
> correspondence in the world of iterators.  And therein lies the catch.
>  We have defined iterators as an abstraction of pointers, but have
> failed to carry over the key concept of a singular pointer.  There is
> nothing defined as the singular value of an iterator that would
> correspond to a NULL pointer, so we don't really have a singular
> iterator, all we can have is an undefined iterator.

Actually, the problem is that we do not know which we have.  Forward
iterators are default constructable and we do not know if all default
constructed iterators of a given type compare equal or crash our
programs when we look at their value.  If vector<T>::iterator is a T*
then vector<T>::iterator() is a null pointer, but vector<T>::iterator
it; is a singular pointer.  List<T>::iterator will have a pointer
inside.  If list<T>::iterator() sets it to a null pointer than we have
a null iterator.  If it leaves it uninitialized, we have a singular
iterator.

> Clearing up this confusion over the use of the term singular when,
> IMHO, undefined would be a better term for the current situation with
> iterators could only help to clarify this discussion.

It is interesting that all default constructed istream_iterator<T>
objects compare equal.  Input iterators are not required to be default
constructable.

The problem is the standard specifies a very clear use of singular
which readers do not want to read and understand.  "The standard is
wrong, that is not what singular means."  Sorry, the standard defines
it.

So, what is a better word?

Unitialized?
No, most iterators are class objects and get constructed.

Undefined?
No, that is behavior, not value.

Does anyone want to rewrite the clause to replace singular with some
other word and add that past-the-end iterators are never that?

Oh well.  Issue 208 is totally wrong and never should have been
accepted.  It was accepted and is in TC1.  The TC changes the wording
of the standard and if you look only at the new wording, you will
never know that there was anything removed.  With the new wording, you
will not likely think that end iterators are not usable.  When people
quit looking at issue 208 they will never know that a null pointer was
mistakenly called singular.  The lawyers win.  :)

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Alan Stokes wrote:
>
> I can't find such a requirement, although I wish I could. Table 74
> requires == over forward iterators to be an equivalence relation,
> although table 72 only requires it to be an equivalence relation "over
> its domain" for input iterators. And of course output iterators are
> not comparable at all.
>
> The only rule I can find about comparing past the end iterators is in
> the bullet after table 74 - "If a and b are equal, then either a and b
> are both dereferenceable or else neither is dereferenceable".
>

You're looking in the wrong place. Past-the-end iterators don't exist in
a vacuum; you get them by calling end() on a standard container. The
container requirements talk about comparing begin() to end().

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

petebecker@acm.org (Pete Becker) wrote in message news:<3D779A24.28C07546@acm.org>...
> Alan Stokes wrote:
> > The only rule I can find about comparing past the end iterators is in
> > the bullet after table 74 - "If a and b are equal, then either a and b
> > are both dereferenceable or else neither is dereferenceable".
> >
>
> You're looking in the wrong place. Past-the-end iterators don't exist in
> a vacuum; you get them by calling end() on a standard container. The
> container requirements talk about comparing begin() to end().

I don't think they do, except in 23.1/7: "begin() returns an iterator
referring to the first element in the container. end() returns an
iterator which is the past-the-end value for the container. If the
container is empty, then begin() == end();".

This doesn't impose any requirement for comparability for non-empty
containers.

As far as I can tell the rest of the semantics have to be deduced from
the iterator requirements (which seems sensible). And unfortunately
this DR has broken those semantics.

- Alan

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Alan Stokes wrote:
>
> petebecker@acm.org (Pete Becker) wrote in message news:<3D768D7B.657D0FFF@acm.org>...
> > Pete Becker wrote:
> > >
> > > Alan Stokes wrote:
> > > >
> > > > The proposed resolution allows a past the end iterator to be singular;
> > > > this means one cannot safely compare any other iterator against it,
> > >
> > > Not requiring them to be non-singular doesn't change the requirement
> > > that iterators be comparable.
>
> I don't follow your logic. Not requiring them to be non-singular
> allows them to be singular.

The C++ standard doesn't say that murder is illegal, but that doesn't
make it legal. Similarly, not saying here that off-the-end iterators
must be non-singular doesn't mean that they can be singular. It only
means that this particular paragraph doesn't prohibit it.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Potter wrote:
>
> vector<int>::iterator it; // may be singular
> it == it;                 // undefined behavior
> vector<int> v;
> v.end() == v.end();   // Pre 208, true.  Post 208, undefined behavior.

No. Not defined by that clause.

>
> If an end iterator may be singular, it may only be assigned a
> non-singular value.  All other operations are undefined behavior.

The change DOESN'T SAY THAT THE ITERATOR MAY BE SINGULAR. Not
prohibiting it in one place doesn't change the rest of the standard.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Pete Becker wrote:
>
> John Potter wrote:
> >
> > vector<int>::iterator it; // may be singular
> > it == it;                 // undefined behavior
> > vector<int> v;
> > v.end() == v.end();   // Pre 208, true.  Post 208, undefined behavior.
>
> No. Not defined by that clause.
>
> >
> > If an end iterator may be singular, it may only be assigned a
> > non-singular value.  All other operations are undefined behavior.
>
> The change DOESN'T SAY THAT THE ITERATOR MAY BE SINGULAR. Not
> prohibiting it in one place doesn't change the rest of the standard.

That sounds reasonable. So, what is the part of the standard that does
prohibit end() (for a non-empty container) from being singular? Or, more
directly, where does it say that it can be compared?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 6 Sep 2002 19:15:16 +0000 (UTC), petebecker@acm.org (Pete
Becker) wrote:

> John Potter wrote:

> > If an end iterator may be singular, it may only be assigned a
> > non-singular value.  All other operations are undefined behavior.

> The change DOESN'T SAY THAT THE ITERATOR MAY BE SINGULAR. Not
> prohibiting it in one place doesn't change the rest of the standard.

Let's accept that statement.  Then:

Standard defines singular as assign a new value only.  Null pointers
are clearly not singular.

Standard said past-the-end values are non-singular.

DR claims that prevents null pointers and it should be removed.

Rational claims that null pointers are singular.

DR removes requirement statement.  Past-the-end values are still
non-singular via other parts of the standard.

The standard says the same thing that it said before the DR.

Obviously there was no defect in the standard and everything in issue
208 from its title to the end is 100% defective.

Removal of that sentence for cause gives the impression that
past-the-end iterators could be useless.

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

This defect report (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#208)
is clearly wrong, and appears to be based on a misapprehension about
what a singular iterator is. The proposed resolution would break the
standard. This was pointed out some time ago (see
news:3a3c619c.134280050@news.csrlink.net), but apparently in vain.

Can anything be done about this?

A singular iterator is defined in 24.1/5; all operations (including
comparison) on a singular  iterator yield undefined behaviour, except
for assigning a non-singular value to it. Uninitialised pointers are
given as an example; uninitialised forward iterators may also be
singular (24.1.3, table 74).

The proposed resolution allows a past the end iterator to be singular;
this means one cannot safely compare any other iterator against it,
which entirely destroys its usefulness.

The previous discussion in this group covered the ground fairly
thoroughly, but to reiterate, the defect report says:

> In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
> past-the-end values are always non-singular."
> This places an unnecessary restriction on past-the-end iterators
> for containers with forward iterators (for example, a
> singly-linked list). If the past-the-end value on such a container
> was a well-known singular value, it would still satisfy all
> forward iterator requirements.

This is not true. For a start how can a singular value be well-known?
You can't compare singular values.

> Removing this restriction would allow, for example, a
> singly-linked list without a "footer" node.

This is already possible. Past the end iterators are not
dereferenceable (24.1/5), and any two non dereferenceable iterators
are allowed to compare equal (24.1.3/1 again).

> This would have an impact on existing code that expects
> past-the-end iterators obtained from different (generic)
> containers being not equal.

Such code is already broken, because any two past the end iterators
may compare equal as just mentioned.

> Rationale: For some kinds of containers, including singly
> linked lists and zero-length vectors, null pointers are
> perfectly reasonable past-the-end iterators. Null pointers
> are singular.

Null pointers are not singular iterators - they can be compared and
assigned safely. Nothing in the standard prevents a null pointer being
used as a past-the-end iterator.

Null pointers are clearly singular in a sense - just not in the sense
used in the standard.

- Alan

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

dmh0xq001@sneakemail.com (Alan Stokes) writes:

> Can anything be done about this?

I suggest you contact one of the committee members - either through
your national standards body, or by contacting the editor directly.

Regards,
Martin

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Alan Stokes wrote:
>
> The proposed resolution allows a past the end iterator to be singular;
> this means one cannot safely compare any other iterator against it,

Not requiring them to be non-singular doesn't change the requirement
that iterators be comparable. What it does do is avoid confusion about
null pointers and singularity.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Pete Becker wrote:
>
> Alan Stokes wrote:
> >
> > The proposed resolution allows a past the end iterator to be singular;
> > this means one cannot safely compare any other iterator against it,
>
> Not requiring them to be non-singular doesn't change the requirement
> that iterators be comparable. What it does do is avoid confusion about
> null pointers and singularity.
>

The requirement is that past-the-end iterators be comparable, not that
iterators in general be comparable.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Pete Becker wrote:
>
> Alan Stokes wrote:
> >
> > The proposed resolution allows a past the end iterator to be singular;
> > this means one cannot safely compare any other iterator against it,
>
> Not requiring them to be non-singular doesn't change the requirement
> that iterators be comparable. What it does do is avoid confusion about
> null pointers and singularity.

Is there an explicit requirement that past-the-end iterators be
comparable? I'd check it myself, but my copy of the standard remains
inaccessible (I'm afraid I may have to buy a new copy).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

petebecker@acm.org (Pete Becker) wrote in message news:<3D768D7B.657D0FFF@acm.org>...
> Pete Becker wrote:
> >
> > Alan Stokes wrote:
> > >
> > > The proposed resolution allows a past the end iterator to be singular;
> > > this means one cannot safely compare any other iterator against it,
> >
> > Not requiring them to be non-singular doesn't change the requirement
> > that iterators be comparable.

I don't follow your logic. Not requiring them to be non-singular
allows them to be singular. Singular iterators cannot be compared.

It seems to me that the rule that you can't do anything except assign
to a singular iterator in 24.1/5 must override the general
requirements on comparing iterators in tables 72 and 74 - otherwise
you'd be allowed to compare uninitialised pointers (which are
singular), and that doesn't seem right.

> What it does do is avoid confusion about null pointers and singularity.

What confusion? The (unmodified) standard makes clear what a singular
iterator is, but a null pointer doesn't fit the defintion. It also
says that a past the end iterator can't be singular but can be
non-dereferencable. Thus nothing prevents a past the end iterator
being a null pointer.

If there is confusion, wouldn't a footnote be a better resolution than
a normative change anyway?

> The requirement is that past-the-end iterators be comparable, not that
> iterators in general be comparable.

I can't find such a requirement, although I wish I could. Table 74
requires == over forward iterators to be an equivalence relation,
although table 72 only requires it to be an equivalence relation "over
its domain" for input iterators. And of course output iterators are
not comparable at all.

The only rule I can find about comparing past the end iterators is in
the bullet after table 74 - "If a and b are equal, then either a and b
are both dereferenceable or else neither is dereferenceable".

- Alan

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 4 Sep 2002 22:38:39 +0000 (UTC), petebecker@acm.org (Pete
Becker) wrote:

> Alan Stokes wrote:

> > The proposed resolution allows a past the end iterator to be singular;
> > this means one cannot safely compare any other iterator against it,

> Not requiring them to be non-singular doesn't change the requirement
> that iterators be comparable. What it does do is avoid confusion about
> null pointers and singularity.

I think it does the opposite.  It supports the confusion.

int* p; // singular
p == p; // undefined behavior
p = 0;  // now null, not singular
p == p; // true

vector<int>::iterator it; // may be singular
it == it;                 // undefined behavior
vector<int> v;
v.end() == v.end();   // Pre 208, true.  Post 208, undefined behavior.

If an end iterator may be singular, it may only be assigned a
non-singular value.  All other operations are undefined behavior.

Stepanov knew what he said in the HP report.  The committee might have
known what they copied into the standard.  Nothing said that iterators
may not contain or be a null pointer.  Issue 208 broke it.  Of course,
no implementation will use that broken spec to break programs.  So, we
don't need a standard?

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]