On Sat, 5 Apr 2003, Caskey Dickson wrote: >Andreas, >Is the parser in imap/recursivedecent written by hand or generated using >a parser/generator like bison/lex? The reason I ask is that I was >working on a patch for the IO problem and I think that some of the >strangeness when doing large uploads of messages can be traced to >coercion of signed characters and ints going back and forth in the IO >subsystem.
The parser is hand written - there are some generic functions in librecursivedescent, but most of the work is done by the individual operators. They all implement their own parse routines for the commands they serve. >Since IO::readChar reliably throws InputException on EOF, we don't need >to return magic numbers and I'm changing it to return type to char from >int. I've been pushing that change through the code base and got to the >parser and didn't want to make the fix to the wrong place. >So, is the code there stuff that should be changed, or should I make >changes elsewhere? You'd just have to find all calls to readChar and see if the conversion to returning char is safe everywhere. Note that in SSLEnabledIO, readChar can return non-char values because of renegotiation (wonder how imap-front handles this), in which case a new call to readChar must be made. This is done in authenticate.cc when SSL data is tunneled, asynchronously. Since readChar's semantics apart from that are "get a character, or catch an EOF inputException", I guess that -2 value should trigger an exception too. But have you managed to reproduce the problem? ;) Andy -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | Nil desperandum
