GitLab now enforces expiry dates on tokens that originally had no set expiration date. Those tokens were given an expiration date of one year later. Please review your personal access tokens, project access tokens, and group access tokens to ensure you are aware of upcoming expirations. Administrators of GitLab can find more information on how to identify and mitigate interruption in our documentation.
We can see that the program segfaults when entering a value between 10^7 and 10^19. Then, starting with 10^19 approximately, is stops segfaulting, but starts giving wrong results.
This is because we set a SIZE of 100 in the program, so the compiler will assume that SIZE will not be higher than 100 (which is wrong because the user can set more than 100 when running the program). So the operating system will allocate at least 100 integers for the "generated_numbers" array, but not necessarily more. This means that if the user choses a size of more than 100, the program will try to write after the allocated space for "generated_numbers", which may result in a segfault.
In addition to that, the SIZE is stored in an integer variable, so if the user choses a size that is higher than INT_MAX, the content of the variable SIZE will be undefined, because it cannot store the number entered by the user. This explains the wrong results after entering a value higher than INT_MAX.
To fix the issue, we first need to allocate the space for "generated_numbers" in the stack instead of the heap (which is what the program currently does). This gives us the ability to set the size of the array at run time instead of compile time. To do that, we use "malloc". We should also add a check to avoid the user to input a number that is higher than INT_MAX, but this isn't straightforward, as we cannot check if an integer is higher than INT_MAX after storing it.