Re: [PATCH] a little step in issue 897: non-recursivesvn_handle_error()

Apologies all.

I just noticed that while I was playing around with a few other things, I
managed to set a flag in my compile environment that put gcc into C99 mode.

When I retried compiling the patch my proposed patch, I noticed the problem.

Am now rerrunning compile/regression tests on my Mandrake RPMs all the way
back to 0.29.0. No error so far, but it never hurts to be sure.

There should not have been a declaration in the for statement - not ANSI C.

I apologize for the oversight.

Correction attached. :)

Any other comments, feel free to let me know. :) :) :) :)

-- 
Shamim Islam
BA BS
Files said:
> I noticed a bug in the last posting.  (there was an == instead of an !=).
>
> What's w/ this "print_message" parameter though. That's really not it's role.
> It's role is "new_message", no? :) :) :) :)
>
> The outside world should know nothing of the choices made inside the black
> box. It should only supply the information.
>
> The black box should decide what to do when it sees a new message. :) :) :)
>
> Also, I disagree w/ the fatal trigger to abort being in the secondary
> function. The secondary function really isn't *handling* anything. It's focus
> should be printing.
>
> Why the static function that "prints" error messages is called "handle_error"
> is beyond me. I've called it "print_error". It really doesn't
> open/close/finalize anything. Or did I miss that part?
>
> And lastly, I keep thinking that the debug pretty printing should happen in
> the main handler, since it really doesn't make use of the buffers and what
> not, but I think that's 6 of one and half dozen of the other.
>
> I do agree that the functions need to be small. I also agree w/ you Greg that
> the changes need to be idiomatic. Esp. in reference to the use of 'for'.
>
> That being said, here is my proposal. I've attached a bz2 file to preserve
> formatting. If you like, great. If not, it was fun to do. :) :) :) :)
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org