Re: Maybe too strict check for frontend/backend name conflicts

On Fri, Nov 02, 2007 at 11:43:23AM +0100, Krzysztof Oledzki wrote:
> >Take a look at how I managed to pass the error messages in return from
> >dumpstats.c,
> OK, found it.
>
> >or even in backend.c (backend_parse_balance, in latest master-git).
> There is no backend_parse_balance. :( Checked both
> 0e21b201e6892c25e8264e43ceb12fed6d0c5e82 (1.3.13) and
> 85130941e7ba66656e302a68a211c3834d7d5a93 (master).

Grrr. I was 100% sure I had pushed to the web tree, and obviously I was wrong, only 1.3.13 was updated. It's now updated master too.

> >I've not found the perfect interface to all parsing functions yet, but
> >I'm sure we'll soon have something standard for use with all
> >sub-components.
> >
> >It will also greatly improve error messages report since each level can
> >complete the message with more information, and the last level can put
> >the line number which we don't always have. I'll have to update ACLs to
> >use the same interface so that we can at last get human-readable error
> >messages for incorrectly written ACLs.
>
> How about adding a global "char errstr[BUFSIZE]"? Each function can then
> easily return a appropriate error message. No need to pass additional
> buffers and lengths.

That's what I thought about first, then I realized that it would not be convenient for intermediate functions to prefix the error messages with their part of context. For instance, such a message could be completed by 4 different levels :

"Proxy xxx: rule yyy: acl zzz requires HTTP mode"

                              <--- level 4 ---->
                      <------- level 3 -------->
            <------------ level 2 ------------->
 <------------------ level 1 ------------------>

So in certain circumstances, the error message will be on the caller's stack.

Best regards,
Willy Received on 2007/11/02 23:11