OK folks, corrected

[jacob navia]

After a heated discussion, I decided to fix this problem of VLAs
It took me almost the whole day to realize that

1) I am storing the size of ALL VLAs in a hidden local variable
in case somebody calls sizeof(vla), and I need to return that
size. This means most of this problem was solved already.

2) I am executing code anyway when I leave a scope.

THEN:

When leaving a scope with level bigger than function, i.e. an inner
scope, go through all local variables of that scope and see if it
is a VLA.

If it is, look where its size is stored. Read that size and add it to
the stack pointer.

----------------------------------------------------------------

Open questions:
--------------
What happens with:

for (int i = 0; i<100; i++) {
int tab[i*1024];
int *pint = alloca(42);
}

With the current scheme of freeing the VLAs this
will crash.

:-(

This was NOT crashing before. I do not know what to do with
this stuff.

gcc dedicates a register to save the stack position
in such blocks. When the block exits, the whole stack
is restored, what means that the alloca's done are
automatically taken care of correctly.

This is a hell of expensive, since I have only 3 free registers in
the x86 32 bit architecture. This means that I would lose 33% of the
machine dedicated to holding the stack value.

gcc uses esi, and it can (with its bloated "optimize it all"
machinery) remark that this is only used in this block and
can be used elsewhere. I do not do global register allocation,
since it just would bring me a few percent speed gain at enormous
cost.

I would have to dedicate the register within the WHOLE function.

For the time being I will leave it like this. Note that using
alloca within a loop is quite suicidal anyway, since all the storage
can't be reclaimed until the function exit in principle in many
implementations.

I can "cheat out" by writing this in the docs...

"Do not use alloca in blocks using VLAs"

:-)

So, I see the regulars come and start arguing:

"Jacob recommended alloca and it crashes. "
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[santosh]

jacob navia wrote:

After a heated discussion, I decided to fix this problem of VLAs
It took me almost the whole day to realize that

1) I am storing the size of ALL VLAs in a hidden local variable
in case somebody calls sizeof(vla), and I need to return that
size. This means most of this problem was solved already.

2) I am executing code anyway when I leave a scope.

THEN:

When leaving a scope with level bigger than function, i.e. an inner
scope, go through all local variables of that scope and see if it
is a VLA.

If it is, look where its size is stored. Read that size and add it to
the stack pointer.

----------------------------------------------------------------

Open questions:
--------------
What happens with:

for (int i = 0; i<100; i++) {
int tab[i*1024];
int *pint = alloca(42);
}

With the current scheme of freeing the VLAs this
will crash.

:-(

This was NOT crashing before. I do not know what to do with
this stuff.

gcc dedicates a register to save the stack position
in such blocks. When the block exits, the whole stack
is restored, what means that the alloca's done are
automatically taken care of correctly.

This is a hell of expensive, since I have only 3 free registers in
the x86 32 bit architecture. This means that I would lose 33% of the
machine dedicated to holding the stack value.

gcc uses esi, and it can (with its bloated "optimize it all"
machinery) remark that this is only used in this block and
can be used elsewhere. I do not do global register allocation,
since it just would bring me a few percent speed gain at enormous
cost.

I would have to dedicate the register within the WHOLE function.

Can't you use a normal variable instead of a register?

<snip>

[Willem]

jacob wrote:
) Open questions:
) --------------
) What happens with:
)
) for (int i = 0; i<100; i++) {
) int tab[i*1024];
) int *pint = alloca(42);
) }

I just tested this on gcc-4.1.3 and it looks like the alloca()'d blocks
are freed as soon as the block is left. Not what the manpage states.

#include <stdio.h>
#include <alloca.h>

int main(void)
{
int i, n;
int *ptr[10];
n = 10;
for (i = 0; i < 10; i++) {
int tab[n];
ptr[i] = alloca(1);
}
for (i = 0; i < 10; i++) {
fprintf(stderr, "%d: %p\n", i, (void *)ptr[i]);
}
return 0;
}

Prints:

0: 0xbf8799e0
1: 0xbf8799e0
2: 0xbf8799e0
3: 0xbf8799e0
4: 0xbf8799e0
5: 0xbf8799e0
6: 0xbf8799e0
7: 0xbf8799e0
8: 0xbf8799e0
9: 0xbf8799e0
NB: This only happens in the presence of a VLA.
If you comment out the VLA, the pointers are different.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[lawrence.jones]

jacob navia <ja***@nospam.comwrote:

>
What happens with:

for (int i = 0; i<100; i++) {
int tab[i*1024];
int *pint = alloca(42);
}

With the current scheme of freeing the VLAs this
will crash.

That's why you shouldn't be recommending that people use alloca(). :-)

I can "cheat out" by writing this in the docs...

"Do not use alloca in blocks using VLAs"

That would be my suggestion. Another alternative would be to set a flag
in the compiler when you see alloca() in a block and then revert to the
previous behavior where you don't adjust the stack pointer at the end of
the block.

-Larry Jones

Years from now when I'm successful and happy, ...and he's in
prison... I hope I'm not too mature to gloat. -- Calvin

[Ben Pfaff]

jacob navia <ja***@nospam.comwrites:

I can "cheat out" by writing this in the docs...

"Do not use alloca in blocks using VLAs"

How about adding a diagnostic so that people who don't read the
docs get some help too?
--
Ben Pfaff
http://benpfaff.org

[Serve Laurijssen]

"jacob navia" <ja***@nospam.comschreef in bericht
news:fq**********@aioe.org...

1) I am storing the size of ALL VLAs in a hidden local variable
in case somebody calls sizeof(vla), and I need to return that
size. This means most of this problem was solved already.

2) I am executing code anyway when I leave a scope.

I havent seen the VLA discussion, but why would anyone want to use alloca
and VLA's at the same time?

Or does it crash too when you have a VLA and call a function that uses
alloca?

[Ian Collins]

jacob navia wrote:

After a heated discussion, I decided to fix this problem of VLAs
It took me almost the whole day to realize that

1) I am storing the size of ALL VLAs in a hidden local variable
in case somebody calls sizeof(vla), and I need to return that
size. This means most of this problem was solved already.

2) I am executing code anyway when I leave a scope.

THEN:

When leaving a scope with level bigger than function, i.e. an inner
scope, go through all local variables of that scope and see if it
is a VLA.

If it is, look where its size is stored. Read that size and add it to
the stack pointer.

That's good to hear. It's a pity not all compiler vendors respond so
quickly.

----------------------------------------------------------------

Open questions:
--------------
What happens with:

for (int i = 0; i<100; i++) {
int tab[i*1024];
int *pint = alloca(42);
}

With the current scheme of freeing the VLAs this
will crash.

Drop alloca in favour of VLAs. Or implement alloca as a wrapper over a VLA.

--
Ian Collins.

[jacob navia]

Serve Laurijssen wrote:

>
"jacob navia" <ja***@nospam.comschreef in bericht
news:fq**********@aioe.org...

>1) I am storing the size of ALL VLAs in a hidden local variable
in case somebody calls sizeof(vla), and I need to return that
size. This means most of this problem was solved already.

2) I am executing code anyway when I leave a scope.

I havent seen the VLA discussion, but why would anyone want to use
alloca and VLA's at the same time?

Or does it crash too when you have a VLA and call a function that uses
alloca?

No, that is not possible anyway since a function when leaving
will erase any alloca allocations

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Kenny McCormack]

In article <c1**********************************@f47g2000hsd. googlegroups.com>,
user923005 <dc*****@connx.comwrote:
....

>reading them. So Jacob will never go into my category for people like
'Kenny' and 'Twink' who are simply contrary for the sake of being
contrary.

No. We're not!

[Keith Thompson]

Ian Collins <ia******@hotmail.comwrites:

jacob navia wrote:

[...]

>Open questions:
--------------
What happens with:

for (int i = 0; i<100; i++) {
int tab[i*1024];
int *pint = alloca(42);
}

With the current scheme of freeing the VLAs this
will crash.

Drop alloca in favour of VLAs. Or implement alloca as a wrapper over a VLA.

The former would break any existing code that uses alloca (which I'm
not entirely convinced would be a bad thing). The latter doesn't
satisfy the required semantics of alloca; if you call alloca N times
in a loop, all N allocated objects continue to exist until the
function terminates.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ian Collins]

Keith Thompson wrote:

Ian Collins <ia******@hotmail.comwrites:

>jacob navia wrote:

[...]

>>Open questions:
--------------
What happens with:

for (int i = 0; i<100; i++) {
int tab[i*1024];
int *pint = alloca(42);
}

With the current scheme of freeing the VLAs this
will crash.

Drop alloca in favour of VLAs. Or implement alloca as a wrapper over a VLA.

The former would break any existing code that uses alloca (which I'm
not entirely convinced would be a bad thing). The latter doesn't
satisfy the required semantics of alloca; if you call alloca N times
in a loop, all N allocated objects continue to exist until the
function terminates.

How can a non-standard function have defined semantics?

--
Ian Collins.

[Serve Laurijssen]

"jacob navia" <ja***@nospam.comschreef in bericht
news:fq**********@aioe.org...

Serve Laurijssen wrote:

>>
"jacob navia" <ja***@nospam.comschreef in bericht
news:fq**********@aioe.org...

>>1) I am storing the size of ALL VLAs in a hidden local variable
in case somebody calls sizeof(vla), and I need to return that
size. This means most of this problem was solved already.

2) I am executing code anyway when I leave a scope.

I havent seen the VLA discussion, but why would anyone want to use alloca
and VLA's at the same time?

Or does it crash too when you have a VLA and call a function that uses
alloca?

No, that is not possible anyway since a function when leaving
will erase any alloca allocations

Well then the only time I can think of that somebody uses alloca and VLA's
at the same time is when a macro is used that uses VLA's or alloca and the
programmer forgot that.
A reminder by the compiler would be very handy :) It could save loads of
debugging time

[Keith Thompson]

Ian Collins <ia******@hotmail.comwrites:

Keith Thompson wrote:

>Ian Collins <ia******@hotmail.comwrites:

>>jacob navia wrote:

[...]

>>>Open questions:
--------------
What happens with:

for (int i = 0; i<100; i++) {
int tab[i*1024];
int *pint = alloca(42);
}

With the current scheme of freeing the VLAs this
will crash.

Drop alloca in favour of VLAs. Or implement alloca as a wrapper
over a VLA.

The former would break any existing code that uses alloca (which I'm
not entirely convinced would be a bad thing). The latter doesn't
satisfy the required semantics of alloca; if you call alloca N times
in a loop, all N allocated objects continue to exist until the
function terminates.

How can a non-standard function have defined semantics?

The same way malloc() had defined semantics before 1989.

Every alloc() man page I've seen says the allocated memory is freed
when the calling function returns. If an implementation wants to
provide a (non-standard) function that doesn't behave that way, it
shouldn't call it "alloca".

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Ian Collins said:

<snip>

How can a non-standard function have defined semantics?

By making it the fourth argument in a qsort call? :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Harald van =?UTF-8?b?RMSzaw==?=]

On Sat, 08 Mar 2008 15:29:15 +0530, santosh wrote:

Harald van D?k wrote:

>Unrelated to the actual topic, but a question about qsort: is the
behaviour defined if compar longjmps out of qsort when the two
arguments are considered incomparable by the application? It needs some
way to exit without returning an integer. :-)

I think so, please correct me if I'm wrong; I have hardly ever used
setjmp and longjmp.

I wasn't serious, but I'm pretty sure the behaviour's meant to be
undefined for such a case the same way as for a comparison function that
unconditionally returns 1. Neither actually violates 7.20.5p4, but that's
only because of sloppy wording, and if the sloppy wording is fixed in the
most obvious possible way (removing "That is,"), both functions would fail
to meet its requiremenets.

However I would avoid this problem in the first
place, by perhaps ensuring that there are no incomparable elements in
the array, say something like NaN. Or I might special case the compare
function so that such "invalid" values always compare either above or
below all valid values.

Yes, that's really the only sensible thing to do.

[jacob navia]

Keith Thompson wrote:

I note that the "restrict" keyword makes it possible to squeeze
slightly more interface information into a prototype than you can
without it. A hypothetical new keyword that says a pointer must be
non-null might be something similar.

In standard C you can say that a pointer is non null with

int function(int tab[static 1]);

tab must point to at least one element, hence it can't be NULL.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Harald van Dijk wrote:

Suppose the compiler can tell that for your processor, it would be more
efficient to save *end, then clear from *start to *end (inclusive), and
finally restore *end. You told the compiler that *end exists, so this is a
perfectly legitimate optimisation. Now suppose that the access to *end
aborts your program.

This is not possible, there is no compiler that will do this.

1) The compiler can't know you are going to clear memory

2) Supposing that a future, intelligent compiler deduces that
you are clearing memory. It will discover also that you
first decrement the pointer, before using it.

It is amazing how the regulars can spew completely fantasy
situations for trying to make their arguments a little less silly.

I would understand an argument like

"What an horrible syntax. I would propose this one".

etc.

But this contrived fantasy situation?

I have often argued for an attribute syntax, and Microsoft/gcc have done
their syntax. I haven't followed either, since I find it
too ugly.

I proposed this ugly syntax because it *is* the current language and it
is maybe important to know.

And it is not misuse of anything.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32