Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #399422 > unrolled thread

Using gotos with local variables in "extra" blocks: Does it get deallocated?

Back to article view | Back to comp.lang.c

Contents

  Using gotos with local variables in "extra" blocks: Does it get deallocated? gazelle@shell.xmission.com (Kenny McCormack) - 2026-05-25 13:46 +0000
    Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-25 16:19 +0200
    Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? Bart <bc@freeuk.com> - 2026-05-25 15:21 +0100
      The C23 thing (Was: Using gotos with local variables in "extra" blocks: Does it get) deallocated? gazelle@shell.xmission.com (Kenny McCormack) - 2026-05-25 14:32 +0000
      Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-25 16:34 +0200
    Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? Andrew Smallshaw <andrews@sdf.org> - 2026-05-25 16:09 +0000
      The whole point of this NG is worrying about "UB" (Was: Using gotos with local variables in "extra" blocks: Does it get) deallocated? gazelle@shell.xmission.com (Kenny McCormack) - 2026-05-25 16:54 +0000
        Re: The whole point of this NG is worrying about "UB" (Was: Using gotos with local variables in "extra" blocks: Does it get) deallocated? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-25 19:08 +0200
          Re: The whole point of this NG is worrying about "UB" (Was: Using gotos with local variables in "extra" blocks: Does it get) deallocated? gazelle@shell.xmission.com (Kenny McCormack) - 2026-05-25 17:23 +0000
            Re: The whole point of this NG is worrying about "UB" (Was: Using gotos with local variables in "extra" blocks: Does it get) deallocated? Bart <bc@freeuk.com> - 2026-05-25 18:48 +0100
    Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-25 16:35 +0000
      Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? scott@slp53.sl.home (Scott Lurndal) - 2026-05-25 17:49 +0000
        Variables in inner blocks (was: Using gotos with local variables in "extra" blocks: Does it get deallocated?) pa@see.signature.invalid (Pierre Asselin) - 2026-05-25 19:52 +0000
        Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-26 14:13 +0000
          Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? scott@slp53.sl.home (Scott Lurndal) - 2026-05-26 17:10 +0000
            Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? David Brown <david.brown@hesbynett.no> - 2026-05-26 20:31 +0200
            Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 16:24 -0700
              Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 16:36 -0700
    Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? David Brown <david.brown@hesbynett.no> - 2026-05-25 18:40 +0200
    Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-26 17:14 -0500
      Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-27 00:23 +0000
        Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? gazelle@shell.xmission.com (Kenny McCormack) - 2026-05-27 02:09 +0000
        Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-26 22:51 -0500
          Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-27 04:46 +0000
            Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? David Brown <david.brown@hesbynett.no> - 2026-05-27 09:21 +0200
          Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-27 12:40 +0000
            Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? scott@slp53.sl.home (Scott Lurndal) - 2026-05-27 14:48 +0000
            Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-27 13:39 -0700
              Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-27 17:04 -0700
                Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-27 18:16 -0700
            Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? antispam@fricas.org (Waldek Hebisch) - 2026-05-28 00:35 +0000
              Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2026-05-29 04:01 +0100
          Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-27 13:32 -0700
    Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? fir <profesor.fir@gmail.com> - 2026-05-27 15:33 +0200
      Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? Bart <bc@freeuk.com> - 2026-05-27 17:18 +0100
        Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? fir <profesor.fir@gmail.com> - 2026-05-27 18:51 +0200
          Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? fir <profesor.fir@gmail.com> - 2026-05-27 18:56 +0200
      Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-27 22:42 +0000
        Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? fir <profesor.fir@gmail.com> - 2026-05-28 07:33 +0200
          Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 05:37 +0000
            Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? fir <profesor.fir@gmail.com> - 2026-05-28 17:35 +0200
              Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? Bart <bc@freeuk.com> - 2026-05-28 16:49 +0100
                Re: Using gotos with local variables in "extra" blocks: Does it get deallocated? fir <profesor.fir@gmail.com> - 2026-05-28 18:04 +0200

Page 1 of 3  [1] 2 3  Next page →

#399422 — Using gotos with local variables in "extra" blocks: Does it get deallocated?

Trigger Warning: This post contains the dreaded "s word".  Viewer
discretion advised.

Based on some recent threads (mostly, the Bart vs. The World ones), and
also on some of my own code, I got to wondering about the following code
fragment:

    void foo(void) {
	/* stuff */
	{	/* Enter an "extra" block */
	int i = 42;	/* 'i' is allocated on the stack */
	/* stuff */
	if (someCond) goto OutOfHere;
	/* more stuff */
	}	/* End of "extra" block */
    OutOfHere: puts("Got to OutOfHere");
    }	/* End of foo() */

Now suppose someCond is true and the branch is taken.  Does the variable
'i' get deallocated (i.e., the stack pointer re-adjusted) ?

Is this guaranteed to work?

Note that in most/all "scripting" languages, this code pattern would be a
big no-no, and if you did it enough times, it will blow up the program.

Note, BTW, that we could make this issue go away by putting OutOfHere a
line earlier - i.e., inside the "extra" block - but then we'd run into
Bart's issue (i.e., we'd have to put an extra ';' after the label).

-- 
"Insisting on perfect safety is for people who don't have the balls to live
in the real world."

    - Mary Shafer, NASA Ames Dryden -

[toc] | [next] | [standalone]

#399423

On 2026-05-25 15:46, Kenny McCormack wrote:
> Trigger Warning: This post contains the dreaded "s word".  Viewer
> discretion advised.
> 
> Based on some recent threads (mostly, the Bart vs. The World ones), and
> also on some of my own code, I got to wondering about the following code
> fragment:
> 
>      void foo(void) {
> 	/* stuff */
> 	{	/* Enter an "extra" block */
> 	int i = 42;	/* 'i' is allocated on the stack */
> 	/* stuff */
> 	if (someCond) goto OutOfHere;
> 	/* more stuff */
> 	}	/* End of "extra" block */
>      OutOfHere: puts("Got to OutOfHere");
>      }	/* End of foo() */
> 
> Now suppose someCond is true and the branch is taken.  Does the variable
> 'i' get deallocated (i.e., the stack pointer re-adjusted) ?
> 
> Is this guaranteed to work?

If allowed by programming languages that's how this sort of
scope-exit usually works, yes.[*] (But for a standards-proof
answer other people have to quote the standard.) Since "C"
supports 'goto' I see no point in doing something unexpected
here.

(A similar question is for (even more drastic) setjmp/longjmp
functionality, but then you explicitly provide the environment
information.)

Usually a problem is with the intention to jump *into* such
embedded scopes, not out.

> 
> Note that in most/all "scripting" languages, this code pattern would be a
> big no-no, and if you did it enough times, it will blow up the program.

Can you give some hints on that, or examples, please?

> 
> Note, BTW, that we could make this issue go away by putting OutOfHere a
> line earlier - i.e., inside the "extra" block - but then we'd run into
> Bart's issue (i.e., we'd have to put an extra ';' after the label).

Relocating the label might work for blocks, this simple case,
but could not be used for embedded control-structures.

Janis

[*] I've got hinted on that fact first when I learned Pascal,
where it had been pointed out that a harmless looking 'goto 99'
will (have to) do all the stack-unrolling, i.e., it's not just
a low-level (assembly-like) jump statement but behind the scenes
non-trivial (for some values of "trivial").

[toc] | [prev] | [next] | [standalone]

#399424

On 25/05/2026 14:46, Kenny McCormack wrote:
> Trigger Warning: This post contains the dreaded "s word".  Viewer
> discretion advised.
> 
> Based on some recent threads (mostly, the Bart vs. The World ones), and
> also on some of my own code, I got to wondering about the following code
> fragment:
> 
>      void foo(void) {
> 	/* stuff */
> 	{	/* Enter an "extra" block */
> 	int i = 42;	/* 'i' is allocated on the stack */
> 	/* stuff */
> 	if (someCond) goto OutOfHere;
> 	/* more stuff */
> 	}	/* End of "extra" block */
>      OutOfHere: puts("Got to OutOfHere");
>      }	/* End of foo() */
> 
> Now suppose someCond is true and the branch is taken.  Does the variable
> 'i' get deallocated (i.e., the stack pointer re-adjusted) ?
> 
> Is this guaranteed to work?

You'll have to wait until the experts chime in to answer that.

Usually, simple variables like this may be allocated on the stack, but 
that merely consists of an offset within the stack frame that is 
allocated on function entry. It may share that slot with other variables 
whose lifetimes don't overlap with 'i'.

No actual allocation or deallocation is done, so there is no problem.

An optimising compiler is also likely to keep 'i' within a register 
anyway (or eliminate its use completely).

With VLAs however it is a different story. I think you can jump out of a 
block which has an active VLA, but you can't jump into it, but there are 
machinations involved.

> Note that in most/all "scripting" languages, this code pattern would be a
> big no-no,

Most won't have 'goto'. Some might not even have block scopes (so 'i' 
has function-wide scope). In any case there are usually more complicated 
things going on so extra stack manipulation would be the least of it.

> and if you did it enough times, it will blow up the program.

That would be a poor scripting language.

(In mine, anything goes, but it does ban 'goto' inside a try-except 
block since that pushes something onto the stack that needs to be 
properly dealt with before it leaves the block.)


> Note, BTW, that we could make this issue go away by putting OutOfHere a
> line earlier - i.e., inside the "extra" block - but then we'd run into
> Bart's issue (i.e., we'd have to put an extra ';' after the label).

If you followed the thread you'd have realised that isn't an issue 
anymore: if you use a C23 compiler. Somebody actually took this 
'non-problem' and persuaded the C committee to fix it.

[toc] | [prev] | [next] | [standalone]

#399425 — The C23 thing (Was: Using gotos with local variables in "extra" blocks: Does it get) deallocated?

In article <10v1lto$1ceqp$1@dont-email.me>, Bart  <bc@freeuk.com> wrote:
...
>> Note, BTW, that we could make this issue go away by putting OutOfHere a
>> line earlier - i.e., inside the "extra" block - but then we'd run into
>> Bart's issue (i.e., we'd have to put an extra ';' after the label).
>
>If you followed the thread you'd have realised that isn't an issue 
>anymore: if you use a C23 compiler. Somebody actually took this 
>'non-problem' and persuaded the C committee to fix it.

Yes, I followed it.  No, I don't have a C23 compiler.  I would imagine that
most people don't - unless they are the intentionally hyper-modern types.

I had been led to believe from those threads that gcc has, as an extension,
solved this earlier, but in my limited testing with (whatever version of)
gcc is on my system, using various -std values, gcc still objects to it.

-- 
To my knowledge, Jacob Navia is not a Christian.

    - Rick C Hodgin -

[toc] | [prev] | [next] | [standalone]

#399426

On 2026-05-25 16:21, Bart wrote:
> On 25/05/2026 14:46, Kenny McCormack wrote:
>> Trigger Warning: This post contains the dreaded "s word".  Viewer
>> discretion advised.
>>
>> Based on some recent threads (mostly, the Bart vs. The World ones), and
>> also on some of my own code, I got to wondering about the following code
>> fragment:
>>
>>      void foo(void) {
>>     /* stuff */
>>     {    /* Enter an "extra" block */
>>     int i = 42;    /* 'i' is allocated on the stack */
>>     /* stuff */
>>     if (someCond) goto OutOfHere;
>>     /* more stuff */
>>     }    /* End of "extra" block */
>>      OutOfHere: puts("Got to OutOfHere");
>>      }    /* End of foo() */
>>
>> Now suppose someCond is true and the branch is taken.  Does the variable
>> 'i' get deallocated (i.e., the stack pointer re-adjusted) ?
>>
>> Is this guaranteed to work?
> 
> You'll have to wait until the experts chime in to answer that.
> 
> Usually, simple variables like this may be allocated on the stack, but 
> that merely consists of an offset within the stack frame that is 
> allocated on function entry. It may share that slot with other variables 
> whose lifetimes don't overlap with 'i'.

I read Kenny's question as a more principle one. It can easier be
understood in, say, C++. For example with below code we observe a
correct allocation and de-allocation of the local objects...

   #include <stdio.h>

   class Int
   {
   public:
     Int () { puts("ctor"); };
     ~Int () { puts("dtor"); };
   };

   int main (void)
   {
     {
       int i = 42;
       Int j;
       if (1) goto OutOfHere;
     }
     OutOfHere: puts("Got to OutOfHere");
   }


Output:
   ctor
   dtor
   Got to OutOfHere


Janis

> 
> No actual allocation or deallocation is done, so there is no problem.
> 
> [...]

[toc] | [prev] | [next] | [standalone]

#399429

On 2026-05-25, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>
> Based on some recent threads (mostly, the Bart vs. The World ones), and
> also on some of my own code, I got to wondering about the following code
> fragment:
>
>     void foo(void) {
> 	/* stuff */
> 	{	/* Enter an "extra" block */
> 	int i = 42;	/* 'i' is allocated on the stack */
> 	/* stuff */
> 	if (someCond) goto OutOfHere;
> 	/* more stuff */
> 	}	/* End of "extra" block */
>     OutOfHere: puts("Got to OutOfHere");
>     }	/* End of foo() */
>
> Now suppose someCond is true and the branch is taken.  Does the variable
> 'i' get deallocated (i.e., the stack pointer re-adjusted) ?
>
> Is this guaranteed to work?

Personally I wouldn't worry too much about, the compiler is going
to do the right thing and speculating whether or when variables
get allocated and released is fool's game that will vary thanks to
the "as-if" rule.  My general hunch would be that i gets allocated
(whether on the stack or in a register) the instant foo() is entered
and stays there until the function exits.  More formally the extent
of i is the duration of the function but it is only in scope in
the inner block.

If the inner block executes repeatedly (e.g. it is a loop body)
although i is logically a fresh variable on each iteration in
practice it will be one and the same.  Again, the as-if rule kicks
in.  If the initialisation was not there there is no guarantee at
all as to the contents of i and so the value it had on a previous
iteration is as valid as any other.

-- 
Andrew Smallshaw
andrews@sdf.org

[toc] | [prev] | [next] | [standalone]

#399432 — The whole point of this NG is worrying about "UB" (Was: Using gotos with local variables in "extra" blocks: Does it get) deallocated?

In article <slrn1118t24.6gi.andrews@sdf.org>,
Andrew Smallshaw  <andrews@sdf.org> wrote:
...
>Personally I wouldn't worry too much about, the compiler is going
>to do the right thing and speculating whether or when variables
>get allocated and ...

But that's the whole point of this NG.  That C is *not* a "safe" language.
That getting it to compile is only the first step in having any idea that
it will behave sensibly.  I.e., you have to both know and follow the rules
in order to be confident that you haven't done something stupid.

Or, to put it another way, that, no, you can't rely on the compiler "doing
the right thing", if you've violated some obscure rule.

In a "safe" language, if it compiles, it is safe to run - e.g., BASIC (*).
The quest of modern language research is create a language that is both
safe and efficient.  Rust (about which I know zilch, so am going only on
what I've heard) seems to be the current "flavor of the month".

(*) I.e., there might still be logic errors, but at least you can be sure
that what you wrote is what gets executed.
-- 
The people who tell us to be proud of the white race are the ones who make
us the most embarrassed by it.

[toc] | [prev] | [next] | [standalone]

#399433 — Re: The whole point of this NG is worrying about "UB" (Was: Using gotos with local variables in "extra" blocks: Does it get) deallocated?

On 2026-05-25 18:54, Kenny McCormack wrote:
> In article <slrn1118t24.6gi.andrews@sdf.org>,
> Andrew Smallshaw  <andrews@sdf.org> wrote:
> ...
>> Personally I wouldn't worry too much about, the compiler is going
>> to do the right thing and speculating whether or when variables
>> get allocated and ...
> 
> But that's the whole point of this NG.  That C is *not* a "safe" language.

LOL, yeah; it's (the situation) in a way pathologically schizophrenic...

> That getting it to compile is only the first step in having any idea that
> it will behave sensibly.  I.e., you have to both know and follow the rules
> in order to be confident that you haven't done something stupid.
> 
> Or, to put it another way, that, no, you can't rely on the compiler "doing
> the right thing", if you've violated some obscure rule.

...but I think another post down-thread addresses the original question
sufficiently.

Janis

> [...]

[toc] | [prev] | [next] | [standalone]

#399434 — Re: The whole point of this NG is worrying about "UB" (Was: Using gotos with local variables in "extra" blocks: Does it get) deallocated?

In article <10v1vmr$1s757$7@dont-email.me>,
Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
...
>> Or, to put it another way, that, no, you can't rely on the compiler "doing
>> the right thing", if you've violated some obscure rule.
>
>...but I think another post down-thread addresses the original question
>sufficiently.

Agreed.  I think I've got my answer.

When you get right down to it, as long as you can be sure it is deallocated
(however you choose to define that term) when the function exits, then
there's really nothing to worry about.

I can imagine a few tests, though, that might be interesting.  Like having
a million or so blocks like this, and have each one jump out from the
middle.  And then you could keep track of how things are going by printing
out the address of i (using printf and %p) and see if they are the same or
different.

Might be a fun thing to do on a rainy day...

-- 
"It does a lot of things half well and it's just a garbage heap of ideas that are
mutually exclusive."

	- Ken Thompson, on C++ -

[toc] | [prev] | [next] | [standalone]

#399435 — Re: The whole point of this NG is worrying about "UB" (Was: Using gotos with local variables in "extra" blocks: Does it get) deallocated?

On 25/05/2026 18:23, Kenny McCormack wrote:
> In article <10v1vmr$1s757$7@dont-email.me>,
> Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
> ...
>>> Or, to put it another way, that, no, you can't rely on the compiler "doing
>>> the right thing", if you've violated some obscure rule.
>>
>> ...but I think another post down-thread addresses the original question
>> sufficiently.
> 
> Agreed.  I think I've got my answer.
> 
> When you get right down to it, as long as you can be sure it is deallocated
> (however you choose to define that term) when the function exits, then
> there's really nothing to worry about.

Not for simple variables. Unless they refer to some resource that needs 
freeing using the value of the variable. But this is just normal 
housekeeping in C.

> 
> I can imagine a few tests, though, that might be interesting.  Like having
> a million or so blocks like this, and have each one jump out from the
> middle.  And then you could keep track of how things are going by printing
> out the address of i (using printf and %p) and see if they are the same or
> different.

Obtaining the address of i forces it to be in memory rather than a 
register. Then, if you have a million nested blocks each declaring 'int 
i;' and using '&i', you will probably get a stack overflow at runtime, 
but it will probably fail to compile anyway (see below):.

> Might be a fun thing to do on a rainy day...

Today's the hottest day of the year in the UK, so I tried a program like 
this:

{int i=rand(); printf("%p\n", &i);
{int i=rand(); printf("%p\n", &i);
{int i=rand(); printf("%p\n", &i);
}
}
}

using N = 1000000 instead of 3. But I couldn't get it to compile:

tcc       crashed
gcc 16    stopped after 20 seconds, but no EXE generated
DMC       After 20-30 seconds, errorcode -1073741571
lccwin32  After a few seconds, errorcode -1073741571 also (?)
bcc       Immediate error "too many block levels"

With a smaller N however, then you just get lots of different addresses 
since they are nested and their lifetimes overlap. With a version like this:

{int i=rand(); printf("%p\n", &i);}
{int i=rand(); printf("%p\n", &i);}
{int i=rand(); printf("%p\n", &i);}

Then the addresses are either all different still, or the same, 
depending on compiler and options.

[toc] | [prev] | [next] | [standalone]

#399430

In article <10v1jrr$35gqh$2@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:
>Trigger Warning: This post contains the dreaded "s word".  Viewer
>discretion advised.
>
>Based on some recent threads (mostly, the Bart vs. The World ones), and
>also on some of my own code, I got to wondering about the following code
>fragment:
>
>    void foo(void) {
>	/* stuff */
>	{	/* Enter an "extra" block */
>	int i = 42;	/* 'i' is allocated on the stack */
>	/* stuff */
>	if (someCond) goto OutOfHere;
>	/* more stuff */
>	}	/* End of "extra" block */
>    OutOfHere: puts("Got to OutOfHere");
>    }	/* End of foo() */
>
>Now suppose someCond is true and the branch is taken.  Does the variable
>'i' get deallocated (i.e., the stack pointer re-adjusted) ?
>
>Is this guaranteed to work?

The variable `i` will be deallocated, yes.  But if the question
is whether that happens immediately after the `goto` or not,
then it's that's a different question.

The standard says that if a variable with "automatic storage
duration" is not a VLA (which describes `i` in this case), then
the lifetime of the object ends when "execution of that block
ends in any way" (sec 6.2.4 of the various standards; para 6 in
n3220).

Here, "lifetime" is defined as, "the portion of program
execution during which storage is guaranteed to be reserved for
it."

So whether or not the storage is _immediately_ reclaimed is
another matter; it may be immediately deallocated after exiting
the block, or when the function returns, or some other time.

>Note that in most/all "scripting" languages, this code pattern would be a
>big no-no, and if you did it enough times, it will blow up the program.

Huh.  Which languages?

>Note, BTW, that we could make this issue go away by putting OutOfHere a
>line earlier - i.e., inside the "extra" block - but then we'd run into
>Bart's issue (i.e., we'd have to put an extra ';' after the label).

It actually doesn't change the issue at all; whether "execution"
of the block ends due to a `goto` out of it or reaching the end
of the block as written is irrelevant: it'll be deallocated
regardless.  But whether that happens immediately or not is
another matter.

Assuming a stack-based implementation, I'd assume most compilers
would deallocate it when the enclosing function returns.


	- Dan C.

[toc] | [prev] | [next] | [standalone]

#399436

cross@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <10v1jrr$35gqh$2@news.xmission.com>,
>Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>Trigger Warning: This post contains the dreaded "s word".  Viewer
>>discretion advised.
>>
>>Based on some recent threads (mostly, the Bart vs. The World ones), and
>>also on some of my own code, I got to wondering about the following code
>>fragment:
>>
>>    void foo(void) {
>>	/* stuff */
>>	{	/* Enter an "extra" block */
>>	int i = 42;	/* 'i' is allocated on the stack */
>>	/* stuff */
>>	if (someCond) goto OutOfHere;
>>	/* more stuff */
>>	}	/* End of "extra" block */
>>    OutOfHere: puts("Got to OutOfHere");
>>    }	/* End of foo() */
>>
>>Now suppose someCond is true and the branch is taken.  Does the variable
>>'i' get deallocated (i.e., the stack pointer re-adjusted) ?
>>
>>Is this guaranteed to work?
>
>The variable `i` will be deallocated, yes.  But if the question
>is whether that happens immediately after the `goto` or not,
>then it's that's a different question.
>
>The standard says that if a variable with "automatic storage
>duration" is not a VLA (which describes `i` in this case), then
>the lifetime of the object ends when "execution of that block
>ends in any way" (sec 6.2.4 of the various standards; para 6 in
>n3220).
>
>Here, "lifetime" is defined as, "the portion of program
>execution during which storage is guaranteed to be reserved for
>it."
>
>So whether or not the storage is _immediately_ reclaimed is
>another matter; it may be immediately deallocated after exiting
>the block, or when the function returns, or some other time.
>
>>Note that in most/all "scripting" languages, this code pattern would be a
>>big no-no, and if you did it enough times, it will blow up the program.
>
>Huh.  Which languages?
>
>>Note, BTW, that we could make this issue go away by putting OutOfHere a
>>line earlier - i.e., inside the "extra" block - but then we'd run into
>>Bart's issue (i.e., we'd have to put an extra ';' after the label).
>
>It actually doesn't change the issue at all; whether "execution"
>of the block ends due to a `goto` out of it or reaching the end
>of the block as written is irrelevant: it'll be deallocated
>regardless.  But whether that happens immediately or not is
>another matter.
>
>Assuming a stack-based implementation, I'd assume most compilers
>would deallocate it when the enclosing function returns.

In believe in most cases, the compiler simply adds the required
storage space for all variables defined in inner-blocks to the
initial stack allocation on function entry. Which is all "deallocated"
when the function returns.  Indeed, I believe that the storage
reserved for inner block variables can be repurposed and used
in subsequent inner-blocks that have local variables in the same
function. 

[toc] | [prev] | [next] | [standalone]

#399437 — Variables in inner blocks (was: Using gotos with local variables in "extra" blocks: Does it get deallocated?)

Scott Lurndal <scott@slp53.sl.home> wrote:

> In believe in most cases, the compiler simply adds the required
> storage space for all variables defined in inner-blocks to the
> initial stack allocation on function entry. Which is all "deallocated"
> when the function returns.

Yeah, I believe so. But in some code I was working on back in 2009,
I had the following pattern in a function that called itself
recursively:

    static void fou(struct something *x)
    {
	struct something *y[3];
	{
	    /* declare many more variables */
	    /* do things that fill the y[] array of pointers */
	}
	if(y[0]) fou(y[0]);
	if(y[1]) fou(y[1]);
	if(y[2]) fou(y[2]);
    }

I put most of the function body in an inner block, hoping that the
inner variables would be deallocated before the recursive phase
and that stack usage would be reduced.

I don't think my micro-optimization worked. It didn't matter,
even with the larger stack frame the function never came close
to blowing up.

(It was a part of a 3D tetrahedral mesher. I'll have to try
with a small self-contained example and look at the assembler.)

-- 
pa at panix dot com

[toc] | [prev] | [next] | [standalone]

#399439

In article <DY%QR.370372$gO1.309583@fx14.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>In article <10v1jrr$35gqh$2@news.xmission.com>,
>>Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>>Trigger Warning: This post contains the dreaded "s word".  Viewer
>>>discretion advised.
>>>
>>>Based on some recent threads (mostly, the Bart vs. The World ones), and
>>>also on some of my own code, I got to wondering about the following code
>>>fragment:
>>>
>>>    void foo(void) {
>>>	/* stuff */
>>>	{	/* Enter an "extra" block */
>>>	int i = 42;	/* 'i' is allocated on the stack */
>>>	/* stuff */
>>>	if (someCond) goto OutOfHere;
>>>	/* more stuff */
>>>	}	/* End of "extra" block */
>>>    OutOfHere: puts("Got to OutOfHere");
>>>    }	/* End of foo() */
>>>
>>>Now suppose someCond is true and the branch is taken.  Does the variable
>>>'i' get deallocated (i.e., the stack pointer re-adjusted) ?
>>>
>>>Is this guaranteed to work?
>>
>>The variable `i` will be deallocated, yes.  But if the question
>>is whether that happens immediately after the `goto` or not,
>>then it's that's a different question.
>>
>>The standard says that if a variable with "automatic storage
>>duration" is not a VLA (which describes `i` in this case), then
>>the lifetime of the object ends when "execution of that block
>>ends in any way" (sec 6.2.4 of the various standards; para 6 in
>>n3220).
>>
>>Here, "lifetime" is defined as, "the portion of program
>>execution during which storage is guaranteed to be reserved for
>>it."
>>
>>So whether or not the storage is _immediately_ reclaimed is
>>another matter; it may be immediately deallocated after exiting
>>the block, or when the function returns, or some other time.
>>
>>>Note that in most/all "scripting" languages, this code pattern would be a
>>>big no-no, and if you did it enough times, it will blow up the program.
>>
>>Huh.  Which languages?
>>
>>>Note, BTW, that we could make this issue go away by putting OutOfHere a
>>>line earlier - i.e., inside the "extra" block - but then we'd run into
>>>Bart's issue (i.e., we'd have to put an extra ';' after the label).
>>
>>It actually doesn't change the issue at all; whether "execution"
>>of the block ends due to a `goto` out of it or reaching the end
>>of the block as written is irrelevant: it'll be deallocated
>>regardless.  But whether that happens immediately or not is
>>another matter.
>>
>>Assuming a stack-based implementation, I'd assume most compilers
>>would deallocate it when the enclosing function returns.
>
>In believe in most cases, the compiler simply adds the required
>storage space for all variables defined in inner-blocks to the
>initial stack allocation on function entry. Which is all "deallocated"
>when the function returns.  Indeed, I believe that the storage
>reserved for inner block variables can be repurposed and used
>in subsequent inner-blocks that have local variables in the same
>function. 

Almost certainly, yes.  Of course there are some exceptions, but
the vast bulk of real-world implementations will use a stack and
likely do exactly what you just said.  And on exit, deallocating
a stack frame may as simple as a single instruction.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#399441

cross@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <DY%QR.370372$gO1.309583@fx14.iad>,
>Scott Lurndal <slp53@pacbell.net> wrote:
>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>In article <10v1jrr$35gqh$2@news.xmission.com>,
>>>Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>>>Trigger Warning: This post contains the dreaded "s word".  Viewer
>>>>discretion advised.
>>>>
>>>>Based on some recent threads (mostly, the Bart vs. The World ones), and
>>>>also on some of my own code, I got to wondering about the following code
>>>>fragment:
>>>>
>>>>    void foo(void) {
>>>>	/* stuff */
>>>>	{	/* Enter an "extra" block */
>>>>	int i = 42;	/* 'i' is allocated on the stack */
>>>>	/* stuff */
>>>>	if (someCond) goto OutOfHere;
>>>>	/* more stuff */
>>>>	}	/* End of "extra" block */
>>>>    OutOfHere: puts("Got to OutOfHere");
>>>>    }	/* End of foo() */
>>>>
>>>>Now suppose someCond is true and the branch is taken.  Does the variable
>>>>'i' get deallocated (i.e., the stack pointer re-adjusted) ?
>>>>
>>>>Is this guaranteed to work?
>>>
>>>The variable `i` will be deallocated, yes.  But if the question
>>>is whether that happens immediately after the `goto` or not,
>>>then it's that's a different question.
>>>
>>>The standard says that if a variable with "automatic storage
>>>duration" is not a VLA (which describes `i` in this case), then
>>>the lifetime of the object ends when "execution of that block
>>>ends in any way" (sec 6.2.4 of the various standards; para 6 in
>>>n3220).
>>>
>>>Here, "lifetime" is defined as, "the portion of program
>>>execution during which storage is guaranteed to be reserved for
>>>it."
>>>
>>>So whether or not the storage is _immediately_ reclaimed is
>>>another matter; it may be immediately deallocated after exiting
>>>the block, or when the function returns, or some other time.
>>>
>>>>Note that in most/all "scripting" languages, this code pattern would be a
>>>>big no-no, and if you did it enough times, it will blow up the program.
>>>
>>>Huh.  Which languages?
>>>
>>>>Note, BTW, that we could make this issue go away by putting OutOfHere a
>>>>line earlier - i.e., inside the "extra" block - but then we'd run into
>>>>Bart's issue (i.e., we'd have to put an extra ';' after the label).
>>>
>>>It actually doesn't change the issue at all; whether "execution"
>>>of the block ends due to a `goto` out of it or reaching the end
>>>of the block as written is irrelevant: it'll be deallocated
>>>regardless.  But whether that happens immediately or not is
>>>another matter.
>>>
>>>Assuming a stack-based implementation, I'd assume most compilers
>>>would deallocate it when the enclosing function returns.
>>
>>In believe in most cases, the compiler simply adds the required
>>storage space for all variables defined in inner-blocks to the
>>initial stack allocation on function entry. Which is all "deallocated"
>>when the function returns.  Indeed, I believe that the storage
>>reserved for inner block variables can be repurposed and used
>>in subsequent inner-blocks that have local variables in the same
>>function. 
>
>Almost certainly, yes.  Of course there are some exceptions, but
>the vast bulk of real-world implementations will use a stack and
>likely do exactly what you just said.  And on exit, deallocating
>a stack frame may as simple as a single instruction.

Experimenting with gcc (4.8.3, 14.2.1) shows that the
stack layout depends on -O.

int fff(int yyy, int xxx)
{
    int ab = yyy + xxx;

    {
       int bb;
       printf("%p\n", &bb);
    }

    {
       int bc;
       printf("%p\n", &bc);
    }

    printf("%p\n", &ab);

    return 0;
}

int main()
{
    fff(1,2);
}

--------------
Without -O:
$ /tmp/a
0x7ffe40c2f338
0x7ffe40c2f334
0x7ffe40c2f33c

With -O3:
$ /tmp/a                   
0x7ffe21e5833c
0x7ffe21e5833c
0x7ffe21e58330

[toc] | [prev] | [next] | [standalone]

#399442

On 26/05/2026 19:10, Scott Lurndal wrote:
> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> In article <DY%QR.370372$gO1.309583@fx14.iad>,
>> Scott Lurndal <slp53@pacbell.net> wrote:
>>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>> In article <10v1jrr$35gqh$2@news.xmission.com>,
>>>> Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>>>> Trigger Warning: This post contains the dreaded "s word".  Viewer
>>>>> discretion advised.
>>>>>
>>>>> Based on some recent threads (mostly, the Bart vs. The World ones), and
>>>>> also on some of my own code, I got to wondering about the following code
>>>>> fragment:
>>>>>
>>>>>     void foo(void) {
>>>>> 	/* stuff */
>>>>> 	{	/* Enter an "extra" block */
>>>>> 	int i = 42;	/* 'i' is allocated on the stack */
>>>>> 	/* stuff */
>>>>> 	if (someCond) goto OutOfHere;
>>>>> 	/* more stuff */
>>>>> 	}	/* End of "extra" block */
>>>>>     OutOfHere: puts("Got to OutOfHere");
>>>>>     }	/* End of foo() */
>>>>>
>>>>> Now suppose someCond is true and the branch is taken.  Does the variable
>>>>> 'i' get deallocated (i.e., the stack pointer re-adjusted) ?
>>>>>
>>>>> Is this guaranteed to work?
>>>>
>>>> The variable `i` will be deallocated, yes.  But if the question
>>>> is whether that happens immediately after the `goto` or not,
>>>> then it's that's a different question.
>>>>
>>>> The standard says that if a variable with "automatic storage
>>>> duration" is not a VLA (which describes `i` in this case), then
>>>> the lifetime of the object ends when "execution of that block
>>>> ends in any way" (sec 6.2.4 of the various standards; para 6 in
>>>> n3220).
>>>>
>>>> Here, "lifetime" is defined as, "the portion of program
>>>> execution during which storage is guaranteed to be reserved for
>>>> it."
>>>>
>>>> So whether or not the storage is _immediately_ reclaimed is
>>>> another matter; it may be immediately deallocated after exiting
>>>> the block, or when the function returns, or some other time.
>>>>
>>>>> Note that in most/all "scripting" languages, this code pattern would be a
>>>>> big no-no, and if you did it enough times, it will blow up the program.
>>>>
>>>> Huh.  Which languages?
>>>>
>>>>> Note, BTW, that we could make this issue go away by putting OutOfHere a
>>>>> line earlier - i.e., inside the "extra" block - but then we'd run into
>>>>> Bart's issue (i.e., we'd have to put an extra ';' after the label).
>>>>
>>>> It actually doesn't change the issue at all; whether "execution"
>>>> of the block ends due to a `goto` out of it or reaching the end
>>>> of the block as written is irrelevant: it'll be deallocated
>>>> regardless.  But whether that happens immediately or not is
>>>> another matter.
>>>>
>>>> Assuming a stack-based implementation, I'd assume most compilers
>>>> would deallocate it when the enclosing function returns.
>>>
>>> In believe in most cases, the compiler simply adds the required
>>> storage space for all variables defined in inner-blocks to the
>>> initial stack allocation on function entry. Which is all "deallocated"
>>> when the function returns.  Indeed, I believe that the storage
>>> reserved for inner block variables can be repurposed and used
>>> in subsequent inner-blocks that have local variables in the same
>>> function.
>>
>> Almost certainly, yes.  Of course there are some exceptions, but
>> the vast bulk of real-world implementations will use a stack and
>> likely do exactly what you just said.  And on exit, deallocating
>> a stack frame may as simple as a single instruction.
> 
> Experimenting with gcc (4.8.3, 14.2.1) shows that the
> stack layout depends on -O.
> 

One of the reasons for using -O0 is debugging, especially with weaker 
debuggers.  As gcc gives every variable its own stack slot, these remain 
consistent throughout the function, making it easier to see.  When 
registers and stack slots are re-used it becomes harder for the debugger 
(and the person doing the debugging) to view the local variables at 
different points in the function.

[toc] | [prev] | [next] | [standalone]

#399571

scott@slp53.sl.home (Scott Lurndal) writes:

[asking about when the storage for local variables in
 nested blocks will be deallocated]

> Experimenting with gcc (4.8.3, 14.2.1) shows that the
> stack layout depends on -O.

Sure.  Isn't that what anyone would expect?  (Not meant
rhetorically.)

> int fff(int yyy, int xxx)
> {
>     int ab = yyy + xxx;
>
>     {
>        int bb;
>        printf("%p\n", &bb);
>     }
>
>     {
>        int bc;
>        printf("%p\n", &bc);
>     }
>
>     printf("%p\n", &ab);
>
>     return 0;
> }

This function has undefined behavior.

[toc] | [prev] | [next] | [standalone]

#399573

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> scott@slp53.sl.home (Scott Lurndal) writes:
[...]
>> int fff(int yyy, int xxx)
>> {
>>     int ab = yyy + xxx;
>>
>>     {
>>        int bb;
>>        printf("%p\n", &bb);
>>     }
>>
>>     {
>>        int bc;
>>        printf("%p\n", &bc);
>>     }
>>
>>     printf("%p\n", &ab);
>>
>>     return 0;
>> }
>
> This function has undefined behavior.

Yes, it has undefined behavior because "%p" requires an argument
of type void*.  The second argument in each printf call should be
cast to void*.

Is that what you're referring to?  Do you see any other instance
of undefined behavior (assuming xxx + yyy doesn't overflow)?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#399431

On 25/05/2026 15:46, Kenny McCormack wrote:
> Trigger Warning: This post contains the dreaded "s word".  Viewer
> discretion advised.
> 
> Based on some recent threads (mostly, the Bart vs. The World ones), and
> also on some of my own code, I got to wondering about the following code
> fragment:
> 
>      void foo(void) {
> 	/* stuff */
> 	{	/* Enter an "extra" block */
> 	int i = 42;	/* 'i' is allocated on the stack */
> 	/* stuff */
> 	if (someCond) goto OutOfHere;
> 	/* more stuff */
> 	}	/* End of "extra" block */
>      OutOfHere: puts("Got to OutOfHere");
>      }	/* End of foo() */
> 
> Now suppose someCond is true and the branch is taken.  Does the variable
> 'i' get deallocated (i.e., the stack pointer re-adjusted) ?
> 
> Is this guaranteed to work?

C does not really have allocating and deallocating of local variables - 
the important concepts here are the storage duration and the lifetime 
(as defined by the C standards).  Then it is up to the compiler to make 
sure any relevant stack slots or registers are available during that 
lifetime.

For a variable that is not a VLA, the lifetime starts at the entry to 
it's block and continues until that block ends in any way.  That also 
applies whether you jump into the block rather than "executing" the 
opening brace, or jump out of the block rather than "executing" the 
closing brace.  (For a VLA, the lifetime starts at the declaration, 
since the actual type and size of the VLA may not be known until then.)

Initialisation is done when execution flow hits the declaration and 
initialisation - just like a normal assignment.  And if you jump into a 
block, past the initialisation, the variable exists (it is within its 
lifetime) but is indeterminate (uninitialised).

The scope is from the declaration until the end of the block.  But it is 
possible to do weird things with goto's where you are within the 
lifetime, but outside the scope :

	int x = 123;
	int *p = &x;
	{
	label:
		printf("%i\n", *p);
		int y = 456;
		p = &y;
		x++;
		if (x == 124) goto label;
	}

That will print "123" then "456".  The second "printf" is using "*p" to 
access the storage of "y" inside its lifetime, but outside its scope.


But if you are wondering how compilers handle code like your example, 
rather than what the semantics of it are, then there is no single fixed 
answer.  Compilers will typically use registers for local variables 
where they can, rather than stack slots.  And whether they use registers 
or stack slots, these do not have to be fixed - the same variable can be 
moved around, and multiple bits of data can be stored in the same 
register or stack slot.  If the compiler doesn't actually have to store 
a value to get the correct runtime behaviour, it can eliminate the 
variable entirely.  And if the stack is used, it is common for all the 
stack space to be allocated (i.e., the stack pointer decremented for a 
downwards-growing stack, and possibly a frame pointer set up) at the 
function entry and the stack restored at function exit - you don't 
usually see individual stack manipulations for separate variables.

[toc] | [prev] | [next] | [standalone]

#399443

On 5/25/2026 8:46 AM, Kenny McCormack wrote:
> Trigger Warning: This post contains the dreaded "s word".  Viewer
> discretion advised.
> 
> Based on some recent threads (mostly, the Bart vs. The World ones), and
> also on some of my own code, I got to wondering about the following code
> fragment:
> 
>      void foo(void) {
> 	/* stuff */
> 	{	/* Enter an "extra" block */
> 	int i = 42;	/* 'i' is allocated on the stack */
> 	/* stuff */
> 	if (someCond) goto OutOfHere;
> 	/* more stuff */
> 	}	/* End of "extra" block */
>      OutOfHere: puts("Got to OutOfHere");
>      }	/* End of foo() */
> 
> Now suppose someCond is true and the branch is taken.  Does the variable
> 'i' get deallocated (i.e., the stack pointer re-adjusted) ?
> 
> Is this guaranteed to work?
> 
> Note that in most/all "scripting" languages, this code pattern would be a
> big no-no, and if you did it enough times, it will blow up the program.
> 
> Note, BTW, that we could make this issue go away by putting OutOfHere a
> line earlier - i.e., inside the "extra" block - but then we'd run into
> Bart's issue (i.e., we'd have to put an extra ';' after the label)

What is the dreaded s word, scripting ?

Lynn

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web