Re: [bug-gawk] array initialization

[arnold]

Hi.

"Andrew J. Schorr" <address@hidden> wrote:

> 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".

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.

> 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.

> 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?

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.

Arnold