On Tue, Feb 11, 2003, John Viega wrote:
> Yes, we're still trying to figure out the mechanism via which we want
> to handle such things. The big problem with returning error codes,
> etc. is that there's a strong tendency to ignore results than indicate
> an error.
Yes, you should not care about this issue. It's not your fault,
if the programmer, that has this tendency, should waste his time
in a more productive way.
> When potentially security-critical problems come up, I would rather
> just see the program die if there's any significant chance of the
> programmer failing to check the error condition and leaving the program
> in an insecure state.
But this limits the library functionality, if for example do I wish use
your library in my Perl/Python/PHP wrapper?
> We are leaning toward providing a callback for when a "fatal" error
> occurs. The default will be to print an error message and abort. This
> solution gives the programmer some flexibility, and even avoids
> needlessly adding a bunch of additional error conditions to check. On
> the down side, it can be difficult to figure out the exact context of
> failure and recover gracefully.
Or in a more simple way (even if it's not smart):
typedef struct error_c
{
unsigned int type; /* type of error*/
char *function;
} error_ctx;
and pass it towards functions (ie.):
char *function_1(const char *someinput, error_ctx *error);
so the programmer can check it, ie:
error_ctx error;
char *result;
result = function_1("goofyski",&error);
if (error.type==ILLEGAL_STRING)
{
fprintf(stderr,"Insecure string");
exit(1);
}
Cheers,
deneb.
This archive was generated by hypermail 2b30 : Tue Feb 11 2003 - 09:08:33 PST