Help request for debugging ICS

[hgm]

Hmm, when I remove the & from &t->name, all the non-sensical warnings and their duplicats disappear. Indeed t->name is an array, which is an address, and I have no idea how you could take the address of an address. Seems to me that this should be an error, rather than a warning. It surely confused the compiler, making it completely lose track of the type of other, unrelated variables.

There is a good explanation here: http://stackoverflow.com/questions/2528 ... value-in-c

OK, great. So the &t->name is not really an error, and I don't have to be afraid the ICS will crash because of it. And the type of &t->name is indeed the char (*)[100] mentioned in the spurious warning.

The compiler still seems to go completely haywire on this, however, claiming the argument of strlen (which is want, and not &t->name) has this type. So I can only cross my fingers in the hope it has compiled it as it should...

[petero2]

The compiler still seems to go completely haywire on this, however, claiming the argument of strlen (which is want, and not &t->name) has this type. So I can only cross my fingers in the hope it has compiled it as it should...

I see this too using gcc 6.3.1 in fedora 24. I think the compiler is working fine, but there are some scary macro definitions involved, presumably to optimize the cases where some of the arguments are known at compile time:

Code: Select all

# define strncmp(s1, s2, n) \
  (__extension__ (__builtin_constant_p (s1) && strlen (s1) < ((size_t) (n))   \
                  ? strcmp ((s1), (s2))                                       \
                  : (__builtin_constant_p (s2) && strlen (s2) < ((size_t) (n))\
                     ? strcmp ((s1), (s2))                                    \
                     : __strncmp_g ((s1), (s2), (n)))))

strcmp is even worse:

Code: Select all

# define strcmp(s1, s2) \
  (__extension__ (__builtin_constant_p (s1) && __builtin_constant_p (s2)      \
                  && (sizeof ((s1)[0]) != 1 || strlen (s1) >= 4)              \
                  && (sizeof ((s2)[0]) != 1 || strlen (s2) >= 4)              \
                  ? memcmp ((const char *) (s1), (const char *) (s2),         \
                            (strlen (s1) < strlen (s2)                        \
                             ? strlen (s1) : strlen (s2)) + 1)                \
                  : (__builtin_constant_p (s1) && sizeof ((s1)[0]) == 1       \
                     && sizeof ((s2)[0]) == 1 && strlen (s1) < 4              \
                     ? (__builtin_constant_p (s2) && sizeof ((s2)[0]) == 1    \
                        ? __strcmp_cc ((const unsigned char *) (s1),          \
                                       (const unsigned char *) (s2),          \
                                       strlen (s1))                           \
                        : __strcmp_cg ((const unsigned char *) (s1),          \
                                       (const unsigned char *) (s2),          \
                                       strlen (s1)))                          \
                     : (__builtin_constant_p (s2) && sizeof ((s1)[0]) == 1    \
                        && sizeof ((s2)[0]) == 1 && strlen (s2) < 4           \
                        ? (__builtin_constant_p (s1)                          \
                           ? __strcmp_cc ((const unsigned char *) (s1),       \
                                          (const unsigned char *) (s2),       \
                                          strlen (s2))                        \
                           : __strcmp_gc ((const unsigned char *) (s1),       \
                                          (const unsigned char *) (s2),       \
                                          strlen (s2)))                       \
                        : __strcmp_gg ((s1), (s2))))))

[hgm]

Ah, that explains why that single & (i.e. one argument of the wrong type) would give me such a shitload of warnings, many repeated multiple times. It is a macro, and its expansion introduces severalstrlen calls on each of the strcmp arguments, also on the wrong one.

What confused me here is that there already was a strlen call in the source code, and that the warning doesn't say what the argument of the call was it complains about.

Thanks for clearing it up. This makes it certain that the warnings were inocent, as the pointers were indeedpointing to an array of characters at the right address. Nevertheless it is nice I now silenced them.