Portable alloca() replacement?

[Freejack]

Recently I've been spending some time googling around for ideas for an
alloca() replacement that could function in a strict ANSI C environment.
As we all know, alloca() is system/arch dependant.

I'm thinking of trying to implement something like "local allocate",
lallocat(), for temporary variables that should be automatically freed
when they go out of scope(function or block).

For simplicity sake, I'm considering something like this...

{
char *mystr = lallocat((char)mystr, (sizeof(mystr) + k));
}

void *lallocat(void foo, size_t size){

void *newfoo[size];

memcpy(newfoo, foo, size);

return newfoo;
}

As you can see, this code has several obvious problems.
As soon as the lallocat() function returns, does it return a pointer
to an array, or a NULL pointer, or undefined. Could be any one of the
three. size_t may have different values depending on the system. Lots of
things.

I cant depend on non-standard concepts such as a stack frame. But I need
to be able to dynamically allocate memory which is local to the scope of
the function or block, which when upon leaving the scope should
automatically be freed for reuse(or possibly returned to the host system.)

Is there any standard way of doing this?

Freejack

 

[Freejack]

How about a variable length array?

It's my understanding that variable length arrays, once allocated, are
fixed in size. That's not so much of a problem, but how would one go about
growing the array in a loop? Also, I understand that implementations might
vary depending on whether it's GNU source or ANSI.

I suppose I could do something like...

{
char *next;
char str[0];
while(fudge /= EOF){
/* Some Code */
char str[strlen (str) + strlen (next) + 1];
strcat(str, next);
}
}

But that looks like it might send performance all to piss. And I would
also be using it for binary data. I'll test it out.

Although it is a possibility.

Freejack

 

[REH]

Recently I've been spending some time googling around for ideas for an
alloca() replacement that could function in a strict ANSI C environment.
As we all know, alloca() is system/arch dependant.

I'm thinking of trying to implement something like "local allocate",
lallocat(), for temporary variables that should be automatically freed
when they go out of scope(function or block).

For simplicity sake, I'm considering something like this...

{
char *mystr = lallocat((char)mystr, (sizeof(mystr) + k));
}

void *lallocat(void foo, size_t size){

void *newfoo[size];

memcpy(newfoo, foo, size);

return newfoo;
}

As you can see, this code has several obvious problems.
As soon as the lallocat() function returns, does it return a pointer
to an array, or a NULL pointer, or undefined. Could be any one of the
three. size_t may have different values depending on the system. Lots of
things.

I cant depend on non-standard concepts such as a stack frame. But I need
to be able to dynamically allocate memory which is local to the scope of
the function or block, which when upon leaving the scope should
automatically be freed for reuse(or possibly returned to the host system.)

Is there any standard way of doing this?

How about a variable length array?

 

[E. Robert Tisdale]

Recently I've been spending some time googling around for ideas for an
alloca() replacement that could function in a strict ANSI C environment.

Use C99 variable size arrays instead.

 

[Andrey Tarasevich]

Recently I've been spending some time googling around for ideas for an
alloca() replacement that could function in a strict ANSI C environment.
As we all know, alloca() is system/arch dependant.
...

There's no way to implement a portable replacement for 'alloca'
function. But in C99 you don't need to. C99 has variable length arrays,
which essentially are core language level equivalents of 'alloca'.

 

[REH]

It's my understanding that variable length arrays, once allocated, are
fixed in size. That's not so much of a problem, but how would one go about
growing the array in a loop? Also, I understand that implementations might
vary depending on whether it's GNU source or ANSI.

Sorry, I missed the part where you wanted it to be able to grow. Anyways, I
thought you wanted something like the non-standard alloc function? As far
as I know, that doesn't create "growable" memory either. You can allocate
more space, but not grow a previous one. That will stay the same until the
function returns, and it is "destroyed."

 

[Andrey Tarasevich]

...
It's my understanding that variable length arrays, once allocated, are
fixed in size.

But the same is true for 'alloca'! If you need a resizable array why do
you consider 'alloca' in the first place?

That's not so much of a problem, but how would one go about
growing the array in a loop?

Growing the array in a loop? You didn't mention this in your original
message. In that case you can forget about 'alloca' and variable length
arrays. Use "regular" dynamic memory manipulation routines: 'malloc'
and/or 'realloc'.

Also, I understand that implementations might
vary depending on whether it's GNU source or ANSI.

As long as the implementation satisfies the requirements of the language
specification, why care about how it is implemented?

 

[pete]

growing the array in a loop?

Maybe it's a job for a linked list instead?

 

[Christian Kandeler]

void *lallocat(void foo, size_t size){

void *newfoo[size];

memcpy(newfoo, foo, size);

return newfoo;
}

As you can see, this code has several obvious problems.

You forgot to mention the most obvious one: void is an incomplete type and
thus cannot be used as the type of a function parameter.


Christian

 

[Villy Kruse]

There's no way to implement a portable replacement for 'alloca'
function. But in C99 you don't need to. C99 has variable length arrays,
which essentially are core language level equivalents of 'alloca'.

The sources for gcc used to come with one, which would work on all systems
to which gcc was ported. This was required because many systems didn't
have a working alloca and gcc itself used it internally. So to botstrap
a gcc compiler using the native compiler a working alloca implementation
had to be provided. That was, by the way, long before there was any C99
standard.

Villy