Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 64.233.170.191 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=UNi8+xQ084zk8qywyiY43kGV8WK84ZIElWPOd3kzuazgNKFUkpSyK2n6DSkmspQoZBAnqA7imp6oIJLVZkn8I3+cvkDZmcj387kOHF9HVEeObcwJR1E1XmK2rNfPfe2SNrlXkFnRRH7X9S4nm4ZYSzkzLg7VDCTmcJBkAUjiPzY=
Message-ID: <47E2CF0A.6000305@roguewave.com>
Date: Thu, 20 Mar 2008 14:54:34 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: [TESTCASE] STDCXX-750 [HP aCC 6.16] Potential null pointer
 dereference
 in aliases.cpp
References: 
 <CFFDD219128FD94FB4F92B99F52D0A499A2BCE@exchmail01.Blue.Roguewave.Com>
 <47E2A684.3000708@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499A2BD0@exchmail01.Blue.Roguewave.Com>
 <47E2CABE.4060009@roguewave.com>
In-Reply-To: <47E2CABE.4060009@roguewave.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

FYI: This was simple enough that I made the change myself:
   http://svn.apache.org/viewvc?rev=639452&view=rev

Martin

Martin Sebor wrote:
> Scott Zhong wrote:
>> Martin, would you suggest that there should be a check after malloc and
>> throw bad_alloc?
> 
> I think we should just use the new expression instead of calling
> malloc. That way we don't need to check. Unless we call malloc()
> in the rest of the program for some reason.
> 
> Martin
> 
>>
>>> -----Original Message-----
>>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>>> Sent: Thursday, March 20, 2008 12:02 PM
>>> To: dev@stdcxx.apache.org
>>> Subject: Re: [TESTCASE] STDCXX-750 [HP aCC 6.16] Potential null
>> pointer
>>> dereference in aliases.cpp
>>>
>>> I was going to say this is the same bug as STDCXX-764:
>>>    http://issues.apache.org/jira/browse/STDCXX-764
>>> but after looking at it more closely I believe the compiler
>>> is correct in this case because malloc() returns 0 when it
>>> fails to allocate memory. The warning could be clearer about
>>> it.
>>>
>>> Martin
>>>
>>> Scott Zhong wrote:
>>>> cat /build/scottz/t2.cpp && aCC -V && aCC -c  +w
>> /build/scottz/t2.cpp
>>>> #include <cstdlib>
>>>>
>>>> int main()
>>>> {
>>>>   static char * test = 0;
>>>>   if (!test) {
>>>>      test = (char *)std::malloc (12345);
>>>>      *test = '\0';
>>>>   }
>>>>
>>>>   return 0;
>>>> }
>>>> aCC: HP C/aC++ B3910B A.06.16 [Nov 26 2007]
>>>> "/build/scottz/t2.cpp", line 8, procedure main: warning #20200-D:
>>>> Potential
>>>>           null pointer dereference through test is detected (null
>>>>           definition:/build/scottz/t2.cpp, line 7)
>>>>
>>>> this test case shows that the warning is bogus because the pointer
>>>> "test" is pointing to a valid location in memory after std::malloc
>> is
>>>> performed.
>>>>
>>
>>
> 
>