1. 02 Mar, 2022 1 commit
  2. 02 Jan, 2022 2 commits
  3. 30 Dec, 2021 1 commit
  4. 23 Apr, 2021 1 commit
    • Rob Swindell's avatar
      Use JS_ValueToECMAUint32 for File position, date, and length properties · 8f79438d
      Rob Swindell authored
      This resolves errors when setting these properties to values > 2147483647
      !JavaScript  /sbbs/exec/load/sauce_lib.js line 69: Error: can't convert
      2430770157 to an integer
      That means you can now seek around (set position) within files > 2GB, truncate
      or extend a file > 2GB, or set a file's date to > Jan-19-2038.
  5. 04 Apr, 2021 4 commits
  6. 30 Mar, 2021 1 commit
    • Deucе's avatar
      Initial poll() work · af30c430
      Deucе authored
      Still needs updates in services_thread(), CGI stuff in websrvr.c,
      and sbbs_t::external()
  7. 05 Mar, 2021 1 commit
  8. 22 Feb, 2021 1 commit
  9. 15 Feb, 2021 4 commits
  10. 26 Jan, 2021 2 commits
  11. 24 Jan, 2021 1 commit
    • Rob Swindell's avatar
      More support for !include in .ini files · 8fdbb169
      Rob Swindell authored
      Some (important) File methods did not support .ini files that used the !include directive because they were using the xpdev iniRead* API (which performs no "pre-processing") instead of xpdev iniGet*.
      Impacted methods:
      - iniGetValue()
      - iniGetKeys()
      - iniGetObject()
      The other existing ini* methods already worked fine with nested (!include'd) .ini files. It's possible there's a slight performance penalty with the new implementation since the entire .ini file is always read for each operation and previously it was possible that only a few "lines" were read to find the key(s) of interest. However, since .ini files are not typically huge and the iniRead/file-stream method likely read large (e.g. 8-32K) blocks anyway (which is usually the entire .ini file) - I don't actually suspect any observable impact to performance.
      This change was needed for the new ctrl/modopts.d support.
      Added new method useful for debugging nested .ini files:
      - iniReadAll()
  12. 03 Jan, 2021 1 commit
  13. 13 Nov, 2020 1 commit
    • Rob Swindell's avatar
      JS File.iniGetObject() and .iniGetAllObjects() now support blank strings · 1af02470
      Rob Swindell authored
      If an .ini file is read by either the iniGetObject() or iniGetAllObjects() methods and contains a key with a blank value, that property would be created with an "undefined" value.
      Both the iniGetObject() and iniGetAllObjects() methods now accept an additional Boolean argument (which defaults to false), to specify that "blanks" are acceptable. When the "blanks" argument is true, then keys with empty values in the .ini file are created as properties with empty string values (length of 0).
      This is going to be useful for modopts.js to read potentially-blank strings from modopts.ini and differentiate between a blank string key and a missing key.
  14. 06 Nov, 2020 1 commit
    • Rob Swindell's avatar
      Replace ctype.h function calls with new MSVC-safe XPDEV macros · 8a7b7308
      Rob Swindell authored
      I'm fed-up with MSVC assertions in ctype functions (e.g. isdigit, isprint, isspace, etc.) when called with out-of-range (e.g. negative) values.
      This problem only affects MSVC debug builds, but if you run them (like I do), these things are like little time bombs that can drive you crazy (knocking your board out of service).
      The new macros names are bit more descriptive as well.
  15. 16 Aug, 2020 1 commit
  16. 17 Apr, 2020 1 commit
  17. 12 Apr, 2020 3 commits
  18. 07 Apr, 2020 1 commit
  19. 06 Apr, 2020 1 commit
  20. 03 Apr, 2020 1 commit
  21. 19 Sep, 2019 3 commits
    • deuce's avatar
      Even more leak paranoia... · 7c162e3f
      deuce authored
      If dup() fails, return NULL
      If callog() fails, fclose() the new FILE*
      No functional change (hopefully).
    • rswindell's avatar
      Don't leak FILE streams for calls to js_CreateFileObject(), setting external · c20f74cc
      rswindell authored
      to TRUE meant the FILE* (created with fdopen) would never be closed. So we now
      duplicate the file descriptor and get rid of the external flag, always closing
      Files (FILE streams) upon File object finalize.
      This fixes the resource leak leading to the eventual "Error 24 opening ..." in
      the ircd.js when loaded via jsexec, on Windows. This error happened after
      169 calls to load(true,...), because each background load creates 3 Files
      (for stdin/out/err) and those FILE streams were never closed/freed, and
      169 * 3 = 507, plus a few open files = 512, the maximum number of open file
      streams in the Microsoft CRTL apparently. Thanks to Deuce for recognizing these
      numbers as "magic" and pointing to the likely cause.
    • rswindell's avatar
      Address some debug-log output issues with the File object: · 437edfa4
      rswindell authored
      "4294967295 File closed"
      "0000 File closed: /path/to/file"
  22. 27 Aug, 2019 1 commit
  23. 21 Aug, 2019 2 commits
  24. 15 Aug, 2019 1 commit
  25. 18 Jul, 2019 1 commit
  26. 15 Jul, 2019 1 commit
    • rswindell's avatar
      Fix long-standing issue with File.attributes on Windows: the value *read* · 16e4d35d
      rswindell authored
      was based on _finddata_t.attrib value while the value *written* was based on
      struct stat.st_mode, and totally incompatible.
      Just use the stat/chmod compatible value for both read and write (for all
      OSes). If you need the old Windows-centric attribute values (e.g. to determine
      "hidden" or "archive" attributes), use file_attrib() instead.
  27. 04 May, 2019 1 commit