[reSIProcate] ParseBuffer::assertNotEof() ?
Jason Fischl
jason at counterpath.com
Wed Oct 25 18:05:51 CDT 2006
Ideally, can you write a test case in testParserCategory that
reproduces the problem and check it in or post to the list.
On 10/25/06, Daniel Pocock <daniel at readytechnology.co.uk> wrote:
>
>
> Jason Fischl wrote:
>
> > On 10/25/06, Daniel Pocock <daniel at readytechnology.co.uk> wrote:
> >
> >>
> >>
> >> Byron Campen wrote:
> >>
> >> > That is not valid syntax, no. However, it would make sense to
> >> > interpret this as the case where there is no tag parameter, and if
> >> > this is something that a TU cannot live with, then it can be rejected
> >> > there. Any objections?
> >> >
> >> I'm still seeing this behaviour in the latest code from SVN.
> >>
> >> Does anyone object if I patch this to allow the tag= nothing syntax, or
> >> is there another preferred solution?
> >
> >
> > How/where are you going to address the issue? I don't think that the
> > parser should be changed to allow tag= syntax but I agree that dum
> > should reject the request.
>
>
> Ok, I'm quite happy to have it reject it - and hopefully log something
> too.
>
> Should assertNotEof() be modified to throw an exception instead of just
> calling assert(0)?
>
> Which exception should be thrown, or should I just create one? Is there
> already a try{} catch{} block to handle this, or does this need to be
> done too?
>
> Unfortunately I've already deleted my core dumps from today - next time
> this happens I'll post a backtrace.
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
More information about the resiprocate-devel
mailing list