https://gitlab.synchro.net/main/sbbs/-/commit/96b077d3cc75e4bdc13b6bf4
Modified Files:
src/sbbs3/sbbsecho.c sbbsecho.h
Log Message:
Treat the *last* (not first) tear line as the divider between body and tail
I was reading some echomail and noticed a message that wasn't word-wrapped.
I thought that was odd, so I looked at the (SMB) header of the message and
it indicated that the *entire* message was the *tail* of the message (it had no body text):
data_field[0] TEXT_TAIL, offset 0, length 641
Looking at the message itself made it obvious to me what had happened: the original message started with a sort of quote indicator, like this (but with no indentation):
--- Original Message ---
SBBSecho saw that leading "--- " as a tear line and imported the remainder of the message text as the message tail. Message tails are not word-wrapped when displayed in SBBS, which was my initial clue that something was amiss.
Now when adding the parsing of the "last" tear line to fmsgtosmsg(), I noticed that there was some handling of the possibility of linefeeds in the imported message text. That was going to complicate my "next" tear line parsing (I'd have to search for all permuations with both CR and CRLF). But that got me wondering: why is getfmsg() returning a buffer with linefeeds in it?
(they're supposed to be ignored, per FidoNet's oldest standard, FTS-1)
So when looking at getfmsg(), I decided I could both add the linefeed ignore/ strip there and improve it as well: getfmsg() no longer reads and seeks and reads again. The logic is now simplier and there's less file I/O (it's a stream so likely it was just dealing with memory anyway), but I thought it best to mostly rewrite getfmsg(). Now everywhere getfmsg() is used in SBBSecho doesn't need to be concerned with the possibility of there being LFs in the message text: there cannot be.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net