net_buf: change return type of net_buf_max_len as size_t

[MarkWangChinese]

Change net_buf_max_len to use size_t as return value type to align with the rest of the net_buf APIs.

[jhedberg]

@MarkWangChinese since you decided to open a new PR for this instead of keeping it in the other PR (and moving everything else out) it means that this will not fulfill the review time criteria before the feature freeze. Because of that it's essential to highlight that it's an API consistency fix. You're also missing the update to the migration guide as we discussed.

[henrikbrixandersen]

This needs to go through the breaking API change process, right?

[jhedberg]

This needs to go through the breaking API change process, right?

IMO "breaking" is a too strong word here. The underlying storage is still uint16_t so there will not be any information loss, even if the return value is stored in a uint16_t. Worst case you'd get compiler or static analyzer warnings of implicit cast to smaller integer type, and for that I think a migration guide entry is sufficient. Any comments from @carlescufi? (author of the change process)

[MarkWangChinese]

@MarkWangChinese since you decided to open a new PR for this instead of keeping it in the other PR (and moving everything else out) it means that this will not fulfill the review time criteria before the feature freeze. Because of that it's essential to highlight that it's an API consistency fix. You're also missing the update to the migration guide as we discussed.

Thanks. I want to keep the #97440 to continue talking about large size support. Maybe creating another RFC to talk about it is better? Since the "breaking API" need to be clarified too, I think this change can't be merged before feature freeze.

[carlescufi]

I agree with @jhedberg here. I would not consider this a breaking change. Worst case scenario you get an explicit warning, and given that the internal storage is still 16-bit, an overflow can never happen, so there is zero risk. I would agree to merge this with an entry in the migration document.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud