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

BL>   Then what's the point of checking if it's already too late? ROFL! 

If fclose() fails, you can report an error to the user.  Or
if you had been writing data to a new file, with the intention
of deleting the original, and then renaming this one, you 
could then report the error and NOT delete the original.  So
long as you check the return from fclose(), it's all possible.
When did you last check?

PE> The file names can be of any format, 72 characters of anything.

BL>   Not if you expect it to do a FREQ it can't.

Using which mailer standard?

BL>   You described the ^a control lines in detail. Why is this any
BL> different?

The ^a lines are designed for a mailprocessor to process, which
is what this documents.  Not the mailer.

BL> I've always thought it would be better for *one* person to
BL> write the standard. They are usually written in committee, and
BL> they sort-of wander a bit.

PE> The best argument against this "committee never works" theory
PE> is the ANSI C standard. It's faultless.

BL>   Either faultless, or you have not found the faults, yet.

Or so few faults that it is faultless for all practical purposes.
BFN.  Paul.
@EOT:

---