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
Mon Sep 13 09:56:05 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 4:

> Patch Set 4: Code-Review+1
> 
> What about uint8_t?

if you're asking for an osmo_str_to_uint8(), then it is a continuation of above discussion: should we add a separate function signature for each integer data type? My personal opinion is that we don't need those and should rather not have API creep for all integer types, given that literally the entire universe fits in an int64_t (signed or unsigned). I'd use constructs like this:

  int val;
  if (osmo_str_to_int(&val, "123", 10, 0, 255))
          return -EINVAL;
  my_obj->my_uint8 = val;
  return 0;

But two reviewers would prefer adding unsigned data types. My status is that I am ok with more API added at a later stage (probably by others), but I will not add more function signatures at this point.

I'm having another idea, we could flip rc and val like this:

  int64_t osmo_str_to_int64(int *rc, ...);

to get

  int rc;
  my_obj->my_uint8 = osmo_str_to_int(&rc, "123", 10, 0, 255);
  if (rc)
        return -EINVAL;
  
I chose the other way because when the rc evaluation happens *after* assigning the value,
we need to either recover back, or anyway use a tmp val placeholder:

  int rc;
  uint8_t val;
  val = osmo_str_to_int(&rc, "123", 10, 0, 255);
  if (rc)
        return -EINVAL;
  my_obj->my_uint8 = val;
  return 0;

So this ends up needing *more* local variables than when rc is returned directly (compare to first code snippet above).

If you guys prefer the implicit cast to whichever int type we can also do that?
(But I guess that's not the point, is it??)


-- 
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: 4
Gerrit-Owner: neels <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: dexter <pmaier at sysmocom.de>
Gerrit-Reviewer: laforge <laforge at osmocom.org>
Gerrit-Reviewer: neels <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-CC: osmith <osmith at sysmocom.de>
Gerrit-Comment-Date: Mon, 13 Sep 2021 09:56:05 +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/20210913/a47e2aa7/attachment.htm>


More information about the gerrit-log mailing list