From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
To: Sverre Rabbelier <srabbelier@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
GIT Mailing-list <git@vger.kernel.org>
Subject: Re: [PATCH 2/2] obstack.c: Fix some sparse warnings
Date: Wed, 14 Sep 2011 00:18:55 +0100 [thread overview]
Message-ID: <4E6FE4DF.7060200@ramsay1.demon.co.uk> (raw)
In-Reply-To: <CAGdFq_ifU2WWbCpRY_EFY=_hwwtFs0eqMhJ7sRoUhrivABFoFw@mail.gmail.com>
Sverre Rabbelier wrote:
> Heya,
>
> On Sun, Sep 11, 2011 at 21:26, Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
>> compat/obstack.c:399:1: error: symbol 'print_and_abort' redeclared with \
>> different type (originally declared at compat/obstack.c:95) \
>> - different modifiers
>
>> @@ -395,7 +395,6 @@ _obstack_memory_used (struct obstack *h)
>> # endif
>>
>> static void
>> -__attribute__ ((noreturn))
>> print_and_abort (void)
>> {
>> /* Don't change any of these strings. Yes, it would be possible to add
>
> Wouldn't the better solution be to add noreturn to the declaration at
> compat/obstack.c:95?
Hmm, well ... maybe; it is at least debatable. But I decided no! :-D
First, although I would not dismiss the possibility of some optimization
of the code of print_and_abort() (the *callee*), the main benefit of the
noreturn attribute should in fact be at the call sites (ie the *caller*).
So, yes, in general, the declaration of the function should have the
noreturn attribute applied, in addition to the definition, in order to
allow the compiler to apply some optimizations to the call sites.
[Note, also, that we should use the NORETURN and NORETURN_PTR macros.]
In this case, however, there are no (direct) call sites. This function
would only be called indirectly via the 'obstack_alloc_failed_handler'
function pointer. So, this would require the use of NORETURN_PTR on
that function pointer. In order to keep both the compiler(s) and sparse
happy, the required change would look like the diff given at the end
of this mail.
This would work fine, and I would happily change the patch to include
this if it is deemed the better approach. However, I looked at the
call sites in _obstack_begin[_1](), and _obstack_newchunck() and could
not see any great opportunity for optimizing the code ... so I decided
to go for the simpler patch ...
ATB,
Ramsay Jones
-- >8 --
diff --git a/compat/obstack.c b/compat/obstack.c
index a89ab5b..2029b8f 100644
--- a/compat/obstack.c
+++ b/compat/obstack.c
@@ -92,8 +92,8 @@ enum
abort gracefully or use longjump - but shouldn't return. This
variable by default points to the internal function
`print_and_abort'. */
-static void print_and_abort (void);
-void (*obstack_alloc_failed_handler) (void) = print_and_abort;
+static void NORETURN print_and_abort (void);
+NORETURN_PTR void (*obstack_alloc_failed_handler) (void) = print_and_abort;
# ifdef _LIBC
# if SHLIB_COMPAT (libc, GLIBC_2_0, GLIBC_2_3_4)
@@ -395,7 +395,7 @@ _obstack_memory_used (struct obstack *h)
# endif
static void
-__attribute__ ((noreturn))
+NORETURN
print_and_abort (void)
{
/* Don't change any of these strings. Yes, it would be possible to add
diff --git a/compat/obstack.h b/compat/obstack.h
index d178bd6..122f93f 100644
--- a/compat/obstack.h
+++ b/compat/obstack.h
@@ -194,7 +194,7 @@ void obstack_free (struct obstack *, void *);
more memory. This can be set to a user defined function which
should either abort gracefully or use longjump - but shouldn't
return. The default action is to print a message and abort. */
-extern void (*obstack_alloc_failed_handler) (void);
+extern NORETURN_PTR void (*obstack_alloc_failed_handler) (void);
\f
/* Pointer to beginning of object being allocated or to be allocated next.
Note that this might not be the final address of the object
prev parent reply other threads:[~2011-09-13 23:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-11 19:26 [PATCH 2/2] obstack.c: Fix some sparse warnings Ramsay Jones
2011-09-11 21:56 ` Sverre Rabbelier
2011-09-13 23:18 ` Ramsay Jones [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E6FE4DF.7060200@ramsay1.demon.co.uk \
--to=ramsay@ramsay1.demon.co.uk \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=srabbelier@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).