From owner-freebsd-stable Sat Apr 28 7:11: 3 2001 Delivered-To: freebsd-stable@freebsd.org Received: from tensor.xs4all.nl (tensor.xs4all.nl [213.84.53.200]) by hub.freebsd.org (Postfix) with ESMTP id E658837B42C for ; Sat, 28 Apr 2001 07:10:59 -0700 (PDT) (envelope-from dim@xs4all.nl) Received: from matrix (matrix.xs4all.nl [192.168.1.2]) by tensor.xs4all.nl (Postfix) with ESMTP id 6241014FA9; Sat, 28 Apr 2001 16:11:15 +0200 (CEST) Message-ID: <200104281611170258.00DFFF78@tensor.xs4all.nl> In-Reply-To: <15082.46019.913297.264758@raw.grenland.fast.no> References: <15082.46019.913297.264758@raw.grenland.fast.no> X-Mailer: Calypso Version 3.20.02.00 (4) Date: Sat, 28 Apr 2001 16:11:17 +0200 From: "Dimitry Andric" To: "Raymond Wiker" Cc: "Erik Trulsson" , freebsd-stable@FreeBSD.ORG Subject: Re: g++ bug in FreeBSD-4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2001-04-28 at 14:12 Raymond Wiker wrote: > Anyway, I came across the following bug report: >. This >looks pretty serious. Sorry, but this is not a bug. The expression: cout << f(d) << "\t" << d << endl; is equivalent to: (((cout << f(d)) << "\t") << d) << endl; which is equivalent to: (((cout.operator<<(f(d))).operator<<("\t")).operator<<(d)).operator<<( endl); And then you come to the nice part of the story: operator '.' is NOT required to evaluate its operands in any particular order! What most compilers do with this type of code is produce something like the following (in pseudo-assembly): // push arguments back-to-front: push endl; push d; // (*) here the value is still 5 push "\t"; push d; // still 5 call f; // here d's value is modified to 1 // call operator<<'s, popping stack as you go call operator<<(double); // for f(d) call operator<<(const char*); // for "\t" call operator<<(double); // for d, which is 5, see (*) call operator<<(endl); // for endl And this will lead to the results from the bug report. It not only happens with g++, but also with VC++ under Win32, for example. The problem is that you should not put code with side effects (such as calling f() in this case) in cout << ... expressions. This will lead only to unexpected results. :) Cheers, - -- Dimitry Andric PGP key: http://www.xs4all.nl/~dim/dim.asc KeyID: 4096/1024-0x2E2096A3 Fingerprint: 7AB4 62D2 CE35 FC6D 4239 4FCD B05E A30A 2E20 96A3 -----BEGIN PGP SIGNATURE----- Version: Encrypted with PGP Plugin for Calypso Comment: http://www.gn.apc.org/duncan/stoa_cover.htm iQA/AwUBOurBPrBeowouIJajEQJ2TACg1+b4J3OjTEFqpBT747nEcZhr1aUAoJCC ZRXzJYLt1Ig9MFY4yLNfiNF+ =3DHO0F -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message