[Mono-dev] [eglib] Warning: assertion function returning

Alex J Lennon ajlennon at dynamicdevices.co.uk
Thu Oct 30 16:34:57 UTC 2014


Hi Rodrigo,

On 30/10/2014 17:28, Rodrigo Kumpera wrote:
> Since the noreturn behavior is not verifiable by the compiler (it's
> part of the API contract) we can a hack to silence the warning.
>

If that's what's wanted that's fine by me of course. Easily done.

But I don't understand: Surely the fact the compiler is complaining
shows that it does know that the function is returning, when it has been
told via the attributing that the function should not?

As a test, if I add a while(1); at the bottom of the function then the
complaint goes away as the compiler knows that the return is unreachable.

I am guessing I am misunderstanding your point?

More importantly, should the assertion handler return or not... ?

Cheers,

Alex

On Thu, Oct 30, 2014 at 12:08 PM, Alex J Lennon
<ajlennon at dynamicdevices.co.uk <mailto:ajlennon at dynamicdevices.co.uk>>
wrote:
>
>     Hi,
>
>     I'm seeing an eglib warning about an assertion handling function
>     with a
>     G_GNUC_NORETURN attribute that is returning.
>
>     goutput.c: In function ‘monoeg_assertion_message’:
>     goutput.c:135:1: warning: ‘noreturn’ function does return [enabled by
>     default]
>
>     I'm wondering how this should be resolved, ie. whether this function
>     should block, whether the attribute should be removed, or
>     "something else"?
>
>     If the assertion handler should block then is while(1); sensible, or a
>     very bad idea?
>
>     Thanks,
>
>     Alex
>
>
>     _______________________________________________
>     Mono-devel-list mailing list
>     Mono-devel-list at lists.ximian.com
>     <mailto:Mono-devel-list at lists.ximian.com>
>     http://lists.ximian.com/mailman/listinfo/mono-devel-list
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20141030/488712dd/attachment.html>


More information about the Mono-devel-list mailing list