> > looks like without local varables the BP/SP reg's are not saved
 > > and restored when optimizations are turned on.

 > DN> I'd consider that a bug in QC's alloca() implementation. AFAIK,
 > DN> MSC had no problems in any versions I used (2, 4, 5, 5.1, 6, 7).

 > I've always assumed QC and MSC-6 shared some of the help files, If
 > you have MSC6 installed check out the online help for alloca() and see
 > if the warning about BP/SP is mentioned.

I don't have it installed now, but when I did use those versions of MSC, I
used alloca() regularly without any problems - at the highest optimisation
levels. I *did* have to avoid some optimisation, but only because of MSC
5.x and above's broken string intrinsics which had an unfortunate tendancy
to blow away register contents.


 > Under normal use there would always be at least 1 local variable
 > as a pointer to hold the return value from alloca()

Ahhh, NOW you're making sense. :)  Yes, you did have to have a stack frame
for alloca() to work correctly, and with MSC you can force this on
regardless, which I did as a matter of course. And yes, under all
circumstances that make any sense, the resulting buffer from alloca should
be assigned to an auto variable. The only danger from optimisation is that
your local variables are assigned to registers, but forcing the stack frame
regardless eliminates the problem. I'm not sure if you can do that with QC,
but I would have thought so. If nothing else works, then using _pascal
calling convention should do it.


 > BTW i'd assume any arguments passed to a function
 > using alloca() would force BP/SP to be setup anyway.

Except with the register calling convention  - _fastcall, I think they
called it). I'm not sure if MSC 6 has this, but MSC 7 certainly did.

Sorry I didn't remember any of this until you triggered the brain cells,
but it has been some time since I worked with MSC now.


Regards,
David

--- MaltEd/2 1.0.b6