I think we should remove all those "debug" checks about lines/columns/levels/... being to big. I don't see any real benefit having them, unless there was a specific issue I am not aware of.
@guy-maurel what do you think? Any reason for those debug checks?

The code should help finding value underfloww for size_t variable, as soon as possible.
Yes 10000 is not the best value.
Let us try with 18446744073709551608

Let us try with 18446744073709551608

I don't see the point to be honest. First I doubt there will even be a file with more that 18446744073709551608 lines or columns (and if there is, I am ok with uncrustify failing in such case) and second if we are seeing an underflow of a size_t variable, it means there is a logic error somewhere. The check is just hiding the problem instead of fixing it.
Can you point me to the original problem/issue with this? I remember sometime last year we had an issue with columns and a size_t variable having an underflow. Is that the case?

Having the test against the big value give me an oportunity to set a breakpunkt with the program eclipse.
I kann see which functions are calling the test.
This way shows me (in the past) more than 10 cases. I could repair them.
Just now, we don't have any problem.
The call is only with the DEBUG set.
The same is to see at uncrustify.cpp lines 450 ..., "// make sure we have 'name' not too big"
The function keywords_are_sorted looks at problem(s) which are already solved.

We could use another macro to test it only if set. Such as at parsing_frame.cpp with the macro DEBUG_PUSH_POP

IMHO, the checks are fine for things other than the lines, since that clearly breaks when running with files longer than 10000 lines. That's why I only removed the checks for the lines. Changing the value from 10000 to 2^63 isn't going to help anything. You might as well just remove the checks in that case since the program would have to run for 10000 years for the trigger to hit.

Having the test against the big value give me an oportunity to set a breakpunkt with the program eclipse.

I find restrictive for users to have such limits and again, if the problem was caused by a size_t value that went underflow, the checks are hiding the problem instead of fixing it.
How about having a special cmake config option variable to enable those checks and set a value? If no option is given, the checks are disabled. If the option is given and the value is >0, then use that value as limit for the check. This still allows you to set a breakpoint but does not affect normal users.

@guy-maurel I tracked down that issue where we were having size_t underflow (see PR #4547). Is that the reason why we introduced the limit checks?

I wanted to repeat my position:
IT IS only a debug tool.
I had (some 10 time) such a problem.
I modify the code to get the posibility to put a break/eclipse,
As the break is reached, I can understand what is going , solve the problem.
After that the test is no more usefull.
We can introduce a special cmake config option variable to enable those checks and set a value.
It would be fine.
The same could be done for DEBUG_PUSH_POP

We can introduce a special cmake config option variable to enable those checks and set a value.

Yes, that would be perfect. You can build with the option set when you want to be able to add breakpoints for testing, while normal users won't be affected by the tests.

It can be a simple #define in the code, for example:

#ifdef USE_LIMIT_TESTS
   if (line > USE_LIMIT_TESTS)
   {
      fprintf(stderr, "%s(%d): the input parameter is too big %zu\n",
              __func__, __LINE__, line);
      log_flush(true);
      exit(EX_SOFTWARE);
   }
#endif

Then when you call cmake, you can pass the value like cmake -DUSE_LIMIT_TESTS=10000 for example. Simple and clean.
Let me know if you want me to prepare a PR for it.