Actually, 2 questions.

First of all, the SDL documentation wiki says the following about SDL_Delay()

"This function waits a specified number of milliseconds before returning. It waits at least the specified time, but possible longer due to OS scheduling. The delay granularity is at least 10 ms. Some platforms have shorter clock ticks but this is the most common."

First question: Negative numbers = no problem, right? It will just wait for 0 ms?

Second question: What is the meaning of the word "granularity" here? What will cause it to wait longer than expected, and how will this effect my framerate if I am using SDL_Delay()?

Well I just tried a negative number and my program completely blew up in my face. So never mind about that one!

SDL_Delay takes an unsigned integer as argument it can impossible be negative. Passing a signed integer will probably be converted into some large value.
Granularity means the timing is less precise than milliseconds. If you do SDL_Delay(16) it might handle it the same as SDL_Delay(10), I think it is like that but not sure exactly.
Your program is not the only one running so it can have to wait longer sometimes because it is doing other things.

SDL_Delay takes an unsigned integer as argument it can impossible be negative. Passing a signed integer will probably be converted into some large value.
Granularity means the timing is less precise than milliseconds. If you do SDL_Delay(16) it might handle it the same as SDL_Delay(10), I think it is like that but not sure exactly.
Your program is not the only one running so it can have to wait longer sometimes because it is doing other things.

Well then why can't I just use something like...

while(true)
{
if ( /*the current frame has been displayed long enough*/ )
{
break;
}
}

...for all frame rate regulation and just skip using delay? Wouldn't a loop be more accurate because it is executing continuously, instead of just waiting a random amount of time depending on the system? Or does delay have some added benefit?

SDL_Delay takes an unsigned integer as argument it can impossible be negative. Passing a signed integer will probably be converted into some large value.
Granularity means the timing is less precise than milliseconds. If you do SDL_Delay(16) it might handle it the same as SDL_Delay(10), I think it is like that but not sure exactly.
Your program is not the only one running so it can have to wait longer sometimes because it is doing other things.

The key here is that SDL waits for at least the number of milliseconds so it will wait at least 16 milliseconds but you may wait longer depending on the resolution of the underlying timer. If the underlying timer only responds every 10 milliseconds then you will wait closer to 20 milliseconds if you request 16.

Frankly I haven't run into an issue on modern hardware where this was an issue. I never found much use for frame limiting however if you just want the game to give up some CPU to the rest of the processes on your computer then do an SDL_Delay(1) if the last frame took less than the desired time each frame should take. This is enough to let your game run as responsive as possible and also let the OS have some time too although if you re playing a game what else should your computer really be doing?

Um, what about chat programs running in the background? Especially voice chatting. You probably want to leave free CPU time for those. Also video recording programs if you want to record what you're doing in the game, etc. Also less CPU heating, of course =P

And why would you want to wait a negative number of milliseconds? Do you want to travel back in time? o_O

Um, what about chat programs running in the background? Especially voice chatting. You probably want to leave free CPU time for those. Also video recording programs if you want to record what you're doing in the game, etc. Also less CPU heating, of course =P

The SDL_Delay(1) should take care of that as it will wait at least 1 ms but as previously mentioned probably more especially if the other processes want more time. The key here is that each application has specific needs for instance a FPS most likely will not be sleeping at all between frames and will be chugging along as fast as it can whereas a turn based strategy can take some more time between frames as things happen in a somewhat synchronous action/response time line.

In most cases frame limiting is used as a timing mechanism to make sure things happen the same way across different hardware. It has been suggested many times on these forums and others that this is a less than ideal solution and time/delta based updates should be used instead. Think about it - if you bought a brand new BMW M3 and went on the German Autobahn but your car was rate limited to only go as fast as say a Ford Focus you would be pretty upset...

That being said - giving up a little bit of CPU time if your game doesn't need it is never a bad idea