Input to make worst case on big O not possible? Sorry if this question is very simplistic; I'm just starting out and I'm trying to wrap my head around all this asymptotic bound stuff. When trying to find the upper bound for the worst case of a function does it need to take into account what the meat of the code actually does? I have some code that would (in the worst case) iterate through a while loop n times, but when you consider what that code actually does, it would always make it so that the condition for the while loop becomes false on the next iteration.

Some people say that it doesn't matter what is actually happening within the code; just that if it has the ability to iterate n times (even though it's virtually impossible because of the body of the loop) then that would be the worst case vs. however many steps the code ACTUALLY runs. 

If anyone has any insight it would be greatly appreciated! Thanks!
It matters what is actually happening in the code. The following pseudocode is O(1)

loop_factor = input()

for x between 0 and loop_factor():
    for y between 0 and loop_factor():
        terminate


However, it doesn't matter what is likely or reasonable to happen. If the body of your loop makes it "virtually" guaranteed that the loop will terminate next iteration, that means nothing; you need an actual hard proof that the loop will exit early for all input, no matter how absurd.

Essentially if you can rewrite your algorithm so that the loop clearly can't iterate n times without changing the meaning (i.e. replace the loop with just a few copies of the loop body in if statements, or something), then you are justified in saying that the loop isn't going to do n iterations. If you really need the loop to be there in the code as a loop that can iterate up to n times, then the big-oh complexity of the loop almost certainly does have to be n times the complexity of the loop body.