Andrew Burgess 5e1d530da8 libiberty/buildargv: handle input consisting of only white space ... GDB makes use of the libiberty function buildargv for splitting the inferior (program being debugged) argument string in the case where the inferior is not being started under a shell. I have recently been working to improve this area of GDB, and noticed some unexpected behaviour to the libiberty function buildargv, when the input is a string consisting only of white space. What I observe is that if the input to buildargv is a string containing only white space, then buildargv will return an argv list containing a single empty argument, e.g.: char **argv = buildargv (" "); assert (*argv[0] == '\0'); assert (argv[1] == NULL); We get the same output from buildargv if the input is a single space, or multiple spaces. Other white space characters give the same results. This doesn't seem right to me, and in fact, there appears to be a work around for this issue in expandargv where we have this code: /* If the file is empty or contains only whitespace, buildargv would return a single empty argument. In this context we want no arguments, instead. */ if (only_whitespace (buffer)) { file_argv = (char **) xmalloc (sizeof (char *)); file_argv[0] = NULL; } else /* Parse the string. */ file_argv = buildargv (buffer); I think that the correct behaviour in this situation is to return an empty argv array, e.g.: char **argv = buildargv (" "); assert (argv[0] == NULL); And it turns out that this is a trivial change to buildargv. The diff does look big, but this is because I've re-indented a block. Check with 'git diff -b' to see the minimal changes. I've also removed the work around from expandargv. When testing this sort of thing I normally write the tests first, and then fix the code. In this case test-expandargv.c has sort-of been used as a mechanism for testing the buildargv function (expandargv does call buildargv most of the time), however, for this particular issue the work around in expandargv (mentioned above) masked the buildargv bug. I did consider adding a new test-buildargv.c file, however, this would have basically been a copy & paste of test-expandargv.c (with some minor changes to call buildargv). This would be fine now, but feels like we would eventually end up with one file not being updated as much as the other, and so test coverage would suffer. Instead, I have added some explicit buildargv testing to the test-expandargv.c file, this reuses the test input that is already defined for expandargv. Of course, once I removed the work around from expandargv then we now do always call buildargv from expandargv, and so the bug I'm fixing would impact both expandargv and buildargv, so maybe the new testing is redundant? I tend to think more testing is always better, so I've left it in for now. 2024-07-16 Andrew Burgess <aburgess@redhat.com> libiberty/ * argv.c (buildargv): Treat input of only whitespace as an empty argument list. (expandargv): Remove work around for intput that is only whitespace. * testsuite/test-expandargv.c: Add new tests 10, 11, and 12. Extend testing to call buildargv in more cases.		2024-07-16 13:52:03 +01:00
..
d-demangle-expected
demangle-expected
demangler-fuzzer.c
Makefile.in
rust-demangle-expected
test-demangle.c
test-expandargv.c	libiberty/buildargv: handle input consisting of only white space	2024-07-16 13:52:03 +01:00
test-pexecute.c
test-strtol.c