Skip to content
Snippets Groups Projects
Select Git revision
  • dd_msg_reader_list_personal_email_in_reverse_choose_msg_fix
  • dailybuild_linux-x64
  • dailybuild_win32
  • master default protected
  • sqlite
  • rip_abstraction
  • dailybuild_macos-armv8
  • dd_file_lister_filanem_in_desc_color
  • mode7
  • dd_msg_reader_are_you_there_warning_improvement
  • c23-playing
  • syncterm-1.3
  • syncterm-1.2
  • test-build
  • hide_remote_connection_with_telgate
  • 638-can-t-control-c-during-a-file-search
  • add_body_to_pager_email
  • mingw32-build
  • cryptlib-3.4.7
  • ree/mastermind
  • sbbs320d
  • syncterm-1.6
  • syncterm-1.5
  • syncterm-1.4
  • sbbs320b
  • syncterm-1.3
  • syncterm-1.2
  • syncterm-1.2rc6
  • syncterm-1.2rc5
  • push
  • syncterm-1.2rc4
  • syncterm-1.2rc2
  • syncterm-1.2rc1
  • sbbs319b
  • sbbs318b
  • goodbuild_linux-x64_Sep-01-2020
  • goodbuild_win32_Sep-01-2020
  • goodbuild_linux-x64_Aug-31-2020
  • goodbuild_win32_Aug-31-2020
  • goodbuild_win32_Aug-30-2020
40 results

pack_qwk.cpp

Blame
    • Rob Swindell's avatar
      4e1ca83a
      Fix possible crash when no extractable file types are configured in SCFG · 4e1ca83a
      Rob Swindell authored
      If libarchive couldn't extract a QWK or REP packet, we'd fallback to searching
      for a match among the configured extractable file types and if no extension/type
      match was found, default to the first configured extractable file type
      (even if there wasn't one) which would result in a NULL pointer dereference
      and most likely a crash. Instead, if no matching configured extractable
      file type is found, just log a warning message and don't continue with the
      extraction attempt. With SBBS v3.19+, it's totally valid/legit to have no
      extractable file types configured in SCFG and things "just work" (using
      libarchive).
      4e1ca83a
      History
      Fix possible crash when no extractable file types are configured in SCFG
      Rob Swindell authored
      If libarchive couldn't extract a QWK or REP packet, we'd fallback to searching
      for a match among the configured extractable file types and if no extension/type
      match was found, default to the first configured extractable file type
      (even if there wasn't one) which would result in a NULL pointer dereference
      and most likely a crash. Instead, if no matching configured extractable
      file type is found, just log a warning message and don't continue with the
      extraction attempt. With SBBS v3.19+, it's totally valid/legit to have no
      extractable file types configured in SCFG and things "just work" (using
      libarchive).