- Jan 14, 2025
-
-
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.
-
- Jan 06, 2025
-
-
Rob Swindell authored
notify() was creating wrongly-formated auto-generated Message-IDs: e.g. Message-ID: <677B3F17.0.notices@vert.synchro.net>
-
- 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.
-
- Dec 14, 2024
-
-
Rob Swindell authored
This is a solution for issue #842, but only for messages posted/sent from the terminal server using built-in functions and not via JS or other means. A more universal/generic solution would be nice (beyond just always storing message headers and bodies in UTF-8), but nothing has come to mind.
-
- Dec 10, 2024
-
-
Rob Swindell authored
(which might be UTF-8 encoded). This works-around the problem that Accession reported in #synchronet with my reply to a UTF-8 encoded message using a CP437 terminal which resulted in a message body that was UTF-8 encoded but a message subject that was CP437 encoded. This mix of encodings is not supported by FTN standards. This is just a work-around since if the user modifies the subject the result could still have the CP437 unside-down question marks (indicating non-translatable UNICODE chars) and those should be converted to UTF-8 chars when going out on FTN or being stored in the message base. So there's still a bug here somewhere that I need to look into more.
-
- Dec 02, 2024
-
-
Rob Swindell authored
Addresses Clang warnings about deprecation
-
- Nov 26, 2024
-
-
Rob Swindell authored
to notify sysop (user #1) that they were paged. Previously, this was a hard-coded string. The new string in text.dat is the same, but adds 2 BELs (CTRL-G chars) and is now customizable. Created an sbbs_t::notify() method to make this easier to use and that method supports @-code expansion, so this text.dat string supports @-codes (which I used). This addresses the feature request in issue #828 (beep the sysop in the telegram/short message, when they're paged).
-
- Sep 07, 2024
-
-
Rob Swindell authored
It appears I had the idea to make the CantPost text.dat string a format string before, but never quite finished that change (e.g. made the change to email.cpp and text.dat too).
-
- May 16, 2024
-
-
Rob Swindell authored
client_t.protocol is no longer a pointer. Warnings reported by gcc (Debian 12.2.0-14) 12.2.0
-
- Feb 16, 2024
-
-
Rob Swindell authored
Don't corrupt UTF-8 strings with SAFECOPY() (use new SAFECOPY_UTF8). Some terminals (notably, Windows Terminal) display zero width UNICODE chars as a single column-wide space. <sigh> Auto-detect the zero-width "width" (1 or 0) of the terminal during connection and UTF-8 auto-detection. getstr() works a lot better now with UTF-8 strings with wide chars (e.g. emojis), but likely much more to do.
-
- Jan 15, 2024
-
-
Rob Swindell authored
This recent enhancement (Commit 61a3ab2d) introduced security and usability concerns. So I created (and am now using where requested) a wrapper for formatting text.dat/ini strings which will automaticlaly detect @-code encoded strings and expand/use them *only* (instead of printf %-specifiers). This might impact issue #696 since although unintentionally, it actually was possible to mix @-codes and %-specifier usage in certain (node status) text.dat/ini strings, but that should not be possible now. It's either/or: @-codes or %-specifiers, not both.
-
- Dec 12, 2023
-
-
Rob Swindell authored
Actually tested myself this time, needed a lot more than first appearances. Also includes a security/safety enhancement where the @-code expanded string is *not* used as an sprintf format string. Supporting both format specifiers and @-codes in a single text.dat string is tricky (always has been). For Accession.
-
- Dec 10, 2023
-
-
Rob Swindell authored
Expected to use the MSG_* @-codes in this context. This allows more freedom of ordering the message header fields reused in this expanded string. The %s specifiers can be eliminated altogether when using @-codes. For Accession to play with.
-
- Nov 22, 2023
-
-
Rob Swindell authored
In response to Nelgin's inquiry: DigitalMan would it be difficult to add login/logoff date/time to these messages? Node 2: xxuserxx logged on Telnet Node 2: xxuserxx logged off Now, you can just use @-codes to add that kind of thing to these text.dat strings.
-
- 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!
-
- May 24, 2023
-
-
Rob Swindell authored
One of the benefits of the new .ini format config files. :-) This increase introduced a few potential buffer overrun warnings (all writes to smb_t.file ?)
-
- May 08, 2023
-
-
Rob Swindell authored
It's possible to use savemsg() (from JS MsgBase.save_msg()) to add a message to a message base that's not a sub-board (not configured in SCFG->Message Areas and not the "mail" base), but in that case, savemsg() would dereference an invalid sub in the scfg->sub array and crash. So use is_valid_subum() to insure the subnum is a valid sub before using as an index.
-
- Feb 19, 2023
-
-
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.
-
- Jan 30, 2023
-
-
Rob Swindell authored
- Most published messages (besides log entries) have a timestamp (in ISO8601 format) prepended and tab-separated - The order and number of elements in client messages (list and activities) has been updated, now includes user number - Server client lists are now published to .../SERVER/client/list - Server client activities (connect, disconnect, update) are now published to .../SERVER/client/action/# - Server client count is now published to .../SERVER/client (with the maximum client count, if applicable) - Server states are now just represented by name (e.g. initializing, ready, stopping, stopped) and not number - BBS errors are logged to sbbs/BBS/action/error/LEVEL (where LEVEL is the log level name, e.g. "critical" or "error') - All server hack-attempts, SPAM attempts, logins, logouts, uploads, downloads, are published to sbbs/BBS/action/ACTION/* - Chat pages are published to sbbs/BBS/action/page/node/# - New users (on the terminal server) are published to sbbs/BBS/action/newuser - Posted messages and executed external programs (on the terminal server) are published to sbbs/BBS/action/ACTION/CODE topic - The event thread started/stopped status is published to .../SERVER/event Yeah, the wiki will get updated soon to reflect/document all these changes
-
- Jan 24, 2023
-
-
Rob Swindell authored
This fixes issue #495.
-
- Oct 24, 2022
-
-
Rob Swindell authored
We may want Ctrl-A sequences in the telegram subject, but not in the message subject
-
- 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).
-
- Mar 10, 2022
-
-
Rob Swindell authored
-
- Apr 14, 2021
-
-
Rob Swindell authored
Some QWKnet vote messages are failing: evnt unpackREP <ENSEMBLE> !ERROR 2 (No such file or directory) in qwk.cpp line 1146 (qwk_vote) writing "/sbbs/data/subs/dove-gen" access=-105 info=smb_addvote thread_back field missing Catch this problem a little higher up (in votemsg()) and log the message's reply-IDs to help determine what's the root-cause here. Don't bother calling smb_addvote() if thread_back is 0.
-
- Apr 04, 2021
-
-
Rob Swindell authored
This macro has expanded to nothing for a while now and even before, the usage was misguided and unnecessary as explained in this video: https://www.youtube.com/watch?v=cjotPqQxxAY
-
Rob Swindell authored
CID 319077
-
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 19, 2021
-
-
Rob Swindell authored
Thanks Mr. Executive Chicken esq. for the telephone call and bug report.
-
- Nov 12, 2020
-
-
Rob Swindell authored
When posting to "All" or replying to a message that was posted by networked (not local) user, don't attempt to search for that username in the local user base to inform them of the posted message to them. savemsg() is the underlying C function for saving a new message (mail or post) to a message base from several places, including JS modules. If there was no "charset" specified in the passed message header, check to see if the message body text is non-ASCII but valid UTF-8, and if it is, set the FIDO_CHARSET header field to the appropriate UTF-8 charset identifier string. This would *also* address Issue #177 reported by Michael J. Ryan. It's possible, but unlikely, that a message text would contain valid CP437 that *also* happened to be valid UTF-8. If that does happen to occur (e.g. in posted ANSI art?), we might want to revert this enhancement to savemsg() and leave to the caller's to detect/specify the charset, always.
-
- Oct 22, 2020
-
-
Rob Swindell authored
And separate the saved/imported message text into body and tail (separate SMB msg data fields) automatically to exclude signatures from quoted text. As requested by Tracker1.
-
- Oct 03, 2020
-
-
Rob Swindell authored
'i' is the return value of savemg(), used to determine success or failure (and what kind of failure) - so we can't use that for the usernumber of the recipient.
-
- Oct 01, 2020
-
-
Rob Swindell authored
-
Rob Swindell authored
While SBBSecho would notify local users of imported messages addressed to them (both EchoMail and NetMail) and QWK-imported messages recently gained the ability to notify local recipients of messages addressed to them, other methods of posting messages (e.g. just using the normal terminal server method, e.g. the 'P' command) or using any JavaScript (e.g. web) methods of posting messages lacked recipient notifications. So that's now fixed. And for JavaScript-saved local email messages too. I don't *think* this will result in any duplicate notifications of received messages, but let me know if you see excess/duplicate notifications. Anonymously posted messages are excluded. Messages posted to yourself are excluded (who does that?).
-
- Sep 07, 2020
-
-
Rob Swindell authored
Eliminate the hack in each server where it will over-write startup host_name (with the configured Internet email address), if it's blank. This hack was subject to a race condition where the parent app (e.g. sbbsctrl.exe) would clear or re-initialize the host_name after the sever threads had initialized. Instead, just use a function which will return either the startup->host_name or (fallback to) scfg.inet_addr.
-
- Aug 16, 2020
-
-
Rob Swindell authored
-
- Aug 15, 2020
-
-
rswindell authored
Try that, Nelgin.
-
- Aug 08, 2020
-
-
rswindell authored
The problem: the sysop (me) is not notified of critical errors (e.g. synchro.net zone file problems) in a timely manner. Part of the solution: notify a configured user (e.g. user #1) via short-message/telegram and email/netmail logged-errors when messages of a configured severity (e.g. "Critical") are logged. The second part of the solution (coming next) will be allowing timed events to log a message of a configurable severity logged when the event fails (returns a non-zero error level to sbbs). I'm saving the error-notification-user-number and log-severity as part of the node.cnf file because: - that's where the validation user number is already set - I can conceive of a large system were certain node ranges (different instances of sbbs) might want different operators to be notified of logged-errors This also means I eliminated all the legacy com port/modem stuff from the end of the node.cnf file. None of that is used in sbbs v3. Also included in this commit are improvements around logging: - reduce the severity of UDP recvfrom failures in services - a more detailed log message when the mail server successfully delivers an email (via SMTP) - easier to answer the question: was that email you/they sent delivered successfully?
-
- May 25, 2020
-
-
rswindell authored
Include a replied-to message's to field to be selected in the post-to history (arrow-up to choose strings from history).
-