The stack and longjmp/setjmp

[Kenny McCormack]

*Yeeawwwwwn*

Is that a broken record I hear?

I would say that the count of the number of things that the regulars
"know" has now reached 3.

1) How to declare main()
2) How not to cast malloc()
3) Whether or not the C standard mentions the word "stack"

 

[Richard]

I would say that the count of the number of things that the regulars
"know" has now reached 3.

1) How to declare main()
2) How not to cast malloc()
3) Whether or not the C standard mentions the word "stack"

It was somewhat amusing to see a particularly cocky and unpleasant
clique member come unstuck in his rush to humiliate another regular
poster with regard to format specifiers. It almost makes it worthwhile
reading this group.

 

[Kenny McCormack]

It was somewhat amusing to see a particularly cocky and unpleasant
clique member come unstuck in his rush to humiliate another regular
poster with regard to format specifiers. It almost makes it worthwhile
reading this group.

Almost.

 

[Chris Dollin]

Almost.

You can stop any time you want.

You /can/ stop, right? Any time you want?

 

[Antoninus Twink]

You can stop any time you want.

You /can/ stop, right? Any time you want?

Why should he abandon CLC to The Clique? He's got as much right to
express his (much more sensible) view of what CLC should be as they do.

 

[David Thompson]

If he is, he's correct for at least the system I'm using, which explains
this its documentation for alloca.

Of course, as alloca is non-standard, other systems are permitted to
implement it differently. I don't know if any do, but I expect it would be
implemented the same way as VLAs, and VLAs can be leaked by longjmp.

Huh? What makes you think that? VLAs have the same lifetime as any
auto variable, which ends at *any* exit from the block (execution).
Any implementation that doesn't deallocate them is buggy. (Albeit not
nonconforming; nothing requires that auto space _must_ be reused,
although that's the obvious purpose and universal choice.)

Of course, *most* implementations use a single stack for all
instance-related data (as M. Navia never tires of reminding us) and
allocating VLA space on that stack means it is implicitly freed when
the stack is cut back by the longjmp, so this is easy to get right.

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[Ben Bacarisse]

<nsip> VLAs have the same lifetime as any
auto variable,

OK, so this is a comp.lang.c nit-pick, but I don't think that is true.
6.3.4 paragraphs 5 and 6 describe a subtle difference in the lifetimes
of VLAs and non-VLA auto objects.

(And, yes, this has nothing at all to do with the point your were
making which is, as usual, a good one.)

 

[Harald van Dijk]

Huh? What makes you think that?

The fact that it's specifically listed in an example attached to the
description of longjmp.

7.13.2.1p5:
EXAMPLE The longjmp function that returns control back to the point of
the setjmp invocation might cause memory associated with a variable
length array object to be squandered.

#include <setjmp.h>
jmp_buf buf;
void g(int n);
void h(int n);
int n = 6;

void f(void)
{
int x[n]; // valid: f is not terminated
setjmp(buf);
g(n);
}
void g(int n)
{
int a[n]; // a may remain allocated
h(n);
}
void h(int n)
{
int b[n]; // b may remain allocated
longjmp(buf, 2); // might cause memory loss
}

I'm aware that examples are not normative. I don't know where (if at all)
this example is reflected in the normative text.

 

[CBFalconer]

OK, so this is a comp.lang.c nit-pick, but I don't think that is
true. 6.3.4 paragraphs 5 and 6 describe a subtle difference in
the lifetimes of VLAs and non-VLA auto objects.

nitting further, there is no such thing as Section 6.3.4.

 

[Richard Heathfield]

Ben Bacarisse said:

6.3.4 paragraphs 5 and 6 describe a subtle difference in the lifetimes
of VLAs and non-VLA auto objects.

The difference must surely be very, very subtle indeed. ISO/IEC 9899:1999
has a section 6.3.2.3 and a section 6.4, but nothing in between.

 

[Ben Bacarisse]

Ben Bacarisse said:



The difference must surely be very, very subtle indeed. ISO/IEC 9899:1999
has a section 6.3.2.3 and a section 6.4, but nothing in between.

A typo, of course. Section 6.2.4.

 

[Keith Thompson]

The fact that it's specifically listed in an example attached to the
description of longjmp.

7.13.2.1p5:
EXAMPLE The longjmp function that returns control back to the point of
the setjmp invocation might cause memory associated with a variable
length array object to be squandered.

[snip]

I think the "Huh?" referred not to the fact that VLAs can be leaked by
longjmp, but by the suggestion that alloca can be implemented the same
way as VLAs.

The lifetime of a VLA ends when execution leaves the scope in which
it's declared. The lifetime of an object created by alloca() ends
when execution leaves the function in which it's called. Calling
alloca() 10 times in a loop must create 10 distinct objects (assuming
memory doesn't run out). This behavior can't be implemented by using
VLAs in any sane way.

Yes, alloca is non-standard, and some corner cases are poorly defined,
but every description of alloca that I've seen is consistent on this
point.

 

[Harald van Dijk]

The fact that it's specifically listed in an example attached to the
description of longjmp.

7.13.2.1p5:
EXAMPLE The longjmp function that returns control back to the point of
the setjmp invocation might cause memory associated with a variable
length array object to be squandered.

[snip]

I think the "Huh?" referred not to the fact that VLAs can be leaked by
longjmp, but by the suggestion that alloca can be implemented the same
way as VLAs.

Oh, that's not how I read it, but it's certainly possible he meant that.
Thanks for pointing it out.

The lifetime of a VLA ends when execution leaves the scope in which it's
declared. The lifetime of an object created by alloca() ends when
execution leaves the function in which it's called. Calling alloca() 10
times in a loop must create 10 distinct objects (assuming memory doesn't
run out). This behavior can't be implemented by using VLAs in any sane
way.

I would expect the code that handles the deallocation of a variably-sized
object to be similar regardless of whether it's performed at the end of
the current block, or at the end of the current function. It's not
possible to implement VLAs using alloca, and it's not possible to
implement alloca using VLAs, but it's possible to implement VLAs and
alloca using a common base.

Yes, alloca is non-standard, and some corner cases are poorly defined,

Interaction between alloca and VLAs could be interesting.

but every description of alloca that I've seen is consistent on this
point.

Including the description of alloca on my system.

 

[santosh]

01:29 +0100, Harald van D?k
On Wed, 05 Mar 2008 01:26:18 +0530, santosh wrote:
<snip>
Do you mean to say that memory allocated with alloca will be
properly freed even if the execution jumps to another function
via longjmp?

If he is, he's correct for at least the system I'm using, which
explains this its documentation for alloca.

Of course, as alloca is non-standard, other systems are permitted
to implement it differently. I don't know if any do, but I expect
it would be implemented the same way as VLAs, and VLAs can be
leaked by longjmp.

Huh? What makes you think that?

The fact that it's specifically listed in an example attached to the
description of longjmp.

7.13.2.1p5:
EXAMPLE The longjmp function that returns control back to the point
of the setjmp invocation might cause memory associated with a
variable length array object to be squandered.

[snip]

I think the "Huh?" referred not to the fact that VLAs can be leaked
by longjmp, but by the suggestion that alloca can be implemented the
same way as VLAs.

Oh, that's not how I read it, but it's certainly possible he meant
that. Thanks for pointing it out.

That's /not/ what David Thompson meant. To quote him:
Huh? What makes you think that? VLAs have the same lifetime as any
auto variable, which ends at any exit from the block (execution).
Any implementation that doesn't deallocate them is buggy. (Albeit not
nonconforming; nothing requires that auto space must be reused,
although that's the obvious purpose and universal choice.)

Of course, most implementations use a single stack for all
instance-related data (as M. Navia never tires of reminding us) and
allocating VLA space on that stack means it is implicitly freed when
the stack is cut back by the longjmp, so this is easy to get right.
<<<<<<

So he was talking about the possibility of memory for VLAs being leaked
with a longjmp call.

<snip>

 

[David Thompson]

(yes, that was what I was responding to, the attempts downthread to
excuse me were too generous)

The fact that it's specifically listed in an example attached to the
description of longjmp.
7.13.2.1p5: <snip>
I'm aware that examples are not normative. I don't know where (if at all)
this example is reflected in the normative text.

Wow, I missed that. Yuck! Too bad. I still would consider it a QoI
flaw to do so, but I may be unable to prove it a nonconformance.

- formerly david.thompson1 || achar(64) || worldnet.att.net