qp_decode (quoted-printable in-place decode of a string) could write 2 characters *beyond* the allocated buffer by appending "\r\n" to a string that was not quoted-printable in the first place. i.e. the  contents of buf were not actually changed in the decode loop. This could result in a corrupted heap and crash of sbbs or smbutil when reading such a message.

This change may result in a lack of CRLF appended to decoded plain text output, so we'll have to keep an eye out for that and resolve it some other way. One possibility could be to only append the CRLF if the destination pointer is sufficiently behind the source pointer.

This solves the crash that Kirkman reported with a specific message in his "mail" base. The header for the message said it was quoted-printable encoded, but the body text was not actually encoded at all:
OtherHeader      Content-Type: text/plain; charset="iso-8859-1"
OtherHeader      MIME-Version: 1.0
OtherHeader      Content-Transfer-Encoding: quoted-printable

<Dan_C> DigitalMan: minor install issue noted today - during a fresh (Linux) install on a test box, the build failed because it was unable to execute the "sudo setcap ..." command.  This was on Slackware 15.0, where the setcap executable is located in /sbin , and that directory is not in the $PATH of a normal user, or even when a normal user uses the 'sudo' command.

This reverts commit 2869cfb8.

SETCAP isn't a command-line after all, it's a build target.

This reverts commit 6a2c3722.

SETCAP isn't a command-line afterall, it's a build target.

So use 'whereis' to find and and 'cut' to trim its output

<Dan_C> DigitalMan: minor install issue noted today - during a fresh (Linux) install on a test box, the build failed because it was unable to execute the "sudo setcap ..." command.  This was on Slackware 15.0, where the setcap executable is located in /sbin , and that directory is not in the $PATH of a normal user, or even when a normal user uses the 'sudo' command.

Also include SETCAP in the set of documented make variables.

Actually probably doesn't fix it, but what'evs

Also, when hitting ESC at the "Use Real Names" prompt, don't prompt for the Lower-casing of the drop file name.

... and USERS.SYS file creation using new C++ type definitions in pcbdefs.hpp.

This mostly fixes issue #366.

PCBOARD.SYS is officially the worst file format ever invented, not just the worst BBS drop file format ever invented. What were these guys smoking?!?

I don't know what reference I used almost 30 years ago when I first implemented PCBOARD.SYS file support, but this time I used the PCBoard v15.3 source code (e.g. sys.c and usersys.c) and even their own code seems to work really hard to conform to these crazy file formats.

USERS.SYS is a little more sane, but not by a lot.

C++ features make this cleaner/easier, but man... there's just so much polish you apply to these turds.

I guess (and hope) that nobody's really running programs that depend on/use these file formats. <shrug>

Just integers right now. And only big or little endian.

Also displays net and aux attribute values when non-zero (weren't displayed
at all with the 'r'ead command previously).

ddfilelister: Now displays extended description in list view if the user has that setting enabled

Closes #363 and #374

See merge request !157

ddfilelister version 2.05 - Now makes use of the user's extended file description setting: If
the user's extended file description setting is enabled, the lister will now show extended file
descriptions on the main screen in a split format, with the lightbar file list on the left and
the extended file description for the highlighted file on the right.
Also, made the file info window taller for terminals within 25 lines high.
This should resolve issue #363 .
This update to ddfilelister also requires the included update to dd_lightbar_menu.js and the
new attr_conv.js.

Functionality replaced with Pascal::String

LORD: Fix crash when exiting aratime igm

See merge request !156

For Trikester (DOVEMOD/BSMNTQQ) 

A visual clue that there was a new navigation method available on some menus (where left/right arrow keys cycle through configured item) was needed. This seems to work nicely.

Passing either WIN_LEFTKEY or WIN_RIGHTKEY in the window "mode" argument enables this new indicator in the upper right of "list" windows. These indicator arrows are mouse-clickable too (translate to the left and right arrow keys).

We had defined uses for all 32 available WIN_* mode bits, so I extended the win mode type from 32 to 64 bits (should this now be called uifc64.c?) :-)

Anyway, it'll be easier to add more WIN_* mode flags as needed later, but I do wonder about JavaScript support (not so great for > 31-bit integers).

Rename len() method to length() to align with std::string.

Note: TEXT_TEXT is actually off-by-one here. I suppose there's no need/use for that value anyway.

Similar to how we can now cycle through the file areas and message areas using left and right arrow keys, do the same for external "online" program sections and program (door) configurations.

/usr/include/c++/v1/iterator:1168:87: error: expected unqualified-id
  ...&& traits_type::eq_int_type(__sbuf_->sputc(__c), traits_type::eof()))
                                                                   ^
/src/sbbs3/../xpdev/filewrap.h:124:21: note:

      expanded from macro 'eof'
        #define eof(fd)                         (tell(fd)==filelength(fd))
  

Does this fix the FreeBSD/clang build?

This was necessary to get to build for MSVC2019 and GCC 8.3.0