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 ofbytes) of a 64-bit integer, and such values were causing floating pointexceptions when running sbbsctrl.exe, e.g.Faulting application name: sbbsctrl.exe, version: 3.20.0.0, time stamp:0x00000000Faulting module name: gdi32full.dll, version: 10.0.19041.2604, time stamp:0x2b5302d5Exception code: 0xc0000090but 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 problemcase, the "min_dspace" value parsing in scfglib2.c). Using conditional/ternaryreturn statement had the same floating point exception occurrences, so thisif-statement shouldn't be removed/changed/optimized!I suspect this has something to do with mix of Borland and MSVC run-time libsand perhaps different expectations or setups with regards to floating pointexceptions. I did notice that when stepping through read_file_cfg(), I wouldget different return values for the same call to iniGetBytes() depending onwhether it was initiated from sbbsctrl.exe (built with C++Builder) orsbbs.dll (built with MSVC).Thanks to Codefenix for providing the sample file.ini file that demonstratedthe issue. This problem would've been very hard to root-cause otherwise!
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/973b548fcd8c126de3633b5c
Modified Files:
src/xpdev/genwrap.c
Log Message:
Use const doubles for time durationsInstead of copy/pasta. No change in function,.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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 ^~~~~~~~~~~~~~~~~~
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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).
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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).
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/78ae0fd80623b830fe86b6d6
Modified Files:
src/xpdev/genwrap.c
Log Message:
Change spaces to tabs in new strlcpy()
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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?
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/3046bd7ae4c3a503d9c5762d
Modified Files:
src/xpdev/genwrap.c
Log Message:
Simplify the Windows version detection a bit, don't use NetWkstaGetInfo()

I started seeing Windows 10.0 reported (without a build number) again on Windows 11 (after a regular update), so changed the logic to always try/use RtlGetVersion() except for Windows 7 where I saw it truncated the Service
Pack details.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/0158699aff72ded56de68882
Modified Files:
src/xpdev/genwrap.c
Log Message:
Don't return -1 from safe_snprintf() when size is zero.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/f5a033dd24945fdd2406c66f
Modified Files:
src/xpdev/genwrap.c
Log Message:
Annotate risky call to random()
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/8f919a6c118cd86c5b672030
Modified Files:
src/xpdev/genwrap.c
Log Message:
More fixups for clock selection.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/46e28f8d2a3862ae429d59bb
Modified Files:
src/xpdev/genwrap.c
Log Message:
When building for Windows Vista+, use GetTickCount64() through-out

At one point while migrating off the Windows XP compatible WinSDK and toolset, I was getting nice deprecation warnings in this file about uses of GetTickCount() and the 49 day roll-over isuse. I stopped getting those deprecation warnings (not sure when/why), but I'm still doing the right thing here/now and using the newer Win32 API function when it's available (always, for the versions of Windows we're building Synchronet and friends for).
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)