<tt>Eric Blake <eblake@redhat.com> wrote on 09/24/2010 04:01:55 PM: > libvir-list</tt> <tt>> > On 09/24/2010 01:38 PM, Stefan Berger wrote: > > > To prevent consecutive spaces in comments from becoming a single space > > (by bash), the IFS variable is now set to an empty string. Also, commands > > are now executed using bash's 'eval' command. > > -#define CMD_EXEC "res=`${cmd}`" CMD_SEPARATOR > +#define CMD_EXEC "res=`eval ${cmd}`" CMD_SEPARATOR</tt> <tt>> > Underquoted. To be robust, this needs to be: > > "res=`eval \"$cmd\"" CMD_SEPARATOR > </tt> <tt>Ok, I made this change.</tt> <tt> > which will then avoid your need for the empty IFS hack and double > escaping (you'll still need single escaping, but that's a bit more > manageable).</tt> <tt>I just tried the TCK test without and with double-escaping in libvirtd</tt> <tt>and double-escaping does seem to be necessary otherwise `ls` and $(ls)</tt> <tt>do get executed and their results end up in the comment. The spaces</tt> <tt>are preserved, though, so I can revert the change to IFS.</tt> <tt> > > > +/* avoiding a compiler warning trough own implementation */ > > +static const char * > > +_strchr(const char *s, int c) > > +{ > > + while (*s && *s != (char)c) > > + s++; > > + if (*s) > > + return s; > > + return NULL; > > +} > > > > Ouch. That's probably 4x slower than the glibc version. I'd much > rather see: > > #undef strchr > </tt> <tt>Yes, that does the trick. Thanks.</tt> <tt> > or > > (strchr)(a, b) > > which then guarantees that you get the function call, rather than the > macro expansion; after all, the macro expansion just defers to the > function call if both arguments are non-constants, not to mention the > fact that the -Wlogical-op warning is only triggered by the macro and > not by the function.</tt> <tt> Stefan</tt>