Re: [PATCH 1/3] pretty.c: fix null pointer dereference

> Interesting.
> 
> Are any of the existing calls to this function that passes
> CMIT_FMT_USERFORMAT trigger a segfault with certain condition?
> 
> For example, there are only two places where CMIT_FMT_USERFORMAT is
> assigned to something.  One is save_user_format() where user_format
> gets a non NULL string before rev->commit_format gets assigned
> CMIT_FMT_USERFORMAT.  Another is git_pretty_formats_config() that
> parses configuration variables "pretty.*" and populate
> commit_formats map.  This is later used in get_commit_format() and
> that function always calls save_user_format() we just saw when the
> format used is CMIT_FMT_USERFORMAT.  So the existing code paths seem
> to be safe by design.
> 
> What I am wondering is if a NULL user_format should be flagged as a
> programming error, instead of getting swept under the rug like this
> patch does.  IOW,
> 
> 	int commit_format_is_empty(enum cmit_fmt fmt)
> 	{
> 		if (fmt != CMIT_FMT_USERFORMAT)
> 			return 0;
> 		if (!user_format)
> 			BUG("never called save_user_format() and using USERFORMAT?");
> 		return !*user_format;
> 	}