Attention is currently required from: laforge.

neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/32323 )

Change subject: sccp: allow separate cs7 for IuPS and IuCS ......................................................................

Patch Set 3:

(2 comments)

This change is ready for review.

File src/osmo-hnbgw/hnbgw_cn.c:

https://gerrit.osmocom.org/c/osmo-hnbgw/+/32323/comment/b3ff89d3_4d55d0f2 PS2, Line 570: hsi = talloc(cnlink, struct hnbgw_sccp_inst);

no zero-initialization

full init of all members follows right in the next line.

https://gerrit.osmocom.org/c/osmo-hnbgw/+/32323/comment/5227b3dd_8455a020 PS2, Line 571: *

Based on my understanding, the compiler is permitted to only set those member fields explicitly stat […]

i've been using the idiom of

*foo = (struct foo){ .something = 123, };

as a way to reliably initialize all members of foo with zero a lot, for a long long time now. If that is wrong then we may have a bit of a problem...

For example in osmo-bsc, in lchan_reset(), i use above idiom to clear out all stale lchan state. It works. But is that just incidental?

We have discussed this idiom a lot on and off, and I am actually pretty sure it is defined to zero-initialize all members. It does/may not initialize the padding, but i almost never care about that, only when going to use memcmp(). Also we discussed 'foo = {}' vs 'foo = {0}', but so far each time I end up being right on that topic. I think Pau or was it Vadim had an interesting link on a discussion among C language developers?

anyhow, I accept your premature-optimization argument, and I want to get this merged as quickly as possible to help out a customer.

(Still I am quite certain that I'm right with that way of initialization.)