Skip to content

fix(crop): prevent division by zero in margin calc - #66

Open
tachibana-shin wants to merge 2 commits into
koreader:masterfrom
tachibana-shin:fix/koptcrop-prevent-zero
Open

fix(crop): prevent division by zero in margin calc#66
tachibana-shin wants to merge 2 commits into
koreader:masterfrom
tachibana-shin:fix/koptcrop-prevent-zero

Conversation

@tachibana-shin

@tachibana-shin tachibana-shin commented Jul 22, 2026

Copy link
Copy Markdown

Change 1: In lib/koptcrop.c:92, the margin calculation computes:

margin = margin * (region->c2 - region->c1) / (kctx->dev_width - margin) / 2;
  • When kctx->dev_width <= margin (e.g. very small device width or very large margin setting), the denominator becomes zero or negative, causing undefined behavior (floating-point division by zero).
  • When the device width is too small to accommodate the requested margin, margin is set to zero (content fills the entire width).

Change 2: The file defines a global float min(float, float) at lib/koptcrop.c:32. This name collides with common min macros defined in system headers and other libraries, causing potential compilation issues or silent behavior changes depending on include order.


This change is Reviewable

Comment thread lib/koptcrop.c Outdated
#include "koptcrop.h"

float min(float a, float b) {
static float k2_min(float a, float b) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason we shouldn't we just use fminf() (from math.h) instead? The output seems to be identical at a quick glance.

Without the -ffast-math it just says branch to fminf which annoyingly doesn't tell me much about the internals. (I suppose I could check glibc etc.) According to the manpage NaN behavior may be different but in a way that sounds better.

These functions return the minimum of x and y.

If one argument is a NaN, the other argument is returned.

If both arguments are NaN, a NaN is returned.
Image Image

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I don't see any reason for it, but since this function is there, I don't want to delete it. The only difference between the results of the two functions is that k2_min returns 0.0 and fminf returns -0.0 when the boundary is -0.0 < 0.0, but I’ve looked through the code snippets and the parameters a + b are always greater than or equal to 0, so I don’t think there’s any difference.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that argument quite works if you're touching all the lines.

Pinging @hugleo, see #44.

Btw @benoit-pierre I noticed something funny if it bothers you or something:

#include <math.h>
#include <math.h>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that argument quite works if you're touching all the lines.

Pinging @hugleo, see #44.

It's fine with fminf.

@Frenzie

Frenzie commented Jul 22, 2026

Copy link
Copy Markdown
Member

Would you mind squashing the last two commits together?

@tachibana-shin
tachibana-shin force-pushed the fix/koptcrop-prevent-zero branch from 1eed128 to dfd4082 Compare July 22, 2026 20:39
@tachibana-shin

Copy link
Copy Markdown
Author

Would you mind squashing the last two commits together?

yeah done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants