- Jan 14, 2025
-
-
Rob Swindell authored
uncrustify nl_split_if_one_liner setting
-
Rob Swindell authored
... using uncrustify mod_paren_on_return config
-
Rob Swindell authored
White-space changes only, exception being the rare insertion of NL before closing brace (couldn't find the option to disable that behavior). I excluded some header files (e.g. sbbs.h) since uncrustify seemed to be doing more harm than good there. I might just end up applying different set of rules to .h files.
-
- Jan 11, 2025
-
-
Rob Swindell authored
e.g. [can|is]_subject_something() is now named subject_[can|is]_something() No functional change.
-
- Dec 21, 2024
-
-
Rob Swindell authored
Increment SMBLIB version to 3.10 Fix issue #845: Changing system/OS time zone, changes dates/times of posted messages Sysops and users shouldn't notice any change unless they change the time zone of their system/OS (not accounting changes for daylight/standard time) and the result will be that message dates appear the same after such a change. For backward compatibily, any stored time_t's in msghdr_t.when_written.time (i.e. all existing SMB messages) will still be decoded and displayed properly. We detect a time_t value by the upper 6 bits being non-zero. When the upper 6 bits of a when_written.time value are zero, then we know the 'year' is stored in the 16-bits before the when_written field (never used bits of the netattr field, now part of the when_t structure definition) and the Month, Day, Hour, Minute, and Second of the wallclock at the poster's site are encoded in the low 26 bits of the time field. This also eliminates more uses of 32-bit time_t that'll likely start being a problem 2038 and really fall over and die in 2106. At least messages' posting dates won't have any issue now. The "when_imported" values could use a similar treatment someday I suppose - and we could get rid of the when_imported.zone value as its not really needed we could use those 16-bits for the when_imported.year. Didn't change anything with filebases (still using time_t's though the when_written hdr field isn't used for much with regards to files). Yes, we could have converted all imported "broken down" message dates to UTC and continued to store them as a time_t using timegm() instead of mktime() for conversion to time_t, and I considered that. But we would have needed to create/use a flag in the message header to indicate such stored date/times (since they'd have to go through different adjustment for original time zone before display, basically reversing the logic of all the places we display the message dates/times using localtime verus gmtime/UTC C RTL functions), couldn't just initialize the time with a call to time() upon import of local messages (unless the local timezone happened to be UTC). And in the end, we'd still have a 32-bit time_t value. So this seemed the better path. I would have liked to have stored the date fields in a more human readable encoding (BCD or decimal, ala isoDate and isoTime_t), but I just didn't have the spare bits in the fixed portion of message headers to be wasteful like that. Here's an example from smbutil v of a message header posted after this change: when_written 03292595 41E0 Fri Dec 20 18:22:21 2024 PST when_imported 6766265D 41E0 Fri Dec 20 18:22:21 2024 PST Notice the difference in the hex encoding of the date/time between the 2 header fields: when_imported still uses time_t. The when_written.year value isn't output here.
-
- Oct 28, 2024
-
-
Rob Swindell authored
This is a code clean-up, no change in functionality
-
- Oct 23, 2024
-
-
Rob Swindell authored
Fix issue #801
-
- Mar 17, 2024
-
-
Rob Swindell authored
This resolves the conflict with MSG_HOLD definition in socket.h on MacOS: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/socket.h And hey... [NET]MSG_HOLD isn't actually used anywhere? What's up with that.
-
- Jun 09, 2023
-
-
Rob Swindell authored
So Clang-FreeBSD was warning (in compiles of scfg/scfg*.c by Deuce): result of comparison of constant 100000 with expression of type 'uint16_t' (aka 'unsigned short') is always true Why? Cause a uint16_t's max value is 65535 (less than 100000). Sure we could have just lowered the UIFC max number of config items to 65535, but that would have been too easy. And why are these compared-with values of type uint16_t to begin with? Because most ctrl/*.cnf lists (of configuration items) were limited to 65535 entries cause ... 16-bit DOS, historically. Now that *.cnf files aren't used, we could just increase these scfg_t.*_total type sizes from 16 to 32-bits, yeah? The result is this commit. I went to (signed) int so we could still keep -1 as the special illegal sub/dir num value (e.g. INVALID_SUB, which is sometimes used to indicate the email message base). Theoretically, 2 billion configuration items could be supported in these lists, but SCFG will limit you to 100000 anyway. So there's a whole lot of s/uint/int in this commit. I'd be very surprised if this doesn't result in some new GCC/Clang warnings, but at least the old "comparison of constant 100000" warnings are now gone!
-
- Mar 04, 2023
-
-
Rob Swindell authored
Upon successful download of a file, recalculate and store the user's download CPS (characters/bytes per second), mainly for subsequent transfer time estimates.
-
- Feb 19, 2023
-
-
Rob Swindell authored
Mostly [s]printf format fixups
-
Rob Swindell authored
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.
-
- Oct 18, 2022
-
-
Rob Swindell authored
Also resolved some 32 vs 64-bit 'long' issues/ambiguities that have long-remained. :-) This commit also removes logon.lst file support. There's a TODO block remaining in js_user.c for setting portions of a user's birthdate (e.g. just the year or month or day).
-
- Jul 03, 2022
-
-
Rob Swindell authored
Use the is_valid_subnum() function before using the smb.subnum as an index into (s)cfg.sub[]. Related to the previous committed fix of writemsg(): leaving the global smb.subnum as -1 (INVALID_SUB) after replying to a post via email or netmail, resulting in a crash here.
-
- Mar 24, 2022
-
-
Rob Swindell authored
-
Rob Swindell authored
Credits and daily free credits are accurate to the byte up to (a maximum) of 18446744073709551615 (that's 18 Exbibytes - 1). User's upload and download byte stats are now similarly extended in maximum range, but the accuracy is only "to the byte" for values less than 10,000,000,000. Beyond that value, the accuracy declines, but is generally pretty damn accurate (to 4 decimal places beyond the nearest multiple of a power of 1024), so I don't expect that to be an issue. This method of storing upload/download byte stats allowed me to use the same 10-character user record fields in the user.dat file. As a side-effect of this enhancements: * User and file credit values are now expressed in multiples of powers of 1024 (e.g. 4.0G rather than 4,294,967,296). * Free credits per day per security level has now been extended from 32 to 64-bits (to accommodate values >= 4GB). * adjustuserrec() now longer takes the record length since we can easily determine that automatically and don't need more "sources of truth" that can be out-of-sync (e.g. the U_CDT field length going from 10 to 20 chars with this change). * setting the stage for locale-dependent thousands-separators (e.g. space instead of comma) - currently still hard-coded to comma * more/better support for files > 4GB in size (e.g. in the batch download queue) * user_t ulong fields changed to either uint32_t or uint64_t - I didn't realize how many long/ulong's remained in the code (which are sometmies 32-bit, sometimes 64-bit) - ugh * Steve's ultoac() function renamed to u32toac() and created a C++ wrapper that still uses the old name, for homage
-
- Mar 03, 2022
-
-
Rob Swindell authored
So this started with addressing CID 174264: Big parameter passed by value (PASS_BY_VALUE), but then I fell down the constification rabbit hole. :-)
-
- Feb 11, 2022
-
-
Deucе authored
This will allow naming consistency in encode/* This is the fix you're looking for Keyop. :)
-
- Apr 04, 2021
-
-
Rob Swindell authored
This won't impact Synchronet as it has a separate signal handling thread, but we still need to behave properly for processes that don't. I'm also saying that ENOMEM does not indicate a disconnection, though it may be better to pretend it was disconnected...
-
- Mar 04, 2021
-
-
Rob Swindell authored
There were 2 bug identified by issue #230: - the "Fwd:" prefix being added to the message subject was being treated as a filename. I first thought to just remove this subject tag, but then thought it best to just ignore obviously invalid filenames in the subject in the first place. - when forwarding files to a netmail address, the 'to' extension (user number) is 0, so the file will be in the data/file/####.out directory of the sender instead. We have 4 places (at least) where the message subjects are parsed and only one of those places currently supports quoted filenames (e.g. with spaces in them) and some of the others (e.g. QWK) don't support multiple filenames at all. That should be fixed.
-
- Feb 15, 2021
-
-
Rob Swindell authored
Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.
-
Rob Swindell authored
Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.
-
Rob Swindell authored
Hopefully not introducing any bugs in the process.
-
Rob Swindell authored
Hopefully not introducing any bugs in the process.
-
- Jan 21, 2021
-
-
Rob Swindell authored
Don't display at all if smb_getplaintext() returns a blank string. Don't display "(null)" if there's no text sub-type.
-
- Dec 20, 2020
-
-
Rob Swindell authored
-
- Dec 10, 2020
-
-
Rob Swindell authored
Since we're calling smb_getplaintext() manually here, and its not going to return the comment headers as part of the plain-text (the way smb_getmsgtxt() can), so we need to display find/display the comment headers first.
-
- Dec 09, 2020
-
-
Rob Swindell authored
Copy some code from atcodes.cpp to show all the aux and network attributes. Also, the MsgAttr text.dat string only contains 17 %s's but we were passing 18, so the last attribute (KillSent) would never be shown. Instead, split this into 3 strings and just pass those 3 strings to the MsgAttr format string along with a ton of blank strings. So we don't have to keep updating the MsgAttr text.dat string every time we add more attribute flags (that was kind of ridiculous).
-
- Sep 27, 2020
-
-
Rob Swindell authored
The return value of getlastmsg() is displayed as the total messages in a sub-board when scanning subs. For sub-boards that allow voting, use the new smb_msg_count() function to determine the number of displayable messages.
-
- Aug 16, 2020
-
-
Rob Swindell authored
-
- May 08, 2020
-
-
rswindell authored
- hot spots are clickable screen areas (e.g. in menus and prompts) that generate key-strokes - commands may be from 1 to 127 ASCII-characters in length - currently using the X10 mouse reporting mode, may change - all mnemonics strings (~Example) are automatically hot-spots - The new ~ @-code defines a hot spot - Any screen-clear operation clears all hot spots - sbbs now tracks the current screen (cursor position) row - eliminated the old "tos" (top-of-screen) boolean (row == 0 indicates "tos") - created an sbbs_t::ungetstr() method - keep track if in pause (hit a key) prompt, for special mouse behavior new JS console object: - row property - tos property is now read-only (and deprecated) - new methods: add_hotspot() clear_hotspots() scroll_hotspots() redrwstr() gets some UTF8 touch-ups as part of this commit. <shrug>
-
- Oct 08, 2019
-
-
rswindell authored
Don't suppress the display of the "from network address" just because there's an '@' in the "from name" - some Internet email (e.g. SPAM) "From" names include '@'s to try and follow the reader. <sigh>
-
- Aug 24, 2019
-
-
rswindell authored
wrapper for utf8_normalize_str() and utf8_replace_chars with the proper arguments. This will fix *a* problem with UTF-8 message not being converted to CP437 in QWK packets correctly (we were just normalizing, not fully converting). Also got rid of the defunct DLLCALL usage str_util.c
-
- Aug 17, 2019
-
-
rswindell authored
characters in message headers and body text will be converted to CP437. Also include a new field in HEADERS.DAT: utf8 = true/false to indicate that the message headers and body text contain UTF-8 encoding (not CP437).
-
- Aug 08, 2019
- Aug 07, 2019
-
-
rswindell authored
can't use it as an argument to sprintf(str, ...) Also, use getfname()... more.
-
- Aug 04, 2019
-
-
rswindell authored
- bstrlen() moved to sbbs_t, accepts an option pmode argument so it can account for UTF-8 encoded strings correctly - JS console.strlen() now accepts an optional pmode argument (e.g. P_UTF8) - Renamed sbbs_t::utf8_to_cp437 to sbbs_t::print_utf8_as_cp437 - Create/use msghdr_hfield() to perform UTF-8->CP437 conversions as needed for printing/copying UTF-8 encoded message header fields. - Defined XTRN_UTF8 misc setting flag. If a message editor does *not* have this flag, it is assumed to *not* support UTF-8. Will likely use this for UTF-8 doors as some point too (none known to exist, yet).
-
- Aug 03, 2019
-
-
rswindell authored
show_msghdr()
-
rswindell authored
flag in the message header. When displaying message header fields containing UTF-8 using show_msghdr() with text.dat string or with msghdr.asc and @-codes, do the "dance" to be sure it's displayed correctly depending on the user's terminal (UTF-8 or not).
-