File and line numbers in error messages

[Ken Raeburn]

On Apr 28, 2009, at 15:37, ghudson at MIT.EDU wrote:
> We had a request from within the MIT krb5 team to optionally include
> file and line numbers in error messages.

Yay!

>  This is fairly easy to do
> with a macro like (relies on a gcc-ism):
>
> #define krb5_set_error_message(ctx, code, fmt, ...) \
>  krb5_set_error_message_fl(ctx, code, __FILE__, __LINE__, fmt, ##  
> __VA_ARGS__)

Even without the gcc bits, if you have C99 support it's doable.  I  
don't know what you'd do for Windows though, where we're stuck with  
VS2003.  I guess you could have it permanently disabled there, along  
with pre-C99 non-GCC platforms.

> kinit: get_in_tkt.c: 1503: Client 'blah at ATHENA.MIT.EDU' not found in  
> Kerberos database while getting initial credentials

It's nitpicky, but I think I'd rather see "(get_in_tkt.c:1503)" added  
at the end.

> We don't want this enabled in production builds; it's not the kind of
> error message you want end users to see on a day-to-day basis and it
> adds a lot of static strings to the library object files.  So we need
> some kind of compile-time flag, either specified through a make-time
> option ("make CPPFLAGS=-DBLAH") or a configure-time option
> ("./configure --enable-blah").

I'd think for many UNIX builds you'd actually want the capability  
compiled in, but turned off by default.  Then when someone reports  
"Waah, my program reports 'generic Kerberos error' using the Kerberos  
packaged with OpenDebHatBuntuKnopp 4.7, what's it mean?" and we don't  
know, we can say, "set KRB5_HELP_ME_OBI_WAN_KENOBI=1 and run it again"  
and get some useful information out without the user having to  
recompile.

But the krb5_set_error_message calls don't happen in enough places.   
Not only do some places still need updating to call it, but many  
places in the code may have nothing else interesting to report, or  
don't even have a context in which to store the information.  It might  
be helpful to have a simple function that can be called within the  
library to indicate, "hey, I'm generating error code X here", where  
one could set a breakpoint and/or cause it to print the file and line  
number when debugging, and which would do nothing normally.  E.g.,  
change "return KRB5_ERR_FOO" to "return mkerr(KRB5_ERR_FOO)" with  
"#define mkerr(CODE) krb5int_mkerr(CODE,__FILE__,__LINE__)" etc; code  
size may suffer a little, but speed isn't very important in the error  
paths.

> I'm also aware that this feature isn't very useful if no one is really
> aware of it, as seems true of a lot of our debugging features.  I'll
> probably create a "debugging tips" page in our wiki to help advertise
> features like this.

Having written more than one bit of debugging code that's fallen into  
this category, I agree, this is a good idea....

Ken


-- 
Ken Raeburn / raeburn at mit.edu / no longer at MIT Kerberos Consortium