- Feb 08, 2025
-
-
Rob Swindell authored
I discovered the first case when FileBase.get_path() failed, but didn't (immediately) throw an exception. Reviewing the other instances of JS_RepoertError() calls found several that either reported a garbage (e.g. NULL) string value or returned JS_TRUE. The design pattern used a little in js_socket.c probably should be used more: if (JS_IsExceptionPending(cx)) return JS_FALSE; return JS_TRUE; ... but that's more of a refactor than I had the stomach for right now.
-
- Jan 18, 2025
-
-
Rob Swindell authored
Many global functions now throw an exception when null or undefined is passed as a required parameter where null or undefined makes no sense. e.g. "Argument #1 is an unexpected 'null' or 'undefined' value" Example exception: is-a/has-a type functions will still return false when passed null or undefined. Changed global function return types: - write() now always returns undefined - printf() always returns a string, never undefined or garbage string - prompt() returns null (not undefined) upon no input (as documented) sbbs works more like jsexec: - read(0) now returns an empty string instead of undefined - readln(0) no longer waits for enter jsexec works more like sbbs: - add missing write_raw() global function, alias for write() Include expected number of argment in "Insufficient Arguments" exception message. Update JSDOCS for some global methods: - file_chmod returns boolean, not number - flags_str requires a minimum of one argument New tests to validate expected exceptions and return types based on usage.
-
- 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 22, 2024
-
-
Rob Swindell authored
-
- 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.
-
- Nov 14, 2024
-
-
Rob Swindell authored
there are still other undocumented fields/properties, but this one for sure was missing.
-
- Sep 14, 2024
-
-
Rob Swindell authored
Nelgin reported a weird error with a failed very large allocation for the base/code argument to the FileBase constructor. There's no good reason these strings were heap-allocated in the first place, so just change to use a stack allocated variable instead. I don't know why this would fix anything, but at least there's one less heap allocation and potential for memory leak here. Fix 2 bugs in js_update_file(): 1. missing parenthesis (really?!? Caught by Coverity - sigh) in last commmit caused attempt/failure/error to remove file after making any updates. The removing is only supposed to happen when its necessary to remove and re-add the file to the filebase (e.g. updating extended description or auxdata). 2. Wrong filename used in 'removing' exception string.
-
- Aug 08, 2024
-
-
Rob Swindell authored
And really, more importantly, the msg header field_list array length would always be interpretted as 0-length! ... introduced in commit 54523145
-
Rob Swindell authored
As was discovered as part of investigation into issue #769, a JavaScript could crash SBBS (cause a segfault) due to a NULL pointer dereference when the script passes 'null' to native JS functions where an object is expected. The issue raised was with console.gotoxy(), but it turns out that *many* Synchronet native JS functions would call JSVAL_TO_OBJECT() and then, without checking for NULL/nullptr, pass its return value to JS api functions such as JS_GetPrivate, JS_GetProperty, JS_GetClass, JS_ObjectIsFunction, JS_IsArrayObject, JS_GetArrayLength, JS_DefineProperty, JS_Enumerate, etc. All of these JS API functions dereference the passed object pointer without NULL/nullptr checking. The fix here is to either call JSVAL_IS_NULL() or JSVAL_NULL_OR_VOID() and if true, not call JSVAL_TO_OBJECT() and/or check the return value for the NULL value before using as an argument to any other JS API functions.
-
- Mar 03, 2024
-
-
Rob Swindell authored
To support the full 32-bit range for things like dates/times, and message numbers (!). This should fix issue #732 Though dates beyond Feb 7 2106 are definitely going to still be an issue. I'll definitley look into solving that by the the 2100.
-
- Jan 20, 2024
-
-
Rob Swindell authored
Still using BOOL where we need Win32 API compatibility. Using JSBool instead of BOOL or bool where it matters. Changed most relevant TRUE/FALSE to true/false too (though it's not as critical). You shouldn't need to #include <stdbool.h> anywhere now - gen_defs.h should do that automatically/correctly based on the language/version/tool. In C23, stdbool.h isn't even needed for bool/true/false definitions (they're keywords), so we don't bother including stdbool.h in that case. Microsoft didn't define __STDC_VERSION__ in their older tool chains (even though they were C99 compatible and had stdbool.h), so we use a _MSC_VER check to know that there's a stdbool.h we should use in that case. For other/old compilers (e.g. Borland C) we #define bool/true/false following the pattern of stdbool.h (doesn't use a typedef). I didn't convert UIFC yet. This addresses issue #698
-
- Dec 31, 2023
-
-
Rob Swindell authored
Should calm the clang warnings reported by Deuce: e.g. passing 'char *[18]' to parameter of type 'const char **' discards qualifiers in nested pointer types
-
- Dec 14, 2023
-
-
Rob Swindell authored
... in malloc error reporting messages
-
- Dec 02, 2023
-
-
Rob Swindell authored
-
- Nov 07, 2023
-
-
Rob Swindell authored
Replaced _property_ver_list (array of numbers) with _property_ver_list (array of objects) with a "ver" and (optional) "desc" property. This solves the enumeration order problem with objects that have both manual and table-based properties. Object's property tables (arrays of jsSyncPropertySpec) can now (optionally) contain the property descriptions. For properties defined in this manner, there will never be another mismatch between ther name/type and description/version in the jsobjs.html (a problem has re-occurred several times through the years with nebulous work-arounds). We still use _property_desc_list arrays for additional (e.g. manually defined) properties in such objects or just objects that only use one method of property definition and are not subject to the enumeration order problem. Fixed numerous typos. Using more consistent terminology and HTML mark-up. Some beautification and enhancement of readability, but nothing too major.
-
- 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!
-
- Jun 04, 2023
-
-
Rob Swindell authored
A bunch of possible (but often, not really) use of undefined values. Some ignored return values (e.g. of chsize/ftruncate, read, write, fgets). Other than some added diagnostics upon some of these unexpected syscall failures, there should be no change in behavior from this commit.
-
- May 27, 2023
-
-
Rob Swindell authored
Mostly just bitfield->bit-flags.
-
- May 25, 2023
-
-
Rob Swindell authored
No functional change, just a little clean-up.
-
- May 09, 2023
-
-
Rob Swindell authored
... rather than just failing silently with a special return value (e.g. false).
-
- May 08, 2023
-
-
Rob Swindell authored
So use js_argc() to report an error if there's fewer than 1 argument, but don't just fail silently when 2 arguments are provided.
-
- Mar 29, 2023
-
-
Rob Swindell authored
... rather than just return false. This will make debugging this type of issue much easier in the future. sendmail.js was allowing empty recipient_list array arguments and the MsgBase .status was 0 and .error just an emtpy string - unhelpful.
-
- Mar 14, 2023
-
-
Rob Swindell authored
Mainly capitalization, but some typos and added details.
-
- Nov 20, 2022
-
-
Rob Swindell authored
js_open() sets the rval for the context (e.g. to JSVAL_TRUE), so we need to set it back to JSVAL_FALSE for failure conditions. Otherwise, the methods always return true even upon (save-msg) failure.
-
- Oct 19, 2022
-
-
Rob Swindell authored
-
- May 08, 2022
-
-
Rob Swindell authored
The other msgbase property values are stored in the smb.status or other private_t members which retain their value when the message base is closed, unlike the 'first_msg' property which required a read of the message base index to get the value (and that doesn't work when the message base is closed, so would return 0). for deon (ALTERANT)
-
- Apr 22, 2022
-
-
Rob Swindell authored
This restores the ability for JS MsgBase() to be used to create the initial mail message base properly, if needed. This means that the 'subnum' should now be equal to scfg.total_subs when referencing an arbitrary SMB via path (not in the configuration).
-
Rob Swindell authored
Before commit 5da26eca, you could pass Msgbase() the path to an SMB on the disk and open() it, no configuration needed. As of 2 years ago, I broke that, and passing a path to an SMB would open the "mail" base instead - most unexpected. This is a feature of smb_open_sub() which we switched to using (from smb_open()), so go back to using smb_open() when an unrecognized code is pass to the constructor. This has the negative consequence that the "mail" base can't be created via JS. Probably should fix that.
-
- Apr 18, 2022
-
-
Rob Swindell authored
This is what was causing the 'is_utf8' message header property to be created as a Number instead of a Boolean.
-
- Mar 21, 2022
-
-
Rob Swindell authored
To fully support files > 4GB in size in file bases, credit values larger than 32-bits must be supported too. There's a couple of todo comments/items included in this commit, but that's mainly to do with messages (which don't really have costs anyway). The main thing to deal with now is the fact that users can't have more than 4GB in credits in the first place! That's got to be fixed next.
-
- Jul 11, 2021
-
-
Rob Swindell authored
When setting the value of a message's 'can_read' property, ignore the PRIVATE message attribute (which is sometimes set in FTN netmail messages) since it's assumed all messages in the mail base are private, no special destination (to) name matching is needed here. This only popped up recently via msglist.js because of the recent addition of checking each messages's 'can_read' property. As reported by <Diehard> via IRC PM.
-
- May 23, 2021
-
-
Rob Swindell authored
Underscores are more JS friendly (and correct).
-
- 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
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...
-
- Feb 15, 2021
-
-
Rob Swindell authored
Hopefully not introducing any bugs in the process.
-
Rob Swindell authored
Hopefully not introducing any bugs in the process.
-
- Dec 25, 2020
-
-
Rob Swindell authored
Advertise the system's QWK-ID (a.k.a. BBS ID) in exported echomail messages. This will allow correlation of avatars that were imported via SYNCDATA carried via QWKnet (e.g. DOVE-Net) with messages imported from those same BBSes via FTN. The alternative was to have SYNCDATA Avatar messages include all the AKAs of each BBS (in the body text), but that was looking like a rather complicated solution. This approach (the BBSID kludge) seems a much simpler solution. I still need to implement the JS side of this solution however (for avatar lookups using the FTN BBSID), but this was the first important step.
-