<blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">Places where expected ranges are not clear or quite wide, see the pid_t</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">This particular case is due to the undefinedness of the pid_t range.<br>We can never get rid of this weird range guessing game with pid_t.</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">My argument here is that INT64_MAX is sufficiently giga-humungous that this is not even a thing in practice: 9223372036854775807!!<br>Ususally we have ranges 0-255 or 0-999 or 0-INT_MAX or even if it is 0-UINT_MAX,<br>these are all way way way WAY WAY WAY WAAAAY (> two billion times!) within int64_t.</p><p style="white-space: pre-wrap; word-wrap: break-word;">So I doubt that we need an osmo_str_to_uint64() ever.<br>But I don't oppose adding unsigned API of this in principle.<br>If we need it, then of course we can simply add this API later.<br>I merely don't see a reason to add this now without a concrete user that needs it:<br>it's called API creep to have more functions than you need, for no *real* reason.</p><p style="white-space: pre-wrap; word-wrap: break-word;">A practical argument would be that we can directly pass an unsigned int as return argument<br>(&val) if the data type matches, but that would mean that we need to add one function for each<br>and every data type we use anywhere. I'd rather avoid that.</p><p style="white-space: pre-wrap; word-wrap: break-word;">BTW, that other patch moving strtol() users to osmo_str_to_int() is optional,<br>we can e.g. leave that pid_t case in the current implementation.</p><p><a href="https://gerrit.osmocom.org/c/libosmocore/+/25345">View Change</a></p><ul style="list-style: none; padding: 0;"></ul><p>To view, visit <a href="https://gerrit.osmocom.org/c/libosmocore/+/25345">change 25345</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/c/libosmocore/+/25345"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: libosmocore </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-Change-Id: I4dac826aab00bc1780a5258b6b55d34ce7d50c60 </div>
<div style="display:none"> Gerrit-Change-Number: 25345 </div>
<div style="display:none"> Gerrit-PatchSet: 1 </div>
<div style="display:none"> Gerrit-Owner: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder </div>
<div style="display:none"> Gerrit-Reviewer: pespin <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-Comment-Date: Tue, 07 Sep 2021 11:22:25 +0000 </div>
<div style="display:none"> Gerrit-HasComments: No </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Gerrit-MessageType: comment </div>