Skip to content
Snippets Groups Projects
  1. Feb 08, 2025
    • Rob Swindell's avatar
      Native JS methods must return JS_FALSE for (Error) exceptions to be thrown · 6ed4a05f
      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.
      6ed4a05f
  2. Jan 18, 2025
    • Rob Swindell's avatar
      Global JS function parameter validation and updated return types · 4914fa1d
      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.
      4914fa1d
  3. Jan 14, 2025
  4. Jan 11, 2025
  5. Dec 22, 2024
  6. Dec 21, 2024
    • Rob Swindell's avatar
      Encode local wallclock (not time_t) in SMB's when_t.time · 445394f9
      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.
      445394f9
  7. Nov 14, 2024
  8. Sep 14, 2024
    • Rob Swindell's avatar
      Don't heap allocate argument to MsgBase and FileBase constructors · a398abb2
      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.
      a398abb2
  9. Aug 08, 2024
    • Rob Swindell's avatar
      Fix CID 508260: Null pointer dereference · 8fc08f0d
      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
      8fc08f0d
    • Rob Swindell's avatar
      Prevent NULL pointer dereference when 'null' object passed to JS functions · 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.
      54523145
  10. Mar 03, 2024
  11. Jan 20, 2024
    • Rob Swindell's avatar
      The great BOOL->bool conversion in xpdev · 118984e9
      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
      118984e9
  12. Dec 31, 2023
  13. Dec 14, 2023
  14. Dec 02, 2023
  15. Nov 07, 2023
    • Rob Swindell's avatar
      JSDOC build cleanup (used to generate jsobjs.html) · 96019606
      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.
      96019606
  16. Jun 09, 2023
    • Rob Swindell's avatar
      <Deuce> ... billion-and-one result of comparison of constant 100000 warnings. · 2b087b8b
      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!
      2b087b8b
  17. Jun 04, 2023
    • Rob Swindell's avatar
      Fix warnings raised by gcc -D_FORTIFY_SOURCE=3 -O1 · 8667e329
      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.
      8667e329
  18. May 27, 2023
  19. May 25, 2023
  20. May 09, 2023
  21. May 08, 2023
  22. Mar 29, 2023
  23. Mar 14, 2023
  24. Nov 20, 2022
  25. Oct 19, 2022
  26. May 08, 2022
    • Rob Swindell's avatar
      Remember the last 'first_msg' property value after msgbase is closed · b1c5d2da
      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)
      b1c5d2da
  27. Apr 22, 2022
    • Rob Swindell's avatar
      Use smb_open_sub() for the "mail" base too · cac411de
      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).
      cac411de
    • Rob Swindell's avatar
      Restore ability for MsgBase.open() to open an arbitrary SMB msgbase · 61ecda33
      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.
      61ecda33
  28. Apr 18, 2022
  29. Mar 21, 2022
    • Rob Swindell's avatar
      SMB items (messages or files) can now have 32-bit or 64-bit cost value · f1332d3e
      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.
      f1332d3e
  30. Jul 11, 2021
    • Rob Swindell's avatar
      Ignore the PRIVATE message attribute for the "mail" base · c3189653
      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.
      c3189653
  31. May 23, 2021
  32. Apr 04, 2021
  33. Feb 15, 2021
  34. Dec 25, 2020
    • Rob Swindell's avatar
      Add/use new FTN "BBSID" control paragraph (kludge line) · bce719a8
      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.
      bce719a8
Loading