> From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf > Of William Killian > > > From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On > Behalf > > Of piclist@xargs.com > > Sent: Thursday, February 23, 2006 6:58 PM > > > > > Such a compiler would have to > > > be pretty good to identify a function that will never return but > know it > > > is not a mistake. > > > > I don't see it as such a difficult problem. If the last statement of > > the function branches to the beginning of the function, and there are > > no breaks/gotos in between that branch beyond the end of the outer > > loop, why would the function need a return? > > There is no coding problem; the problem lies elsewhere possibly in > comprehension. Since I intend to assume the best about you, it seems > you obviously are not getting the point. It does not need a return. > You are indeed correct. That is my entire point. > > But, how does the compiler know that? How does it know that it can > appropriately not generate any entrance and exit code? Because you > wrote the function like that? What if that is an error and you would > have wanted a warning about 'non reachable code' or 'function does not > exit'. Sure in a non multitasking word that is sometimes 'just one > function'. In a multi-tasking world it is not. Quite a few times I've > stumbled across applications - such as the slot machine I am working on > now - that has quite a few layers of functions called before you even > get into the one that has the endless loop. This is a PIC list but the > issue is relevant more to non PIC chips in this case. I've seen this handled two ways: 1) Issue a warning and generate non-returning code anyway 2) Include a special directive for the compiler I just started working with IAR C for the AVR and it uses approach #2. If I remember right they have two ways of dealing with it. An ANSI compliant #pragma and an extended __noreturn modifer. -Mike -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist