Re: [bug-gawk] array initialization

[Andrew J. Schorr]

On Sat, Jan 05, 2019 at 11:25:20AM -0700, address@hidden wrote:
> > Arguably, this should say "assoc_length(symbol)" instead of
> > "symbol->table_size".
> 
> Yes, actually it should just be `assoc_empty(symbol)'.   There are
> a few other places where we use xxx->table_size that should be
> assoc_empty, instead.

OK. So I guess the patch should look like this:

diff --git a/array.c b/array.c
index aa52f3a..5bbed72 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 (assoc_empty(symbol))
+               /* last element was removed, so reset array type to null */
+               null_array(symbol);
 
 #undef free_subs
 }

> > 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)
> 
> Let's leave well enough alone for now.

Hmmm. I'm not convinced. The existing assoc_length macro involves an indirect
function call that accomplishes nothing. It's a waste of cycles. And the code
is not consistent about using the assoc_length macro. For example, in
gawkapi.c, there are a bunch of places where the table_size field is accessed
directly instead of using the assoc_length macro.

I think the smart move is to remove the alength entry in array_funcs
and get rid of all of this cruft. Why have a useless abstraction in the
code that serves no purpose?

> nlink on a directory is the number of subdirectories it has; looks like
> something got added or removed in between two calls to stat.  It doesn't
> happen for me after two runs.

Perhaps I was running make check at the same time as make valgrind-noleak.
It doesn't seem like a real concern.

Regards,
Andy