Re: Reuse strtonum(3) and reallocarray(3) from OpenBSD

[christos%astron.com@localhost (Christos Zoulas)]

In article <trinity-c60151a8-7fcc-4d85-b88d-4ce61b9ab7ff-1421366624151@3capp-mailcom-bs03>,
Kamil Rytarowski <n54%gmx.com@localhost> wrote:
>-=-=-=-=-=-
>
>Christos Zoulas wrote:
>> In article
><trinity-ca966487-0a1b-4764-aed0-db52921dcd0b-1421288059648@3capp-mailcom-bs04>,
>> Kamil Rytarowski <n54%gmx.com@localhost> wrote:
>> >-=-=-=-=-=-
>> >
>> >Christos Zoulas wrote:
>> >> On Jan 14,  1:35am, n54%gmx.com@localhost ("Kamil Rytarowski") wrote:
>> >> -- Subject: Re: Reuse strtonum(3) and reallocarray(3) from OpenBSD
>> >> 
>> >> | Christos Zoulas wrote:
>> >> | > I still don't get what you buy by having 2 sets of functions to
>> >save a passed
>> >> | > NULL pointer... Aside confusion.
>> >> | 
>> >> | Remove duplication of information returned to caller, related to
>> >partial conversion.
>> >> | Also returning error for valid conversion is (for me) misguiding.
>> >> | 
>> >> | What do you think about this to return ENOTSUP only if:
>> >> | - endptr was passed as NULL and
>> >> | - there happened partial conversion.
>> >> 
>> >> What about if no characters match? How do you tell the difference?
>> >> So if endptr != NULL behave differently? This is confusing.
>> >
>> >Well, I was thinking about this use-case and if there is need to
>differentiate
>> >partial conversion with and without parsed digits.
>> >
>> >A candidate would be to set *rerror to ECANCELED in this case.
>> 
>> I think there is because if no characters were read there was no conversion,
>> and thus no valid return value. ECANCELED for that seems ok to me.
>> 
>
>Done!

Committed.

christos