[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [azverkan@yahoo.com: Joe Orton please read: Overrrun a neon buffer size during svn merge URL URL]

From: Joe Orton <joe_at_manyfish.co.uk>
Date: 2002-12-23 01:39:09 CET

On Sun, Dec 22, 2002 at 10:43:02PM +0100, Branko Čibej wrote:
> Joe Orton wrote:
> >On Sun, Dec 22, 2002 at 06:34:15PM +0100, Branko Čibej wrote:
> >>Judjung by the Windows Socket API docs, /nont/ of the socket functions
> >>use errno on Windows. There's a (non-standard, of course) function that
> >>returns the latest error code. Do you think this would work?
> >>
> >>#ifdef WIN32
> >>#define NEON_SOCK_ERRNO() errno
> >>#else
> >>#define NEON_SOCK_ERRNO() WSAGetLastError()
> >>#endif
> >>
> >>Then use that macro wherever errno is being checked after a socket call.
> >
> >OK - a few questions: can the return value from WSAGetLastError() be
> >passed to strerror() to get useful error strings,
> >
> Hmm, don't know. I can test it, though. Let's see... Nope, it's in a
> different error space, which implies...
>
> > and compared with
> >ECONNRESET to detect a connection reset?
> >
> ...that you can't do that, etither.
>
> >Is select() one of the functions which doesn't use errno on Win32?
> >
> Oh, yes. It looks like none of them does.
>
> Do I suspect correctly that Neon needs a bit of abstraction for sockets,
> at least for error handling?

The code in question is all inside neon's socket abstraction,
ne_socket.[ch] - only read_raw/write_raw/readable_raw should need
changing, it should be pretty clear what needs to be done.

e.g. for read_raw, if the recv() fails, return NE_SOCK_RESET if the
connection has been reset, or NE_SOCK_ERROR otherwise; either way, copy
an error string into the sock->error buffer.

Regards,

joe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 23 01:39:43 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.