You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a few input values that cause panics in rand or from bad maths. It would be nice to protect users from these.
width <= 0 cause range errors in rand
height <= 0 cause range errors in rand
max_samples == 0 cause divide by zero errors
very high widths / heights or very low min_radius causes multiplication overflow errors when creating the grid vector.
The first three are easy to handle. The last one, not so much. Integer overflow is obviously not great but what if we were to fix it? Attempted allocation for > 2^64 Vec2 is a good hundred exabytes. I am for preventing an overflow panic, but I am very against handling 'too large' grids because we don't want to impose arbitrary limits.
One option is to create a proper builder, with a build method returning something along the lines of Result<BlueNoise, BuildError>.
The text was updated successfully, but these errors were encountered:
There are a few input values that cause panics in
rand
or from bad maths. It would be nice to protect users from these.width <= 0
cause range errors in randheight <= 0
cause range errors in randmax_samples == 0
cause divide by zero errorsThe first three are easy to handle. The last one, not so much. Integer overflow is obviously not great but what if we were to fix it? Attempted allocation for > 2^64
Vec2
is a good hundred exabytes. I am for preventing an overflow panic, but I am very against handling 'too large' grids because we don't want to impose arbitrary limits.One option is to create a proper builder, with a
build
method returning something along the lines ofResult<BlueNoise, BuildError>
.The text was updated successfully, but these errors were encountered: