read and inconsistent handling of trailing null field?

[Clint Hepner]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: darwin19.2.0
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname output: Darwin hemma.local 19.2.0 Darwin Kernel Version 19.2.0: Sat Nov  
9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64 x86_64
Machine Type: x86_64-apple-darwin19.2.0

Bash Version: 5.0
Patch Level: 11
Release Status: release

Description:
        
read seems to incorrectly drop a null field when performing word-splitting and 
more fields than variables.

All the examples below use

    IFS== read -r n v

for some input of the form ``name=var...``


The relative bit of the POSIX spec concerns how to set the variables when there 
are fewer arguments
to read than there are fields.

        • The field that corresponds to the last var in the normal assignment 
sequence described above

        • The delimiter(s) that follow the field corresponding to the last var

        • The remaining fields and their delimiters, with trailing IFS white 
space ignored

Repeat-By:


    % ./bash
    bash-5.0$ echo $BASH_VERSION
    5.0.11(5)-release
    bash-5.0$ IFS== read -r n v <<< "name=var="
    bash-5.0$ echo "$v"
    var

I would expect "var=" as the output, as the string is split into 3 fields (the 
last being empty).
(ksh and dash also drop the final null field, which is what makes me suspect I 
am missing a subtlety
of the POSIX spec. zsh seems to preserve the final =, though I did not dig into 
which options
I have set that might affect the result.)

Same result using here-document, so I don't think this is a here-string issue.

If the trailing null field is not the one to put the field count over the 
argument count, it
works as expected.

    bash-5.0$ IFS== read -r n v <<< "name=var=f="
    bash-5.0$ echo "$v"
    var=f=
    bash-5.0$ IFS== read -r n v <<< "name=var=="
    bash-5.0$ echo "$value"
    var==