On Mon, Sep 14, 2009 at 2:44 PM, Jeff King <peff@xxxxxxxx> wrote:
> Right. What I'm guessing is that it sees the noreturn on die(), but then
> doesn't actually look inside die to confirm that the noreturn is upheld.
> You could test that with:
>
> #include <stdlib.h>
> void __declspec(noreturn) die(void);
> void die(void) { }
> int main(void) { die(); }
>
> If it doesn't complain, then I am right. If it does, then it is
> something magic with the function pointer (presumably it decides that
> the function pointer could exit, so it stops the analysis and gives your
> code the benefit of the doubt).
It seems that you are right. It doesn't complain here.
>> The arguments against each solution I see are these:
>> - abort() gives a run-time error instead of a compile-time warning, so
>> breakage is trickier to detect (on GCC, which seems to be the target
>> compiler for the vast majority of git-developers).
>> - NORETURN_PTR might be bit big of a hammer for a small problem, as it
>> "pollutes" the whole git source-tree instead of just usage.c.
>
> I don't know that NORETURN_PTR pollutes the whole source-tree. At least
> no more than NORETURN does. The only functions that will need it are
> these two function pointers.
Well, it does pollute the global name space, and it's "noise" when
reading the source code. But those are really very unimportant points
IMO.
And sure, that "pollution/noise" is there for the NORETURN case anyway
for a functional/practical reason, so you might argue that it
justifies the presence in the NORETURN_PTR case.
I'll wait a day or so and see if anyone else has any insight. If not,
I'll go ahead and re-post a version based on the
NORETURN_PTR-solution.
--
Erik "kusma" Faye-Lund
kusmabite@xxxxxxxxx
(+47) 986 59 656
--
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