Did I hit a gcc bug in my first C compile this year? (Am I reading this C right?)

[eekee]

Code: Select all

	if (buf[MAP_SEARCH_DESC])

Does this line of code test the contents of a cell of buf or the address of that cell? It's the contents, isn't it? gcc apparently optimizes the test away because the address can never be 0:

Code: Select all

tt/src/mapper.c:3868:13: warning: the comparison will always evaluate as ‘true’ for the address of ‘buf’ will never be NULL [-Waddress]
 3868 |         if (buf[MAP_SEARCH_DESC])
      |             ^~~
mapper.c:3797:14: note: ‘buf’ declared here
 3797 |         char buf[MAP_SEARCH_MAX][BUFFER_SIZE], arg1[BUFFER_SIZE], arg2[BUFFER_SIZE], *str;
      |              ^~~

$ gcc --version
gcc (GCC) 13.3.0

This is from the TinTin++ MUD client on Sourceforge. The version is 2.02.42, (the latest,) released January 4th. I'm not seeing browsable source online, only the tarballs here:
https://sourceforge.net/projects/tintin ... de/2.02.4/

The compile environment is MSYS2's Cygwin-equivalent "MSYS" environment.

[zaval]

Code: Select all

char buf[a][b]; // this is an 2D array of chars

char c = buf[i][j]; // this is a char, from the i-th (base 0) row and j-th column
char *p = buf[i]; // buf[i] is (conceptually) a pointer to the i-th row of chars (each of which are array of chars of b length)
char **pp = buf; // buf is (conceptually) a pointer to the array of pointers buf[i +1], p, each of which points to start of an array of chars like c.

If you declared

Code: Select all

buf[a][b]

you will have buf and any

Code: Select all

buf[i]  where i [0 : a - 1]

not NULL. It all will be addresses of the 2D char array elements with correspining indices. e.g. buf will be the same as buf(0) and it will be address of buf(0)(0). buf(1) will be the address of buf(1)(0) and so on. so, unsurprisingly, it's not a bug. At least not in gcc.