Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-ID: <000f01bf8bfa$2bb5e8d0$0201a8c0@jayk_home4nt>
From: "Jay Krell" <jay DOT krell AT cornell DOT edu>
To: "swe sd" <ccwork AT hotmail DOT com>
Cc: <cygwin AT sourceware DOT cygnus DOT com>
Subject: Re: problem in C++ pointer
Date: Sun, 12 Mar 2000 00:08:36 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700

The behavior at a different time and place of code with undefined behavior
is not entirely relevant. Different processors, different command lines,
different optimizations (possibly processor specific), different versions,
can lead to different definitions of undefined behavior. Still, sometimes
undefined behavior is predictable.

I do not yet know if this code is undefined, but certainly the outcome of
code like
i = i++;
i = ++i;
i = i--;
i = --i;
printf("%d%d", i, ++i);
printf("%d%d", --i, ++i);
etc.

is. If it isn't clear if code falls into this pattern, that's probably
enough reason to not write code like it. But even so, if it is defined, it
is a bug if Gcc doesn't consistently give it the standard definition.

Here's a good imho boiled down example:
class X
{
public:
    X* F(int i) { printf("%d", i); return this;}
};

int i = 0;
X x, *px = &x;
px->F(i++)->F(i++)->F(i++);

is the expected output 012 or is it undefined?
Could it reasonably be 000, if none of the storages occur till after all
parameters are evaluated but before any functoins are called?

according to the parts of the standard I can find and decipher:
[expr] 5.0.2: "..uses of overloaded operators are transformed into function
calls as described in 13.5. Overloaded operators obey rules for syntax
specifidd in this clause, but the requirements of operand type, lvalue, and
evaluation order are replaced by the rules for function call".

I couldn't find the evaluation order for function calls except

[intro.execution]1.8.17 "..There is also a sequence point after the copying
of a returned value and before the execution of any expressions outside the
function". I don't know if that "copying of a returned value" applies to
pointers and references, and I find "expressions outside the function"
unclear.

Ordinarily, the sides of a -> I don't believe have a defined order of
evaluation:

eg:
class C
{
public:
int i;
C(int i) { this->i = i ; }
void F(C* c) { printf("%d%d", this->i, c->i); }
};

C carray[2] = { C(0), C(1) };
C* pc = carray;

(pc++)->F(pc++);

Is the output defined?
It could "reasonably" be
01
10
00
?

I'm assuming the order of eval of an unoverloaded -> is the same, if
defined, as the order of eval of ".".

"sequence point" is not in the index..

 - Jay

-----Original Message-----
From: swe sd <ccwork AT hotmail DOT com>
To: jay DOT krell AT cornell DOT edu <jay DOT krell AT cornell DOT edu>
Cc: cygwin AT sourceware DOT cygnus DOT com <cygwin AT sourceware DOT cygnus DOT com>
Date: Saturday, March 11, 2000 9:20 PM
Subject: Re: problem in C++ pointer


>  I do not agree. I execute the same program on a UNIX station with gcc
>compiler and it works fine ... ie the output of line 7 is
>same as the output of line 9.
>
>>From: "Jay Krell" <jay DOT krell AT cornell DOT edu>
>>To: "swe sd" <ccwork AT hotmail DOT com>, <cygwin AT sourceware DOT cygnus DOT com>
>>Subject: Re: problem in C++ pointer
>>Date: Sat, 11 Mar 2000 16:31:28 -0800
>>
>>Your code might be triggering undefined behavior in C++, because of the
>>++X[0] in the same statement where you otherwise read X[0]. Definitely
>>something like
>>printf("%d%d", X[0], ++X[0]);
>>is undefined but I've read something along the lines that when the
>>operator's are actually overloaded, function calls, that the order of
>>evaluation becomes defined..
>>
>> >     line 9:    cout<<A[0]<<" "<<&A<<" "<<&A[0]<<endl
>> >     line 10:       <<*X<<endl
>> >     line 11:       <<*X+5<<endl
>> >     line 12:       <<*X<<" "<<A[0]<<endl
>> >     line 13:       <<5+X[0]<<endl
>> >     line 14:       <<( X[0]==0 ? "X[0]=0" : "X[0]!=0")<<endl
>> >     line 15:       <<++X[0]<<endl
>>
>>something like, skipping endl.
>>cout.<<(A[0]).<<(" ").<<(&A).<<(" ").<<(&A[0]).<<(*X).<<(*X+5).<<(*X).<<("
>>").<<A[0].<<(5+X[0]).<<(( X[0]==0 ? "X[0]=0" : "X[0]!=0")).<<(++X[0]);
>>
>>  - Jay
>>
>>-----Original Message-----
>>From: swe sd <ccwork AT hotmail DOT com>
>>To: cygwin AT sourceware DOT cygnus DOT com <cygwin AT sourceware DOT cygnus DOT com>
>>Date: Saturday, March 11, 2000 9:31 AM
>>Subject: B20: problem in C++ pointer
>>
>>
>> >   I compiled the following program (attachment test.cc):
>> >     line 1:  #include <iostream>
>> >     line 2:  void main()
>> >     line 3:  { const int size=10;
>> >     line 4:    int A[size];
>> >     line 5:    int *X=NULL, i;
>> >     line 6:    for (i=0;i<size;i++) A[i]=i;
>> >     line 7:    cout<<A[0]<<" "<<&A<<" "<<&A[0]<<endl;
>> >     line 8:    X=A;
>> >     line 9:    cout<<A[0]<<" "<<&A<<" "<<&A[0]<<endl
>> >     line 10:       <<*X<<endl
>> >     line 11:       <<*X+5<<endl
>> >     line 12:       <<*X<<" "<<A[0]<<endl
>> >     line 13:       <<5+X[0]<<endl
>> >     line 14:       <<( X[0]==0 ? "X[0]=0" : "X[0]!=0")<<endl
>> >     line 15:       <<++X[0]<<endl
>> >     line 16: }
>> >    and executing it gives output:
>> >           $./a.out
>> >           0 0x259fd7c 0x259fd7c
>> >           1 0x259fd7c 0x259fd7c
>> >           1
>> >           6
>> >           1 1
>> >           6
>> >           X[0]!=0
>> >           1
>> >    Obviously, the output of line 9 is different from line 7 which >
>> >should be the same indeed. Is there anything wrong ? Thanks.
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
>


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com