lördag 24 februari 2007 09:51 skrev Junio C Hamano:
> 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.
I think it'd sane to keep the name much shorter than what is actually possible. The
patches will have a counter to keep the names unique anyway.
>
> 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.
Ok with me.
-- robin
-
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