[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: unassigned/untyped behaviour
From: |
Andrew J. Schorr |
Subject: |
Re: unassigned/untyped behaviour |
Date: |
Thu, 16 Nov 2023 17:46:32 -0500 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hi,
And it's a bit different for a regular variable as opposed to an
array element. Using the master branch:
./gawk 'BEGIN {print typeof(a); printf "test %d\n", a; print typeof(a); printf
"test2 %s\n", a; print typeof(a)}'
untyped
test 0
unassigned
test2
unassigned
I think that looks right to me, based on the descriptions in 9.1.8.
But the behavior for array elements does not seem consistent with the manual.
Section 9.1.8 gives this example:
‘"unassigned"’
X is a scalar variable that has not been assigned a value yet.
For example:
BEGIN {
# creates a[1] but it has no assigned value
a[1]
print typeof(a[1]) # unassigned
}
But in fact, that's not what the master branch produces:
bash-4.2$ ./gawk 'BEGIN {a[1]; print typeof(a[1])}'
untyped
I'd guess that gawk is right and the documentation is wrong in that case.
The coercion to string type by saying 'printf "%s", a[1]' seems like it needs
some investigation...
bash-4.2$ ./gawk 'BEGIN {print typeof(a[1]); printf "test %s\n", a[1]; print
typeof(a[1])}'
untyped
test
string
I'm not clear on whether accessing a[1] in a scalar context should leave it
untyped; perhaps it should be unassigned at that point, based on the section
9.1.8 descriptions? I imagine the internal implementation details are rather
complicated...
Regards,
Andy
On Thu, Nov 16, 2023 at 05:29:32PM -0500, Andrew J. Schorr wrote:
> Hi,
>
> Thanks for the bug report, but gosh, this is a super big test program. Does
> this shorter program capture the essence of your issue? In general, it makes
> life much easier for the developers to provide shorter examples of problems.
>
> gawk 5.1.1:
> bash-5.1$ ./gawk 'BEGIN {a[1]; print typeof(a[1]); printf "test %d\n", a[1];
> print typeof(a[1]); printf "test2 %s\n", a[1]; print typeof(a[1])}'
> unassigned
> test 0
> unassigned
> test2
> unassigned
>
> gawk 5.3.0 (same as gawk 5.2.0):
> bash-5.1$ ./gawk 'BEGIN {a[1]; print typeof(a[1]); printf "test %d\n", a[1];
> print typeof(a[1]); printf "test2 %s\n", a[1]; print typeof(a[1])}'
> untyped
> test 0
> untyped
> test2
> string
>
> Regards,
> Andy
>
> On Thu, Nov 16, 2023 at 09:00:56PM +0100, M wrote:
> > From: crap0101
> > To: bug-gawk@gnu.org
> > Subject: unassigned/untyped behaviour
> >
> > Configuration Information [Automatically generated, do not change]:
> > Machine: x86_64
> > OS: linux-gnu
> > Compiler: gcc
> > Compilation CFLAGS: -g -O2 -DNDEBUG
> > uname output: Linux orange 5.15.0-46-generic #49-Ubuntu SMP Thu Aug 4
> > 18:03:25 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
> > Machine Type: x86_64-pc-linux-gnu
> >
> > Gawk Version: 5.3.0
> >
> > Attestation 1:
> > I have read https://www.gnu.org/software/gawk/manual/html_node/Bugs.html.
> > Yes
> >
> > Attestation 2:
> > I have not modified the sources before building gawk.
> > True
> >
> > Description:
> > Hi! here again :)
> > I found a "strange" behaviour testing a lib/extension i'm writing.
> > It's about managing unassigned/untyped array's values. At first it was a
> > bug in the code i wrote, but i noticed this behaviour only in the last
> > release (5.3.0, pulled from git just today). As per the manual section
> > (9.1.8 Getting Type Information) referencing never used identifiers (simple
> > variable or array elements) come "bring" them to life, and this should
> > works for every (builtin or not) function but typeof() and isarray(). So,
> > printing an untyped array elements, we expect it to become
> > unassigned...but, for example printing with printf() (see attached files)
> > with a different format string gives different results: using %s gives the
> > array element a string type, using %d left it untouched, untyped. I don't
> > know if it's a printf() releated issue (same behaviour using sprintf).
> >
> > Repeat-By:
> > printf on untyped array elements (see attached files).
> >
> > Fix:
> > I don't have yet.
> >
> > --
> > me -> http://crap0101.altervista.org/
>
>
> > [-- mutt_octet_view: file type is unsupported for autoview (use 'v' to view
> > this part) --]
>
> > --- /tmp/r_5.1 2023-11-16 19:47:30.321162662 +0100
> > +++ /tmp/r_5.3 2023-11-16 19:47:22.221153534 +0100
> > @@ -2,23 +2,23 @@
> > <arr[0]> (type:number) (isarray:0)
> > <arr[1]> (type:strnum) (isarray:0)
> > <arr[2]> (type:string) (isarray:0)
> > -<arr[3]> (type:unassigned) (isarray:0)
> > +<arr[3]> (type:untyped) (isarray:0)
> > <arr[4]> (type:regexp) (isarray:0)
> > ¿val? (type:untyped) (isarray:0)
> > * again...
> > <arr[0]> (type:number) (isarray:0)
> > <arr[1]> (type:strnum) (isarray:0)
> > <arr[2]> (type:string) (isarray:0)
> > -<arr[3]> (type:unassigned) (isarray:0)
> > +<arr[3]> (type:untyped) (isarray:0)
> > <arr[4]> (type:regexp) (isarray:0)
> > ¿val? (type:untyped) (isarray:0)
> > * print also `invented` value
> > <arr[0]> (type:number) (isarray:0)
> > <arr[1]> (type:strnum) (isarray:0)
> > <arr[2]> (type:string) (isarray:0)
> > -<arr[3]> (type:unassigned) (isarray:0)
> > +<arr[3]> (type:untyped) (isarray:0)
> > <arr[4]> (type:regexp) (isarray:0)
> > -<> (type:untyped) (isarray:0)
> > +<> (type:unassigned) (isarray:0)
> > * print `a` values
> > arr[0] = <2>)
> > arr[1] = <1>)
> > @@ -30,16 +30,17 @@
> > <arr[0]> (type:number) (isarray:0)
> > <arr[1]> (type:strnum) (isarray:0)
> > <arr[2]> (type:string) (isarray:0)
> > +<arr[3]> (type:string) (isarray:0)
> > <arr[4]> (type:regexp) (isarray:0)
> > <> (type:unassigned) (isarray:0)
> >
> > * b[0],b[1] (untyped|unassigned)
> > -b[0]: (type:unassigned) (isarray:0)
> > -b[1]: (type:unassigned) (isarray:0)
> > +b[0]: (type:untyped) (isarray:0)
> > +b[1]: (type:untyped) (isarray:0)
> > * printf b[0] with format %s gives: <>
> > * printf b[1] with format %d gives: <0>
> > -b[0]: (type:unassigned) (isarray:0)
> > -b[1]: (type:unassigned) (isarray:0)
> > +b[0]: (type:string) (isarray:0)
> > +b[1]: (type:untyped) (isarray:0)
> >
> > * invented2...
> > invented2 (type:untyped) (isarray:0)
>
>
> --
> Andrew Schorr e-mail: aschorr@telemetry-investments.com
> Telemetry Investments, L.L.C. phone: 917-305-1748
> 152 W 36th St, #402 fax: 212-425-5550
> New York, NY 10018-8765
--
Andrew Schorr e-mail: aschorr@telemetry-investments.com
Telemetry Investments, L.L.C. phone: 917-305-1748
152 W 36th St, #402 fax: 212-425-5550
New York, NY 10018-8765
- unassigned/untyped behaviour, M, 2023/11/16
- Re: unassigned/untyped behaviour, Andrew J. Schorr, 2023/11/16
- Re: unassigned/untyped behaviour,
Andrew J. Schorr <=
- Re: unassigned/untyped behaviour, arnold, 2023/11/21
- Re: unassigned/untyped behaviour, arnold, 2023/11/21
- Re: unassigned/untyped behaviour, Andrew J. Schorr, 2023/11/21
- Re: unassigned/untyped behaviour, arnold, 2023/11/21
- Re: unassigned/untyped behaviour, arnold, 2023/11/22
- Re: unassigned/untyped behaviour, Andrew J. Schorr, 2023/11/22
- Re: unassigned/untyped behaviour, arnold, 2023/11/22
- Re: unassigned/untyped behaviour, Andrew J. Schorr, 2023/11/22