4.0 core dump from printf -v foo %s bar

[Greg Wooledge]

The other two messages I sent today were just things I encountered while
bringing my bash 4.0 up to the current patch level.  This is the real
problem I've been chasing.

imadev:/var/tmp/bash-4.0$ bash-3.1.17 -c 'printf -v foo %s bar'
imadev:/var/tmp/bash-4.0$ bash-4.0.10 -c 'printf -v foo bar'
imadev:/var/tmp/bash-4.0$ bash-4.0.10 -c 'printf -v foo %s bar'
Segmentation fault (core dumped)
imadev:/var/tmp/bash-4.0$ ./bash --version | head -1
GNU bash, version 4.0.35(2)-release (hppa2.0-hp-hpux10.20)
imadev:/var/tmp/bash-4.0$ ./bash -c 'printf -v foo bar'
imadev:/var/tmp/bash-4.0$ ./bash -c 'printf -v foo %s bar'
Segmentation fault (core dumped)

I looked into printf.def using gdb, but I only partially understand
what's happening.  I don't understand why this works on other platforms
but fails on HP-UX 10.20, but maybe that's my ignorance....

In the "printf -v foo bar" case, there's no format specifier with a
percent sign.  So, even though the vbuf variable is never initialized
beforehand, the first macro that it calls is PC, which calls vbadd,
which allocates space for vbuf.

In the "printf -v foo %s bar" case, vbuf is still not initialized,
but the first macro that gets called is PF.  PF calls vbprintf, which
calls vsnprintf (vbuf + vblen, ....) but vbuf is still NULL.

If my understanding is correct, the vbprintf function either needs to
do the nlen vs. vbsize check before calling vsnprintf(vbuf+...), or
it needs to call vsnprintf with a locally allocated buffer first, and
then copy the result into vbuf once it's been resized.

I have no idea how "printf -v foo %s bar" works on other platforms, given
what appears (to me) to be a dereferenced NULL or nearly-NULL pointer.