strncpy(&ret[pos], path, strlen(path));
strncpy(&ret[pos], dir, strlen(dir));
I suggest to replace strncpy by strcpy. The length of these strings (path, dir, ...) has already been taken into account while allocating ret. No overflow is possible.
The same remark apply to:
grep strncpy *.c
The strncpy usage is inappropriate almost everywhere.
By the way, in get_default_prefs wouldn't it better to use strdup instead of all that complex stuff with malloc + strncpy?
Thanks for the bug report. I feel that the use of strncpy is so unburdensome that I'd rather have the extra sanity check for the string operations than have to think about whether I'm going out of bounds every time I see strcpy in the code.
As to strdup() in get_default_prefs - yes it would work just as well and save a few lines of code. I'll take a patch if you care to send me one, but I don't feel the need to change it myself :)
The thing is that using strncpy this way does not bring any extra security at all. The third argument of strncpy is supposed to be the size of the destination buffer not the size of the source buffer.
strdup would help you remove the hardcoded string lengths, which in my opinion are quite a bad coding practice.
What strncpy does is it allows me to very quickly check whether it is possible for that line of code to cause a buffer overflow. Which strcpys often do. If it were strcpy - I would have to do a lot more looking and thinking in order to establish the same.
I agree with you about strdup, feel free to fix it and attach a patch to this bug.