Re: MSVC and GCC compilation warnings
Francisco Olarte <[email protected]> Thu, 30 Apr 2026 20:40:20 +0200
| Newsgroups | gmane.comp.lang.lua.general |
|---|---|
| Message-ID | <CA+bJJbxC7J0i+4ZX+QZw6eK9F6x_6ro9WwbAMKjPw1sz9gTTrA@mail.gmail.com> |
Roberto: On Thu, 30 Apr 2026 at 17:24, Roberto Ierusalimschy <[email protected]> wrote: > Can anyone explain this warning? The recursive call is guarded by two > if's, and it calls the function with a different argument (L in the > original call, mainth in the recursive call). How can the compiler decide > that the recursion is infinite? > > More exactly: the recursive call only happens if L->errorJmp is nil. > But then it is done with a new L (mainth) which errorJmp field is not > nil. So, it seems quite easy to prove that the recursive call happens at > most once. Or am I missing something? > Does seem correct, but you may be hitting a compiler bug or the infinite recursion detector is not that smart. What optimization settings are you using? I have found some cases of things detected differently when the compilers works harder analyzing the code. Also, I do not know if it matters, but mainth is obtained from an external source, errorJmp is checked and then setobjs2s is called. setobjs2s could, via an external alias pointer, clear mainth->errorJmp before the recursion. I am not sure what definitions are visible to the compiler when it hits that spot. You could try to eliminate that bogus report by doing an unnecessary extra check of ->errorjmp guarding just the recursive call line and seeing if it clears the warn. I think these "restrict" qualifiers young ones use those days help, but I fear they are not C89. Francisco Olarte. -- You received this message because you are subscribed to the Google Groups "lua-l" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/lua-l/CA%2BbJJbxC7J0i%2B4ZX%2BQZw6eK9F6x_6ro9WwbAMKjPw1sz9gTTrA%40mail.gmail.com.