BL> The "fields" are actually strings, and anyone who used a
BL> 72-byte buffer with no guaranteee that it wouldn't overflow
BL> deserves all he gets. 

PE> No he doesn't. His program is designed to process FTS-1
PE> packets, and it does.

BL>   Are you saying that it's okay to lock the computer if he gets 73
BL> bytes? 

Are you saying it's OK to send non-standard packets to a system?

BL> Strange idea of programming. You have no concept of failsafe.

I do, I just don't always code for it.  When was the last time
you checked the return code from fclose()?  You do realise that
if fclose() fails (on writing) you could actually lose data?

BL> You did not explain how the Subject is used to send a Freq.

PE> 0x0800 - subject specifies name of file to file-request

PE> That's all there is to a FREQ as far as the PKT format is
PE> concerned.

BL>   Not so. How long are the file names? What about multiple files? The
BL> existing FTS-0001 specifies that the filenames may not have the three
BL> separator characters defined. You define nothing. I much prefer the
BL> existing words in FTS-0001. You are supposed to be improving it, not
BL> making it more obscure.

The file names can be of any format, 72 characters of anything.
If you want to know what format an FTS-1 MAIL session will
handle, you'll have to refer to that spec.  If you want to see
what format an FTS-6 MAIL session will handle, see that one.
Ditto for FSC-whatever, FSC-whatever2, etc etc.  There is no
need for the PKT format to dictate that, that is for the
mail protocol to care about.  That's what I reckon anyway.
Same as the File-request bit.  The subject is also a string.  On
my system (when I was running Squish anyway), that subject
string was actually converted into a .REQ file suitable for an
FTS-6 session.  THAT is a purely local issue.

PE> The C standard has footnotes, which are usually
PE> interpretations, and future library directions, and a
PE> rationale.

BL>   Great! There is a trap in this however. You have to be incredibly
BL> careful not to contradict the actual standard. I've always thought it
BL> would be better for *one* person to write the standard. They are
BL> usually written in committee, and they sort-of wander a bit.

The best argument against this "committee never works" theory
is the ANSI C standard.  It's faultless.  BFN.  Paul.
@EOT:

---