directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Bug?
Date Thu, 01 Jan 1970 00:00:00 GMT
Alex,

> On line 167 of org.apache.ldap.common.name.DnParser is:
>
>                m_parserIn.write( name.getBytes() ) ;
>                m_parserIn.write( '#' ) ;
>                m_parserIn.write( '\n' ) ;
>                m_parserIn.flush() ;
>
> Should that '#' be a control character, perhaps '\r'?

I can't really do that because the value of the last rdn in a dn may have '\r' as a valid
value.    I have to think about this some more and review the latest drafts by ldapbis to
figure this out.  I chose # then \n because it cannot be a valid sequence according to the
E-BNF grammar for a DN.  Usually # is used to escape out hex but that requires two hex characters
after it. 

Just in case you're wondering why I need this sequence ... The parser is designed to be reusable
rather than blowing it away after a single use.  This terminator helps switch the lexical
state of the parser so it is ready to read another DN.  I have to definately find a better
solution to this.

> The problem appears to be that the '#' falls into the antlrTypeLexer lexical error handler
since it isn't a recognized character.

Hmmm but it is in the valuelexer.  Seems to me something might be getting messed up upstream
to cause this problem - we might be in the wrong lexical state hence # is no longer recognized.
 If Mark can post a bug request on this with the specific DN causing it I'll get right on
the problem.  Better yet I'd love to have a simple test case to add to the suite which can
demonstrate where and on what kind of DN we're getting the failure.

Cheers,
Alex



Mime
View raw message