<p><a href="https://gerrit.osmocom.org/c/libosmocore/+/26307">View Change</a></p><p>1 comment:</p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0;"><p><a href="https://gerrit.osmocom.org/c/libosmocore/+/26307/1/src/bitvec.c">File src/bitvec.c:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/c/libosmocore/+/26307/1/src/bitvec.c@479">Patch Set #1, Line 479:</a> <code style="font-family:monospace,monospace">uint64_t bitvec_read_field(struct bitvec *bv, unsigned int *read_index, unsigned int len)</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">I'm not really liking the idea of using errno in non libc code. […]</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">Why using errno outside of libc is bad? And what do we loose in this case?</p><p style="white-space: pre-wrap; word-wrap: break-word;">In general, it looks fundamentally wrong to me that we have to use 'special' values like -1 to indicate errors. Yes, this is because C does not offer standard means for that, like C++ has exceptions or Erlang allows to return tuples of several values. We're mixing up data types, and then ending up in situations like this, where it's not clear if such 0xfffffff(...) is a valid value that is actually in the vector or a special value indicated by the function itself.</p><p style="white-space: pre-wrap; word-wrap: break-word;">An alternative approach would be to deprecate this function and introduce bitvec_read_field2(), which would accept an additional pointer for the resulting value. This is what I also don't really like, because in reality the new function does exactly what the old function does, but requires different way of invocation. And you get tons of deprecation warnings in osmo-pcu, where we use this function a lot, whereas in some cases it's fine to not check if an error occurred during parsing. The approach involving errno allows to avoid deprecation and at the same time provides a way to check if parsing succeeded, but rather in a unobtrusive way.</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.osmocom.org/c/libosmocore/+/26307">change 26307</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/+/26307"/><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: I2cc734caa3365d03c2ae2b3f2cd9544933c25e9e </div>
<div style="display:none"> Gerrit-Change-Number: 26307 </div>
<div style="display:none"> Gerrit-PatchSet: 1 </div>
<div style="display:none"> Gerrit-Owner: fixeria <vyanitskiy@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder </div>
<div style="display:none"> Gerrit-CC: pespin <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-Comment-Date: Wed, 17 Nov 2021 14:43:27 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Comment-In-Reply-To: pespin <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-MessageType: comment </div>