> I assume this function lets you search for an element starting in the middle of a single-linked list (the middle because you could call `ft_list_find(&p-next, data_ref)` where `p` points to any element in the
> middle of the list, including possibly the last item in the list, in which case the loop body wouldn't run). If so, I don't think this does what's intended. This actually unlinks (and memory-leaks) elements up to > where the match is found. I think you want to advance `start_list` this way (I didn't test this):
Note the usage of a pointer to pointer so the correct way to call the code is : `pointer_t * list_ptr ; list_ptr = first_list_element ; ft_list_find(list_ptr, data_rf, cmp);`.
This is correct that if you point to the last item in the list, the loop body wouldn't run (which is the expected behavior). When there is a match, the pointer `*start_list` takes as value the memory address of the next element in the list, the contained structure pointer is not changed. The code has been tested a while back, though it's indeed clearer if a typedef `pointer_t` for list is fully given:
```
typedef struct s_list
{
void *content;
size_t content_size;
struct s_list. *next;
} pointer_t
```
> This is why we don't use C - unsafe, unclear, unnecessary.
Actually, I think libbitcoin is using its own maintained fork of secp256k1, which is written in C.
For sure, I wouldn't recommend using C across a whole codebase as it's not memory-safe (euphemism) though it's still un-match if you wish to understand low-level memory management in hot paths.
It can be easier to use C++ or Rust, though it doesn't mean it will be as (a) perf optimal and (b) hardened against side-channels.
I have not read in detail the last Eric's email on the whole caching identity in case of invalidity discussion, though I'll do so.
Best,
Antoine