Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Jul 2019 17:29:18 -0400
From:      Phil Shafer <phil@juniper.net>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        <arch@FreeBSD.org>
Subject:   Re: expand_number(3)
Message-ID:  <F947286A-9D2A-48A8-9C30-76879D6A7A0E@juniper.net>
In-Reply-To: <afdc443d-3138-baca-337a-1111c6df4f7c@FreeBSD.org>
References:  <afdc443d-3138-baca-337a-1111c6df4f7c@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Would a reasonable goal be to make expand_number and humanize_number =

(with HN_IEC_PREFIXES) should be as compatible as possible?

The API doesn't allow many humanize-style features, but having the =

number->string->number work would be ideal so support for =

HN_DECIMAL-style input should be added, so "1.1K" does the right thing =

(thought it rounds to 1126).

Lacking support for "suffix", trailing garbage should not be an error =

(ala atoi), though I wish there was a parameter like strtol()'s endptr =

to pass the next point to the character back in.  If there was a suffix =

parameter, the endptr would be skipped over it, if present.

The expand_number API uses uint64_t where humanize_number uses signed =

int64_t so the answer for negative numbers is DOA.

Is it worth making a new expandize_number() function =

(dehumanize_number?) that brings the API more into sync with =

humanize_number?

Thanks,
  Phil



On 10 Jul 2019, at 14:14, John Baldwin wrote:

> While working on some bhyve changes I happened to look at the source
> to expand_number(3) and noticed what I think are several bugs.  I
> wrote some tests to validate that these bugs are present, but in some
> cases I'm not sure what the correct / desired behavior is?  I posted
> a review with the tests and questions about what some of the behavior
> should be with folks who have worked on expand_number(3) previously,
> but haven't gotten any feedback.  The URL to the review is below if
> other folks would like to offer feedback on some of my open questions
> such as should we support negative numbers, hex and octal bases,
> trailing garbage, etc.?
>
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__reviews.freebsd.=
org_D20796&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D=
And7spKEXmRNIrq8pYCiSg&m=3DEHG6EmocNCDS6VoOZVxzZoCq-BqbJjBpsC9kXhGFTd0&s=3D=
bUQ8xvhg6vv95W5fHxswOrzDIeVxFsFJIa2582tjHgA&e=3D
>
> -- =

> John Baldwin
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__lists.freebsd.or=
g_mailman_listinfo_freebsd-2Darch&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBX=
eMK-ndb3voDTXcWzoCI&r=3DAnd7spKEXmRNIrq8pYCiSg&m=3DEHG6EmocNCDS6VoOZVxzZo=
Cq-BqbJjBpsC9kXhGFTd0&s=3D_ChOm4nn2d9pTlDuA6I2EdYXc73LOiS_N4c0k0DOWPo&e=3D=

> To unsubscribe, send any mail to =

> "freebsd-arch-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F947286A-9D2A-48A8-9C30-76879D6A7A0E>