Quoting Ken Murchison ([EMAIL PROTECTED]): > John Capo wrote: > >Quoting Ken Murchison ([EMAIL PROTECTED]): > >>Ken Murchison wrote: > >>>Obviously, the chances of header_size being 0xdeadbeef is remote, but it > >>>is possible. Would it make more sense to use ULONG_MAX as the "failure > >>>size"? > >>Or better yet, how about just using 0 (zero)? IIRC, RFC2822 stipulates > >>that the message header has to be non-zero (Date and From are mandatory) > > > >I have seen zero size messages created with IMAP uploads from desktop > >clients. This is probably a bug elsewhere. I do not know if the > >zero size messages were replicated. > > > >Sending more than one magic number would be the safest way. The > >value of the second magic number could be used to signal other > >conditions if needed. I can't imagine what that would be other > >than aborting the upload. Two ULONG_MAX is a row can't be a valid > >message. > > After thinking about this some more,do we even need a magic number? If > we don't send anything after the flags list, shouldn't this be enough to > signal that we have an invalid/missing message?
We still need to see what's next in the stream if anything. When upload_message_work() returns due to not being able to open a message, the next byte in the stream should be the first letter of a command. Testing the next character returned by prot_getc() for alpha or numeric could signal an abort. If its alpha then its the next command. If its numeric then its the header size. prot_ungetc() the character and return or fetch the header size from the stream and continue. If the connection is closed prot_getc() would return EOF and cmd_upload() would return to cmd_loop(). cmd_loop() would also see EOF since its a flag in the prot structure. Not sure how to test the EOF case. I'll see if the basic idea works later today. John Capo > > -- > Kenneth Murchison > Systems Programmer > Project Cyrus Developer/Maintainer > Carnegie Mellon University