On 30/10/2014 18:57, Rodrigo Kumpera wrote: > Forgot to CC dev > > ---------- Forwarded message ---------- > From: *Rodrigo Kumpera* <kump...@gmail.com <mailto:kump...@gmail.com>> > Date: Thu, Oct 30, 2014 at 1:57 PM > Subject: Re: [Mono-dev] [eglib] Warning: assertion function returning > To: Alex J Lennon <ajlen...@dynamicdevices.co.uk > <mailto:ajlen...@dynamicdevices.co.uk>> > > > > > On Thu, Oct 30, 2014 at 12:34 PM, Alex J Lennon > <ajlen...@dynamicdevices.co.uk <mailto:ajlen...@dynamicdevices.co.uk>> > wrote: > > 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... ? > > > The problem is that the abort happens through the logging callback and > that can't be verified by the compiler. > > Any well behaved implementation must make sure it does not return. I > think adding a while (1); at the end is a good enough solution. > We want the noreturn semantics there. >
OK thanks. I agree I tend to think an assertion handler shouldn't continue execution (if things have blown up to that extent then it's perhaps better not to try to soldier on...) I am sort of wondering what that means in real world production systems though. e.g. Something unexpected happens, Mono outputs an assertion and hangs with the CPU full on? That would be less than ideal for the type of use cases I have, with an black box embedded system possibly running on batteries. Most simplistic system watchdog / error condition handling probably just checks for the existence of the process, restarting the process or the hardware on error, so Mono getting locked into a while(1); look wouldn't be caught I imagine? Wouldn't it be better for the process to log an error and exit in some manner when the assertion handler is called? (Just some thoughts...) Cheers, Alex
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list