On Sat, Mar 02, 2019 at 03:40:48PM +1100, Finn Thain wrote: > On Fri, 1 Mar 2019, Guenter Roeck wrote: > > > > > Another possible fix might be to write a 'static inline int strncmp()' > > function for non-coldfire code. > > This build failure and some possible fixes have been discussed before... > > https://lore.kernel.org/lkml/[email protected]/ > https://marc.info/?l=linux-m68k&m=153791317509016&w=2 > https://marc.info/?l=linux-m68k&m=154591539929923&w=2 > https://marc.info/?l=linux-m68k&m=154762988212234&w=2 > https://lore.kernel.org/lkml/?q=3ba14e34f666486b5e77253a82dfde882a505e23.1547616204.git.fthain > > The reason I sent that patch is that I want the compiler to just do code > generation and not pretend that it is doing program transformation. > > If we use static analysis and semantic patching for actual program > transformation then users of any compiler and architecture can benefit. > That would not work in the observed case, or I would have submitted a patch to do just that. The strncmp() is against a configuration symbol and can not always be replaced with strcmp(). Providing strncmp() explicitly as static inline would serve the same purpose, ie it would also prevent the compiler from trying to do anything fancy.
Never mind, who am I to argue. Thanks for the information. Guenter
