Otherwise, array->esize is promoted to int and if array->esize * num
results in a value > 0x7fffffff the return value would be incorrect due
the implicit sign extension when getting cast to size_t.
Currently we use the very versatile linked-list collection to store elements
with variable count. This is fine, but very inefficient: Due to the many
methods in the linked list, on 64-bit platforms an empty list alone is more
than 200 bytes. As we currently have about 50 lists per IKE_SA/CHILD_SA pair,
this takes up to 10KB just for managing the empty lists. This is about the
half of memory used by an IKE_SA/CHILD_SA pair, and obviously way too much.
The new array type is not an object, but a collection of functions on an
abstract type.
The following lists are per IKE_SA and should be considered for a replacement
with more efficient arrays (this uses load-testers on-demand created dynamic
configurations, other scenarios have different lists):
14 -> ike_sa_create() @ src/libcharon/sa/ike_sa.c:2198
10 -> auth_cfg_create() @ src/libstrongswan/credentials/auth_cfg.c:1088
6 -> task_manager_v2_create() @ src/libcharon/sa/ikev2/task_manager_v2.c:1505
6 -> proposal_create() @ src/libcharon/config/proposal.c:592
5 -> peer_cfg_create() @ src/libcharon/config/peer_cfg.c:657
4 -> child_sa_create() @ src/libcharon/sa/child_sa.c:1090
2 -> child_cfg_create() @ src/libcharon/config/child_cfg.c:536
1 -> ike_cfg_create() @ src/libcharon/config/ike_cfg.c:330
1 -> put_connected_peers() @ src/libcharon/sa/ike_sa_manager.c:854