# LDAP bug - Thread: https://externals.io/message/49008 - Original archive: https://news-web.php.net/php.internals/49008 - Started by Richard Lynch on 2010-07-07T15:38:53+00:00 - Messages: 9 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #49008 — Richard Lynch — 2010-07-07T15:38:53+00:00 URL: https://externals.io/message/49008#49008 If anybody with LDAP extension experience could take a look at this, I'd sure appreciate it: http://bugs.php.net/bug.php?id=52266 I'm working on getting an environment where I can compile from source and reproduce and trace through C with a bunch of printf statements, but I suspect that's going to be a long-term effort, given current commitments... --- ## #49009 — Grant Croker — 2010-07-07T16:25:04+00:00 URL: https://externals.io/message/49008#49009 · In reply to: #49008 > If anybody with LDAP extension experience could take a look at this, > I'd sure appreciate it: > > http://bugs.php.net/bug.php?id=52266 > > I'm working on getting an environment where I can compile from source > and reproduce and trace through C with a bunch of printf statements, > but I suspect that's going to be a long-term effort, given current > commitments... > Hi Richard, According to the contributed notes in http://www.php.net/manual/en/function.ldap-search.php, LDAP_OPT_REFERRALS should be set to 0 and not 2 as you have in your test case. When set to 0 I don't see the "Operations Error" message. I also have it set this way to enable search in AD for a rudimentary phonebook. regards grant -- Grant Croker, Ingres Corp Ingres PHP and Ruby maintainer http://planetingres.org The seat received him in a loose and distant kind of way, like an aunt who disapproves of the last fifteen years of your life and will therefore furnish you with a basic sherry, but refuses to catch your eye. --- ## #49010 — Pierre Joye — 2010-07-07T20:51:48+00:00 URL: https://externals.io/message/49008#49010 · In reply to: #49009 hi, Please add the comments to the bug report. So we can see it while reading the status of this issue (which seems to do not be one). >  On 07/07/10 17:38, Richard Lynch wrote: > > […] > > Hi Richard, > > According to the contributed notes in > http://www.php.net/manual/en/function.ldap-search.php, LDAP_OPT_REFERRALS > should be set to 0 and not 2 as you have in your test case. When set to 0 I > don't see the "Operations Error" message. I also have it set this way to > enable search in AD for a rudimentary phonebook. > > regards > > grant > > -- > Grant Croker, Ingres Corp > Ingres PHP and Ruby maintainer > http://planetingres.org > The seat received him in a loose and distant kind of way, like an aunt > who disapproves of the last fifteen years of your life and will > therefore furnish you with a basic sherry, but refuses to catch your > eye. > > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #49011 — Shijiang — 2010-07-08T02:26:03+00:00 URL: https://externals.io/message/49008#49011 · In reply to: #49010 Hi I'm not sure whether it's really a bug. The following sample code will emit a parse error. '; echo 'afafa'; } ?> The parser treate the PHP tag within the commented line as a normal tag . --- ## #49012 — Scott MacVicar — 2010-07-08T03:18:30+00:00 URL: https://externals.io/message/49008#49012 · In reply to: #49011 The scanner is looking for \r \n % if ASP tags are enabled or ?> before it marks the end of the comment. Take the following I am HTML, hear me roar! Parsing ends with ?> regardless if its a comment or not but its not context sensitive. It can't understand that its within a string. - S > Hi > I'm not sure whether it's really a bug. > The following sample code will emit a parse error. > if(true){ > //echo ''; > echo 'afafa'; > } > ?> > > The parser treate the PHP tag within the commented line as a normal tag . --- ## #49013 — jvlad — 2010-07-08T19:50:58+00:00 URL: https://externals.io/message/49008#49013 · In reply to: #49012 > Parsing ends with ?> regardless if its a comment or not but its not > context sensitive. It can't understand that its within a string. > > - S Not exactly, it's only // comment style does not comment the tag while /* */ does. The following script outputs its 'afafa': '; */ echo 'afafa'; } ?> -j --- ## #49014 — Scott MacVicar — 2010-07-08T20:12:49+00:00 URL: https://externals.io/message/49008#49014 · In reply to: #49013 Yeah because /* */ has a clear end where // and # doesn't. - S > > […] > > Not exactly, it's only // comment style does not comment the tag while /* */ > does. > The following script outputs its 'afafa': > > if(true){ > /* echo ''; */ > echo 'afafa'; > } > ?> > > -j --- ## #49015 — jvlad — 2010-07-08T20:49:19+00:00 URL: https://externals.io/message/49008#49015 · In reply to: #49014 >"Scott MacVicar" wrote: >Yeah because /* */ has a clear end where // and # doesn't. > >- S Shouldn't the end of the line be always considered as a true end of the one-line comment? In other words, I think it always has a clear end too. Similarly, lexer always regognizes the strings - their start and the end so it could ignore the tags in them too. Seems the only problem is BC that shouln't be broken. At least not before v6. -j --- ## #49016 — johannes@schlueters.de — 2010-07-08T23:00:55+00:00 URL: https://externals.io/message/49008#49016 · In reply to: #49015 > > […] > > > Shouldn't the end of the line be always considered as a true end of the > one-line comment? > In other words, I think it always has a clear end too. > Similarly, lexer always regognizes the strings - their start and the end so > it could ignore the tags in them too. > Seems the only problem is BC that shouln't be broken. At least not before > v6.

is an absolutely valid reason to use single line comments which end at ?>. I don't think there is a strong enough arguement to change that part of the syntax in any release. Yes it might be confusing some times but it is well defined and established. johannes > -j