Re: GSSet explodes with too many data

[Andre Levy]

Richard Frith-Macdonald wrote:

> On 7 Sep 2004, at 11:56, Nicola Pero wrote:
>
> > > my company develops a software to explore very large quantities of data
> > > using GNUstep-base 1.9.2 mainly on windows.
> > >
> > > it works generally well in production with our customers. (our customers
> > > are bankers!...)
> > >
> > > In development, it allows us to do the coding on mac OSX then build on
> > > windows and then check for diffences. we're also very happy with this.
> > >
> > > however we did find some bugs for which we wrote some workaround.
> > >
> > > when we feed the product with too many data it explodes with a
> > > windows-like core-dump.
> > >
> > > our debugging showed that we relied on GSSet: - (NSArray*) allObjects
> > > which explodes because the objects array is allocated on the stack,
> > > which has a limited size, rather than on the heap.
> > > therefore, we rewrote the method as:
> >
> >
> > The best option might be to count the number of objects; if we have less
> > than, say, fifty, we use the stack, else we malloc memory.
>
>
> The base library has macros to make it trivial to do just that ... and 
> we should
> be using them.  I've fixed this in CVS ... but there are probably other 
> places
> where similar problems have been overlooked.
ok. I understand that you use

GS_BEGINIDBUF(objects,count)
GS_ENDIDBUF()

from GSPrivate.h to do just that.

I've checked all the places where I found the problem occured and 
compared it with CVS tree.

it seems that the same fix can be applied to:

NSArray: - (void) removeObjectsFromIndices: (unsigned*)indices
                       numIndices: (unsigned)count

NSSet: - (id) initWithCoder: (NSCoder*)aCoder
        - (id) initWithArray: (NSArray*)other
        - (id) initWithSet: (NSSet*)other copyItems: (BOOL)flag

of course, it may exist in other places but these are the only places i 
am aware of.

thanks a lot for all your work!

--andre