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/baseband-devel@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Max,
On Mon, Dec 16, 2013 at 05:11:58PM +0100, ☎ wrote:
> While looking at osmocom-bb compilation warnings I've noticed that
> there are plenty of those cause by signed-unsigned comparison with
> msgb-related functions. Attached is a trivial patch which fixes that
> by changing int -> uint16_t. For the sake of completeness I've also
> changed other functions to explicitly use uint16_t - this is used for
> length fields in "struct msgb" anyway.
I'm not squite sure how you will fix the problem if the return values
are changed to unit16_t. All you get is that the result is truncated ?
Keeping the implementation with unsigend int / int and the
implementation having uint16_t means that we can still later change the
implementation [if we ever need msgb's larger than that] with only an
ABI breakage but no ABI breakage, so I liked that somehow.
> Although technically it's API change I do not expect any sane code to
> break. If you still think it's potentially insecure, this could be
> applied during next api version bump alongside with gprs api change.
The GPRS API change can be applied at any time, I'm not worried about
that, really. But msgb API changes are affecting literally every
program/project in the Osmocom sphere...
Summary: Yes, I appreciate this being fixed - but I'd appreciate it even
more if we didn't have to break the ABI :)
--
- 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)