From:	ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: "typePointer = new type[n] ;" SIGSEG's in malloc?
Date:	12 Jun 1997 04:22:30 GMT
Organization:	The National Capital FreeNet
Lines:	33
Message-ID:	<5nnti6$q5m@freenet-news.carleton.ca>
References:	<339F4082 DOT 4F93 AT cs DOT purdue DOT edu>
Reply-To:	ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire)
NNTP-Posting-Host:	freenet5.carleton.ca
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Cory Bloyd (bloydcg AT cs DOT purdue DOT edu) writes:
> I'm writing a program to parse a binary file involving alot of dynamic
> allocation (but no deallocation required `til the end).  All access to
> the allocated arrays are carefully bounds checked.  About midway through
> the file "new" bombs on me.  It always dies in the same place, which is
> the ninth time the calling function is run.  n == 1;  Also, the same
> code with the same input file work just fine in msvc4.2 (I want to keep
> this in gcc, but I was hoping msvc's debugger could help me );  
>  I'm really more of a C type of guy, not very familiar with this "new"
> and "delete" stuff from the Object Oriented WonderLand.  And so I was
> wondering if anyone has a suggestion as to what might be causing this? 
> What sort of behavior should one avoid in C++ to prevent such nasty
> behavior?

Unless G++ has a bug in "new", then it shouldn't SIGSEGV unless the
pointer being assigned to is actually out of bounds of an array of
pointers or something.

So,

int *ints[2];
ints[2]=new int[1];

can be expected to crash.



--
    .*.  Where feelings are concerned, answers are rarely simple [GeneDeWeese]
 -()  <  When I go to the theater, I always go straight to the "bag and mix"
    `*'  bulk candy section...because variety is the spice of life... [me]
Paul Derbyshire ao950 AT freenet DOT carleton DOT ca, http://chat.carleton.ca/~pderbysh

- Raw text -