Bug #6088 FOUND_ROWS returns wrong values for prepared statements when LIMIT is used

Description:
When executing a prepared statement "SELECT SQL_CALC_FOUND_ROWS ... LIMIT x"  
FOUND_ROWS returns the number of records in the resultset and not the number of rows without 
LIMIT. 

How to repeat:
5.0.2-alpha-debug-log 
[12:29] root@test> create table t1 (a int); 
Query OK, 0 rows affected (0.08 sec) 
 
5.0.2-alpha-debug-log 
[12:30] root@test> insert into t1 values (1),(2),(3),(4),(5),(6),(7),(8),(9),(10); 
Query OK, 10 rows affected (0.00 sec) 
Records: 10  Duplicates: 0  Warnings: 0 
 
[12:30] root@test> PREPARE my_stmt FROM 'SELECT SQL_CALC_FOUND_ROWS * FROM t1 LIMIT 2'; 
Query OK, 0 rows affected (0.00 sec) 
Statement prepared 
 
5.0.2-alpha-debug-log 
[12:30] root@test> execute my_stmt; 
+------+ 
| a    | 
+------+ 
|    1 | 
|    2 | 
+------+ 
2 rows in set (0.00 sec) 
 
5.0.2-alpha-debug-log 
[12:30] root@test> SELECT FOUND_ROWS(); 
+--------------+ 
| FOUND_ROWS() | 
+--------------+ 
|            2 | 
+--------------+ 
1 row in set (0.00 sec)

Fixed in 4.1.7
Subject: bk commit - 4.1 tree (konstantin:1.2132) BUG#6088

ChangeSet
  1.2132 04/10/22 22:49:12 konstantin@mysql.com +4 -0
  A fix and test case for Bug#6088 "FOUND_ROWS returns wrong values for
  prepared statements when LIMIT is used" and post-review comments.
  The fix changes the approach we calculate the need for ORDER BY
  in UNION: the previous was not PS friendly, as it damaged SELECT_LEX
  options in case of single select.