From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25234 invoked by alias); 20 Jul 2005 14:59:00 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 25214 invoked by uid 22791); 20 Jul 2005 14:58:54 -0000 Received: from mailgw.cs.york.ac.uk (HELO mailgw.cs.york.ac.uk) (144.32.40.3) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 20 Jul 2005 14:58:54 +0000 Received: from minster.cs.york.ac.uk ([144.32.40.2]) by mailgw.cs.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1DvFzr-0001jc-QY; Wed, 20 Jul 2005 15:56:31 +0100 Received: from bushfire.cs.york.ac.uk ([144.32.40.24] helo=[192.168.112.229]) by minster.cs.york.ac.uk with esmtp (Exim 4.44) id 1DvFzr-0007LO-UV; Wed, 20 Jul 2005 15:56:32 +0100 Message-ID: <42DE661C.9030009@bubblescope.net> Date: Wed, 20 Jul 2005 14:59:00 -0000 From: random@bubblescope.net User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) MIME-Version: 1.0 To: Milena Constantino Caires CC: gcc-help@gcc.gnu.org Subject: Re: signed/unsigned char References: <20050720144555.GA63554@registro.br> In-Reply-To: <20050720144555.GA63554@registro.br> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-07/txt/msg00202.txt.bz2 Milena Constantino Caires wrote: >I would like to know why the following statements do not generate a >error during compiling but they do generate segmentation fault and >core dump when the program is running: > > >char* c = new char(1024); > >or > >u_char* c = new u_char(1024); > >I know that the correct form of this memory allocation is "[1024]" and not >"(1024)" but sometimes it occurs by mistake. > >The compiler is not supposed to complain about it??? > > > Because what you have written is that you want a new char whose value is initalised to 1024. For example write: To convince yourself this is true, try for example: #include int main(void) { char* c = new char(65); std::cout << *c << std::endl; } Which should almost certainly print A, unless you are on a very strange machine (65 is the ASCII value for A). I'll admit I'm slightly suprised that the compiler doesn't warn you that 1024 is out of range for a char (on the other hand, the code is still valid I believe if the char is unsigned). Unfortunatly I don't know of a good way to catch these kinds of errors, other than of course a tool like valgrind. Chris