IFS and read bug

[holzhey]

Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux
Compiler: gcc -I/usr/src/packages/BUILD/bash-2.05b 
-L/usr/src/packages/BUILD/bash-2.05b/../readline-4.3
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i586' 
-DCONF_OSTYPE='linux' -DCONF_MACHTYPE='i586-suse-linux' -DCONF_VENDOR='suse' 
-DSHELL -DHAVE_CONFIG_H  -I.  -I. -I./include -I./lib  -O2 -march=i586 
-mcpu=i686 -fmessage-length=0 -D_GNU_SOURCE -Wall -pipe -g
uname output: Linux ppprs1 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 
unknown
Machine Type: i586-suse-linux

Bash Version: 2.05b
Patch Level: 0
Release Status: release

Description:

There seem to be strange bugs when using IFS and read: The end of line will get 
a carriage return (maybe this is still ok) and the first element will become a 
'DEL' char (octal 177), if it should be empty. This is very strange, since I 
never used that character anywhere.

Just see the example.

Repeat-By:
( I wanted to split a pathname into its parts. Let the name be: 
'/kghfjk/jkfzuk/i' . I read it into an array named uu:

  IFS="/" read -r -d $'\000' -a uu <<< /kghfjk/jkfzuk/i

now I check, what is in 'uu':

  declare -p uu               produces:
  declare -a uu='([0]="" [1]="kghfjk" [2]="jkfzuk" [3]="i\
")'

The first strange thing is, that field number 3 ends with a newline. But maybe 
tis is what you want and I just don't understand.

The more strange thing is field number 0 of the array uu. At first it looks 
nice: it seems to be empty. But in reallity, it is a 'DEL'. We can prove this:

   [ "${uu[0]}" = "" ] && echo yes
(nothing happens)

  [ "${uu[0]}" = $'\177' ] && echo yes     produces:
yes

This definitely seems to be a bug.

Greetings. Andre'

Fix:
        [Description of how to fix the problem.  If you don't know a
        fix for the problem, don't include this section.]