From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-237380-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 333 invoked by alias); 4 Dec 2007 20:38:10 -0000
Received: (qmail 32722 invoked by uid 48); 4 Dec 2007 20:37:57 -0000
Date: Tue, 04 Dec 2007 20:38:00 -0000
Message-ID: <20071204203757.32721.qmail@sourceware.org>
X-Bugzilla-Reason: CC
References: <bug-34307-15463@http.gcc.gnu.org/bugzilla/>
Subject: [Bug c++/34307] when data member name is same as parameter name, possible to omit parameter name in constructor without warning
In-Reply-To: <bug-34307-15463@http.gcc.gnu.org/bugzilla/>
Reply-To: gcc-bugzilla@gcc.gnu.org
To: gcc-bugs@gcc.gnu.org
From: "myselfhimself at free dot fr" <gcc-bugzilla@gcc.gnu.org>
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2007-12/txt/msg00311.txt.bz2



------- Comment #2 from myselfhimself at free dot fr  2007-12-04 20:37 -------
Hi
this is to say that my first example was not a problem so sorry for posting.
a conclusion is that c++ tolerates nameless parameter names even in function
definition.

As to the second example, Andrew Pinski, you state that the parameter msg,
which is passed to the string constructor of msg, in the member initialization
list.
I agree with this, but now given the following class definition:
#include <iostream>
#include <string>
using namespace std;

class Something
{
        public:
        string msg;
        Something():msg(msg)
        {}
        void sayMsg()
        {
                cout << "sayMsg() yo here's my message "<< msg <<
"-done"<<endl;
        }
};

int main()
{
        cout << "crash if nothing after that" << endl;
        Something a;
        cout << "msg taken from public is:" << a.msg << "-done"<<endl;
        a.msg = "yo here's a msg";
        a.sayMsg();
        cout << "no crash" << endl;
        getchar(); //pause
        return 0;
}

Here are the output of this program:
---when compiled with MS Visual Studio 2005:
crash if nothing after that
msg taken from public is:-done
sayMsg() yo here's my message yo here's a msg-done
no crash
----when compiled with g++ (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) (this
is on a solaris. I know this is not 4.1.3 but I'm 99% sure I had the same
problem on my linux machine (g++ 4.1.3, i586)). Options used are -Wall and
-pedantic and g++ said nothing when compiling:
crash if nothing after that
Erreur de segmentation //this means Segfault in english

The problem is that, at the moment the constructor of Something is called,
the constructor of msg (that is to say the constructor of class string) is
called and passed msg itself. The problem is that what is passed here does not
contain anything yet.

If we think lower level, calling the constructor of Something does something in
this spirit:
1. allocate memory space for something of the size of a Something object (that
is sizeof(string) because class Something only contains one data member which
is  string msg)
2. read the values of any parameter passed as arguments of the constructor(in
our case above, the parameter given does not have a name and is not used
anywhere whether in the constructor's body or in its member initialization
list, so this step 2. is skipped)
3. do data member initialization. In our case something like this happens:
string Something.msg::string(Something.msg) (which calls string's copy
constructor I believe).

If step 1. if memory allocation were done with a calloc (in C terms...) then
unitialized string object msg would be full of zeros, so passing it to string's
constructor in step 3. would just pass a zero filled object, and maybe or not,
the string's constructor would not complain or crash the whole program. What
seems to happen with MS Visual Studio 2005's compiler is this automatic
zero-filling on allocation.
For g++ it seems that when memory allocation is done (for non-dynamic
variables), the allocated spaces are not automatically filled with zeros. So
weird things are passed to the string class's constructor in the above case
with g++. Hence the segfault.

I believe that g++ should raise an error or warning when compiling if we try to
pass a data member to its own constructor during member list initialization.

What do you think of it ?
Sincerely,
Jonathan-david Schroder


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34307