Re: RFC: warnings on ignoring return value on some list operations

[Tim Janik <timj imendio com>]

On Thu, 24 Nov 2005, Owen Taylor wrote:

> if (head) {
>    g_list_append(tail, new);
>    tail = tail->next;
> } else {
>    head = tail = g_list_append(null, new);
> }
>
> strikes me as acceptable code, and I know there are some examples like this
> in GTK+. Maybe the gain is worth the pain ... unless someone is compiling
> production code with -Werror it isn't going to *break* a build, and there
> is no bin-compat issue. But it's definitely a compatibility break of some
> sort.

i think one can argue both ways here, in the above code, i'd still write
head = g_list_append (tail, new); and recommend that people also do that,
because a) code is duplicated so often and this easily introduces errors
in another context, and b) i'd like to think of the list API as something
where i'm not allowed to ignore return values to avoid mistakes ;)

> Does
>
>   (void)g_list_append(tail, new);
>
> Suppress the warning?

i was assuming that, unfortunately that is not the case:

========warn_unused_result.c========
void* __attribute__ ((warn_unused_result)) bla (void)  { return (void*) 5; } 
int main () { (void) bla(); return 0; } 
========warn_unused_result.c========
$ gcc-3.4 -Wall warn_unused_result.c 
warn_unused_result.c: In function `main':
warn_unused_result.c:2: warning: ignoring return value of `bla', declared with attribute warn_unused_result

the same happens with gcc-4.0.

unless you strongly object to it, i still think we should add the attribute to
all list functions that can return modified lists. it'll be stricter and thus
may require some adaptions when introduced, but better in the long-term because
it helps people to avoid easy errors.

> Regards,
> 							Owen

---
ciaoTJ