https://gitlab.synchro.net/main/sbbs/-/commit/a302a01b1b42887cdece9b23
Modified Files:
src/xpdev/genwrap.c
Log Message:
Escape chars >= 0x7f too (DEL and ex-ASCII/UTF-8 and whatnot)

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

https://gitlab.synchro.net/main/sbbs/-/commit/735aa51e4f3bcaa8a6640416
Modified Files:
src/xpdev/genwrap.c
Log Message:
Fix for previous commit and escaped char values > 127 (0x7F)

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

https://gitlab.synchro.net/main/sbbs/-/commit/7081a525902dcc4acf4f00a2
Modified Files:
src/xpdev/genwrap.c
Log Message:
Fix mysterious double overflow issue in parse_byte_count()

It's possible that some values (e.g. "16384P") exceed the storage (count of bytes) of a 64-bit integer, and such values were causing floating point exceptions when running sbbsctrl.exe, e.g.
Faulting application name: sbbsctrl.exe, version: 3.20.0.0, time stamp: 0x00000000
Faulting module name: gdi32full.dll, version: 10.0.19041.2604, time stamp: 0x2b5302d5
Exception code: 0xc0000090

but interesting (and perhaps a clue), not with sbbs.exe.

Anyway, this added range checking, limiting the maximum value to INT64_MAX (after division by unit, though there was no division-unit in the problem
case, the "min_dspace" value parsing in scfglib2.c). Using conditional/ternary return statement had the same floating point exception occurrences, so this if-statement shouldn't be removed/changed/optimized!

I suspect this has something to do with mix of Borland and MSVC run-time libs and perhaps different expectations or setups with regards to floating point exceptions. I did notice that when stepping through read_file_cfg(), I would get different return values for the same call to iniGetBytes() depending on whether it was initiated from sbbsctrl.exe (built with C++Builder) or
sbbs.dll (built with MSVC).

Thanks to Codefenix for providing the sample file.ini file that demonstrated the issue. This problem would've been very hard to root-cause otherwise!

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

https://gitlab.synchro.net/main/sbbs/-/commit/973b548fcd8c126de3633b5c
Modified Files:
src/xpdev/genwrap.c
Log Message:
Use const doubles for time durations

Instead of copy/pasta. No change in function,.

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

https://gitlab.synchro.net/main/sbbs/-/commit/ea44c50ad1ffe1a9cef1a7ff
Modified Files:
src/xpdev/genwrap.c
Log Message:
Fix clang warning: implicit conversion from 'long' to 'double'

changes value from 9223372036854775807 to 9223372036854775808 [-Wimplicit-const-int-float-conversion]
if(bytes < 0 || bytes > INT64_MAX)
~ ^~~~~~~~~
/usr/include/x86/_stdint.h:90:19: note: expanded from macro 'INT64_MAX'
#define INT64_MAX 0x7fffffffffffffff
^~~~~~~~~~~~~~~~~~

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

https://gitlab.synchro.net/main/sbbs/-/commit/58b4de5093abeb6c7d2371f1
Modified Files:
src/xpdev/genwrap.c
Log Message:
The %g printf specifier doesn't work the same as %f, use %f instead

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

https://gitlab.synchro.net/main/sbbs/-/commit/9031ac11bbc1003e9cd13f3e
Modified Files:
src/xpdev/genwrap.c
Log Message:
Cosmetic improvements to duration*_to_[v]str() functions

Use lower case y/w/d/h/m suffix.

If a duration is an exact multiple, don't display ".0" fraction. This is not consistent with byte_estimate_to_str() string generation, but I think it's
more in line with human expectations.

Don't display "90d" as "12.9w" (unless the requested unit is one-week).

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

https://gitlab.synchro.net/main/sbbs/-/commit/984f1eb68d22b45de08fd723
Modified Files:
src/xpdev/genwrap.c
Log Message:
Insure all builds of safe_strerror() write the string to the passed buf

The GNU_SOURCE build of this function was (sometimes?) just returning the string and not actually copying it to the passed buf. This is consistent
with the GNU manpage on strerror_r():
"This may be either a pointer to a string that the function stores in buf ..." but was inconsistent with all the other build types of this function.

Also updated to use strlcpy and write the problematic error number to the default string (if unknown).

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

https://gitlab.synchro.net/main/sbbs/-/commit/0d60813bb295908d35ad556e
Modified Files:
src/xpdev/genwrap.c
Log Message:
Fix issue in last commit

Need to update the parameter names as well.

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

https://gitlab.synchro.net/main/sbbs/-/commit/78ae0fd80623b830fe86b6d6
Modified Files:
src/xpdev/genwrap.c
Log Message:
Change spaces to tabs in new strlcpy()

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

https://gitlab.synchro.net/main/sbbs/-/commit/746ccfd57d43877a95aaded3
Modified Files:
src/xpdev/genwrap.c
Log Message:
Attempt to fix musl builds

The non-standard strerror_r() is glibc specific, musl doesn't do
that. It *appears* that __USE_GNU implies glibc.

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

https://gitlab.synchro.net/main/sbbs/-/commit/8084997ba19ed4b9c1773003
Modified Files:
src/xpdev/genwrap.c
Log Message:
Use RtlGetVersion to get/report Windows 11 (and build number) correctly

This is fun Microsoft. If Windows 11 is actually Windows 10.22000+, what will Windows 12 be? No one can guess.

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

https://gitlab.synchro.net/main/sbbs/-/commit/d58cc13fde38ff3a965dc838
Modified Files:
src/xpdev/genwrap.c
Log Message:
Move the #pragma warning to just before the call to GetVersionEx()

Needed for building sbbsexec.dll

I guess #pramga warning only affects the following source line.

Apparently we're disabling this warning effectively via other means in all other MSVC projects.

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

https://gitlab.synchro.net/main/sbbs/-/commit/0c385ef21ba3488214dfa917
Modified Files:
src/xpdev/genwrap.c
Log Message:
Only use RtlGetVersion for Windows 10/11

This function appears to truncate the service pack info for Windows 7 (6.1): "Windows NT Version 6.1 (Build 7601) Service Pack 1 x86" became:
"Windows NT Version 6.1 (Build 7601) S x86"

Don't close the handle to ntdll.dll (hey, that's stupid filename, Microsoft!) since the module could be unloaded from the address space and then a call to the captured procedure address could/would crash. This handle will be closed when the process terminates anyway.

While we're here, correct the Windows 6.1 -> 7.0 numbering. That looks better: "Windows NT Version 7.0 (Build 7601) Service Pack 1 x86"

Something should probably be done for Windows 6.2 -> 8.0 numbering too, but I don't have a VM handy. Is anyone actually still running Windows 8.x?

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