https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117180

            Bug ID: 117180
           Summary: Confusing -Warray-bounds output for Tor
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sjames at gcc dot gnu.org
                CC: qing.zhao at oracle dot com
            Blocks: 56456
  Target Milestone: ---

With Tor from git (8f43b97895c2fb3179a83b4535c5fc2a97d75998) and using Qing's
RFC patch (https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657150.html) for
-fdiagnostics-explain-harder, I see:
```
$ gcc -std=gnu23 -DHAVE_CONFIG_H -I.  -I./src -I./src/ext -I./src/ext/trunnel
-I./src/trunnel -I./src/ext/ -I./src/ext/equix/hashx/include/
-DSHARE_DATADIR="\"/usr/local/share\"" -DLOCALSTATEDIR="\"/usr/local/var\""
-DBINDIR="\"/usr/local/bin\"" -DTOR_UNIT_TESTS  -DHAVE_MODULE_RELAY=1
-DHAVE_MODULE_DIRAUTH=1 -DHAVE_MODULE_DIRCACHE=1 -DHAVE_MODULE_POW=1    -O2
-Werror=array-bounds -fdiagnostics-explain-harder -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -fstack-protector-all -Wstack-protector --param
ssp-buffer-size=1 -fPIE -fasynchronous-unwind-tables -Wall -fno-strict-aliasing
@warning_flags -MT
src/feature/nodelist/core_libtor_app_testing_a-networkstatus.o -MD -MP -MF
src/feature/nodelist/.deps/core_libtor_app_testing_a-networkstatus.Tpo -c 
src/feature/nodelist/networkstatus.c -O2 -o /dev/null
-fno-diagnostics-explain-harder
src/feature/nodelist/networkstatus.c: In function
‘networkstatus_set_current_consensus’:
src/feature/nodelist/networkstatus.c:2149:41: error: array subscript [0, 1] is
outside array bounds of ‘consensus_waiting_for_certs_t[2]’
[-Werror=array-bounds=]
 2149 |   waiting = &consensus_waiting_for_certs[flav];
      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
src/feature/nodelist/networkstatus.c:144:8: note: while referencing
‘consensus_waiting_for_certs’
  144 |        consensus_waiting_for_certs[N_CONSENSUS_FLAVORS];
      |        ^~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
```

I think -fdiagnostics-explain-harder is a real improvement here:
```
$ gcc -std=gnu23 -DHAVE_CONFIG_H -I.  -I./src -I./src/ext -I./src/ext/trunnel
-I./src/trunnel -I./src/ext/ -I./src/ext/equix/hashx/include/
-DSHARE_DATADIR="\"/usr/local/share\"" -DLOCALSTATEDIR="\"/usr/local/var\""
-DBINDIR="\"/usr/local/bin\"" -DTOR_UNIT_TESTS  -DHAVE_MODULE_RELAY=1
-DHAVE_MODULE_DIRAUTH=1 -DHAVE_MODULE_DIRCACHE=1 -DHAVE_MODULE_POW=1    -O2
-Werror=array-bounds -fdiagnostics-explain-harder -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -fstack-protector-all -Wstack-protector --param
ssp-buffer-size=1 -fPIE -fasynchronous-unwind-tables -Wall -fno-strict-aliasing
@warning_flags -MT
src/feature/nodelist/core_libtor_app_testing_a-networkstatus.o -MD -MP -MF
src/feature/nodelist/.deps/core_libtor_app_testing_a-networkstatus.Tpo -c 
src/feature/nodelist/networkstatus.c -O2 -o /dev/null
src/feature/nodelist/networkstatus.c: In function
‘networkstatus_set_current_consensus’:
src/feature/nodelist/networkstatus.c:2149:41: error: array subscript [0, 1] is
outside array bounds of ‘consensus_waiting_for_certs_t[2]’
[-Werror=array-bounds=]
 2149 |   waiting = &consensus_waiting_for_certs[flav];
      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
  ‘networkstatus_set_current_consensus’: events 1-2
 2123 |   if (flav == FLAV_NS) {
      |      ^
      |      |
      |      (1) when the condition is evaluated to true
......
 2149 |   waiting = &consensus_waiting_for_certs[flav];
      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                         |
      |                                         (2) out of array bounds here
src/feature/nodelist/networkstatus.c:144:8: note: while referencing
‘consensus_waiting_for_certs’
  144 |        consensus_waiting_for_certs[N_CONSENSUS_FLAVORS];
      |        ^~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
```

... but I don't get how FLAV_NS (defined to be 0) is related here. The warning
makes me think that consensus_waiting_for_certs isn't guaranteed to be a valid
object anymore but I can't see why not, and I don't see why the FLAV_NS case is
special (why not the FLAV_MICRODESC case too which is defined to be 1)?

What do you think Qing?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

Reply via email to