This was quite confusing previously: While calling insert_before()
and then remove_at() properly replaced the current item, calling them the
other way around inserted the new item before the previous item because
remove_at() changed the enumerator's position to the previous item.
The behavior in corner cases (calling the methods before or after
enumeration) is also changed slightly.
This will allow us to implement e.g. enumerator_cleaner without having to
use that unportable 5 pointer forwarding or having to define a callback for
each instance.
A generic implementation for enumerate() is provided so only venumerate()
has to be implemented, which may be simplified by using the VA_ARGS_VGET()
macro.
Because enumerate() for value based arrays returns a pointer directly to
the internal array elements and because array_remove_at() or rather the
called array_remove() may move elements over the element at the currently
enumerated position, the pointer passed to enumerate() will point to a
different array element after the array_remove_at() call. The caller
will thus operate on the wrong element if that pointer is accessed again
before calling enumerate().
For performance reasons we currently don't change the implementation to copy
each array element during enumeration to a private member of the enumerator and
return a pointer to that. Similarly, due to the danger of subtle bugs we don't
remember the pointer passed to enumerate() to later redirect it to a copy
created during the array_remove_at() call.
While glob should return a NULL terminated gl_pathv when having no matches,
at least on OS X this is not true when using GLOB_DOOFFS. Rely on the
number of matches returned in gl_pathc, which seems to be more reliable in
error cases.
This enumerator is a wrapper around glob(3). If that function is not
supported NULL is returned. If no files match or an error occurs during
the pattern expansion an error is logged and the enumerator simply returns
no items.
RFC: if GLOB_ERR is not supplied glob returns GLOB_NOMATCH if e.g. the
base directory of the pattern does not exist, which would otherwise
result in an error. This way there is at least a clear error message in
case of a typo.
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.
This required some refactoring when handling encrypted payloads.
Also changed log messages so that "encrypted payload" is logged instead
of "encryption payload" (even if we internally still call it that) as
that's the name used in RFC 5996.
Its functionality can be replicated by calling insert_before() followed
by remove_at(). Not the other way around, though, because remove_at()
changes the enumerator position.
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
Since we always search for the nearest separator (and strip them from
the front of the next token) there can't be any separators left at the
end of a token.
Tobias Brunner