This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [trunk<-vta] Re: [vta, 4.4] make df-scan df_collection_rec arrays overflow-safe


Alexandre Oliva <aoliva@redhat.com> writes:

>> So I came up with a trade-off that should benefit nearly everyone.
>> First, I arranged for the array to start out still on the stack, but
>> to grow as needed onto the heap.  Using GC memory for growth would
>> work, but it was easy enough to add explicit deallocation where
>> needed.
>
>> And then, given that the array could now grow unbounded, the initial
>> sizes didn't have to be so outrageously conservative, so I've reduced
>> stack usage while at that.  No biggie, but still...

I like the idea but (sorry) I would rather see this as a more general
data structure which can be used in other places.  I don't like the ##
stuff you are using.  Perhaps if you defined a new type of VEC:
VEC(TYPE, alloca).  This would be a different data structure from the
existing VEC types, but the interface could otherwise be the same.  For
example, VEC_alloc would always alloca, say, 256 bytes of stack space.
When more was needed, it would switch to malloc.

Does anybody think that would be a bad idea?

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]