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...
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.
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:
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.--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi
I'm not sure whether it's really a bug.
The following sample code will emit a parse error.
<?php
if(true){
//echo '<?php date('Y-m-d H:i:s'); ?>';
echo 'afafa';
}
?>
The parser treate the PHP tag within the commented line as a normal tag .
The scanner is looking for \r \n % if ASP tags are enabled or ?> before it marks the end of the comment.
Take the following
<?php
echo 'PHP';
// echo $moo; ?> 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.
<?php
if(true){
//echo '<?php date('Y-m-d H:i:s'); ?>';
echo 'afafa';
}
?>The parser treate the PHP tag within the commented line as a normal tag .
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':
<?php
if(true){
/* echo '<?php date('Y-m-d H:i:s'); ?>'; */
echo 'afafa';
}
?>
-j
Yeah because /* */ has a clear end where // and # doesn't.
- S
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':<?php
if(true){
/* echo '<?php date('Y-m-d H:i:s'); ?>'; */
echo 'afafa';
}
?>-j
"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
<h1><?php //some comment ?></h1>"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.
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