https://gitlab.synchro.net/main/sbbs/-/commit/8ec10e369d8a64ae26341460
Modified Files:
src/sbbs3/atcodes.cpp cmdshell.h con_hi.cpp con_out.cpp data.cpp email.cpp exec.cpp execfile.cpp execmsg.cpp file.cpp getkey.cpp getmsg.cpp getstr.cpp inkey.cpp js_bbs.cpp listfile.cpp logfile.cpp logon.cpp mail.cpp main.cpp msgtoqwk.cpp netmail.cpp pack_qwk.cpp postmsg.cpp prntfile.cpp putmsg.cpp qwk.cpp qwk.h qwktomsg.cpp readmail.cpp readmsgs.cpp sbbs.h sbbsdefs.h scandirs.cpp scansubs.cpp startup.h str.cpp telgate.cpp tmp_xfer.cpp writemsg.cpp xtrn.cpp xtrn_sec.cpp src/xpdev/dirwrap.c dirwrap.h
Log Message:
The great 'long int' purge of 2023 part 1

At one time, Synchronet was a 16-bit DOS project, plagued by the 16-bit [u]int, so long's were used everywhere > 16-bits were known to be needed/wanted (This is before the days of the standard sized types from stdint.h), and they've persisted.

But '[u]long int' is 64-bits on *nix 64-bit builds, 32-bits everywhere else (even 64-bit Windows builds if/when we ever get around to that), so this could lead to insidious bugs that would only show up on one flavor or the other. Since [u]int is 32-bits on everything we currently support, we'll use that instead of [u]long.

This "part 1" because I'm sure there's going to be warnings and errors from the GCC/Clang builds as a result, which I'll get to next.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net