Re: [bug-gawk] array initialization

[Andrew J. Schorr]

On Sat, Jan 05, 2019 at 09:35:30AM -0500, Andrew J. Schorr wrote:
> diff --git a/array.c b/array.c
> index aa52f3a..8a252cc 100644
> --- a/array.c
> +++ b/array.c
> @@ -618,6 +618,9 @@ do_delete(NODE *symbol, int nsubs)
>  
>       (void) assoc_remove(symbol, subs);
>       DEREF(subs);
> +     if (symbol->table_size == 0)
> +             /* last element was removed, so reset array type to null */
> +             null_array(symbol);
>  
>  #undef free_subs
>  }

Arguably, this should say "assoc_length(symbol)" instead of
"symbol->table_size".

In awk.h, we have:
#define assoc_length(a) ((*((a)->alength(a, NULL)))->table_size)

In practice, the array alength functions all return a pointer to the
array itself, as far as I can tell. So this is equivalent to
(a)->table_size, at the expense of making the function call, etc.

I guess there's a theory that there could be a backend array implementation
that doesn't store the current array length in the table_size field, but we
don't seem to have any at the moment. Is there a reason to do this?

One might redefine:
#define assoc_length(a) ((a)->table_size)

This passes "make check", but I'm getting some strange errors running
"make valgrind-noleak":

============== _functab4 =============
*** functab4.ok 2017-04-07 08:57:12.304181000 -0400
--- _functab4   2019-01-05 10:04:56.557905000 -0500
***************
*** 1,4 ****
  foo!
  ret1 = 0
  ret2 = 0
! no problems encountered
--- 1,5 ----
  foo!
  ret1 = 0
  ret2 = 0
! mismatch element "nlink"
! 1encountered

But this was intermittent and disappeared when I ran it again. One could
imagine improving this test case to show better errors: what is the mismatch?

Regards,
Andy