"Peter N. Lundblad" <peter@famlundblad.se> wrote on 11/09/2004 04:03:48
PM:
> On Tue, 9 Nov 2004, [UTF-8] Branko ?^Libej wrote:
>
> > Julian Foad wrote:
> >
> > And I disagree with the idea that a "debug" version of the code do
more
> > checking than a "release" version, except where it really does check
> > "can't happen" conditions. But even then I'm sceptical, although I
have
> > put asserts here and there in our code.
> >
> I aggree. Therefore, I don't define NDEBUG even for non-debug builds. I
> never understood why that's the default on some Windows build systems.
I just ran into this issue in our port of Subversion to OS/400, because we
were not defining NDEBUG when we compiled, so we had the assert's in our
code.
I was testing our port of svnserve, and was using Subclipse (which uses
JavaHL) from Windows. When I take the option to checkout a project,
Subclipse sends a list command to the server with a trailing slash on the
end of the path name. On the server, the request would get into
svn_path_remove_component which does this as its first line.
assert (is_canonical (path->data, path->len));
The assert fails because of the trailing slash and the server aborts. A
Windows debug build of svnserve does the same thing.
So where does this problem lie? Subclipse shouldn't be sending this
request, but apparently the JavaHL layer lets it. It doesn't seem like a
server ought to abort over something like this, but I do not want to
damage my repository either. In researching this, we realized that we
need to define NDEBUG on our compile to remove the assert(). Is this the
wrong thing to be doing?
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 9 22:06:19 2004