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

[Mark Hammond]

> > The only reason I didn't go that way was that I was
> > concerned about the "footprint" of the patch and trying
> > not to touch the non-windows code where
> > possible.  I'm happy to help move this to
> > a better solution though.
>
> Actually, I think we can touch less generic code and get a better
> result!
>
> In xapian-core we always use '#include "safeerrno.h"' instead of
> '#include <errno.h>', so we can hook in there, something like this:
...
> And then xapian_win32_formaterror() can be defined in a win32 specific
> source file (looking at it, I think it will need a static
> buffer, which makes inlining it from a header awkward).

Yeah, trying to return a 'char *' is a bit of a problem.  A static buffer is
also awkward in the face of threads.  The FormatMessage() API can allocate
memory for you, but the 'char *' return makes freeing the memory difficult.


> The stuff in the inlined wrapper above is arbitrary of course
> - perhaps
> it's best to just forward all calls by replacing the inlined wrapper
> with a prototype for xapian_win32_strerror(), and then defining
> xapian_win32_strerror() in the extra source file.

It is a little painful :(  FormatMessage() works for win32 defined error
codes.  errno values are frustratingly similar, but not exactly the same
(and obviously the win32 set is much larger).  This means that in general,
you can't use FormatMessage with a value obtained from errno (or the crt in
general) - only with a value from the API.  Similarly, using strerror() on
an API error code might not give the correct results, even for low error
values.

Then we have sockets.  Although some of the winsock API tries to look like
posix, it does not use the crt errno at all.  All error results come from
WSAGetLastError() - and as a result FormatMessage() must always be used.
I've no idea what mingw does with this.

So the best I can come up with is a couple of utility functions (possibly
static methods in a utility class) that promises to do nothing more than
"get last socket error", and "format this socket error code".  The latter
could use std::string to hide the memory allocation needed on windows.  It
still doesn't seem to pass the "small footprint" test though :)

Cheers,

Mark