Excuses, excuses. See SourceForge for an updated version of the previously posted patch; I neglected to add the new rfcsize arguments to the sort call, and something else gone wrong read_header(). Valgrinding as we speak!
Aaron "Aaron Stone" <[EMAIL PROTECTED]> said: > Now I remember! I continued fixing a bug or two in the 2.0rc2-fixes-snap1 > tree after I'd made the patches from it. But to start clean, I took a fresh > 2.0rc2, applied the patches, and then started working towards the next set > of patches... apparently without bringing this bugfix into the new tree :-\ > > I read over the rest of the diff to make sure that I didn't leave anything > else out, and this does seem to be the only thing I missed. > > Apply the attached patch, *reversed* (because I really need sleep :-P) > > Aaron > > > ""Aaron Stone"" <[EMAIL PROTECTED]> said: > > > Oh, weird. I really did fix that already; I'll see if maybe I fixed it in an > > older tree by accident. Will post a patch this afternoon. > > > > Aaron > > > > > > Ilja Booij <[EMAIL PROTECTED]> said: > > > > > I've applied the patch (have not updated CVS yet). > > > > > > I ran into the following problem: > > > When delivering a message, all message go into the mailbox of user_idnr > > > 0 (that is: zero). > > > > > > The problem seems to be, that the user_idnrs to deliver the messages to > > > are kept in delivery->userids (in a list), but that this list is never > > > used when attempting delivery. The delivery->userids field is not used > > > when calling sort_and_deliver(). In that call, only delivery->useridnr > > > is used, which defaults to zero. > > > > > > Ilja > > > > > > Aaron Stone wrote: > > > > > > > Here it goes... I'll also post to SourceForge. > > > > > > > > Aaron > > > > > > > > > > > > Ilja Booij <[EMAIL PROTECTED]> said: > > > > > > > > > > > >>HEAD is completely updated. I'm having some trouble updating > > > >>dbmail_2_0_branch, due to conflicts when applying patches. I guess I'll > > > >>wait with updating that branch. Or, like somebody suggested a while > > > >>ago, > > > >>do the branching on release of 2.0 final (and abandon the current > > > >>branch > > > >>for now). > > > >> > > > >>Good luck finishing your project :) > > > >> > > > >>Ilja > > > >>Aaron Stone wrote: > > > >> > > > >> > > > >>>If you have CVS updated to your latest working tree I'll patch against > > > >>>it > > in a > > > >>>few hours. This moment I have to finish up a project before daybreak. > > > >>> > > > >>>Aaron > > > >>> > > > >>> > > > >>>Ilja Booij <[EMAIL PROTECTED]> said: > > > >>> > > > >>> > > > >>> > > > >>>>Just tried this for myself. A lot of warnings.. > > > >>>> > > > >>>>I guess the cleaned up statements are in the patches you'll send me > > > >>>>today? ;) > > > >>>> > > > >>>>I agree we should keep the __attribute__ thing in the source. It does > > > >>>>not cost us anything, and it helps preventing bugs. Sounds like free > > > >>>>lunch to me! :) > > > >>>> > > > >>>>Ilja > > > >>>> > > > >>>>Aaron Stone wrote: > > > >>>> > > > >>>> > > > >>>> > > > >>>>>Well that was fun! I also caught three or four more of the missing comma > > > >>>>>errors, and a handful of "%s, %s: ...." formats that were missing the > > > >>>>>__FILE__, __FUNCTION arguments. > > > >>>>> > > > >>>>>I cleaned up all of the warnings, though we should definitely keep > the GNU > > > >>>>>attribute in the source to warn against format bugs in the future. > > > >>>>> > > > >>>>>Aaron > > > >>>>> > > > >>>>> > > > >>>>>"Aaron Stone" <[EMAIL PROTECTED]> said: > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>I found the GNU extension to turn on pritnf style format checking! > > > >>>>>>In > > > > > > > > debug.h, > > > > > > > >>>>>>make this your declaration of trace(): > > > >>>>>> > > > >>>>>>void trace(int level, char *formatstring, ...) > > > >>>>>> __attribute__((format(printf, 2, 3))); > > > >>>>>> > > > >>>>>>Voila, tons of errors next time you make. > > > >>>>>> > > > >>>>>>Aaron > > > >>>>> > > > >>>>> > > > >>>>_______________________________________________ > > > >>>>Dbmail-dev mailing list > > > >>>>Dbmail-dev@dbmail.org > > > >>>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > >>>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>_______________________________________________ > > > >>Dbmail-dev mailing list > > > >>Dbmail-dev@dbmail.org > > > >>http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > >> > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Dbmail-dev mailing list > > > Dbmail-dev@dbmail.org > > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > > > > > > > > -- > > > > > > > > _______________________________________________ > > Dbmail-dev mailing list > > Dbmail-dev@dbmail.org > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > > > -- > > > > > --
