On Thu, Oct 13, 2005 at 11:18:57AM -0400, Mikhail Teterin wrote:
> On Thursday 13 October 2005 03:24 am, Joe Orton wrote:
> = This mixes two separate changes so is hard to review.  A patch to 
> = optionally add support for srandomdev() would be welcome.
> 
> I don't know, how to change configure scripts. My point was not so much
> about srandomdev, as that there is no need to MD5 random data to get
> random data :-)

Well, presume there is a cpp symbol HAVE_SRANDOMDEV which will be 
magically provided, and go from there ;)

> = >   2) patch-md5 -- when already using OpenSSL (almost always), use
> = >      OpenSSL's MD5 implementation, instead of Neon's own. It is, probably,
> = >      more reliable and, sometimes, assembly- and/or hardware-optimized.
> = 
> = This breaks the library ABI so absolutely cannot go in as-is.
> 
> Sorry, if you really cared about compatibility, you would not have
> broken the API compatibility, so that cadaver fails to build :)

neon breaks API/ABI across minor versions.  That patch breaks ABI across 
SSL/non-SSL builds, which is why it's unacceptable.

> As for ABI compatibility, the clients of the library should never
> have used its md5 implementation anyway, should they have?

Yes, it's used by at least one neon-based application (sitecopy).  

> = >   3) patch-tests -- several tests were failing. Please, take a look.
> = >      Some of these are, I'm sure, misguided... The patch also makes the
> = >      certificate-generation (for wildcard* tests) independant from Linux.
> = >      Instead of Linux-only features of hostname(1), it uses much wider 
> spread
> = >      features of modern sh (or bash or ksh) -- and now works on FreeBSD as
> = >      well.
> = 
> = common/child.c: change looks spurious.  why?
> 
> I was hoping, it would make long_line_chunked run quicker. I don't
> think, it helped though :-( Any better way to speed that test up?

Not sure if it's possible without losing the ability to reliably test 
the code.

> = test/request.c: that code triggered a real bug which was fixed recently
> 
> Can we have a patch, please? Or is 0.25.4 going to be out in a few days?

The patch is r729 in the SVN repos 
(http://svn.webdav.org/repos/projects/neon/trunk) - I might be able to 
do a new release that soon, not sure.

> = test/socket.c: the ne_sock_connect_ssl() is only used if SOCKET_SSL
> = is defined, when building socket-ssl -- what was the problem this
> = "fixed"?
> 
> I changed the begin() in the process of investigating the write_reset
> failure in the non-SSL case. It expects reset, but was getting EPIPE
> instead. I had to modify the write_reset() itself...

This is a failure to simulate an RST; it needs more work rather than the 
workaround.  (it's not a regression since 0.24.x, which had the same 
problem in the test suite)

> = test/lock.c: what was the problem? needs further diagnosis.
> 
> Don't know -- the server was closing connection instead of rejecting
> authentication...

Please supply the debug.log and child.log produced from running:

  make check TESTS=lock

> = The hostname munging could probably be rewritten using sed and be
> = really portable.
...

I've committed the changes to use sed and \0NNN literals; thanks.

Regards,

joe
_______________________________________________
neon mailing list
[email protected]
http://mailman.webdav.org/mailman/listinfo/neon

Reply via email to