Re: no alloca() available - alternative?

FWiW: Over-consumption of the Automatic Storage will terminate a thread\process; i.e. resource limited within the thread [stack frames], versus being limited across either the system [heap, etc.] storage or user profile limits. May be best to avoid the use of MODASA for an application with many "large" allocations and highly recursive utilization, to avoid that limitation. The most negative effect is when the application exhausts the Automatic Storage only to a point whereby an invoked system program fails, possibly obfuscating the origin; i.e. appearing to be a defect in the OS for termination within the OS program, but instead, being a side effect of the actions of the application. If that system program is performing auditing, then beware the effect of a high-impact setting for QAUDENDACN :-Q

Regards, Chuck

On 12/6/10 7:37 AM, Mark S. Waterbury wrote:

It is not simply just a matter of replacing every occurrence of
alloca() with malloc() ... you must also insert the corresponding
free() calls at the appropriate place -- at the "end of scope" for
the function (just before the function returns) ... but you must also
consider other ways that the function could implicitly exit this
scope, such as a longjump ... or due to exception handling.

I suggest you create your own include file, called e.g. "alloca.h"
that looks something like this (for OS/400):

#ifndef _alloca_
#define _alloca_
#include <mih/modasa.h>
#define alloca(s1) (modasa(s1))
#endif

This will automatically include the MIH/MODASA header file, and
define a macro named "alloca" that changes any occurence of alloca
in your source code to a direct call to modasa. Then, you only need
to include this near the beginning of any source that uses alloca,
e.g.:

#include "alloca.h"

On 12/6/2010 1:30 AM, Schmidt, Mihael wrote:

Thanx. I'll probably go that route.

Scott Klement on Sunday, December 05, 2010 7:45 PM wrote:

I'd change the ported code to use malloc(), and add code to clean
up the allocations (as appropriate)

That way, your code would be portable, run anywhere, etc.

If you use a MI call, such as _modasa, that code will only run on
IBM i... if you try to port to another system that doesn't have
alloca(), you'll need a separate workaround for that system, and
you end up with 20+ sections of #define macros for
compatibility.

Better to use malloc/free and write it in a portable fashion in
the first place. (I'd only write my own alloca() if changing to
malloc() would be too time-consuming.)

On 12/3/2010 1:46 PM, Schmidt, Mihael wrote:

the ported software uses alloca() at some locations. Obviously
alloca() is not support on IBM i. What is the alternative?
malloc? What do I have to take into account when changing this
to malloc? (besides freeing the memory afterwards)