Re: Extension api: get_argument return value and invalid flags combination

[Aharon Robbins]

Hi.

Apologies for the long delay in replying.

> From: M <c24p0101@gmail.com>
> Date: Tue, 12 Dec 2023 00:36:34 +0100
> Message-ID: 
> <CAOCQO0iKgLvnLOT4p+Vs8Sdo0igg679_L_wUXpPn+s5fgSh=BA@mail.gmail.com>
> Subject: Extension api: get_argument return value and invalid flags 
> combination
> To: bug-gawk@gnu.org
>
> Description:
> Hi... here again :)
> This time maybe with something more sensible.
> Using the API function get_argument, as states in the doc `Return true if
> the actual type matches wanted, and false otherwise. In the latter case,
> result->val_type indicates the actual type` (mentioned also in section
> 17.4.9 and Table 17.2), I'm expecting that calling the function with, for
> example, the $count argument of type bool and $wanted set to AWK_STRING
> returns false, or when passing a string type as the $count argument and
> requesting a AWK_UNDEFINED as $wanted, get_arguments returns false again.
> But I noticed that if $wanted is AWK_UNDEFINED it returns always true.
> Maybe is only a documentation bug?

It seems that the API converts strings to numbers and numbers
to strings for us.  I think I need to update the doc.
Also w/respect to AWK_UNDEFINED.

> Another thing... writing this test I got a warning about invalid flags
> combination, which suggested to fill a bug report (so i'll can be partially
> excused :D). Note that using the commented out printf doesn't show the
> warning... could it have anything to do with the untyped/unassigned
> behaviour with print we talked some weeks ago?

Yes, that's exactly true. The uncommented printf turns arr[4] from
undefined into unassigned, and the current code doesn't realize
that such types can come from sources other than Nnull_string. I need
to make that smarter.

Thanks for the interesting test case(s).  I will work on a patch.

Arnold