Hi Karl Thank you for your help > Or, can we use general strncpy() instead of SH assemble one ? (snip) > Though ultimately I do not have a say in that, it would appear that string_32.h is in arch/sh/include/asm > and has been there for a very long time. > In fact, it appears that x86 also has similar utility functions defined in inline assembly: > see arch/x86/include/asm. As straightforward as it would be to make C versions, there may be a reason > that they are in inline assembly--optimization would be my guess--and converting it all to C may require> > an overhaul of the string.h backend (something I would not be much help with given that I am unable to get > modern Linux booting on my machine, which is a Sega Dreamcast). > I also do not know what the performance implications of switching it all to C would be, if there even are any. > > Hopefully this information may be useful and my asm version is alright for the time being; > I have not been able to unearth much more on the topic of why this is structured the way it is, How about this ? You / I post each patch (= Me: use generic strnpy() patch You: fixup SH strnpy() patch) And follow SH maintainer's judge Thank you for your help !! Best regards --- Kuninori Morimoto
