• src/sbbs3/atcodes.cpp cmdshell.h con_hi.cpp con_out.cpp data.cpp email

    From Rob Swindell (in GitKraken)@VERT to Git commit to main/sbbs/master on Sat Feb 18 20:37:12 2023
    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