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.