Hi, Am Sa., 3. Apr. 2021 um 00:49 Uhr schrieb Bruno Haible <br...@clisp.org>:
> This is useful if the list has to be traversed while nodes are added > > because an iterator cannot be used here. > > I don't understand. You want to use a list_node_t while adding nodes to > the list? This is invalid, since the comments in gl_list.h say: > > /* Type representing the position of an element in the list, in a way > that > is more adapted to the list implementation than a plain index. > Note: It is invalidated by insertions and removals! */ > typedef struct gl_list_node_impl * gl_list_node_t; > It won't work with removals but it does work with insertions because gl_list_add_before/gl_list_add_after/... etc. all return new, valid list node objects. > > What I want to propose is to allow the NULL value in > > gl_next_node/gl_previous_node. In this case, gl_next_node shall return > the > > first node and gl_previous_node shall return the last node. > > It's not useful to extend an API > - for a rare fringe use-case, > Why do you think it is a fringe use-case? Algorithms that walk a list and add nodes during the traversal are not uncommon. - when there are already two other ways to do what you ask for (with the > same O(·) performance). > User's code would be more self-documenting if a "hack" like gl_list_node_t last_node = gl_list_set_last (list, gl_get_last (list)) wouldn't be needed. Thanks, Marc
