FreeTDS Development Group

[Marc Abramowitz <msabramo AT gmail.com>]

That makes sense.

OK, I took another stab at creating a louder notification when the
encryption setting is incorrect:

*https://gitorious.org/freetds/freetds/merge_requests/16* ("Improve
handling of invalid encryption setting")

The goal here is to make it much more noticeable when there is an invalid
encryption setting. I do this by:

   - calling tdserror with a new error code (TDSECONF = 20214 = "Local
   configuration error")
   - print a message to stderr in case in case someone is looking there
   - exiting the process if the ENABLE_EXIT_ON_INVALID_CONFIG is defined
   (defined by passing --enable-exit-on-invalid-config to./configure).



On Sat, Oct 19, 2013 at 11:49 AM, James K. Lowden <jklowden AT freetds.org>wrote:

> On Sat, 19 Oct 2013 09:48:12 -0700
> Marc Abramowitz <msabramo AT gmail.com> wrote:
>
> > >> Merge request to make an invalid encryption setting a fatal error:
> > >> https://gitorious.org/freetds/freetds/merge_requests/10
> > >
> > > Ouch indeed.  I think the next release of FreeTDS should probably
> > > reject all incorrect configurations, both invalid keywords and
> > > out-of-range values.  Diagnosing configuration errors is easier if
> > > the error is obvious, and the remedy is simple.
> >
> > Freddy pointed out that my merge request wasn't acceptable because
> > printing to stderr and exit aren't appropriate for a library.
> ...
> > Is there some middle ground - some way of indicating a config error
> > (esp. a serious config error like an invalid encryption setting) that
> > is very noticeable but doesn't overstep what a library should do?
>
> The Right Way is to hook into the error handler.  Add something like
> this to the table in sybdb.h:
>
> #define SYBECONF         2501   /* local configuration error */
>
> and to the dblib.c::dblib_error_messages table
>
> and invoke that error with tdserror or dbperror.
>
> It's not obvious to me that printing to standard error and exiting is
> all that bad, though.
>
> In general, there are two kinds of errors:
>
> 1.  logic errors, caused by the programmer getting something wrong.
> Examples include off-by-one errors and failure to check for a NULL
> pointer.  These kinds of problems can and do cause the library to
> exit via  e.g. assert(3).  There is no point in continuing, because the
> program has reached an "impossible" state that the program did not
> anticipate and thus cannot handle.
>
> 2.  runtime errors, caused by invalid user input or dynamic failures
> such as network disconnection or the server not responding.  These
> should always return an error to the user, who is the only person in a
> position to deal with it.
>
> Is an invalid configuration a logic or runtime error?  is the
> administrator a programmer or a user?
>
> I would say the configuration file is more like program text.  It is
> static data isolated from the program in such a way that it can be
> modified without requiring recompilation.  The very first time it is
> read -- compiled, if you will -- it will be validated.  If it is
> invalid, the library exits.  Once the configuration is valid, no amount
> of other invalid input will cause it to become invalid.
>
> Printing to stderr is unfortunately not robust, because some
> applications will not have that descriptor open.  Invoking the error
> handler is is more general, but will go unseen if the application
> doesn't install and error handler. On the other hand, the problem can be
> instantantly diagnosed by using any command-line tool such as tsql.
>
> So, IMO printing to stderr and exiting is fine, and invoking the error
> handler is in some ways friendlier (perhaps in addition to writing to
> stderr).  Exiting is OK, too, even if it does force the admin to clean
> up errors that might otherwise be innocuous.
>
> HTH.
>
> --jkl
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>