bug-gawk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Aharon Robbins
Subject: Re: Extension api: get_argument return value and invalid flags combination
Date: Tue, 26 Dec 2023 09:27:16 +0200
User-agent: Heirloom mailx 12.5 6/20/10

Hi.

I apologize for the delay in dealing with this.

> From: M <c24p0101@gmail.com>
> Date: Tue, 12 Dec 2023 00:36:34 +0100
> Subject: Extension api: get_argument return value and invalid flags 
> combination
> To: bug-gawk@gnu.org
>
> 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?

The behavior is as documented. Basically, gawk does number <-> string
conversion for you, paralleling what it does in code. This is what
the API has always done.  I am adding some more text to the doc,
see the attached diff.

> btw, searching in the source code, in gawkapi.h, approx at line 707
> (function node_to_awk_value), i see:
>
> case AWK_UNDEFINED:
> > /* return true and actual type for request of undefined */

Exactly, and that's what the table shows.

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

As mentioned in an earlier email, the printf turns an undefined
into an unassigned.

Nonetheless, there were some buglets in that part of the code,
also fixed in the attached patch.

Thank you for the report,

Arnold

Attachment: api.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]