On May 28, 2018 4:25:02 PM GMT+02:00, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: >On 05/28/18 11:19, Richard Biener wrote: >> On Sat, May 26, 2018 at 10:19 AM Bernd Edlinger ><bernd.edlin...@hotmail.de> >> wrote: >> >> >> >>> On 05/17/18 16:37, Bernd Edlinger wrote: >>>> On 05/17/18 15:39, Richard Biener wrote: >>>>> On Thu, May 17, 2018 at 3:21 PM Bernd Edlinger >>>>> <bernd.edlin...@hotmail.de> >>>>> wrote: >>>>> >>>>>> Ping... >>>>> >>>>> So this makes all traditional users go through the indirect >>>>> splay_tree_compare_wrapper >>>>> and friends (which is also exported for no good reason?). And all >> users >>>>> are traditional >>>>> at the moment. >>>>> >>>> >>>> all except gcc/typed-splay-tree.h which only works if VALUE_TYPE is >>>> compatible with uint_ptr_t but cannot check this requirement. >>>> This one worried me the most. >>>> >>>> But not having to rewrite omp-low.c for instance where >splay_tree_lookup >>>> and access to n->value are made all the time, made me think it >>>> will not work to rip out the old interface completely. >>>> >> >>> Well, I think it will be best to split this patch in two parts: >> >>> One that adds just two utility functions for avoiding undefined >>> function type casts which can be used with the original C interface. >>> This first part is attached. >> >>> And another part that uses a similar approach as the splay-tree in >>> libgomp, but instead of creating a type-safe C interface it should >>> translate the complete code from splay-tree.c/.h into a template. >>> The second part, I plan to do at a later time. >> >> >>> Is this OK for trunk? >> >> Looks ok to me. Do we need to worry about !HAVE_STRING_H and >> using strcmp? >> > >No, I would be rather surprised if libiberty would compile at all >without string.h. First some files include it without HAVE_STRING_H >for instance sha1.c and argv.c, so I just replicated what >the majority of the code base here did. > >Most sources include <string.h> ifdef HAVE_STRING_H, and use strcmp >even if it is not declared (which should work for functions with int >result). > >So I would commit this patch as is, if you agree.
Sure - go ahead. Richard. > >Bernd. > > >> Thanks, >> Richard. >> >> >>> Thanks >>> Bernd.
