[Xapian-devel] Re: [Xapian-commits] 7990: trunk/xapian-core/trunk/xapian-core/bin/ trunk/xapian-core/tests/harness/

[Mark Hammond]

Richard writes:

> Olly Betts wrote:
> > Looking at the winsock.h header in mingw, the "WSA" error
> > codes are all
> > at least 10000.  So it would be easy enough to decode real
> > errno values
> > with strerror() while handling the other values with something else.
> >
> > If you're talking about sticking error codes which collide
> > with errno
> > values in the "errno" field of Xapian::Error objects, that
> > way madness
> > surely lies!  Catchers of Xapian::Error (not unreasonably)
> > expect to be
> > able to decode the errno field with strerror().  And
> > strerror() would
> > give an entirely irrelevant message if we start sticking
> > other integer
> > error codes there with overlapping ranges.
>
> Certainly, overlapping ranges would be a mistake...  I
> assumed that all
> WSA error codes were non-overlapping with errno codes, but if
> this isn't
> the case I think the best approach would be as Olly suggests to check
> for values less than 10000 returned by socket_errno() and just append
> the formatted message to the error message held in the exception for
> these (I think messing around with translating error codes
> would just be
> a painful waste of time).

I think my point got a little lost.  Note that as soon as you check a value
for 10000, you are implicitly assuming the value could have come from a
socket related function - but if the value did come from a socket related
function, you can not pass it to strerror() *regardless* of the error value.
If a socket function ever returned a low valued error, the potential exists
that it is one of the non-overlapping values.

For example, if a future OS from MS decided to lock down sockets a little
more, and needed to return an "access denied" error code, it would return
ERROR_ACCESS_DENIED (5) instead of EACCES (13).  If it had to return "file
not found" (unlikely, but...), it would return ERROR_FILE_NOT_FOUND (2),
which happily matches up with ENOENT.

However, I think it is largely a theoretical problem.  I'm not aware of
socket related functions returning error codes other than those > 10000.  As
a result, I think a solution lies in having a system that could deal with
this situation in the future, but happily ignores it for the time being,
other than in comments.

> Would it be a good idea, though, to add a method to the base
> Xapian::Error class which decoded error codes, and returned a string.
> On unix platforms, this would just be a wrapper around
> strerror(), but
> on windows it could call whatever is appropriate (and not
> have to worry
> about freeing memory).  The codes must still be unique, though.

That sounds like a reasonable approach.  Another alternative might be to
make this new method virtual, and have NetworkError provide its own
implementation.  Indeed, it might make sense to have NetworkError *always*
call FormatMessage() on Windows, but Error itself stick with strerror (and
possibly even Assert it never sees a winsock error).

> Incidentally, I've now finished merging Mark's patches into HEAD, so
> remote databases should now work on windows... Unless I've mucked
> something up of course, which I probably have.  However,
> we're certainly pretty close now!

Thanks very much Richard!

Mark