I would really prefer if this did not need floating point.
>From owner-tech+m90...@openbsd.org Mon Aug 29 03:52:24 2022
>Delivered-To: dera...@cvs.openbsd.org
>Date: Mon, 29 Aug 2022 11:47:16 +0200
>From: =?utf-8?B?0L3QsNCx?= <nabijaczlew...@nabijaczleweli.xyz>
>To: Stuart Henderson <s...@spacehopper.org>
>Cc: tech@openbsd.org
>Subject: Re: [PATCH] Correctly (per POSIX) round up df usage percentage
>References: <20220827135316.4l2aawaoylbmb...@tarta.nabijaczleweli.xyz>
> <ywpemkt1vmuqi...@bamboo.spacehopper.org>
>MIME-Version: 1.0
>Content-Type: multipart/signed; micalg=pgp-sha512;
> protocol="application/pgp-signature"; boundary="g24jmql4w5mrdtfc"
>Content-Disposition: inline
>In-Reply-To: <ywpemkt1vmuqi...@bamboo.spacehopper.org>
>User-Agent: NeoMutt/20220429
>List-Help: <mailto:majord...@openbsd.org?body=help>
>List-ID: <tech.openbsd.org>
>List-Owner: <mailto:owner-t...@openbsd.org>
>List-Post: <mailto:tech@openbsd.org>
>List-Subscribe: <mailto:majord...@openbsd.org?body=sub%20tech>
>List-Unsubscribe: <mailto:majord...@openbsd.org?body=unsub%20tech>
>X-Loop: tech@openbsd.org
>Precedence: list
>Sender: owner-t...@openbsd.org
>
>
>--g24jmql4w5mrdtfc
>Content-Type: text/plain; charset=utf-8
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>Hi!
>
>On Sat, Aug 27, 2022 at 05:20:00PM +0100, Stuart Henderson wrote:
>> df is used on the ramdisk, so this would need testing there (at least on
>> the tighter media on some archs).
>>=20
>> at least one other ramdisk binary does pull in libm so the overall size
>> increase might not be terrible, but definitely would need checking.
>
>I lack the knowledge and capability to do testing beyond "I just built
>the patched version on CI and it rounded correctly", sorry.
>
>But if linking to libm is an issue, we could substitute the ceil(3)s
>with something trivial like
>-- >8 --
>int iceil(double d) {
> int ret =3D d;
> if(ret < d)
> ++ret;
> return ret;
>}
>-- >8 --
>since all the formatting specifiers use %.0f anyway and the [0, 200)
>domain is small enough that precision loss/overflow is not a factor.
>
>Best,
>=D0=BD=D0=B0=D0=B1
>
>--g24jmql4w5mrdtfc
>Content-Type: application/pgp-signature; name="signature.asc"
>
>-----BEGIN PGP SIGNATURE-----
>
>iQIzBAABCgAdFiEEfWlHToQCjFzAxEFjvP0LAY0mWPEFAmMMiyEACgkQvP0LAY0m
>WPFsSBAAqhg/9kgI6wLF1tX/S8PslI/LcIarSSw5C97acfarU9KbI++k1doVsKL4
>MeCXfBYqHVN4abVjpnQdVbf+wxsbj0g+SYNj+bEs1kQnpt0444tfgN8ea/6KrDS2
>l4eUHss1Bp667BoWyil8MgIESyPyswxdRwk5Ik/sXCSj7f89xTJAnwfDuuqEZpU9
>/xIey7E0d72lhpiTXDFdB50TsH3Cvtggf/ImXgbLdALZ1L7j8LurOu5jtjENTWtL
>4lkP/h6J46yuh0NAAFQk35mP48zeuMuICt5KxdlSTJAdmrDpQz+4W74g0izF1Lqs
>SNUWrkIHYirtPtjbPLB/+FgQt9okGY7ZGrRFSAwR0jxQh28+xTxpyaLSbrUqxYor
>rKG5JsNtCkV9ylXHpeQNeXu7uGy7ZO6mdnVGnwK7CdiQCU0QQ/BbbnNJ1lyhgkiB
>gHuK4MibINo/psF33tDMfN4hck6X6FW6mfemYei8sEsVLI/L1ioECJLXLcUyZKGl
>v00g4usuAl8Xb/WRhSOnGc98HQEcDuLtiE3gc8VT30NsQsKruPtX4gf47aGUbt8S
>dRVM5sdSAaxMixS7VN2cmIOJtt1y4GysrO7v3Gt06mvcYLrRLkfazIWYMXTjpgRT
>7k4fTZqMFWa1wDuPe9wL72oVv/VKZsKUkfkpj3WQmFO9Wu4yCp8=
>=RKzL
>-----END PGP SIGNATURE-----
>
>--g24jmql4w5mrdtfc--
>
>
