Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> writes:
> -static void reopen_stdout(struct commit *commit, int nr, int keep_subject)
> +static int reopen_stdout(struct commit *commit, int nr, int keep_subject)
> {
> - char filename[1024];
> + char filename[PATH_MAX];
> char *sol;
> int len = 0;
> - int suffix_len = strlen(fmt_patch_suffix) + 10; /* ., NUL and slop */
> + int suffix_len = strlen(fmt_patch_suffix) + 1;
>
> if (output_directory) {
> - strlcpy(filename, output_directory, 1000);
> + if (strlen(output_directory) >= sizeof(filename) - 64 - suffix_len)
> + return error("name of output directory is too long");
> + strlcpy(filename, output_directory, sizeof(filename) - suffix_len);
Sorry for a late doubt, but I started wondering if we should use
NAME_MAX instead of hardcoded 64. Purists might argue for using
pathconf() but I think it is an overkill.
NAME_MAX is 255 on Linux, POSIX says it should be 14 at least
(and further says if the platform supports only smaller max,
NAME_MAX should not be defined -- heh). I do not know how
universal NAME_MAX is defined, and I hate dealing with header
incompatibility across different systems, so I am tempted to
just do something like:
#define FORMAT_PATCH_NAME_MAX 64
locally, and use that instead.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html