Re: Breaking a table of record rows into an array

On 2024-03-13, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Kaz Kylheku <433-929-6894@kylheku.com> writes:

On 2024-03-13, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

arnold@freefriends.org (Aharon Robbins) writes:

In article <usqkgn$he7u$2@dont-email.me>,
Ed Morton  <mortonspam@gmail.com> wrote:

the effect of setting `NF` is
undefined behavior per POSIX and so will do different things in
different awk variants and even in 1 awk variant can behave differently
depending on whether you're setting it to a higher or lower than
original value

>
This is not true. The effect of setting NF was well defined
by the original awk book and also in POSIX.
>
Decreasing NF throws away fields. Increasing NF adds the
intervening fields with the null string as their values
and rebuilds the record.

>
I don't see that in the POSIX specification.

>
The key is this:
>
  References to nonexistent fields (that is, fields after $NF), shall
  evaluate to the uninitialized value.
>
NF is assignable, and fields after $NF do not exist. Thus if we
have four fields and set NF = 3, then $4 doesn't exist.

>
That describes what happens if NF is modified by assignment, but I don't
see that it implies that such an assignment is allowed.

"The left-hand side of an assignment and the target of increment and
decrement operators can be one of a variable, an array with index, or a
field selector."

NF is described as a variable.  Some unique remarks are made about NF,
but none deny that it's assignable like any other variable.

But I can imagine a hypothetical awk-like language in which assigning to
NF has undefined behavior.  My question is, how does the POSIX
specification not describe that language?

That language is failing to support an instance of a variable
being the left operand of an assignment, which a variable "can be".

It looks like the violation of a requirement.

On the other hand, it also implies that `foo = 42` is valid where `foo`
is the name of a user-defined function (gawk disallows it).

POSIX does say that "[t]he same name shall not be used as both a
function parameter name and as the name of a function or a special awk
variable." So foo = 42 isn't valid if foo is already a function.

Also: "The same name shall not be used both as a variable name with
global scope and as the name of a function. The same name shall not be
used within the same scope both as a scalar variable and as an array."

All that said, the business of the NF tail wagging the $1, $2, ...
legs of the dog should be the target of at least one clarifying remark,
and the other defects should also be corrected:

- In a BEGIN clause NF should be undefined unless any action
  whatsoever is executed that sets its value: direct assignment,
  use of getline or assignment to $0.

- At the start of the execution of an END clause, NF retains
  its current value (or undefined status, if it was never set);
  the END clause has no implicit effect on NF.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca