#ident "%Z%%M% %I% %E% SMI"

CDDL HEADER START

The contents of this file are subject to the terms of the

Common Development and Distribution License, Version 1.0 only

(the "License"). You may not use this file except in compliance

with the License.

You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE

or http://www.opensolaris.org/os/licensing.

See the License for the specific language governing permissions

and limitations under the License.

When distributing Covered Code, include this CDDL HEADER in each

file and include the License file at usr/src/OPENSOLARIS.LICENSE.

If applicable, add the following below this CDDL HEADER, with the

fields enclosed by brackets "[]" replaced with your own identifying

information: Portions Copyright [yyyy] [name of copyright owner]

CDDL HEADER END

Nov 30, 1979:

Awk has been modified yet again, in an attempt to make

its behavior more rational and predictable in the areas

of initialization, comparison, and type coercion.

Herewith what we believe the current truth to be:

1. Each variable and field can potentially be a string

or a number or both at any time.

When a variable is set by the assignment

v = expr

its type is set to that of expr. (This includes +=, ++, etc.)

An arithmetic expression is of type number, a

concatenation is of type string, and so on.

If the assignment is a simple copy, as in

v1 = v2

then the type of v1 becomes that of v2.

2. In comparisons, if both operands are numeric,

the comparison is made numerically. Otherwise,

operands are coerced to string if necessary, and

the comparison is made on strings.

3. The type of any expression can be coerced to

numeric by subterfuges (kludges?) such as

expr + 0

and to string by

expr ""

(i.e., concatenation with a null string).

4. Uninitialized variables have the numeric value

0 and the string value "". Accordingly, if x is

uninitialized,

if (x) ...

is false, and

if (!x) ...

if (x == 0) ...

if (x == "") ...

are all true. But note that

if (x == "0") ...

is false.

5. The type of a field is determined by context

when possible; for example,

$1++

clearly implies that $1 is to be numeric, and

$1 = $1 "," $2

implies that $1 and $2 are both to be strings.

Coercion will be done as needed.

In contexts where types cannot be reliably determined, e.g.,

if ($1 == $2) ...

the type of each field is determined on input by

inspection. All fields are strings; in addition,

each field that contains only a number (in the

sense of Fortran, say) is also considered numeric.

This ensures (for better or worse) that the test

if ($1 == $2) ...

will succeed on the inputs

0 0.0

100 1e2

+100 100

1e-3 1e-3

and fail on the inputs

(null) 0

(null) 0.0

2E-518 6E-427

as we believe it should.

Fields which are explicitly null have the string

value ""; they are not numeric.

Non-existent fields (i.e., fields past NF) are

treated this way too.

As it is for fields, so it is for array elements

created by split(...).

6. There is no warranty of merchantability nor any warranty

of fitness for a particular purpose nor any other warranty,

either express or implied, as to the accuracy of the

enclosed materials or as to their suitability for any

particular purpose. Accordingly, the AWK Development

Task Force assumes no responsibility for their use by the

recipient. Further, the Task Force assumes no obligation

to furnish any assistance of any kind whatsoever, or to

furnish any additional information or documentation.