Skip to content
Snippets Groups Projects
  1. Mar 05, 2021
  2. Feb 22, 2021
  3. Feb 15, 2021
  4. Jan 26, 2021
  5. Jan 24, 2021
    • Rob Swindell's avatar
      More support for !include in .ini files · 2ff1a3b5
      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()
      2ff1a3b5
  6. Jan 03, 2021
  7. Nov 13, 2020
    • Rob Swindell's avatar
      JS File.iniGetObject() and .iniGetAllObjects() now support blank strings · 6d6451c8
      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.
      6d6451c8
  8. Nov 06, 2020
    • Rob Swindell's avatar
      Replace ctype.h function calls with new MSVC-safe XPDEV macros · ec20d959
      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.
      ec20d959
  9. Aug 16, 2020
  10. Apr 17, 2020
  11. Apr 12, 2020
  12. Apr 07, 2020
  13. Apr 06, 2020
  14. Apr 03, 2020
  15. Sep 19, 2019
    • 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).
      7c162e3f
    • 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.
      c20f74cc
    • 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"
      437edfa4
  16. Aug 27, 2019
  17. Aug 21, 2019
  18. Aug 15, 2019
  19. Jul 18, 2019
  20. Jul 15, 2019
    • 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.
      16e4d35d
  21. May 04, 2019
    • rswindell's avatar
    • rswindell's avatar
      Define and use a wrapper for JS_GetInstancePrivate(): js_GetClassPrivate() · 6f83c4ff
      rswindell authored
      Use this in place of JS_GetPrivate() in native class methods that need the
      class instance's private data pointer and will do bad things if that pointer
      points to something other than what is expected. mcmlxxix (matt) discovered
      that using Object.apply(), you can invoke class methods where the 'this'
      instance is a different class. This would result in
      "Internal Error: No Private Data." or a crash.
      So now, gracefully detect this condition and report a meaningful error:
      "'<class-name>' instance: No Private Data or Class Mismatch"
      
      Also, important to note: if the method uses JS_THIS_OBJECT to get the JSObject*
      to pass to JS_Get*Private, then it must do this *before* it calls JS_SET_RVAL.
      
      From jsapi.h:
       * NB: there is an anti-dependency between JS_CALLEE and JS_SET_RVAL: native
       * methods that may inspect their callee must defer setting their return value
       * until after any such possible inspection. Otherwise the return value will be
       * inspected instead of the callee function object.
      
      The js_crypt*.c files still need this treatment.
      6f83c4ff
  22. Mar 24, 2019
  23. Jan 20, 2019
    • rswindell's avatar
      The "stdio" File objects (stdin, stdout, stderr) did not work on Windows, · 7acadb70
      rswindell authored
      because the stdout FILE* is a different address in jsexec than it is in sbbs.dll
      (where the actual File I/O operations occurred). Refactored by passing the
      stdio file descriptor (and open mode) to js_CreateFileObject rather than the
      FILE* and using fdopen() to get a FILE* associated with the descriptor.
      stdout.write() now works, for example.
      7acadb70
  24. Jan 10, 2019
  25. Jan 09, 2019
  26. Aug 28, 2018
  27. Apr 02, 2018
    • rswindell's avatar
      Updated JS warning when using old/deprecated file open mode 'e': · aad09443
      rswindell authored
          "Deprecated file open mode: 'e'"
      If this is your script generating this warning, either remove the 'e' from
      the File open() mode string (it had no effect anyway) or change to 'x' to
      get the real/working exclusive-open functionality (added in v3.17).
      aad09443
    • rswindell's avatar
      The 'e' (exclusive-open) mode flag (introduced in v3.12) never worked. It was · 95d30e01
      rswindell authored
      simply ignored when converted to the underlying open mode passed to sopen().
      Deprecate this flag and log a warning when it is detected as used in a script:
      Deprecated open flag used: 'e'
      Added 'x' (exclsuive-open) mode flag which:
      1. was tested to work as intended
      2. is consistent with the C11 standard for fopen() mode flags
      3. won't cause existing scripts to suddenly break
      95d30e01
  28. Feb 20, 2018
Loading