without while(1) why this code in MPLAB is running continuously - c

Question

In this code I have not used while(1), only when it enters 'if' condition it calls TIMER_ISR function which has been initialised for every 250ms. But when it enters else condition there is no any timer function or anything but then also why it is running continuously.
#include <stdint.h>
#include <stdlib.h>
#include <string.h>
#include "mcc_generated_files/mcc.h"
#include "mcc_generated_files/eusart1.h"
void main(void)
{
SYSTEM_Initialize();
INTERRUPT_GlobalInterruptEnable();
INTERRUPT_PeripheralInterruptEnable();
char temp1[] = "ok";
char temp2[3] = { '\0', '\0', '\0' };
char temp3[3], temp4[3];
int i, j;
for (i = 0; temp1[i] != '\0'; i++)
{
temp3[i] = temp1[i] - 32;
EUSART1_Write(temp3[i]);
}
EUSART1_String("\r\n");
for (i = 0; i < 2; i++)
{
temp2[i] = EUSART1_Read();
EUSART1_Write(temp2[i]);
}
EUSART1_String("\r\n");
if (strcmp(temp1, temp2) == 0)
{
for (i = 0; temp1[i] != '\0'; i++)
{
if (temp1[i] >= 'a' && temp1[i] <= 'z')
{
temp1[i] = temp1[i] - 32;
}
}
for (j = 0; temp1[j]; j++)
EUSART1_Write(temp1[j]);
//Timer initialization (timer is initialized for every 250mS)
TMR0_Initialize();
}
else
EUSART1_String("\r\nERROR GIVE'ok'");
}

Answer 1

In case the question is: does it make sense to return from main() on a bare metal MCU application, then TL;DR: No it doesn't make sense because there is nobody to return to. No OS to hold your hand - your application is all there is.
Detailed explanation:
All modern MCUs have a point of entry called "reset interrupt". Where you can end up when you get a power-on, or perhaps after a watchdog circuit has reset the MCU, or because you have an external /reset signal on the MCU reset pin.
The program counter then starts the program by entering the interrupt service routine for power-on reset (sometimes called reset vector). From here on, the most basic stuff on the MCU are set, then typically it will call a "C run-time" (CRT), which is compiler-specific start-up code for the purpose of initializing all memory regions to enable a standard C environment, such as initializing variables etc. When the CRT is done with all that, it calls main().
Or in case you wrote everything in assembler, you wouldn't have to bother with the CRT but can call whatever function you like from the reset ISR. Often this is done with a direct jump instead of a function call, without stacking any parameters, because you don't expect to ever return. You'd only waste stack space needlessly.
That's why the most common form of main() in embedded systems is void main (void), rather than the strictly C conforming int main (void) - the latter may waste space on the stack needlessly due to calling convention. (On the gcc compiler, always pick embedded "freestanding" systems as your target with -ffreestanding.)
Now if you wrote the program in C and were to return from main(), you will at best crash back out into the CRT code, where if you are lucky, some kind person wrote a for(;;){} loop there to catch the program counter. This is common with rookie-friendly environments. Alternatively you could crash all the way back out to the power-on reset ISR.
Or more likely, in case main() was called the assembler way described above (either from the CRT or from your custom code) you jump straight into the unknown since no return address was saved.
From there, the program counter will run out in random memory locations, starting to execute whatever it comes across next in the memory it ends up, interpreting the contents of those cells as OP codes, whether they are that or not - you get "runaway code", which is a severe and dangerous bug condition. It will keep doing this either until it stumbles upon something that causes a hardware exception, like accessing protected memory, or until the watchdog resets everything, in case the watchdog is enabled.