Change in libosmocore[master]: utils: add osmo_str_to_int() and osmo_str_to_int64()

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

neels gerrit-no-reply at lists.osmocom.org
Tue Sep 7 11:22:25 UTC 2021


neels has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/25345 )

Change subject: utils: add osmo_str_to_int() and osmo_str_to_int64()
......................................................................


Patch Set 1:

> Places where expected ranges are not clear or quite wide, see the pid_t

This particular case is due to the undefinedness of the pid_t range.
We can never get rid of this weird range guessing game with pid_t.

> or simply a vty command where you'd like yo parse any unsigned range. By not having an unsigned API, you are limiting the code to lower ranges since the range of naturals numbers an integer variable can hold is always less than the unsigned counterpart.

My argument here is that INT64_MAX is sufficiently giga-humungous that this is not even a thing in practice: 9223372036854775807!!
Ususally we have ranges 0-255 or 0-999 or 0-INT_MAX or even if it is 0-UINT_MAX,
these are all way way way WAY WAY WAY WAAAAY (> two billion times!) within int64_t.

So I doubt that we need an osmo_str_to_uint64() ever.
But I don't oppose adding unsigned API of this in principle.
If we need it, then of course we can simply add this API later.
I merely don't see a reason to add this now without a concrete user that needs it:
it's called API creep to have more functions than you need, for no *real* reason.

A practical argument would be that we can directly pass an unsigned int as return argument
(&val) if the data type matches, but that would mean that we need to add one function for each
and every data type we use anywhere. I'd rather avoid that.

BTW, that other patch moving strtol() users to osmo_str_to_int() is optional,
we can e.g. leave that pid_t case in the current implementation.


-- 
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/25345
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I4dac826aab00bc1780a5258b6b55d34ce7d50c60
Gerrit-Change-Number: 25345
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-Comment-Date: Tue, 07 Sep 2021 11:22:25 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210907/1e4b9eb6/attachment.htm>


More information about the gerrit-log mailing list