Xref: utzoo comp.unix.xenix:1292 comp.sys.att:2025
Path: utzoo!utgpu!water!watmath!clyde!bellcore!decvax!decwrl!labrea!aurora!amelia!ames!amdcad!uport!admin!jmsully
From: jmsully@admin.UUCP (John M. Sully)
Newsgroups: comp.unix.xenix,comp.sys.att
Subject: Re: mailx and big files
Message-ID: <184@admin.UUCP>
Date: 8 Jan 88 19:20:42 GMT
References: <2433@dasys1.UUCP> <1988Jan4.140623.19127@lsuc.uucp>
Reply-To: jmsully@admin.UUCP (John M. Sully)
Organization: Microport Systems, Scotts Valley, CA
Lines: 26

In article <1988Jan4.140623.19127@lsuc.uucp> dave@lsuc.UUCP (David Sherman) writes:
>In article <2433@dasys1.UUCP> samperi@dasys1.UUCP (Dominick Samperi) writes:
>>When I use mailx to send a large text file (about 50K or more) via
>>'mailx user < file', I get error messages of the form "can't append
>>to /usr/mail/user" and "can't write to dead.letter", yet it turns out
[...]
>Sure.  You're using a 16-bit machine, and the value for the number
>of bytes written is stored in a regular (short) "int" variable.  Once this
>tops 32767, it goes negative.  The code which tests for success of
>the write assumes that "n<0" means failure (normally -1 is returned
>on failure of a system call), so it tells you the write failed when
>in fact it worked fine.

What was actually going on here was that the length of the message to be
written to the specified file was held in a long, but the loop counter for
the loop which wrote the characters was an int.  When the message length
was greater than 32767 the int went negative and, since the test was for
i<k the writes continued successfully, but eventually the read returned
EOF before the loop terminated.  This caused an error flag to be set and
blooey! your message was sent, but mail didn't know it.

Dominick, we now have a fix for this available on the BBS in the support286
section.

John M. Sully
Microport Systems