out of bound warning in non-builtin strcmp() with a fixed argument with two characters.
Ian Lance Taylor
iant@google.com
Fri Oct 16 17:58:00 GMT 2009
Alfonso Cepeda Caballos <cepeda@gmail.com> writes:
> I obtain a warning when compiling the following code:
> #include <stdio.h>
> #include <string.h>
>
> int main(int argc, char **argv)
> {
> printf("%i",strcmp(argv[0],"A")); // NO warning
> printf("%i",strcmp(argv[0],"AA")); // warning: array subscript is above array bounds
> printf("%i",strcmp(argv[0],"AAA")); // NO warning
> return 0;
> }
>
> with:
> gcc -O3 -fno-builtin -funsigned-char -Wall test.c
> test.c: In function ‘main’:
> test.c:7: warning: array subscript is above array bounds
>
> It only show the warning with this combination options (at least in
> linux). If you use signed-char or the strcmp() builtin function, it
> doesn't show the warning. And it only shows if the second comparision
> string is two bytes length (I mean three with the \0).
You didn't mention the machine you are using, nor the version of gcc.
However, I hypothesize that you are using GNU/Linux. On GNU/Linux,
<string.h> includes <bits/string2.h>. When optimizing,
<bits/string2.h> defines strcmp as a macro, as follows:
# define strcmp(s1, s2) \
__extension__ \
({ size_t __s1_len, __s2_len; \
(__builtin_constant_p (s1) && __builtin_constant_p (s2) \
&& (__s1_len = strlen (s1), __s2_len = strlen (s2), \
(!__string2_1bptr_p (s1) || __s1_len >= 4) \
&& (!__string2_1bptr_p (s2) || __s2_len >= 4)) \
? __builtin_strcmp (s1, s2) \
: (__builtin_constant_p (s1) && __string2_1bptr_p (s1) \
&& (__s1_len = strlen (s1), __s1_len < 4) \
? (__builtin_constant_p (s2) && __string2_1bptr_p (s2) \
? __builtin_strcmp (s1, s2) \
: __strcmp_cg (s1, s2, __s1_len)) \
: (__builtin_constant_p (s2) && __string2_1bptr_p (s2) \
&& (__s2_len = strlen (s2), __s2_len < 4) \
? (__builtin_constant_p (s1) && __string2_1bptr_p (s1) \
? __builtin_strcmp (s1, s2) \
: __strcmp_gc (s1, s2, __s2_len)) \
: __builtin_strcmp (s1, s2)))); })
The warning is coming from a reference in that macro. At a guess, the
macro somehow gets too complicated for gcc to sort out that some code
is never executed. I'm not sure why that only occurs in one case but
not the others.
It's probably worth filing a bug report on this. Please follow the
directions at http://gcc.gnu.org/bugs.html . In particular, please
include the preprocessed source code. Thanks.
Ian
More information about the Gcc-help
mailing list