BBS:      TELESC.NET.BR
Assunto:  src/sbbs3/sbbsecho.c sbbs
De:       Rob Swindell (on Windows
Data:     Sat, 31 Jan 2026 20:59:00 -0800
-----------------------------------------------------------
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.
n
---
  mSynchronetn  hgVertrauen n hHome of Synchronet n gh[vert/cvs/bbs].synchro.net

-----------------------------------------------------------
[Voltar]