Re: Patch for curses module

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

On 13 September 2015 at 18:47, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Sep 13,  1:58pm, Sebastian Gniazdowski wrote:
> }
> } _provide_clean_memory_to_old_zsh() {
> }     local i=100
> }     while (( i-- )); do
> }         local a b
> }         a="               "
> }         b="               "
> }         unset a b
> }     done
> } }
>
> If malloc works the way you think, that loop is just going to allocate
> and free the same two blocks over and over.  Declaring "local" inside a
> loop doesn't have any special meaning.  You would at least need e.g.
>
>   while (( i-- )); do
>     local a$i="                 " b$i="                 "
>   done

Maybe local means that the memory comes from stack, while zalloc()
works on heap? I tried with global variables but still no luck though.

> Then because declared local, all the a$i and b$i will be freed at the end
> of the function scope, you don't need an explicit unset.
>
> } Hash node which is part of colorpairnode as:
> } struct hashnode {
> }     HashNode next;          /* next in hash chain */
> }     char *nam;                  /* hash key           */
> }     int flags;                      /* various flags      */
> } };
>
> Yes, but you need to clear single blocks the size of the entire
> colorpairnode struct (18+ bytes, a hashnode plus a short) rather
> than just the size of the prefix hashnode.

I have printed sizeof of the struct and it's 16, and 32 on 64 bit machine.

> } Therefore filling a 16/32 byte area with zeros or e.g. spaces and then
> } freeing it should provide proper memory for zcurses. But this doesn't
> } happen. Does unset free memory? What can be done to allocate and free
> } 16/32 bytes block?
>
> Even if you get the size right, the malloc library isn't guaranteed to
> re-use freed memory in LIFO order.  It may (re)use it in the order
> that it can access it the fastest, whether or not that's best-fit.
> It might also aggressively release freed blocks back to the OS, in
> which case any value you write there may be clobbered by another
> thread even if you do get back the same block you previously freed.

Yes it's hard to say about guarantees with such trick, good that it's
only about colors and older zsh versions.

Best regards,
Sebastian Gniazdowski