Paul Eggert wrote: > And as far as I can tell, the diagnostics he > got were (in some sense) all false positives.
Generally, if the second argument to strchr is a variable, it can contain any character, thus the warning is warranted. Whereas if the second argument to strchr is a literal character, such as ' ' or '\n', there is no risk, and the warning is a false alarm. > How about if we separate out the "if you care about > internationalization" diagnostics into a separate category, enabled if > GNULIB_UNUSUAL_ENCODING_CHECK is defined, instead of GNULIB_POSIXCHECK? > These diagnostics aren't so much about POSIX as they are about GB18030 > and other unusual encodings, and since they generate so many false > positives they're good candidates for a separate category. While GNULIB_POSIXCHECK produces warnings for portability and warnings for i18n support, I don't think it would be good to separate their activation. The most probable consequence would be that people deactivate the i18n warnings, and thus get i18n bugs at runtime on glibc systems. It would be better to think about how to reduce the false alarms. For example by analyzing the second argument at compile-time: * For functions whose second argument is a string, in C++, it is possible to analyze a string at compile time, using the techniques that implement <format>. (I'm not saying it's easy. But it's possible.) Maybe we should implement this, and give the advice to set CC="gcc -x c++" or CC="g++" together with GNULIB_POSIXCHECK? * For functions whose second argument is a character, such as 'strchr', we can probably play with __builtin_constant_p. Bruno
