Bug#526620: marked as done (False positive from -Wreturn-type)
Your message dated Thu, 24 Dec 2009 02:46:27 +0100
with message-id <dacf4780912231746s2d1b14e3t17be074a9b44fdcf@mail.gmail.com>
and subject line Re: Bug#526620: closed by Arthur Loiret <aloiret@debian.org> (reply to aloiret@debian.org) (Re: Bug#526620: False positive from -Wreturn-type)
has caused the Debian Bug report #526620,
regarding False positive from -Wreturn-type
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
526620: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526620
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: gcc-4.4
Version: 4.4.0-1
I have the following code:
static void *queue_thread(void attribute((unused)) *arg) {
struct packet *p;
for(;;) {
/* Get the next packet */
pthread_mutex_lock(&receive_lock);
while(!received_packets) {
pthread_cond_wait(&receive_cond, &receive_lock);
}
p = received_packets;
received_packets = p->next;
if(!received_packets)
received_tail = &received_packets;
--nreceived;
pthread_mutex_unlock(&receive_lock);
/* Add it to the heap */
pthread_mutex_lock(&lock);
pheap_insert(&packets, p);
nsamples += p->nsamples;
pthread_cond_broadcast(&cond);
pthread_mutex_unlock(&lock);
}
}
This function's return type is required to be 'void *' because it is
passed to pthread_create(); but it never actually returns. However,
gcc-4.4 -Wall generates the following warning for it:
playrtp.c: In function ‘queue_thread’:
playrtp.c:327: error: no return statement in function returning non-void
(It's shown here as an error since I always use -Werror, because many
warnings actually indicate problems that really must be fixed.)
GCC 4.3 generates no such warning.
The underlying warning is -Wreturn-type, which is enabled by -Wall. The
documentation for this function hasn't changed since GCC 4.3 as far as I
can see but evidently the behavior has - it now has a false positive
which it previously did not.
I'd rather not just disable the warning from configure since it also can
detect real errors.
ttfn/rjk
--- End Message ---
--- Begin Message ---
2009/12/24, Richard Kettlewell <rjk@terraraq.org.uk>:
>>> This function's return type is required to be 'void *' because it is
>>> passed to pthread_create(); but it never actually returns. However,
>>> gcc-4.4 -Wall generates the following warning for it:
>>>
>>> playrtp.c: In function ‘queue_thread’:
>>> playrtp.c:327: error: no return statement in function returning non-void
>>
>> This is expected behavior, your function is not of type void.
>
> It is not expected behavior to anyone who has read the documentation for
> the option.
It is expected behavior, as you can see in gcc/c-decl.c:
/* Complain if there's just no return statement. */
if (warn_return_type
&& TREE_CODE (TREE_TYPE (TREE_TYPE (fndecl))) != VOID_TYPE
&& !current_function_returns_value && !current_function_returns_null
/* Don't complain if we are no-return. */
&& !current_function_returns_abnormally
/* Don't warn for main(). */
&& !MAIN_NAME_P (DECL_NAME (fndecl))
/* Or if they didn't actually specify a return type. */
&& !C_FUNCTION_IMPLICIT_INT (fndecl)
/* Normally, with -Wreturn-type, flow will complain, but we might
optimize out static functions. */
&& !TREE_PUBLIC (fndecl))
{
warning (OPT_Wreturn_type,
"no return statement in function returning non-void");
TREE_NO_WARNING (fndecl) = 1;
}
> > Make your function return the NULL pointer to avoid the warning.
>
> Sorry but this suggestion makes no sense. The function never returns so
> suggesting it return a null pointer is meaningless.
Right. Maybe your function just misses a call to pthread_exit (arg) then?
Closing again. If you think the documentation needs to be fixed,
please report a bug upstream, but this is irrelevant for Debian.
--- End Message ---
Reply to: