Page 1 of 1
Did I hit a gcc bug in my first C compile this year? (Am I reading this C right?)
Posted: Thu Apr 24, 2025 1:44 pm
by eekee
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.
Re: Did I hit a gcc bug in my first C compile this year? (Am I reading this C right?)
Posted: Thu Apr 24, 2025 3:54 pm
by 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
you will have buf and any
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.