Re: lchan->s and integer overflow

Holger Hans Peter Freyther wrote:

Here you point out that the range of 4 to UINT8_MAX is coming from the specification. Which is very good. The way it is done is a violation of the principle of least surprise though. If a BSC sends the value '2' it doesn't make sense that '32' is used. The configurator/implementor certainly wanted to have a low value.

IMHO the right thing to do is to NACK the set bts attributes with a descriptive error message. The same goes for the conn fail crit being present but not of the type we support.

hi holger,

the range is actually 4..64, so i send a NACK now, if the given attribute is not is that range. also the counting of S value is moved to a seperate function. check out the attached patch.

regards,

andreas