On Tue, Jul 07, 2015 at 02:05:52PM -0700, Junio C Hamano wrote:
> And that is because DATE_NORMAL is defined to be 0; we can claim
> that the compiler is being stupid to take one of the enum
> date_mode_type values that happens to be 0 and misinterpret it as
> the program wanted to pass a NULL pointer to a structure, but that
> is not what happened.
Ah, I didn't think the compiler would coerce an enum into a pointer
constant. That seems kind of insane. But it is indeed what gcc does.
In that case, we can indeed do the NULL-pointer thing I mentioned. Which
is not even _that_ ugly; it follows the standard.
The "cast DATE_RELATIVE to a pointer and uncast it on the other side"
thing _does_ violate the standard. It is not needed for this, but it
would make the DATE_MODE() macro reentrant.
> > + static const struct fallback_mode = { DATE_NORMAL };
>
> Yes, that is nasty. Renumbering the enum to begin with 1 may be a
> much saner solution, unless somebody does
I am worried more about somebody who does memset(0) on a struct, and
expects that to default to DATE_NORMAL.
> In any case, I did another evil merge to fix it.
OK. Do you want to leave it be, then, or would you prefer me to do the
NULL fallback? Or we could bump the enum to start with 1, and then
explicitly treat "0" as a synonym for DATE_NORMAL (in case it comes in
through a memset or similar).
-Peff
--
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