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.