|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #58536 SetLimits uses wrong parameter ordering
Submitted: 2009-02-05 10:55 UTC Modified: 2009-02-05 13:01 UTC
From: ash at ewelike dot com Assigned:
Status: Not a bug Package: sphinx (PECL)
PHP Version: 5.2.5 OS: OS X Tiger
Private report: No CVE-ID: None
 [2009-02-05 10:55 UTC] ash at ewelike dot com
Calling $sphinxClient->setLimits(0, 10) should return 
(maximum) of 10 results, but in fact returns an error:

"per-query max_matches=0 out of bounds (per-server 

The PECL documentation at shows 
the order is ($offset, $limit, ...) but it's being treated as 
($limit, $offset, ...)

The documentation order ($offset, $limit) is consistent with 
the pure PHP SphinxClient, and as the pecl package aims to be 
API compatible, the PECL client should change to honour the 
documented parameter order.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-02-05 11:15 UTC] ash at ewelike dot com
The parameter ordering is correct (and consistent)- I 
misinterpreted the results caused by this bug:

 [2009-02-05 11:26 UTC] tony at daylessday dot org
max_matches is third parameter of setLimits() and it's 0 by default.
There is nothing wrong with the order of parameters, they're passed just as the documentation says.
 [2009-02-05 13:01 UTC] ash at ewelike dot com
The default max_matches value of '0' is handled badly 
(causing an error.)

I see you (Tony) have a patch attached to the sphinxsearch 
bug - the patch looks good (matching the pure PHP client) 
and getting the fix into a new PECL build would fix the 
problem reported here (despite the misleading summary.)
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sat Nov 26 08:05:54 2022 UTC