Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Subject: Re: Many pthread failures in the test suite, one setgroup failure
From: Robert Collins <rbcollins AT cygwin DOT com>
To: egor duda <cygwin-developers AT cygwin DOT com>
In-Reply-To: <52772748984.20020930104301@logos-m.ru>
References: <20020925141653 DOT GA6134 AT redhat DOT com>
	<1033139976 DOT 22908 DOT 333 DOT camel AT lifelesswks>
	<163544913434 DOT 20020927192540 AT logos-m DOT ru>
	<1033140780 DOT 9593 DOT 0 DOT camel AT lifelesswks>
	<44642850720 DOT 20020928223759 AT logos-m DOT ru>
	<1033254454 DOT 4375 DOT 48 DOT camel AT lifelesswks> 
	<52772748984 DOT 20020930104301 AT logos-m DOT ru>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature";
	boundary="=-Tgm/N9ZrHBmU10yBPkVL"
Date: 30 Sep 2002 21:35:48 +1000
Message-Id: <1033385748.11273.194.camel@lifelesswks>
Mime-Version: 1.0


--=-Tgm/N9ZrHBmU10yBPkVL
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2002-09-30 at 16:43, egor duda wrote:
> Hi!
>=20
> Sunday, 29 September, 2002 Robert Collins rbcollins AT cygwin DOT com wrote:
>=20
> >> Now, in verifyable_object_isvalid you're casing pointer to variable of
> >> subclass to pointer to base class. Ain't it case of 'never do like
> >> this'? I suppose to safely perform cast from subclass to base class
> >> one should always use dynamic_cast().
>=20
> RC> It's a case of this is always ways ok to do - upcasting is FINE.. (it
> RC> happens every time you call a virtual function in fact).
>=20
> Yes, it's fine as long as it's done via compiler. When virtual
> function is called it's compiler duty to arrange things so that this
> is pointing to the proper place in memory. The same for dynamic_cast,
> compiler knows how to update pointer. But what's done in
> verifyable_object_isvalid() is _not_ upcasting. It's essentially a
> pointer arithmetic. And i bet it's not guaranteed to work -- it will
> obviously fail in the case of multiple inheritance when class C is
> derived from class A and class B, and clearly, you won't be able to do
> the trick with pointer assignments to cast pointer to the instance of
> class C to both class A and class B. You'll need to use compiler
> knowledge about class C instance layout for either casting to class A
> or class B. So, the safe way is to always use dynamic_cast (or virtual
> functions) and let compiler to arrange everything.

The main reason it's not guaranteed in my code is that we are using void
* tricks at the moment - I agree with you there.
Secondly, we are not calling generic methods, but static methods, which
means if we tell the compiler that we will pass (say) verifyable_object
** to the static method, then it should be able to upcast safely. I'm
not sure what the spec has to say about upcasting from a foo ** pointer
though.
=20
> Which bug in gcc? I guess we should look into C++ standard first. But
> i suspect it doesn't say anything about offsets for common members in
> base and derived classes being always equal, so that programmer can do
> pointer assignment to cast from base to derived and vice versa. As i
> said, it wouldn't be true in at least one case -- multiple
> inheritance. So, before qualifying this as a gcc bug, you should first
> give an appropriate reference to the standard.

Oh, absolutely. If I couldn't generate an in-spec test case, I wouldn't
raise anything as a bug.

Rob

--=20
---
GPG key available at: http://users.bigpond.net.au/robertc/keys.txt.
---

--=-Tgm/N9ZrHBmU10yBPkVL
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA9mDcUI5+kQ8LJcoIRAl2fAKDHKnazTISsC+x7F7v9c4eIgBYrwQCaAsjC
d3VsnOj4QrwoC95PVf9bSNo=
=kTFr
-----END PGP SIGNATURE-----

--=-Tgm/N9ZrHBmU10yBPkVL--