From 4219510935822356149
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,8366734ec6aad121
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1994-06-06 08:29:11 PST
Newsgroups: comp.std.c++
Path: nntp.gmd.de!xlink.net!howland.reston.ans.net!darwin.sura.net!ms!mo.cs.wm.edu!adrian
From: adrian@mo.cs.wm.edu (Adrian Filipi-Martin)
Subject: Re: new foo[0]
Message-ID: <1994Jun6.152021.20287@cs.wm.edu>
Sender: news@cs.wm.edu (News System)
Nntp-Posting-Host: mo.cs.wm.edu
Organization: College of William & Mary, founded 1693
References:  <CquD6C.LEK@lehman.com>
Date: Mon, 6 Jun 1994 15:20:21 GMT
Lines: 35

In article <CquD6C.LEK@lehman.com>, eschwarz@shearson.com (Edward Schwarz) writes:
|> A)	foo* myfoo0 = new foo[0];
|> 
|> and
|> 
|> B)	foo* myfoo1 = new foo[1];
|> 
|> The ARM says that A) will retun a pointer to an object, and that distinct calls will return distinct objects. This would seem to imply that there is no difference between A) and B).
|> 

        I think the first one should be read as returning a valid pointer to an
array of objects, not returning a pointer to an object. In order to successfully
execute a delete[] on any pointer to an array of objects. Some internal (hidden)
bytes are allocated (usually immediately before the actual array) that contain
the size of the array of objects. In case A, this is 0. But the space to hold 0
was still allocated and is only reclaimed when delete[] is used.

        How this works became painfully clear when I had an off-by-1 that stepped
on the bytes immediately preceding, but not overlapping, an array of objects. My
visible data never was trashed, but delete[] would cause a core dump. The only
way I discovered the bug, the off-by-1 was a non-trivial nested loop, was to
watch the memory via gdb for any changes in the vicinity of the array.

        Has anyone ever considered providing a mechanism for either accessing the
fields of the internal data or validating it from within C++? The inaccessibility
of this data was what made finding the bug so difficult. Even an implementation
dependent mechanism would be appreciated.

cheers,
	Adrian
-- 
adrian@cs.wm.edu          ---->>>>| Support you local programmer,
adrian@icase.edu            --->>>| STOP Software Patent Abuses NOW!
Member: The League for        -->>| membership info at prep.ai.mit.edu:/pub/lpf
       Programming Freedom      ->| print "join.ps" for an application