| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As it turns out, after doing a malloc(), strcat() can't be used
directly on top of it. I'd guess that the implementation of strcat()
goes through the first string until its end, the \0 NULL terminator,
and then starts copying the characters to the new string, overwriting
the existing terminator to allow the string to actually be continuous.
However, strcat() can't do this in a string that was just malloced and
has no content. So it will probably run over the end of the memory
untill it finds a NULL byte, and concatenate starting from that. I
didn't check this elsewhere, but this explanation sounds reasonable,
and Valgrind's diagnostics seem to confirm that.
The solution is to strcpy() the first string, and than strcat() the
others after that, so that strcat() has an existing string to work on,
while strcpy doesn't need that.
Fixes #task-bd165b74-c559-48ee-1d29-eaa906aa0393.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Those tests led me to handling the case where $XDG_DATA_HOME was set,
but as an empty string. This is the equivalent of the "[ -z ".." ]"
test.
I also parameterized get_profile_file() to receive the stream where it
should write to in case of failing to getenv("HOME"). Even though this
makes the arguments of functions that print longer, it looks like an
overall good pattern. It is the equivalent of every sh function
printing to STDOUT, and let the caller decide if it should go to STDOUT
or STDERR.
|
