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/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Max,
On Fri, Oct 13, 2017 at 11:57:51AM +0200, Max wrote:
> While looking at osmocom/netif/datagram.h I've noticed that it's organized
> differently compared to other libosmo*. Most notably, it does not have structure
> definitions, only brief declarations in datagram.h while the actual definition is in
> datagram.c
This is correct. It's probably following the kind of learning curve that Pablo
was making with netfilter related libraries over time.
> This effectively means that client code using the library do not have access to
> struct internals and have to use various "osmo_dgram_.x_set_*()" functions to
> manipulate them.
correct.
> This got me curious - what are the pros and cons of this approach?
>
> I can see the benefit of being able to change struct internals without changing the
> API. I can also see the downside in having to define lot's of boilerplate
> setter/getter functions.
I think that's about it. If you want to keep a long-term stable ABI +
API, then hiding the structure is the only sane approach. But yes, it
comes at a cost.
> Is there a way to avoid or at least simplify setter/getter
> boilerplate?
I think it's called C++ with its ability to have private/friend/public members ;)
In C, I'm not aware of any simplification.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)