POSIX AWK and GNU AWK: Associative Array Indexing Consistency

Direct answer

Yes. The implicit conversion of numeric keys to strings produces identical retrieval behavior in any POSIX‑conforming awk (e.g., mawk, BWK awk) and in GNU awk (gawk). Hash collisions are an internal detail; different hash functions may be used, but they never change the observable result of a lookup. Memory usage grows roughly linearly with the number of unique keys in all implementations, though the per‑entry overhead differs: gawk typically consumes more memory per element than mawk.

Confirmed facts

• POSIX requires that every associative array subscript be converted to a string before lookup. The conversion uses CONVFMT for non‑integers and a %d-style format for integers, so 1 and 1.0 both become the key "1" in every conforming implementation.
• The standard does not specify the hash function, so mawk, BWK awk and gawk may use different internal hashing schemes. Collisions are resolved internally and do not affect the correctness of in tests or value retrieval.
• All three implementations allocate roughly one record per unique key; therefore total memory grows linearly with the cardinality of the set of keys. Empirical measurements show gawk’s per‑entry overhead is higher than mawk’s, but neither implementation spills to disk for purely in‑memory arrays.

Likely explanation

Because the observable behavior depends only on the final string key, any differences in the underlying hash algorithm are invisible to the script. The linear memory trend holds because each implementation must store a distinct entry for each unique string key; the constant factor (bytes per entry) varies with the interpreter’s internal data structures, which explains why gawk tends to use more RAM than mawk for the same dataset.

Verification steps for this case

1. Write a small aggregation script that inserts a known set of numeric keys (e.g., 1, 1.0, 2, 2.5) into an array and then prints key,value pairs sorted by key.
2. Run the script under gawk, mawk, and awk (or BWK awk on a BSD/macOS system). Capture the output and run diff -u on the sorted results; they should be identical.
3. Measure peak resident set size (RSS) for each run using /usr/bin/time -v (Linux) or time -l (macOS) on a dataset with millions of unique keys (e.g., generated with seq 1 2000000 | awk '{a[$1]++} END{for(k in a)print k,a[k]}').
4. Compare the RSS numbers; you will see roughly linear growth, with gawk’s RSS higher than mawk’s by a constant factor.

Missing diagnostic detail

If you need to decide whether gawk’s higher per‑entry memory overhead is acceptable for your environment, please provide the measured peak RSS for each implementation on your actual dataset. That single measurement will determine whether the difference impacts your deployment.