Mark Phippard wrote:
>"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
>
It's better for the the server to abort than to corrupt your data. So
the assert should remain enabled, IMHO. Of course, in this case you also
found a bug in either the Eclipse plug-in, or JavaHL, depending on
whether JavaHL documents that its input paths should be canonical or not.
> our compile to remove the assert(). Is this the
>wrong thing to be doing?
>
>
I'd say so, yes.
-- Brane
---------------------------------------------------------------------
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:13:58 2004