Re: [bitcoindev] Re: Great Consensus Cleanup Revival

[Antoine Riard <antoine.riard@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3253 bytes --]

> 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


Le jeu. 4 juil. 2024 à 00:57, Eric Voskuil <eric@voskuil.org> a écrit :

> This is why we don't use C - unsafe, unclear, unnecessary.
>
> e
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/bitcoindev/CAfm7D5ppjo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bitcoindev/33dfd007-ac28-44a5-acee-cec4b381e854n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/33dfd007-ac28-44a5-acee-cec4b381e854n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/CALZpt%2BFs1U5f3S6_tR7AFfEMEkgBPSp3OaNEq%2BeqYoCSSYXD7g%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 4460 bytes --]