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/.
☎ Max.Suraev at fairwaves.ruI see your point. You're right it's better to just switch msgb*room to unsigned - those values should never be negative anyway. 12.01.2014 19:40, Harald Welte пишет: > Hi 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 :) > -- best regards, Max, http://fairwaves.ru