osmo-bts: rach_ind.ra size

[Max]

That's probably related to https://gerrit.osmocom.org/#/c/427/3
If that's really the case than fix would be to check for is_11bit of
ph_rach_ind_param and adjust length accordingly.

On 07/25/2016 12:22 PM, Neels Hofmeyr wrote:
> I just came across this compiler warning:
>
> l1sap.c: In function 'gsmtap_ph_rach':
> l1sap.c:291:8: warning: assignment from incompatible pointer type [enabled by default]
>   *data = &l1sap->u.rach_ind.ra;
>         ^
>
> It's a
> 	uint16_t ra
> and used like this in common/l1sap.c:
>
> 	static int gsmtap_ph_rach(struct osmo_phsap_prim *l1sap, uint8_t *chan_type,
> 		uint8_t *tn, uint8_t *ss, uint32_t *fn, uint8_t **data, int *len)
> 	{
> 	[...]
> 		*data = &l1sap->u.rach_ind.ra;
> 		*len = 1;
>
> A cast like this would fix the compiler warning and make sense if data is
> interpreted to point at a 16 bit data block, probably in host byte order
> though:
>
> 		*data = (uint8_t*)&l1sap->u.rach_ind.ra;
> 		*len = 1;
>
> But *len = 1 means that **data is an 8bit value?
> This is sent to gsmtap.
>
> Is *len = 1 something we should fix?
>
> ~Neels
>
>

-- 
Max Suraev <msuraev at sysmocom.de> http://www.sysmocom.de/
======================================================================= 
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93 
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B 
* Geschaeftsfuehrer / Managing Director: Harald Welte