Change in libosmocore[master]: bitvec_read_field(): indicate errors using errno

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/.

fixeria gerrit-no-reply at lists.osmocom.org
Wed Nov 17 14:43:27 UTC 2021


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

Change subject: bitvec_read_field(): indicate errors using errno
......................................................................


Patch Set 1:

(1 comment)

https://gerrit.osmocom.org/c/libosmocore/+/26307/1/src/bitvec.c 
File src/bitvec.c:

https://gerrit.osmocom.org/c/libosmocore/+/26307/1/src/bitvec.c@479 
PS1, Line 479: uint64_t bitvec_read_field(struct bitvec *bv, unsigned int *read_index, unsigned int len)
> I'm not really liking the idea of using errno in non libc code. […]
Why using errno outside of libc is bad? And what do we loose in this case?

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.

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.



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

Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I2cc734caa3365d03c2ae2b3f2cd9544933c25e9e
Gerrit-Change-Number: 26307
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: pespin <pespin at sysmocom.de>
Gerrit-Comment-Date: Wed, 17 Nov 2021 14:43:27 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin at sysmocom.de>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20211117/75090253/attachment.htm>


More information about the gerrit-log mailing list