You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Doing that is wrong. Imagine a scenario where w and h are 0. In that case, we enter the loop, and write to mip_data… but mip_data has a length of zero at that point so we can't write to it. We have a bug here either way. (If you look at the full code you'll also see that our access to data has a bug as well, since the first iteration will access data[4], but it will only have a total size of four at that point. But that's just for bonus points.)
If we get to a situation where this //PARANOID code actually does something, then we're already in trouble. Some part of the code messed up, and now we're dealing with invalid data. This paranoid stuff allows the code to limp along a little bit further, so it can then crash somewhere else, where nobody knows where it's coming from.
The solution? assert. In that case,
assert(w > 0 && h > 0);
Plain and simple. If the condition is violated, we get a crash, exactly at the point where we got the wrong data, and can debug it. The app never enters an undefined state.
The text was updated successfully, but these errors were encountered:
There are a number of places in the code where some invariant is enforced with a comment saying something like //PARANOID! See for example:
from bordered_texture_atlas.cpp.
Doing that is wrong. Imagine a scenario where w and h are 0. In that case, we enter the loop, and write to
mip_data
… butmip_data
has a length of zero at that point so we can't write to it. We have a bug here either way. (If you look at the full code you'll also see that our access to data has a bug as well, since the first iteration will access data[4], but it will only have a total size of four at that point. But that's just for bonus points.)If we get to a situation where this //PARANOID code actually does something, then we're already in trouble. Some part of the code messed up, and now we're dealing with invalid data. This paranoid stuff allows the code to limp along a little bit further, so it can then crash somewhere else, where nobody knows where it's coming from.
The solution? assert. In that case,
Plain and simple. If the condition is violated, we get a crash, exactly at the point where we got the wrong data, and can debug it. The app never enters an undefined state.
The text was updated successfully, but these errors were encountered: