C++ teaser: Is this a compiler bug, or is this expected behavior?

[Generic Usenet Account]

Compile the following snippet of code and run it. If the program spits
out bat:bat instead of bat:zat, what would you say? Would you say that
the compiler has a problem, or would you lay the blame on "undefined
execution of function parameters" in the C/C++ standard and "sequence
points"?

/////// Code snippet begins ///////

#include <iostream>
char foo[10]="cat";
char* writestring()
{
foo[0]='b';
return foo;
}

char* write2()
{
foo[0]='z';
return foo;
}
int main(void)
{ std::cout << writestring() << ":" << write2() << std::endl; }

/////// Code snippet ends ///////

Thanks,
Bhat
[Purists who hold that this NG is meant to discuss compiler neutral,
standard C++ issues only may not proceed beyond this point;-)]




For those of you who are "trivially inclined", here's some
background..... .
I stumbled upon a "bug" in my C++ compiler (g++ 3.3.1), which I
promptly reported to Bugzilla. The code snippet above was actually
provided by someone from the GCC volunteer community. They attributed
the unexpected behavior to the undefined behavior of execution of
function parameters and sequence points. In my original code snippet,
I was maintaining an STL map between IP addresses e.g. 105.52.20.33,
5000 and 47.32.68.95, 6000.

When I displayed the entries in the map, the second IP address was
displayed incorrectly. So instead of the mapping:

105.52.20.33, 5000 >>-->> 47.32.68.95, 6000
I got

105.52.20.33, 5000 >>-->> 105.52.20.33, 6000

The bug does not manifest when the code is compiled using native
Solaris C++
compiler version "WorkShop Compilers 5.0 02/04/10 C++ 5.0 Patch
107311-17"

Here's my original code snippet

/////// Code snippet begins ///////
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#include <string>
#include <map>
#include <iostream>

using namespace std;
struct addrLessThan:pu blic binary_function <const struct sockaddr_in,
const
struct sockaddr_in, bool>
{
bool operator()(cons t struct sockaddr_in addr1, const struct
sockaddr_in
addr2) const
{
bool retVal = true;

string addrStr1 = inet_ntoa(addr1 .sin_addr);
string addrStr2 = inet_ntoa(addr2 .sin_addr);

if(addrStr1 > addrStr2)
retVal = false;
else if(addrStr1 == addrStr2)
retVal = (addr1.sin_port < addr2.sin_port) ;

return retVal;
}
};

typedef map<struct sockaddr_in, struct sockaddr_in, addrLessThan>
IpV4AddrMap;

main()
{
struct sockaddr_in actualAddress, mappedAddress;

actualAddress.s in_port=5000;
actualAddress.s in_addr.s_addr = inet_addr("105. 52.20.33");

mappedAddress.s in_port=6000;
mappedAddress.s in_addr.s_addr = inet_addr("47.3 2.68.95");

IpV4AddrMap map;

map[actualAddress] = mappedAddress;

IpV4AddrMap::it erator itor = map.find(actual Address);

if(itor != map.end())
{
cout << "Key: " << inet_ntoa(itor->first.sin_addr )
<< ", " << itor->first.sin_po rt << endl
<< "Value: " << inet_ntoa(itor->second.sin_add r)
<< ", " << itor->second.sin_por t << endl
<< endl;
}
return 0;
}

/////// Code snippet ends ///////
For more details, you can go to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22265

[Victor Bazarov]

Generic Usenet Account wrote:

Compile the following snippet of code and run it. If the program spits
out bat:bat instead of bat:zat, what would you say? Would you say that
the compiler has a problem, or would you lay the blame on "undefined
execution of function parameters" in the C/C++ standard and "sequence
points"?

/////// Code snippet begins ///////

#include <iostream>
char foo[10]="cat";
char* writestring()
{
foo[0]='b';
return foo;
}

char* write2()
{
foo[0]='z';
return foo;
}
int main(void)
{ std::cout << writestring() << ":" << write2() << std::endl; }
[..]

Yes, the latter, the correct term is "the order of evaluation of the
function arguments is unspecified". A simpler expression is

cout << writestring() << write2();

which is the same as

( cout.operator<< ( writestring() ) ) . operator<< ( write2() );

in which 'write2()' is allowed to be evaluated before 'writestring()'
as I understand it. The part to the right of the second dot is the
function with its arguments. The left part is the object, which also
needs to be evaluated...

V

[Old Wolf]

Generic Usenet Account wrote:

Compile the following snippet of code and run it. If the program
spits out bat:bat instead of bat:zat, what would you say? Would
you say that the compiler has a problem, or would you lay the blame
on "undefined execution of function parameters" in the C/C++
standard and "sequence points"?

#include <iostream>
char foo[10]="cat";
char* writestring()
{
foo[0]='b';
return foo;
}

char* write2()
{
foo[0]='z';
return foo;
}

int main(void)
{ std::cout << writestring() << ":" << write2() << std::endl; }
The behaviour is unspecified (NOT undefined), and
"bat:bat", "bat:zat", and "zat:zat" are all valid outputs.
(But "zat:bat" is not.)

You must remember that writestring() can be called at any point
between the start of this statement's execution, and the point
where its return value is needed. The same goes for write2().

Sequence points are not an issue here, because there are
no instances of multiple side-effects occuring without an
intervening sequence point (a function call has a sequence
point after its arguments have been evaluated, and another one
as it returns).

The example has some similarities to:

foo( a(), b() );

where there is no reason to suspect that a() will be called
before b().

BTW, Why are you posting to comp.sources.d ?
The code snippet above was actually provided by someone from
the GCC volunteer community. They attributed the unexpected
behavior to the undefined behavior of execution of function
parameters and sequence points.
If that was their exact wording, then they are wrong (or
expressed their intention incorrectly).

The behaviour is only unexpected if you were expecting
the wrong thing :)
I stumbled upon a "bug" in my C++ compiler (g++ 3.3.1), which I
promptly reported to Bugzilla. cout << "Key: " << inet_ntoa(itor->first.sin_addr )
<< ", " << itor->first.sin_po rt << endl
<< "Value: " << inet_ntoa(itor->second.sin_add r)
<< ", " << itor->second.sin_por t << endl
<< endl;

Unfortunately you have wasted the time of the Bugzilla people.
You have correctly identified the essence of the "problem",
namely that inet_ntoa() returns a pointer into a static buffer.
In fact, on my system, the inet_ntoa manpage specifically
says:
The string is
returned in a statically allocated buffer, which
subsequent calls will overwrite.

If you still think this is a bug, then what do you think the
'fix' should be? The most common suggestion that people make
on comp.lang.c (or c++) is to force left-to-right evaluation
of function parameters.

This has been discussed to death before, but the main reason
for opposing it is that it would force compilers to produce
slower code in many cases. For example, some calling conventions
feature parameters being pushed onto a stack, with the right-most
parameters pushed first. A function with this calling convention
would need the compiler to jump through some hoops, instead of
a few simple function calls followed by a stack push of the
return value.

[Geo]

Old Wolf wrote:

The behaviour is unspecified (NOT undefined), and
"bat:bat", "bat:zat", and "zat:zat" are all valid outputs.
(But "zat:bat" is not.)

Attempting to modify a literal value is undefined behaviour, surely ?

[msalters]

Geo schreef:

Old Wolf wrote:

The behaviour is unspecified (NOT undefined), and
"bat:bat", "bat:zat", and "zat:zat" are all valid outputs.
(But "zat:bat" is not.)

Attempting to modify a literal value is undefined behaviour, surely ?

It would be. However, char[10] is not a literal. It can be modified.
It's equivalent to { int foo = 10; ++foo; } That doesn't modify 10.

HTH,
Michiel Salters

[Geo]

msalters wrote:

Geo schreef:

Old Wolf wrote:

The behaviour is unspecified (NOT undefined), and
"bat:bat", "bat:zat", and "zat:zat" are all valid outputs.
(But "zat:bat" is not.)

Attempting to modify a literal value is undefined behaviour, surely ?

It would be. However, char[10] is not a literal. It can be modified.
It's equivalent to { int foo = 10; ++foo; } That doesn't modify 10.

HTH,
Michiel Salters

No it's not equivalent at all,
char foo[10]="cat";

reserves 10 character slots and points char[0] at the address of "cat",
which is a literal. Later, foo[0] = 'z' is an attempt to modify the
first chatacter of "cat", i.e. modify the literal, which is undefined
behaviour.

[Karl Heinz Buchegger]

Geo wrote:

msalters wrote:

Geo schreef:

Old Wolf wrote:

> The behaviour is unspecified (NOT undefined), and
> "bat:bat", "bat:zat", and "zat:zat" are all valid outputs.
> (But "zat:bat" is not.)

Attempting to modify a literal value is undefined behaviour, surely ?

It would be. However, char[10] is not a literal. It can be modified.
It's equivalent to { int foo = 10; ++foo; } That doesn't modify 10.

HTH,
Michiel Salters

No it's not equivalent at all,

char foo[10]="cat";

reserves 10 character slots and points char[0] at the address of "cat",
which is a literal. Later, foo[0] = 'z' is an attempt to modify the
first chatacter of "cat", i.e. modify the literal, which is undefined
behaviour.

You might want to reread your 'C++ begining programmers intorduction'
to figure out what
char foo[10] = "cat";
realy does.
Hint: It does not what you describe above.

--
Karl Heinz Buchegger
kb******@gascad .at

[Ian Malone]

Geo wrote:

msalters wrote:

Geo schreef:

Attempting to modify a literal value is undefined behaviour, surely ?
It would be. However, char[10] is not a literal. It can be modified.
It's equivalent to { int foo = 10; ++foo; } That doesn't modify 10.

No it's not equivalent at all,
char foo[10]="cat";

reserves 10 character slots and points char[0] at the address of "cat",
which is a literal. Later, foo[0] = 'z' is an attempt to modify the
first chatacter of "cat", i.e. modify the literal, which is undefined
behaviour.

I may be wrong, but I was under the impression that:
char foo[10]="cat";
results in an array of size 10 in which members are initialised from
the string "cat" (including terminating \0). Whereas
char *bar="cat";
results in a pointer which points to the address of the literal "cat".

--
imalone

[msalters]

Geo schreef:

msalters wrote:

Geo schreef:

Old Wolf wrote:

> The behaviour is unspecified (NOT undefined), and
> "bat:bat", "bat:zat", and "zat:zat" are all valid outputs.
> (But "zat:bat" is not.)

Attempting to modify a literal value is undefined behaviour, surely ?

It would be. However, char[10] is not a literal. It can be modified.
It's equivalent to { int foo = 10; ++foo; } That doesn't modify 10.

HTH,
Michiel Salters

No it's not equivalent at all,
char foo[10]="cat";

reserves 10 character slots and points char[0] at the address of "cat",
which is a literal. Later, foo[0] = 'z' is an attempt to modify the
first chatacter of "cat", i.e. modify the literal, which is undefined
behaviour.

That's the description for { const char* foo = "cat"; }

You can't even point foo[0] to "cat". foo[0] is a char, check typeid()
or sizeof() if you don't believe me. A 'char' is not a 'char*', and
only the latter points.

Also, if you could point foo to "cat", you surely could later point
it to "dog". However, the compiler will tell you that

char foo[10]="cat";
foo = "dog"

is illegal. Of course,

const char* foo = "cat";
foo = "dog";

is legal.

HTH,
Michiel Salters

[Geo]

Sorry my mistake, you are all of course correct, I'll shut up now.