Skip to content
Snippets Groups Projects
  1. Jan 14, 2025
  2. 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
  3. Dec 23, 2023
  4. Jun 05, 2023
  5. 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
  6. May 24, 2023
  7. Apr 09, 2022
  8. Mar 10, 2022
  9. Apr 26, 2021
  10. Apr 04, 2021
    • Rob Swindell's avatar
      A poll() failure with EINTR does not mean a socket is closed. · 925e3b0a
      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...
      925e3b0a
  11. Feb 15, 2021
  12. Feb 14, 2021
  13. Jan 18, 2021
    • Rob Swindell's avatar
      Safe string handling with config-load error messages · 4a13b65d
      Rob Swindell authored
      We were just trusting that the error strings would be shorter than 256 (usually), but since we're including paths and strerror() results, we really have no control over the length of the error strings. So enforce some healthy boundaries. This could explain the crashes that Divarin of Mutiny is seeing with SCFG on WinXP or maybe it was the truncsp(strerror()) stuff that was just removed as well. We'll see...
      4a13b65d
  14. Nov 23, 2020
    • Rob Swindell's avatar
      The great C function dependency refactor of 2020 · cee2d280
      Rob Swindell authored
      The goal of this commit is that: only modules that either are part-of sbbs.dll/libsbbs.so or need to link with/use that library, will #include "sbbs.h" and thus be dependent on its subsequent includes (e.g. cryptlib.h, jsapi.h). This should mean extdeps.mk can be trimmed way down.
      
      I also removed CVS keyword/comments and trimmed up the boilerplate copyright notice in modified and added source/header files in this commit.
      
      There is no functional change in behavior in this comment.
      cee2d280
  15. Sep 19, 2020
  16. Aug 17, 2020
  17. Aug 16, 2020
    • Rob Swindell's avatar
      Fix issue with jsexec being used for CGI scripts · 54431b31
      Rob Swindell authored
      If jsexec is used for a CGI script and the SBBSCTRL env var was not
      set, a warning would be printed (to stderr), even if the -c option
      was used to specify the path to the ctrl dir.
      
      get_ctrl_dir() now accepts a boolean argument to specify whether to
      print a warning when the default value ("/sbbs/ctrl") is used.
      Pass FALSE for jsexec, TRUE for other callers (currently).
      54431b31
    • Rob Swindell's avatar
      Commit with CVS Keywords expanded. · dfa1a0a4
      Rob Swindell authored
      dfa1a0a4
  18. Jan 03, 2020
    • rswindell's avatar
      Add/use a new get_ctrl_dir() function to query the SBBSCTRL env var and if · b236be71
      rswindell authored
      not set (or blank), use the default ("/sbbs/ctrl") and print a warning to
      stderr. This resolves a FAQ for sysops that struggle with setting the SBBSCTRL
      env var, but do have sbbs install in /sbbs or a symlink from /sbbs to where
      sbbs is actually installed.
      
      Note: this function is different than the one previously defined in getctrl.c
      but never used. If/when we ever really need to support PREFIX, then perhaps
      we'll use that one (which copies a string to a buffer).
      b236be71
  19. Feb 20, 2018
  20. Aug 22, 2015
  21. Oct 24, 2012
  22. Oct 29, 2011
    • deuce's avatar
      Fix format-related warnings. · 8563ad46
      deuce authored
      This is *likely* to break the Win32 build and even when the macros are
      specified in xpdev, I doubt Microsoft has added support for the 'z' size
      specifier used in smblib/smbadd.c we'll likely need a SIZE_T_SIZE macro
      that is "z" on C99 systems and "ll" or "64" or whatever it is on Win32.
      
      Or maybe a whole slew of complete SIZE_T macros since the 32/64 but thing
      and the max file size thing may actually need the full format specification
      to be in the macro... "zu" on C99 platforms and whatever magic Microsoft
      needs there.
      8563ad46
  23. Jun 04, 2008
  24. Feb 24, 2008
  25. Jul 08, 2007
  26. Dec 04, 2005
  27. Sep 20, 2005
  28. Sep 10, 2005
  29. Jul 11, 2003
  30. Apr 23, 2002
  31. Apr 12, 2002
  32. Mar 28, 2002
  33. Mar 13, 2002
Loading