This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


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

Re: alloca is bad?


Jim Blandy wrote:
> 
> I think alloca is terribly useful.  I have every intention of using it
> the next time it's appropriate.  We should not reject new uses of
> alloca.

To decide it is appropriate I think there need to be some clear and
objective guidelines.  Otherwise people submitting code are going to run
into the problem that their submition is being accepted or dismissed
based on the arbitrary wim of the reviewer.  It also means that what
ever decision is reached it has some rationale behind it - otherwize the
alloca debate will just flare up again in another 6 months.

The discussion has already identified the issues:

	o	need to call alloca(0) somewhere
		(perhaphs do_cleanups() should do this :-)

	o	total stack bound of <2mb

	o	(from memory) limit of 64k
		on a single stack frame
		(some rs6000 platforms)

	o	the suggestion that some platforms
		don't support even libiberty's alloca.

		I'd be very interested in knowing the
		details of this.

> Of course, strictly typed mechanisms, like GCC's dynamically sized
> arrays, are preferable, but not widely available.

(Personally, since C doesn't do bounds checking, I think dyamic arrays
are only slightly better :-)

This brings up an additional, possibly relevent, point.  Given the code:

	int a[size];
vs
	int *const a = alloca (size * sizeof (int));
or	int *const a = (int *) alloca (size & sizeof (int));

(er and there is even one in the above and no it wasn't contrived!) the
latter definitely has more potential error points (both when being
written and being maintained).  Coding pratices that minimize a
programmers error rate should be considered.

One ``cute trick'' I'm guilty of is probably worth considering:

	#define XCALLOC(N,TYPE) ((TYPE *) xmalloc ((N) * sizeof (TYPE)))
	int *a = XCALLOC (size, int);

(which works because GDB has a zero tolerance policy towards basic
warnings).

	Andrew

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