Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Division by zero FPD #1956

Closed
Destroy666x opened this issue Apr 12, 2015 · 7 comments
Closed

Division by zero FPD #1956

Destroy666x opened this issue Apr 12, 2015 · 7 comments
Assignees
Labels
b:1.8 Branch: 1.8.x s:resolved Status: Resolved. Solution implemented or scheduled t:bug Type: Bug. An issue causing error / flaw / malfunction
Milestone

Comments

@Destroy666x Destroy666x added t:bug Type: Bug. An issue causing error / flaw / malfunction s:confirmed Status: Confirmed. Retested and found the issue exists b:1.8 Branch: 1.8.x labels Apr 12, 2015
@Destroy666x Destroy666x added this to the 1.8.6 milestone Apr 12, 2015
@dvz
Copy link
Contributor

dvz commented Apr 21, 2015

Added the second part;
in case of repsperpage and membersperpage the value would be defaulted like in the other places; I guess we should do the same with maxwarningpoints (default is 10)?

@dvz dvz self-assigned this Apr 21, 2015
@Destroy666x
Copy link
Contributor Author

I guess we should do the same with maxwarningpoints (default is 10)

Probably, if we want to be consistent at least. I'd also add a minimum note to that setting's description because some admins may think that 0 disables the maximum.

As for the commits you made - I think the check should be rather something like:

$perpage = (int)$mybb->settings['repsperpage'];
if($perpage < 1)

to be completely safe. Because right now someone can change it to -1 or anything stupid and this may lead to unexpected behavior (or even a MySQL error because of invalid LIMIT).

@dvz
Copy link
Contributor

dvz commented Apr 22, 2015

Integers can be negative, so that would have to go by abs((int)$mybb->settings['repsperpage']).

Doing the thing with maxwarningpoints will eliminate the math issue but is likely to cause unpredictable behavior (the value of 0 won't produce errors but the application logic might fail).

@Destroy666x
Copy link
Contributor Author

Integers can be negative

That wouldn't make any sense in any of the settings mentioned in this issue though - per page and warning points are supposed to be always positive.

so that would have to go by abs((int)$mybb->settings['repsperpage'])

I don't see the need of abs() when there's an if check that reverts the setting to default if a non-positive value is entered for some reason. We could make the number positive instead, yes, but that doesn't really matter - both default and absolute will use other number than the one specified in ACP anyways. And we already use the default in these cases in some places, for example: https://github.com/mybb/mybb/blob/feature/showthread.php#L364

@dvz
Copy link
Contributor

dvz commented Apr 22, 2015

That wouldn't make any sense in any of the settings mentioned in this issue though - per page and warning points are supposed to be always positive.

True, but it should be corrected anyway because it emits a PHP error, leading to FPD (you never know when it might get in handy for someone).

I don't see the need of abs() when there's an if check that reverts the setting to default if a non-positive value is entered for some reason.

In this case there is no such check ((bool)(int)'-1', an equivalent of that IF, returns true). Many examples related to LIMIT statements: http://community.mybb.com/thread-169555-post-1154569.html#pid1154569).

@Destroy666x
Copy link
Contributor Author

True, but it should be corrected anyway because it emits a PHP error, leading to FPD
In this case there is no such check ((bool)(int)'-1', an equivalent of that IF, returns true).

I'm still not sure what you mean, -1 (or anything less than 1) in the setting with the code I suggested above would be changed to the default 20, which would always prevent FPD - or am I missing something?

@dvz
Copy link
Contributor

dvz commented Apr 22, 2015

Right, ($perpage < 1) would work (I must have been looking at a different fragment - (!$perpage), there are lots of these - changing to < 1 would do the trick).

@dvz dvz added s:resolved Status: Resolved. Solution implemented or scheduled and removed s:confirmed Status: Confirmed. Retested and found the issue exists labels Apr 22, 2015
@Destroy666x Destroy666x modified the milestones: 1.8.5, 1.8.6 Apr 25, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
b:1.8 Branch: 1.8.x s:resolved Status: Resolved. Solution implemented or scheduled t:bug Type: Bug. An issue causing error / flaw / malfunction
Projects
None yet
Development

No branches or pull requests

2 participants