I'd advise some research before you institute option (A) as that can kill your CPU 😉 Letting SQL actually do the limiting can make your application faster. One thing you could do, is run a very quick query to get the IDs of those records you want. Then, when the IDs are returned, you can count() the array, divide that count by the number you want displayed, then figure out where you should "start" in the rows by some simple math:
($page - 1) $num_per_page
which would give you the correct number to start with. For example:
(1 - 1) 25 = 0 (first page, start at the first returned record)
(2 - 1) * 25 = 25 (second page, start at the 25th record)
Then run a query selecting records with IDs only in the previously retrieved IDs, and starting at the start which was calculated by you, and limiting it to 25 rows. With larger datasets, this can really speed things up.
Unless you can control your environment, I'd be weary of option (c) as well. If two queries go off one right after the other, and you run "SELECT FOUND_ROWS()" expecting the result of the first, you'd actually get the result of the second. Here's a quick break-down in time:
[17:08:05.00 GMT] - UserA runs query1 (SELECT FROM table LIMIT 0, 100)
[17:08:05.50 GMT] - UserB runs query2 (SELECT FROM alt_table LIMIT 0, 50)
[17:08:05.90 GMT] - UserA executes query3 (SELECT FOUND_ROWS())
[17:08:05.99 GMT] - UserB executes query3
Now, both UserA and UserB would see the exact same row count even though they both queried different tables for different information. I could be wrong (by that I mean MySQL may be able to differentiate between multiple sessions of your script), but it's still something you want to be careful about.