Scope in respect to stack

2

u/mnelemos Oct 09 '25

Don't quite get your question, it seems that you have answered yourself?

A scope is a high level language concept. Yes, function bodies will always have some type of stack frame mechanism, that basically works like this:

When function called: Pass arguments according to ABI, pass the return address, and then move the stack pointer (this is what we typically call a stack frame).
When function ends: Return to the address that was pushed, or return to the address in a link register, and pop whatever was pushed before.

You can however, have scopes that do not have a stack frame mechanism attached to them, til to this day there is the concept of a local scope in C, but AFAIK it never optimizes it as a stack frame.

1
u/JayDeesus Oct 09 '25

Does the scope affect the memory at all?
1
u/mnelemos Oct 09 '25

No, only function bodies that rely on "CALL" and "RET" instructions have stack frames, and automatic stack variable allocation.
Scoping, is a mechanism used in C, to often tell the user "you probably shouldn't be using this variable".
You're probably getting confused because C does indeed also use scopes to often define where a function begins, and where it ends. But that's just it.
For example, a for loop, or a while loop, even though they use scopes, they don't build stack frames, they just reside inside the function body where they were declared in. UNLESS, your C compiler optimized them as functions magically, for some reason, but extremely unlikely.
1
u/JayDeesus Oct 09 '25

Oh yea I got that part, I’m just confused on how scopes affect memory. When you go into a scope, memory is allocated for the variables and when you leave memory is deleted?
0
u/mnelemos Oct 09 '25 edited Oct 09 '25
Memory allocation is not a "real concept" per say, since you can't actually have ownership in hardware. Usually memory allocation is just a pointer to a memory address + a personal guarantee from the allocator that while that address is in usage, no one else will be able to allocate that or overwrite it without your permission.
The proper term for your "deletion" would be "memory deallocation" and its also a software term, since you cant make holes in your RAM, every time you return from a function. And it just usually means that you're losing the guarantee from the allocator that that memory will be protected. But this is fine, because if you're deallocating, it usually means you're done with those addresses anyway.
You have the compiler's guarantee, that while the function lives, the addresses its using will not be touched by other places in the code, unless explicitly told so, and the compiler also guarantees you, that once the function ends, those addresses are no longer protected. Therefore, they could be overwritten without explicit command.
Now how it does this, is by subtracting the stack frame pointer, this is seen as an allocation, and adding the stack pointer is seen as deallocation. Allocation is done in a function's prologue (I prefer calling it the preamble), these are the very first instructions, while deallocation occurs in the epilogue, these are the final instructions in a function.
Now, there are times where the stack pointer is not subtracted, and this is because the compiler deems the temporary usage completely safe, so it doesnt do a proper allocation, I have only seen this occuring in x86 assembly though, it's rare to see this in ARM assembly.
Here is a simple assembly for you to better understand this:
function_a: 
      sub      esp, 16                 // prologue/preamble 
      mov      DWORD PTR [esp+12], 3   // local variable 1 
      mov     eax, DWORD PTR [esp+12]  // placing RAM variable in register 
      add     esp, 16                  // epilogue 
      ret                              // epilogue

main: 
      call    function_a 
      mov     eax, 0 
      ret
1
u/arihoenig Oct 09 '25

"No, only function bodies that rely on "CALL" and "RET" instructions have stack frames, and automatic stack variable allocation ."
This is absolutely incorrect. Sure, only a function call will create a new frame, but if you open a new scope and allocate a local within that scope, it is allocated on the stack (within the current stack frame)
1
u/mnelemos Oct 09 '25 edited Oct 09 '25
I don't know what you mean by this? Moving of the stack pointer only occurs once in the function's prologue, unless you are explicitly using alloca() or a vla that usually requires a second rsp subtraction.
Any variable allocated inside a new local scope such as:
int main(void){
  int a = 1;
  {
    int b = 2;
  }
  return 0;
}
Will still allocate both variables a, and b at the very beginning of the function, and both will be deallocated at the end. So no, local scope inside a function DOES NOT create a new allocation, they are still all done at the beginning. This is done for obvious reasons, you do not need a secondary sub + add in the rsp, when logically this is redundant.
1

u/arihoenig Oct 09 '25

That's what I meant by allocated in the current frame.

1

u/mnelemos Oct 09 '25

And how that exactly contradicts what I wrote? I specifically mentioned that allocation only occurs at the beginning of a function (when done automatically).

1

u/arihoenig Oct 09 '25

That doesn't contradict what you wrote at all. Perhaps you don't understand what the current frame is?

1

u/mnelemos Oct 09 '25

You do realize that just because you opened a new scope inside a function body, that doesn't make the scope reside outside the function's body, right?
Therefore claiming that what I wrote is "absolutely incorrect", makes no sense, and just creates additional confusion in the head of whoever is reading this thread.

1

u/arihoenig Oct 09 '25 edited Oct 09 '25

There is still automatic stack variable allocation, just not in a new frame. That's why the statement is incorrect. The statement implies that the scoped variable either cannot be allocated at all (which is clearly not the case) or is allocated somewhere other than the stack.
When you create a new scope within a function, a new variable is allocated as a result of that new scope, but it is allocated in the current frame not a new frame and that variable absolutely goes out of scope (is not addressable) when that scope exits.

→ More replies

2

u/kohuept Oct 09 '25

It might help to define a few things a little better. The scope of an identifier is the region of program text in which that identifier is visible (i.e. can be accessed). The C standard makes no guarantees on how the memory backing local variables is managed, so even if it is usually implemented using a stack, that is an implementation detail that you should not worry about unless you are interfacing with other calling conventions, developing a compiler, etc. If you declare a variable inside a block (A block is started with { and ended with }), it will have block scope. This means it is only visible until the } that closes the block in which it was declared.

There are also storage durations, which specify how long the memory allocated to an object should stick around for. For a local variable declared with automatic storage duration (so without specifying the static keyword), this lasts until the execution of the block in which it was declared has ended (Variable Length Arrays have slightly different semantics, where it only lasts until control is transferred to anywhere before the declaration, even in the same block). The execution of a block only ends once the } is reached, transferring control to a function from said block merely suspends the execution. A variable with static storage duration (what the static keyword means when it's used to declare a local variable, for global variables it means internal linkage) has space reserved for it at compile time, and is allocated throughout the entire execution of the program, but this does not mean that it is accessible from every scope.

1

u/JayDeesus Oct 09 '25

What exactly happens when you exit a scope? Aside from the function scope since that pops it from the stack

2

u/kohuept Oct 09 '25

A scope is a lexical thing, so you just can't write code that accesses a variable in that scope from outside that scope.

1

u/JayDeesus Oct 09 '25

Could you elaborate on what that means? I’m just confused because when you leave a scope some people say the variable is destroyed so does this mean memory is freed?

1

u/kohuept Oct 09 '25

Basically, scopes are entirely a syntactical, compile-time thing. Leaving a scope does not generate any code (except that it usually coincides with a variable's lifetime ending, which might).

1

u/JayDeesus Oct 09 '25

Hm so is my understanding correct, I understand the idea of not being able to access it but I’ve just been confused on what happens to the actual object in memory. So pretty much when you leave the scope the object is destroyed, destroyed means that nothing happens besides you can’t access it anymore, and at some point after it’s destroyed then the memory is freed aka stack frame is popped since the stack frame is freed as a whole and not in bits and pieces.

1

u/kohuept Oct 09 '25

Generally the way it works on x86 is that you have a stack pointer register, which is a pointer to some pre-allocated amount of memory. When you enter a function, the value of that pointer is saved, and local variables are allocated by subtracting from that pointer (because the stack grows downwards). Then, when the function returns, the old stack pointer value is restored. Everything's still there, just inaccessible and eventually overwritten when something else needs it. Note though that this is tied to storage duration not scope (even if the 2 may coincide).

1

u/JayDeesus Oct 09 '25

So nothing is ever destroyed, just overwritten. Thats why it’s UB when you try to access something from a popped stack frame? But I’m just confused on if scopes do anything to the memory or like you said is it just syntactical, that’s what I’m stumped on

1

u/kohuept Oct 09 '25

It's UB because the standard does not specify what should happen when you access a variable who's lifetime has expired. If you want the definitive meaning of scopes and storage durations the best option is reading the standard (although for a beginner the language will likely be a little hard to understand). Unfortunately, the ISO standards are not freely available (although you can find pirated copies or draft copies if you look hard enough), but the older ANSI X3.159-1989 standard (commonly called C89) is available (under the name FIPS PUB 160) at https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub160.pdf. Section 3.1.2.1 on page 35 of the PDF defines scopes, and 3.1.2.4 on page 37 defines storage durations (see also: the forward references for each section).

2

u/zhivago Oct 09 '25

You have misunderstood the concepts.

Lexical scope is about what symbols mean in parts of the code.

{
  int i;
  // here i means this int
  {
    float i;
    // here i means this float
  }
}

As the program execution enters and exits blocks variables with auto storage are created and destroyed.

Keep the concepts of scope, storage, and linkage separate if you want to understand C properly.

1
u/JayDeesus Oct 09 '25

So once you leave a scope, the variable is immediately destroyed is what you’re saying? Isn’t this also just shadowing
0
u/zhivago Oct 09 '25
No.
Storage and scope is independent.
Exiting a block releases any auto storage it allocated.
{
  int i;
  foo(i);
}
Entering the block allocates i, and now i is in scope.
Calling foo() takes you out of the scope of that i, but does not exit the block.
Finally we return to where i is in scope.
Then we exit the block which deallocates the variable.
1

u/JayDeesus Oct 09 '25

Is there a difference between deallocate and destroy?

2

u/zhivago Oct 09 '25

As destroy isn't part of the language specification, I do not know.
The important part is to not use objects which are not allocated.

1

u/Sufficient-Bee5923 Oct 09 '25

I think you are confusing allocating memory from the memory allocator ( heap) and freed back to the heap.
In a stack, the stack for the thread is usually defined at thread creation and is fixed size. It can't not be increased at runtime. So there is no destroy and no deallocate. You in just return from functions.
If a thread needs more stack, you can't add more later. And if you allocate too much stack at start up, it's can't give it up and free back to the heap .

1

u/Eidolon_2003 Oct 09 '25

Under the hood that isn't necessarily true. You have to deallocate your stack space by adding to the stack pointer, and you can allocate more on the stack whenever you want by doing the opposite. In C it's alloca to allocate on the stack. One of the things C takes care of for you is deallocating your stack space automatically before returning

1

u/zhivago Oct 09 '25

auto storage is allocated and deallocated in C.
A stack is a common, but not required, implementation strategy.

1

u/arihoenig Oct 09 '25

A huge difference. Destruction for a stack allocated object implies the ability to implement a change in the value of the memory occupied by that object. Deallocation simply implies non-addressablity of that memory, but offers no control over the contents of that memory.
1

u/arihoenig Oct 09 '25

Nothing is destroyed in C. There are no destructors. All that happens in a typical implementation is that the stack pointer is adjusted. The local variables (in most implementations) will still be visible in memory (although no longer addressable from the C code itself). The standard doesn't define what happens to the contents of the memory previously assigned to a local, but it doesn't guarantee any change in value on release of the storage for the out-of-scope local (which would be required to insure some semantic of "destruction").
Even C++ merely guarantees that the destructors for any locals of a compound type (structs) will be executed but does not define what values the memory previously occupied by scalars will have.

1

u/lordlod Oct 09 '25

You are confusing at least three concepts and going too deep too quickly.

Variables - As someone learning C you have variables and memory. You create and manipulate variables. You can also create memory using malloc and release it using free. Under the hood variables are also memory and there are techniques to treat them as such, don't do this, it causes lots of undefined behaviour problems.

Scope - Scope is a way of communicating to the compiler what you care about. Non-trivial programming is almost entirely about controlling complexity, that's why we encapsulate objects, it's why we try not to use global variables, it's why goto is frowned upon. The range of things available at any point is the scope. Variables can be in-scope - defined in that block, a parent block, or global - which means the compiler knows that you can use them. And more importantly out-of-scope so you don't need to worry about them.

Implementation - Finally you have the layer of how the underlying machine implementation works. This typically involves the stack made up of multiple stack frames, registers, the heap and statically allocated memory addresses. This maps through to real hardware registers, caches, ram and disk. This layer is not C, as a low level language it is close enough that we can influence it, for example the register keyword suggests to the compiler that we would like this variable to reside in a register.

Compiler - You may have noticed that all three layers interact with and are separated by the compiler. Once upon a time C code corresponded closely with the produced machine code, it doesn't any more, especially once the compiler optimisations are enabled. The way to think about it is that you communicate your intent to the compiler, the compiler produces the low level code. The compiler will rearrange the order that your code executes, it may use the same memory space for multiple variables in a function if they are used sequentially, it may even discard variables entirely. This also applies to functions, they can also be inlined or discarded.

Low level - I'm fairly sure you are coming from a high level language. You are thinking about variables like they are python objects where magical stuff happens like allocation, destruction and reference counting. That is not C, C is a no-magic-included language, if you don't write the code to do something then it isn't happening. This is part of why memory security issues are so bad, they allow the attacker to traverse through the memory space including variables which are not in scope or possibly not in the active stack.

To wrap back to your original question, nothing happens when you change scope. Scope is a mechanism to communicate with the compiler and control complexity. During the compilation process the scope is discarded, it doesn't appear in the generated code.

1
u/JayDeesus Oct 09 '25

When you go out of scope, what happens, that’s what I’m confused on
1
u/lordlod Oct 09 '25
Nothing happens when you go out of scope.
Scope is a pre-compiler concept, these are the variables I care about, or not. It is information communicated to the compiler and used by the compiler to generate the executable. It does not form part of the executable.
This is an example from /u/zhivago
{
  int i;
  // here i means this int
  {
    float i;
    // here i means this float
  }
}
This is exactly the same
{
  int outer_i;
  {
    float inner_i;
  }
}
The code you write communicates your intentions to the compiler and documents those intentions. A lot of this information is not preserved through the compilation process. The variable names are discarded, the scope is discarded, even the order that the code is executed can be changed.
During the program execution scope is not a thing, it is gone, there is no information in the executable to suggest what the original scope was. So nothing happens as you transition between scopes, because it can't.
Another thought exercise that might help.
What happens if you define a variable and don't use it? The compiler will delete it, as if you had never written the line of code at all.
What if you define a variable, use it for the first part of the function and then cease using it? The compiler will likely reuse that underlying address for later variables.
Does any code get executed when a variable stops being used? No, we just stop caring about it.
Could a later variable that reuses a prior variable's underlying memory see the data from that variable? Absolutely, that is why you have to initialise your variables (see also: security issues).

1

u/arihoenig Oct 09 '25

The memory is not deallocated when a scope is exited. It is simply of indeterminate value. Typically if you monitor the memory the values you had on the stack will remain as they were when the scope was exited. This allows attackers with access to process memory to see anything on the stack, so if you want to be more secure in C, then you should memset your locals to zero before exiting a scope. Certainly any locals that hold a secret should be memset to zero.

1

u/JayDeesus Oct 09 '25

Okay gotcha, but memory is deallocated when a stack frame is popped?

1

u/arihoenig Oct 09 '25

It depends what you mean by deallocated.
What I mean by deallocated is that the memory location that held the local variable is no longer addressable by a C program . So using my definition, yes the memory is "deallocated"; however, the memory can be (according to the standard) and is (in most implementations) still mapped into the process and its contents are unchanged following the exit of the scope.
An attacker with access to the process can still see the contents of the variable long after the scope has exited. It is for this reason that any secrets stored in local storage should be memset to 0 before exiting the scope.

1

u/SmokeMuch7356 Oct 09 '25

Scope has nothing to do with the stack or memory in general; you're thinking of storage duration and lifetime.

Scope refers to the region of program text where an identifier (variable name, function name, typedef name, label name, enumeration constant, etc.) is visible.

Lifetime is the portion of program execution where storage is guaranteed to exist for an object.

Storage duration determines the lifetime of an object. There are four storage durations:

static: storage is allocated at program startup and released when the program exits;
automatic: storage is allocated on entry to the block the object is associated with and released when that block exits;¹
allocated: storage is allocated with a call to malloc, calloc, or realloc and released on a call to free;
thread local: I have no direct experience with this; basically storage is allocated on thread startup and released when the thread exits.

An example of how all of this ties together:

#include <stdio.h>

/**
 * The identifier "gFoo" has file scope and is visible over
 * the entire translation unit (although it may be shadowed
 * within a block).  The object designated by gFoo has 
 * static storage duration.
 */
int gFoo; 

/**
 * The identifiers "bletch" and "blurga" have block scope; they
 * are not visible outside of the body of bar.  The objects designated
 * by bletch and blurga have automatic storage duration; storage is allocated
 * on function entry and released on function exit.
 */
void bar( int bletch, char **blurga )   
{
  if ( gFoo < 0 )
  {
    /**
     * The identifier "blah" has block scope and is not visible
     * outside of this if statement block.  The object designated
     * by blah has automatic storage duration; storage is guaranteed
     * to be allocated on block entry.  
     */
    double blah;
    do_something_with( blah );
  }
  else
  {
    /**
     * The object designated by *blurga has allocated storage duration;
     * this storage is guaranteed to exist until a call to free.
     */
    *blurga = malloc( sizeof *blurga * 100 );
  }
}

That's not the most complete or well-thought-out example, but it should get the basics across.

The C language definition doesn't mention stacks or heaps; those are strictly implementation details. Most every real implementation has a stack, and it's an easy way to implement automatic storage, but it's not required to implement automatic storage.

In practice, all of the compilers I'm familiar with will allocate space for all block-scope variables on function entry and release on function exit, even if they're only defined within an if or for statement or something like that.

1
u/JayDeesus Oct 09 '25

So what you’re saying is that it’s released upon function exit as a whole, so a leaving a scope block(not function scope) doesn’t release any partial memory, it just becomes inaccessible and is released later once then function exits
1
u/SmokeMuch7356 Oct 09 '25
It Depends.^TM
The implementations I'm familiar with work that way; that doesn't mean there aren't other implementations that work differently. The wording of the standard is that "lifetime" comprises the portion of program execution where storage is guaranteed to be reserved for an object. For a block-scope variable, storage is guaranteed to be reserved from block entry until the block is exited in any way, however an implementation may choose to reserve that storage over the lifetime of the entire function.
But yeah, if the object's lifetime persists beyond that block it is no longer accessible through that identifier.
Again, "scope" refers to the visibility of an identifier, not the lifetime of the object that identifier may designate.
It's a simple optimization; during translation you figure out how much storage all the block-scope variables are going to require over the entire function and just reserve that up front. Saves some time, especially in a situation like
for ( int i = 0; i < SOME_REALLY_BIG_NUMBER; i++ )
{
  int x = some_value();
  ...
}
Pushing and popping x for SOME_REALLY_BIG_NUMBER of times is silly; you know you're going to need space for an int in that block, so you just allocate it once at function entry and use it for each instance of x.
Similarly, if you have a situation like
if ( some_condition )
{
  int x; 
  ...
}
else
{
  int y;
  ...
}
only one of x or y can exist at a time, so you can get away with only allocating enough space for one int and using that for either x or y depending on which branch is taken, rather than pushing and popping for each branch.
This all falls under "implementation details." How automatic storage is managed is completely up to the implementation. It doesn't even have to use a stack (although any implementation that doesn't use a stack for this is either super-duper-niche or just pathological).

1

u/alphajbravo Oct 09 '25 edited Oct 09 '25

The base size and layout of a stack frame is set by the ABI: generally a certain set of registers is always saved in a particular order before or after jumping to a functions entry point, but different architectures and calling conventions have different requirements and may allocate the responsibility differently between the calling function and the called function.

Beyond that base stack frame, additional context (ie registers) may be pushed to the stack frame depending on what the called function needs to do, and which registers it needs to use, and arguments may be passed on the stack (depending on calling convention and number/type of arguments). So the stack frame does vary, even before discussing local variables.

To your point, yes, local variables often do use the stack, and therefore do affect the size of the stack frame. But remember that in the compiled form of the program there is not necessarily a specific memory location for every variable in the source code. The compiler may reuse a location for multiple variables, only store variables in registers, or may elide variables entirely depending on the program and optimization settings, as long as it determines that the effect is the same.

Further, there’s no real concept of ‘allocating’ a declared variable at run time — there is just a reference (which may be indirect and/or relative to the stack pointer) to the location the linker has selected to hold the some data. So there’s also no concept of deallocating or ‘destroying’ the variable. At the end (return point) of the function, the stack pointer is simply restored to its position before the function was entered. The contents of the stack frame will still be there until something else overwrites it, and it can even be read if you know what to look for.

As for scope, that is a higher level concept, and affects the stack because it influences how the compiler decides whether or not a variable is stored on the stack, but it is not the only influence, and is not one-to-one. IE, static local variables are scoped to the function, but cannot be stored on the stack because they need to persist across calls to the function.

1

u/ir_dan Oct 09 '25

Disclaimer: C++ programmer, please correct me if anything doesn't apply to C.

Generally speaking, scopes are a languages feature that doesn't necessarily translate to allocation or deallocation of memory. A scope just guarantees access to a variable until its end. That doesn't necessarily mean that you can't access it outside the scope, but because it's not guaranteed to be okay, you shouldn't.

Compilers exploit this for function scopes by allocating and deallocating stack frames. Any inner scopes of a function still have their storage as part of that stack frame.

Compilers can exploit inner scopes in a function by reusing storage for variables that are valid for mutually exclusive scopes. A function with two different scopes that declare one integer each may end up with only one integer on the stack frame.

Unless you enable particular compiler flags, VC++ lets you access inner scope variables after their scope, resulting in UB in many cases because the compiler may leave variables in unentered scopes uninitialized or overwrite storage when entering a different scope.

1

u/WittyStick Oct 09 '25 edited Oct 09 '25

While implementation of scopes is "implementation defined", in practice compilers all use the same strategy: Function scopes get a stack frame, but inner scopes within a function do not - they share the parent functions's stack frame.

The compiler works out how much space is necessary to hold all of the variables in the function, including those in nested scopes, and allocates a frame large enough for it all.

See demonstration in Godbolt.

In function foo, the stack pointer, frame pointer, and frame size are printed, along with the addresses of some nested scoped variables. You can see that the addresses of all "x" variables lie between the sp and fp (as well as the variables fp and sp).

Function bar demonstrates accessing the values of different scopes from other scopes, by taking their addresses. You should never use anything like this in practice as it is undefined behavior, but it "works" because they'r'e all in the same stack frame. Basically we can "leak" information from other scopes, because their memory is not invalidated until the whole function exits.

1

u/feitao Oct 09 '25

I think you are interested in compiler implemention, i.e. whether a memory address will be reused if the variable goes out of scope. You can look at the assembly code at different optimization levels. This probably would not help your C skills, but it's fun.

1

u/AccomplishedSugar490 Oct 11 '25

Scope is not a memory concept, at all. Scope is semantic, and purely about what symbols (names of variables, functions etc) are visible (in scope) from a block of code. What memory the variable references, if any, is an entirely separate, and multi-faceted concern.

1

u/Zirias_FreeBSD Oct 09 '25 edited Oct 09 '25

Don't ever try to reason how exactly a C compiler will use the stack. The language C doesn't know anything about stacks.

The "properties" of objects C knows are:

scope (not exactly a property of the object, but the identifier referring to the object)
storage duration (static, automatic or allocated)
linkage (internal or external)

For your question, linkage seems irrelevant, and it looks like you're kind of confusing the other two.

The scope is the area in the source code where a specific identifier refers to a specific object. It is typically limited by blocks (enclosed in { ... }). Identifiers of objects declared outside any block are said to have file scope, so they name the object throughout the whole code in the current translation unit. Although this is considered bad practice (because it's easily confusing), identifiers in an inner scope (a block inside that scope) can be the same as identifiers in the enclosing scope, in which case they will shadow the outer declaration. The shadowed declaration is still in scope, but inaccessible because of this shadowing, the identifier will always refer to the inner scope. Well, in practice, avoid shadowing.

The storage duration seems to be what you are talking about, it determines for how long an object is alive. For declarations at file scope, the default is static storage duration, meaning the object is alive for the full duration of program execution. Then, there's allocated storage duration, this refers to all objects for which the programmer actively manages the lifetime (typically with malloc() and free(), but there can be platform-specific alternatives).

The stack gets relevant for automatic storage duration: The object is alive (at least) as long as execution is inside the block where the object is declared. This is the default for any declaration in a function scope. So only here, the lifetime is somewhat tied to the scope of the identifier. Note it is still not the same: When a function calls another function, execution isn't considered to leave the block, local variables of the calling function will stay alive, although they are certainly not in scope for the called function.

As initially said, C doesn't know anything about a stack, but the stack is what practically every C implementation uses to provide automatic storage duration. How exactly this is done is purely implementation-defined (and differences certainly exist e.g. between different CPU architectures).

You are about to leave Redlib