bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

prohibit_strcmp


From: Akim Demaille
Subject: prohibit_strcmp
Date: Thu, 23 Feb 2012 17:32:09 +0100

Hi!

Bison features some warnings from syntax-check:

prohibit_strcmp
../../doc/bison.texinfo:2572:    if (strcmp (ptr->name,sym_name) == 0)
../../src/files.c:145:  if (strcmp (ext, ".y") == 0)
../../src/muscle-tab.c:53:  return strcmp (m1->key, m2->key) == 0;
../../src/muscle-tab.c:410:    if (!strcmp (conversion[i].obsolete, variable))
../../src/print_graph.c:136:            && strcmp (symbols[sym]->tag, "error") 
!= 0)
../../src/uniqstr.c:114:  return strcmp (m1, m2) == 0;
maint.mk: replace strcmp calls above with STREQ/STRNEQ

I don't understand too well what is expected from me here.
While I see in

../../src/files.c:145:  if (strcmp (ext, ".y") == 0)
../../src/print_graph.c:136:            && strcmp (symbols[sym]->tag, "error") 
!= 0)

an opportunity to write a static pattern instead of the constant
string, in the remaining cases, I doubt there's really value to
move to streq's STREQ.  Actually, in gnulib itself, there are quite many
strcmp, including with literal strings, and all the STREQ/STRNEQ
are really using literal strings.

So maybe this warning refers to another kind of STREQ/NEQ?  Such as:

fnmatch.c:# define STREQ(s1, s2) (strcmp (s1, s2) == 0)
fnmatch.c:   (STREQ (string, "alpha") || STREQ (string, "upper")                
        \
fnmatch.c:    || STREQ (string, "lower") || STREQ (string, "digit")             
        \
fnmatch.c:    || STREQ (string, "alnum") || STREQ (string, "xdigit")            
        \
fnmatch.c:    || STREQ (string, "space") || STREQ (string, "print")             
        \
fnmatch.c:    || STREQ (string, "punct") || STREQ (string, "graph")             
        \
fnmatch.c:    || STREQ (string, "cntrl") || STREQ (string, "blank"))

which, I concur, is more readable.  It is confusing that there are
two sets of STREQ in gnulib, and at least the comment for prohibit_strcmp
should point this out.

Or am I missing something?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]