• Enable address sanitizer in compilations on supported platforms/toolch

    From Rob Swindell@1:103/705 to GitLab issue in main/sbbs on Sun Jun 4 16:06:02 2023
    open https://gitlab.synchro.net/main/sbbs/-/issues/574

    Per https://twitter.com/JSAMcFarlane> Whenever you see examples of 'cursed' C or C++, run it built on GCC/Clang with -Werror -Wall -Wextra -fsanitize=undefined,addres> and see how far it gets. These flags should be enabled by default in IDEs, build systems and for testing and development.I won't go for -Werror since that would be disruptive (compiler upgrade == broken build). -Wextra might be good, at least as an option.
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Sun Jun 4 19:54:35 2023
    https://gitlab.synchro.net/main/sbbs/-/issues/574#note_3615

    Not sure if this part of the 'undefined' (behavior) sanitizer or address sanitizer, but this seems a little over dogmatic:```2023-06-04T16:55:42.319298-07:00 git sbbs: evnt FIDOOUT sbbsecho: ars.c:609:24: runtime error: store to misaligned address 0x7ffc945718c7 for type 'short int', which requires 2 byte alignment2023-06-04T16:55:42.319347-07:00 git sbbs: evnt FIDOOUT sbbsecho: 0x7ffc945718c7: note: pointer points here2023-06-04T16:55:42.319360-07:00 git sbbs: evnt FIDOOUT sbbsecho: 00 01 03 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00```
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Sun Jun 4 19:56:48 2023
    https://gitlab.synchro.net/main/sbbs/-/issues/574#note_3616

    Enabling address sanitizer causes any memory leaks to change the return value of the program, e.g.:```2023-06-04T16:55:43.092257-07:00 git sbbs: evnt FIDOOUT sbbsecho: SUMMARY: AddressSanitizer: 5439520 byte(s) leaked in 71473 allocation(s).2023-06-04T16:55:43.121631-07:00 git sbbs: evnt FIDOOUT Timed event: FIDOOUT returned 1```Memory leaks from a program that is terminating are harmless, but as I recently discovered (with SCFG), resolving those memory leaks (calling `free()` on all the dangling pointers) can be helpful in exposing otherwise-silent heap corruption (!).
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Mon Jun 5 00:07:25 2023
    https://gitlab.synchro.net/main/sbbs/-/issues/574#note_3617

    Honeslty, when I did the SunOS/SPARC port, I had to fix all of those since it would segfault when that access was attempted, so I don't think it's overly dogmatic.That said, I'm not interested in doing all that work again, and I'm pretty sure the original work is lost to the sands of time (iirc, it was about 20 years ago).
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Mon Jun 5 10:01:32 2023
    https://gitlab.synchro.net/main/sbbs/-/issues/574#note_3618

    Yeah, I suppose a memcpy call is not too onerous in likely all cases.
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)