Re: [PHP-DEV] Php LDAP and LDIF format

[Stig Venaas]

On Thu, Oct 24, 2002 at 06:18:58PM +0200, Alban Médici wrote:
> I need to realize a Php (non web mode) API which will generate some text 
> file in the LDIF format. ( easy to do)
> Then with the same API i would like to charge the text file into the db.
> 
> Is there any Php function exist to command the LDAP DB to load this file 
> like the command line utility "Ldif2db" ???

I'm not aware of such, but why not use tools like Ldif2db, ldapadd,
slapadd etc? Someone might have written something like this in PHP,
perhaps you could ask on the php-general list where this question
belongs? There are also numerous places where you might find PHP
code. Look for links at the PHP site, ask on php-general, or maybe
use google.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: mb_convert_case (Was: Re: #19257 [Bgs]: strtolower & strtoupper does not work for UTF-8 strings)

[Stig Venaas]

On Thu, Sep 26, 2002 at 02:10:04AM +0100, Wez Furlong wrote:
> All:
> 
> I've just committed a php-style version of the ucdata package that Stig
> directed me to.

Great!

> Stig:
> Rather than generate binary data files at configure time, based on
> a bundled UnicodeData.txt file which is quite large, causes problems
> for win32 builds, and has run-time thread safety and data file location
> issues (for freshly built but not installed php binaries), I settled on
> having ucgendat generate a header file with the ctype and case data tables
> declared within it.
> All that is needed is to add these files to the build and voila! it works :-)

Yes, I think that's a good solution. The tables are very stable.
Could you also commit the source for your modified ucgendat? Or is it
there somewhere?

> There are some interesting functions available in the ucdata package; some
> of them might benefit mbstring, so perhaps it is worth a look?

I think Unicode normalization should be useful to people. If you want to
do matching (looking for "equal" Unicode strings), you really need this.
But I haven't really seen anyone ask for this yet. So far I have avoided
this problem since I've been using OpenLDAP to store data, and it does
the necessary normalization and matching for me, if I stored Unicode in
another database... If for instance you use some SQL database, you should
normalize all data before storing it, and also normalize strings in
queries.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: #19257 [Bgs]: strtolower & strtoupper does not work for UTF-8 strings

[Stig Venaas]

On Fri, Sep 13, 2002 at 11:55:50AM +0100, Wez Furlong wrote:
> Where mapping is one of "upper", "lower" or "title" (since unicode
> knows about title case).  This function would then be able to
> internally convert to unicode, apply the appropriate transformation
> and then convert back to the original encoding.
[...]
> Until we make the whole of PHP multi-byte aware, I think mbstring is
> the best place for this functionality.
[...]
> I'm tempted to volunteer for this, if you don't mind supplying that
> unicode manipulation code (I'm fairly familiar with the mbstring
> internals).

Sounds good. The code I have in mind is currently in a library (the
license should not be a problem), and is currently used in OpenLDAP
and also some other applications. It consiste of code to parse the
Unicode tables (that specifies what upper, lower and title of the
different characters are) and create multiple data files, we would
only need case.dat for this. This should be done once. Then there is
code to load the data file, and do the actual case folding. I think
it would be best to distribute the Unicode text file with PHP, build
the comp.dat file on make, and install comp.dat on make install. We
only need to do this when this extension is enabled of course. There
are a lot of other Unicode functions in this library if it's
interesting. I said that I had code, I wrote some of the code, but
most is not mine. I think it makes sense to include just the code we
want in PHP, rather than relying on this library being installed.
See http://crl.nmsu.edu/~mleisher/ucdata.html and the documentation
link near the top.

I can contribute some to this as well perhaps, but it's in good hands
if you do it (:

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] array_unique broken?

[Stig Venaas]

On Tue, Sep 03, 2002 at 11:47:58AM +0300, Andrey Hristov wrote:
> IMO that's good idea to have keys ordered too. All my nightmares with
> array_diff() came from that
> the key order is undefined and I tried all kind of tricks (traversing like
> in a marathon forward and backwards to
> find are there couples [k,v] that are identical).

Note that the sorting in array_unique() is just for internal reasons,
it did until recently determine which key was returned for a value
though. I think for array_diff() and array_intersect() the ordering
should be as in the first argument, current implementations do that.
I don't think any sorting should be done except internally and that
is just to make things efficient. If we need something like
array_diff_associative() etc those should also do sorting internally
for efficiency (I see no other way), and not rely on the unsorted
output from array_diff() etc.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] array_unique broken?

[Stig Venaas]

On Tue, Sep 03, 2002 at 11:21:12AM +0300, Andrey Hristov wrote:
> So the docs are right?
> 
> Note that keys are preserved. array_unique() sorts the values treated as
> string at first, then will keep the first key encountered for every value,
> and ignore all following keys. It does not mean that the key of the first
> related value from the unsorted array will be kept.

They are right for current releases, but what is not said is that it's
not obvious what the order will be after sorting, so it's not really
useful to know that the first key for every value is kept. I would say
that the order now is undefined. I think it will be better with the new
code when there is a defined and concistent ordering, and I would say
it's backwards compatible since previously it wasn't defined.

As Melvyn just said in another post, mergesort would be nice since it's
stable, so I would like to see zend_mergesort() perhaps. It can be better
than qsort on small datasets, and some qsort() implementations use it
when the partition size is small enough. Some platforms have mergesort()
or msort().

In one way it might make sense to use the systems native sorting functions
when available, they are probably faster. OTOH it might lead to different
sorting on different platforms which is why I say that which key for a
value array_unique() keeps is undefined (except for new implementation).
I would expect mergesort functions to always be stable though, so it might
be safe to use native implementations.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-QA] array_unique broken?

[Stig Venaas]

On Tue, Sep 03, 2002 at 11:04:55AM +0300, Andrey Hristov wrote:
> Hi,
> I am not too much in array_unique() but played with array_diff() for a week
> to implement array_diff_assoc() with no success so far but atm I am dreaming
> the code of array_diff. I
> saw that most of the code of array_diff() is in array_intersect() and
> probably in array_unique() (yup it is like them).
> The argument is sorted with zend_qsort() by value and nothing is known for
> the key order in the
> sorted array. Then the array is traversed from the beginning to the end and
> when two or more sequental elements are equal everything starting the second
> equal is wiped (in the result that is returned).

The new code in CVS for array_unique() does actually (or should) always
keep the first element.

This was accidentally the case, at least on some platforms, before
zend_qsort() was introduced because some native qsort() implementations
use mergesort (at least on small datasets) which preserves the order.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] array_diff not working with last element different

[Stig Venaas]

On Tue, Aug 27, 2002 at 05:04:41PM +0300, Andrey Hristov wrote:
> so, is there need of array_adiff()?

Right, it should then work on ordered pairs, right? Only remove
(key, value) pair from 1st array if it exists in any of the others?
Same goes for array_intersect... I'm not sure if there is that much
of a need, but if there is one could either have new associative
ones, or flags to the existing ones. But first we should see if
there is a real need, then we need to see if someone will implent it.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] array_diff not working with last element different

[Stig Venaas]

On Tue, Aug 27, 2002 at 06:39:57AM -0700, Brad LaFountain wrote:
>  $ar = array("b" => 1, "blah" => 1);
> $a1 = array("b" => 1, "blah" => 2);
> var_dump(array_diff($ar, $a1));
> ?>
> array(0) {
> }

I guess this may not be clear from documentation. array_diff() works
with values. So it will return all values from first array that are
not in the others. Since the value 1 is present in $a1, all elements
of value 1 are removed from $ar in the returned array.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] UTF-8 encoding

[Stig Venaas]

On Sun, Aug 25, 2002 at 09:26:29PM +0200, [EMAIL PROTECTED] wrote:
> On Sun, 25 Aug 2002, Stig Venaas wrote:
> 
> > BTW It seems that for some reason I can't post to php-dev anymore,
> > at least some of you get this...
> 
> I was not in the list, but got your message through php-dev.

Thanks for telling me. I posted a few mails a few weeks ago,
that didn't go through... I suppose adding the text above made
it work (:

I'm glad it works now anyway.

Stig

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] UTF-8 encoding

[Stig Venaas]

On Sun, Aug 25, 2002 at 06:28:44PM +0100, Wez Furlong wrote:
> Hi Stefan,
> 
> I borrowed that code from the mbstring extension.  Either I misinterpreted
> the code, or mbstring also has it's utf-8 decoder incorrect.
> 
> --Wez.
> 
> On 08/25/02, "Stefan Esser" <[EMAIL PROTECTED]> wrote:
> > Hello,
> > 
> > html.c / get_next_char() has an utf-8 decoder. The implementation
> > is a little bit fishy. AFAIK utf-8 sequences are 1 upto 4 chars
> > but this one supports 5, 6 byte utf-8 sequences. I wonder
> > where this addition to the standard is defined..
> > The problem is the following: the german ue is 0xFC which is an
> > invalid utf-8 sequence. But the utf-8 decoder would recognise it
> > as the lead byte of a 6 byte utf-8 sequence.

I wonder too, but it would still be recognized (or should, I haven't
checked the code), unless the next 5 bytes all have values between
128 and 192.

BTW It seems that for some reason I can't post to php-dev anymore,
at least some of you get this...

Stig


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [Patch] LDAP Error reporting for 4.2.1

[Stig Venaas]

On Tue, Jun 25, 2002 at 08:13:29PM -0400, Kristofer T. Karas wrote:
> I'm using OpenLDAP 1.x in PHP 4.2.1, and was dismayed that
> $x = @ldap_add(...);
> dumps verbiage to stderr if the add fails, despite the "@".
> 
> Figured it'd be faster to fix it than to whine and complain.
> 
> In fixing, I found some inconsistency in the way errors are reported -
> some with explanations (e.g. a call to ldap_err2string) and some
> without.  I removed the offending ldap_perror calls (which don't honor
> "@", obviously) and augmented the php_error calls.  Patch attached.
> 
> Oh, I couldn't find a FAQ question handy regarding patch submission, so
> I hope I'm not violating etiquette.  At least the patch isn't enormous.
> :-)

Thanks, I'll review your patch more carefully before I apply it, but
it looks good. We should indeed be consistent. Mailing patches to
this list is fine.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] getting images from LDAP

[Stig Venaas]

Hi

On Mon, Jun 24, 2002 at 04:05:19PM -0400, Jennifer Telisky wrote:
> Only thing I can think of, is to somehow store $data out to a file
> data.jpg,  then use this file as the .  Although, I
> can't seem to find a way to do this either.

Write one script that displays the ASCII info and uses img src doing
something like  where
getjpegphoto.php is the script you already wrote to displays jpegs.
To display the right photo you might for instance pass the entry's
dn to the script like I'm hinting above. If you have the dn of the
entry in $dn, you can create the appropriate img src by doing say
echo "";

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] On vacation

[Stig Venaas]

I'm on vacation until June 16th and will not read any mail until I return.
Your mail concerning "Assigned PHP 4 bugs reminder" will be read when I'm back.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] On vacation

[Stig Venaas]

I'm on vacation until June 16th and will not read any mail until I return.
Your mail concerning "Assigned PHP 4 bugs reminder" will be read when I'm back.

PS See http://www.venaas.no/whereami/ for my current location.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] On vacation

[Stig Venaas]

I'm on vacation until June 16th and will not read any mail until I return.
Your mail concerning "Assigned PHP 4 bugs reminder" will be read when I'm back.

PS See http://www.venaas.no/whereami/ for my current location.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] resource problem, advice wanted

[Stig Venaas]

On Fri, May 03, 2002 at 03:34:46PM +0300, Zeev Suraski wrote:
> If ldap_first_entry() relies on the resource that is passed onto it, then 
> it should add a reference count to it, using zend_list_addref().  The 
> resource ldap_first_entry returns should be responsible for this reference, 
> and its destructor should call zend_list_delete().  Then, only when no 
> resources need the resource returned by ldap_read(), it'll be allowed to be 
> freed.

Thanks, I've done that now. If you (or anyone else) have the time, please
review the ldap.c changes I just committed.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] resource problem, advice wanted

[Stig Venaas]

This is a bit involved, I'll try to explain. I'm trying to fix a
problem in the LDAP extension, but not sure how best to do it.

The issue is that code like

$e = ldap_first_entry($ds, ldap_read($ds,$dn,"objectClass=*"));
$a = ldap_get_attributes($ds, $e);

crashes.

What happens is that ldap_read() returns a resource. After
ldap_first_entry() is executed, the resource returned by
ldap_read() is freed because it is not referred any more,
at least it looks that way to the Zend. The destructor for
that resource will free the result obtained by ldap_read().
The problem is that the resource returned by ldap_first_entry()
is simply a pointer inside the data obtained with ldap_read(),
but this has now been freed, so when ldap_get_attributes()
tries to access it, it's already freed. The solution would be
to make sure that the result resource created by ldap_read()
is not freed as long as there exists entry resources created
by ldap_first_entry() etc. Or that the result destructor for
the resource created by ldap_read() does not free it, and
have the entry destructor (created by ldap_first_entry() etc)
free the memory if it is the last entry resource for that
result resource. That would require some additional data
structures and refcounting though. Maybe a Zend variable could
be used and let Zend do the ref counting, perhaps I could
increase the refcount for the result resource each time I
create an entry resource, and decrease it again in the
entry destructor? Anyone got some advice?

BTW, the following code works

$info = ldap_read($ds,$dn,"objectClass=*");
$e = ldap_first_entry($ds, $info);
$a = ldap_get_attributes($ds, $e);

since $info is not freed until the script finishes. This is
why this bug hasn't been found before (AFAIK).

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RE: [PHP-CVS] cvs: php4 /ext/ftp ftp.c ftp.h

[Stig Venaas]

On Thu, Feb 07, 2002 at 11:21:26PM +0100, Stig Venaas wrote:
> On Thu, Feb 07, 2002 at 12:42:29AM +0100, marc wrote:
> > I just left it with the new sizeof, but there may be side-effects?
> 
> It's okay as long as you don't have IPv6, 95/98 doesn't.

I've now committed a proper fix with no side-effects... There
might be other similar issues on 95/98 that I'm not aware of.

Stig

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RE: [PHP-CVS] cvs: php4 /ext/ftp ftp.c ftp.h

[Stig Venaas]

On Thu, Feb 07, 2002 at 12:42:29AM +0100, marc wrote:
> I just left it with the new sizeof, but there may be side-effects?

It's okay as long as you don't have IPv6, 95/98 doesn't.

> Don't worry, it's in the -dev cvs so I expect some things not to work.
> At least we caught it in time before release branch started.
> 
> > At least I'm now aware of the problem when doing more IPv6
> > porting later.
> 
> I hope you didn't do too much work already if a lot of changes are
> required...

Seems that just a couple of minor changes are needed, I'll write, test
and commit something tomorrow I hope. Nice if you can help test that
too then. I guess you used passive get now, could you check if it
works with normal (active) get?

As you mentioned, the php_connect_nonb() has a comment about probably
not working on Win32. What happens is that it just does a normal
connect() and not the timeout code since doesn't know whether it
works or not. If you feel like it, you might try to remove the
"&& !defined(PHP_WIN32)" part and check whether it compiles and if
the timeout works. Would be neat if we could have timeouts on Win32
as well. If we fix it, it will make timeouts work other places too.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RE: [PHP-CVS] cvs: php4 /ext/ftp ftp.c ftp.h

[Stig Venaas]

On Wed, Feb 06, 2002 at 10:03:50AM +0100, Marc Boeren wrote:
> > Thanks, this helps a lot (I think). Does it work if you in line
> > 1053 or so, replace
> > size = sizeof(php_sockaddr_storage);
> > with
> > size = sizeof(struct sockaddr_in);
> 
> OK, this makes it work... on Win98 at least (and it still works on NT :-)

Ah, great, ignore my last mail then (:

> > ? If it does, could you perhaps try to determine the maximum value?
> > I would try to add 1 to the size above, and also 256, 128 and 64.
> 
> Adding one is enough for the function to fail... (adding 256 fails too)
> 
> Hope this helps! (it has helped me, at least :)

Sure does. I know how to solve it then, it will make the code a bit
more involved though ):

> BTW, I also get a compile warning: 
> H:\home\php-dev\php4\ext\ftp\ftp.c(120) : warning C4761: integral size
> mismatch in argument; conversion supplied
> 
> which can be solved by changing the line from
>   ftp->fd = php_hostconnect(host, port ? port : 21, SOCK_STREAM, (int)
> timeout_sec);
> to
>   ftp->fd = php_hostconnect(host, (unsigned short) (port ? port : 21),
> SOCK_STREAM, (int) timeout_sec);

Thanks, will fix.

I'm quite happy you reported this.  Else we might have had a release
with lots of bug reports.  I'm sorry that my IPv6 patch caused
problems.  At least I'm now aware of the problem when doing more IPv6
porting later. I suspect there might be some similar problems with the
socket extension on 95/98.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RE: [PHP-CVS] cvs: php4 /ext/ftp ftp.c ftp.h

[Stig Venaas]

On Tue, Feb 05, 2002 at 11:44:18PM +0100, marc wrote:
> > Thanks, this helps a lot (I think). Does it work if you in line
> > 1053 or so, replace
> > size = sizeof(php_sockaddr_storage);
> > with
> > size = sizeof(struct sockaddr_in);
> 
> I tried sizeof(ftp->pasvaddr), but no effect... (same errormsg)
> Could this be a wsock32 version difference between the win95/98 and
> NT/2000 versions?

That's no surprise, the size of pasvaddr is the same as
php_sockaddr_storage. Please try sizeof(struct sockaddr_in);
like I said above.

> > ? If it does, could you perhaps try to determine the maximum value?
> > I would try to add 1 to the size above, and also 256, 128 and 64.
> > You've done a good job already, I understand if you don't want to
> > check all this.
> 
> No problem, I want to get the problem solved...

So please try the above.

> I'll try the official 4.1.0 as well, and I probably have some older
> versions on my disk too, that might narrow it down a bit...

4.1.0 doesn't contain my changes, so that probably works. If what I
wrote above solves it, then I can go through and make it work. If
it works with some larger sizes like 256, 128 or 64 (the larger the
better), I might be able to find a more elegant solution.

Note that if you use passive ftp, there will be two connect calls
that might fail.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RE: [PHP-CVS] cvs: php4 /ext/ftp ftp.c ftp.h

[Stig Venaas]

Hi

On Tue, Feb 05, 2002 at 05:55:45PM +0100, Marc Boeren wrote:
> 
> > Hi Stig (and others, Wez for instance),
> > 
> > The patch below seems to have broken the ftp_get function (I used
> > ftp_get($conn_id, $local_file, $remote_file, FTP_BINARY)) in Win95 and
> > Win98, it now displays a warning:
> > Warning: Type set to I. in  on line  and returns false.
> > It works OK on WinNT and Win2000.
> 
> I looked into it a bit, and I get a windows error for the connect()
> function:
> 
> WSAEFAULT:
>  The name or the namelen parameter is not a valid part of the user address
>  space, the namelen parameter is too small, or the name parameter contains
>  incorrect address format for the associated address family.
> 
> 
> Any pointers?

Thanks, this helps a lot (I think). Does it work if you in line
1053 or so, replace
size = sizeof(php_sockaddr_storage);
with
size = sizeof(struct sockaddr_in);
? If it does, could you perhaps try to determine the maximum value?
I would try to add 1 to the size above, and also 256, 128 and 64.
You've done a good job already, I understand if you don't want to
check all this.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] zend_qsort() problems

[Stig Venaas]

_zend_qsort_swap() is broken, it only works when siz is sizeof(int) or
sizeof(char). The following patch fixes it:

+++ Zend/zend_qsort.c   Wed Jan 16 22:46:11 2002
@@ -32,23 +32,24 @@
int t_i;
chart_c;

-   for (i = sizeof(int); i <= siz; i += sizeof(int)) {
-   tmp_a_int = (int *) a;
-   tmp_b_int = (int *) b;
+   tmp_a_int = (int *) a;
+   tmp_b_int = (int *) b;

+   for (i = sizeof(int); i <= siz; i += sizeof(int)) {
t_i = *tmp_a_int;
-
-   *tmp_a_int++ = *(int *) b;
+   *tmp_a_int++ = *tmp_b_int;
*tmp_b_int++ = t_i;
}

-   for (i = i - sizeof(int) + 1; i <= siz; ++i) {
-   tmp_a_char = (char *) a;
-   tmp_b_char = (char *) b;
+   if (i - sizeof(int) == siz)
+   return;

-   t_c = *tmp_a_char;
+   tmp_a_char = (char *) a;
+   tmp_b_char = (char *) b;

-   *tmp_a_char++ = *(char *) b;
+   for (i = i - sizeof(int) + 1; i <= siz; ++i) {
+   t_c = *tmp_a_char;
+   *tmp_a_char++ = *tmp_b_char;
*tmp_b_char++ = t_c;
}
 }

Another thing which I don't like, is that it doesn't preserve the order
of "equal" values. This is a problem for array_unique(), see bug #14805.
The reason is that instead of storing the pivot separately by copying
the middle value, the first and middle values are exchanged in order to
store the pivot in the first value (I know, that's not quite clear, but
if you look at the code and understand quicksort, you know what I mean).
Can we please fix this? I can submit a patch if you like. Another slight
improvement is to compare the pivot candidate (middle) with first and
last, and sort those. This gives better performance in some cases, and
it isn't really a penalty since these comparisons then can be skipped
in the following loops by setting seg1 = begin + siz and seg2 = end - siz.
With these changes I think the performance would be about as good as now.
The big penalty is memory allocation for the pivot I guess, but it is
done only once for the entire sort, so I think it is okay.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Using PHP in my own apps

[Stig Venaas]

On Mon, Dec 31, 2001 at 07:14:32PM +0100, Daniel Lorch wrote:
> Hi,
> 
> > I was wondering how i could use PHP to interpret scripts for my own apps
> > using php4ts.dll  ?
> 
> the best way to start is not the PHP sources. have a look at apaches
> DSO support (or the windows counterpart - the DLL files. there should
> be some notes on them in the same documentation):
> 
>   http://httpd.apache.org/docs/dso.html
> 
> if you succeed to implement this interface, you will be able to
> include future PHP releases without touching the PHP sources.

Yes, but you could also interface with PHP's SAPI. PHP is interfaced
with say Apache using the code in sapi/apache. It might be better to
interface at this level.

BTW, BIND 9 has a simple database interface that I've used to write
an LDAP backend. I've toyed with the sick idea of having a PHP back-
end for BIND. Then you would run a PHP script on every DNS loookup.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: is_array_multidimensional

[Stig Venaas]

On Sat, Dec 29, 2001 at 11:13:11PM +0200, Andi Gutmans wrote:
> I agree with Jim. Arrays can contain "things". Things can also be other 
> arrays. You can have an array which contains two other arrays and four 
> integers. I don't think we should add these functions because they are 
> wrong *especially* the is_array_multidimensional().

Agree

> Of course, if there's a good reason to have them and we're all convinced 
> that the reasons are good we could add them.
> Can you please roll back that patch and open up a discussion with examples 
> of why this functionality is needed? It might even lead to a different 
> solution.

One solution (not so sure I like it myself), could be a function that
tells whether an array contains values of a given type. Then you could
check if the array contained an array (or any other type). I've never
had a use for such myself.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Development question: DNS lookups

[Stig Venaas]

On Fri, Dec 28, 2001 at 05:00:20PM +0100, Edwin Boersma wrote:
> At 16:51 28-12-01, you wrote:
> >On Fri, Dec 28, 2001 at 04:30:33PM +0100, Edwin Boersma wrote:
> > > Hi there,
> > >
> > > My provider stopped the DNS service on the server that runs mySQL and
> > > PHP. By result, the function GetHostByAddr() is useless. Can I tell PHP
> > > to use another DNS server to lookup the IP-address?
> >
> >No PHP uses whatever is configured on the system. PHP just does the
> >gethostbyaddr() call, and the system does the rest. One solution
> >could be to call an external program like host or something. host
> >can be told to use a specific nameserver, and does not depend on
> >system configuration.
> >
> >Stig
> 
> Hmm, not a very satisfying answer. I don't know of any Linux program, that 

I know it's not very satisfying, but on most Linux installations you have
the program called "host". Try "host ipaddress serveraddress". If you
have this, it is simple to call the program from PHP and use the output.

> does what you suggest. Wouldn't it be handy to extend the function (or have 
> another one), so that it can use any DNS server, that is parsed to the 
> function?

Sorry, but I'm against adding all that extra code for a special case
like this. Personally I would say that if service provider blocked
DNS, then the provider is the problem. If provider wants to, he can
block all DNS lookups going out from the box. I'm cc-ing this to
php-dev.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Development question: DNS lookups

[Stig Venaas]

On Fri, Dec 28, 2001 at 04:30:33PM +0100, Edwin Boersma wrote:
> Hi there,
> 
> My provider stopped the DNS service on the server that runs mySQL and
> PHP. By result, the function GetHostByAddr() is useless. Can I tell PHP
> to use another DNS server to lookup the IP-address?

No PHP uses whatever is configured on the system. PHP just does the
gethostbyaddr() call, and the system does the rest. One solution
could be to call an external program like host or something. host
can be told to use a specific nameserver, and does not depend on
system configuration.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Suggestion: Adding fmt like linebreak algorithm

[Stig Venaas]

On Wed, Dec 26, 2001 at 01:10:47PM +0100, [EMAIL PROTECTED] wrote:
> On Wed, 26 Dec 2001, Markus Fischer wrote:
> 
> > On Wed, Dec 26, 2001 at 02:22:02AM -, Dominik Roettsches wrote :
> > > Another suggestion is to replace the wordwrap code by the algorithm of
> > > Knuth.
> >
> > This would break BC and therefore isn't an option.
> 
> Only changin the algorithm, but not touching the parameters will not break
> BC IMO. It just outputs something different, but that isn't a problem with
> wrapping lines IMO.

I think it's okay if you just use the wordwrap part of fmt. I don't like
the idea of wordwrap() doing the other stuff fmt does. Better add a new
function then.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main rfc1867.c

[Stig Venaas]

On Thu, Dec 13, 2001 at 09:23:26PM +0100, Sterling Hughes wrote:
> Hrrm, yeah, I'm thinking that the test suite should contain a simple
> webserver which we can run PHP with (as a CGI even), it would make
> the test suite more robust as there are a lot of features that rely
> on the presence of a webserver...  (we might also provide an FTP
> server, that doesn't need to run PHP, just to test certain request
> based services..)

I think this is a great idea, I can set up something for LDAP. I'm
going to write an LDAP test suite. I was planning to have it write
to a server and read back the results. I could however set up a
publicly available server with test scripts that only do "reading".

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] two of the LDAP functions are equivalent, alias and deprecate?

[Stig Venaas]

The LDAP extension has two functions that are exactly the same, namely
ldap_modify() and ldap_mod_replace(). I think we should start thinking
of getting rid of one of them. We could start with making one of them
an alias for the other, and state that the alias is deprecated in the
manual. The question then is which one we want to get rid of.

ldap_modify() is a short and descriptive name, and fits well with other
names like ldap_add(), ldap_delete(). But modifications are individual
attributes, not the complete entry.

ldap_mod_replace() fits in with some other function names like
ldap_mod_add() and ldap_mod_delete(). All these three modify only
specific attributes, not the entire entry. And are specific cases of
the more general C LDAP API ldap_modify() function.

Thus I suggest that we make ldap_modify() an alias, and get rid of it
at some point. Possibly replacing it with an entirely new ldap_modify()
at some point if necessary. Does anyone think that we should get of the
other function instead? Or that we shouldn't deprecate any of them?

Stig



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] php and ldap ?

[Stig Venaas]

Hi

Is this still a problem? I don't really know how to solve it, but it
sounds like LDAP was found when building, but that the  PHP binary
was not linked with the LDAP library. Near the end when libphp4.so is
built you should see several libs specified, you might try to see if
LDAP is listed, and if not, add it by hand.

The bigger question is why it failed for you, but that is pretty hard
to debug, I'm no guru on the build process, so tracking down the
problem by mail is pretty hard. And that's why no one has responded
I guess.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [NEW EXTENSTION]: templates

[Stig Venaas]

On Wed, Dec 05, 2001 at 02:09:22PM -0500, Robinson, Mike wrote:
> You submitted a proposal.
> There was discussion.
> The concensus is no, it won't go into the php source.

But there are probably still a lot of people that would like to use
it. I think it's good that people get to know about it. There are
other ways to distribute it than putting it into ext/

> Open Source doesn't mean anybody can put whatever the
> hell they want into it.

Yes, Open Source software can easily get bloated.

> There are extensions far better and far more useful than yours
> that are not in the php source. There will be more and more.

Maybe, I think however we should appreciate any new extensions
made and offered, that way the best ones hopefully survives and
get the publicity they deserve in the end.

BTW, I'm interested in that Russian report. I'm trying to learn
Russian for some reason.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP can't compare...

[Stig Venaas]

On Wed, Dec 05, 2001 at 12:09:33PM +0200, Zeev Suraski wrote:
> There's no clean 3.55, there simply isn't.  It's just how computers 
> work.  The only way to do what you're asking for is to switch to a whole 
> different string-based representation, which is going to slow things down 
> very considerably.

I guess one can try to think of 355 binary which is easy enough. But
since 100 is not a power of 2, you quickly run into problems. Several
numbers that have a finite decimal representation are not finite in
binary. In the trinary system 1/3 would be finite, but not in decimal
or binary.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Zend Hash Question

[Stig Venaas]

On Wed, Dec 05, 2001 at 01:35:26AM -0500, l0t3k wrote:
> something that has confused me for a second is the use of HashTables to
> store a user defined type. the constructor is fine, its just insertion and
> querying that's mildly confusing. for instance, it seems as if
> zend_hash_add takes sizeof(struct) as an argument as opposed to
> sizeof(struct *) when i assume that generally we only store pointers in the
> hash.

The data is actually copied. Of course it's up to you what data to store.
So you can store the struct or pointer to the struct, up to you.

> suppose i have a struct of type widget_t which gets allocated on the heap.
> what's the general practice of inserting and retrieving widget from the hash
> table ?

This is probably documented at www.zend.com. You have functions for
traversing it sequentially zend_hash_internal_pointer_reset(),
zend_hash_get_current_data(), zend_hash_move_forward(). And you can
also use zend_hash_find() and zend_hash_index_find() to use the
key/index to access something. There's much more to say about this,
it might be helpfull to look at the code for the array functions
in ext/standard/array.c. It should be relatively easy to read the
source when you know from the manual what they do. You could also
look in Zend/zend_hash.h (and the .c file).

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP can't compare...

[Stig Venaas]

On Tue, Dec 04, 2001 at 05:38:10PM -0500, Matthew Hagerty wrote:
> I'm going to stop ranting and go check PHP's source, make some tests in C 
> and such.  But with this type of number representation, PHP becomes 
> inaccurate in all but the most simple use of numbers.

I find this surprising as well, I would like to see an internal
representation that avoids this as well. I suppose I should look
at the internals too. All that is required I guess, is someone
interested in this that can write some code that fixes this with-
out too many side-effects (like bad performance).

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] php-patches@lists.php.net?

[Stig Venaas]

On Tue, Dec 04, 2001 at 09:01:31PM -, James Moore wrote:
> Only if youll spend the time subscribing me to them all.. I really dont have
> time to subscribe myself to 40 somthing lists :)

Someone could write a PHP script to do the job...

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Testing LDAP (was: [PHP-QA] 4.1.0RC5)

[Stig Venaas]

On Mon, Dec 03, 2001 at 05:47:16PM +0100, Alexander Wirtz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Monday 03 December 2001 16:41, you wrote:
> > Great, you can test with ldap.uninett.no (base dc=uninett,dc=no)
> > and ldap.openldap.org (base dc=OpenLDAP,dc=org).
> 
> ok, I made a test from SuSE 7.3 with openldap 2.0.12, with both 
> servers, the first is delivering the expected output, with the second, 
> the "email"-string is not returned - I'm not familiar with ldap, so ...

You didn't specify "email" I hope, try "mail". I've been doing some LDAP
tests myself, pretty sure it's okay. I wouldn't mind if others did tests
as well though. I'm thinking of writing a little LDAP test suite. I've
got some of the material, just need some shining up.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] 4.1.0RC5

[Stig Venaas]

On Mon, Dec 03, 2001 at 04:31:40PM +0100, Alexander Wirtz wrote:
> I'd love to test the LDAP, but I haven't got a server at hand :-/ 

Great, you can test with ldap.uninett.no (base dc=uninett,dc=no)
and ldap.openldap.org (base dc=OpenLDAP,dc=org).

There are several public servers out there. You can find some at
http://sites.inka.de:8002/web2ldap, which btw uses Python. Of
course we would have liked them to use PHP (: To find the bases
of the servers, you can press connect and then "Root DSE". Of
course you could also have read that with PHP. You can do that
from PHP I think by using ldap_read(), objectclass=* as filter
and namingContexts as attribute. Like this I think:
ldap_read($ds, "", "objectclass=*", array("namingContexts"));

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.1.0RC4

[Stig Venaas]

On Sat, Dec 01, 2001 at 09:55:19AM -0700, Zak Greant wrote:
> On December 1, 2001 01:36 am, Stig Venaas wrote:
> > Isn't there anyone on the QA team doing LDAP tests? I hope you agree
> > that ldap_first/next_attribute() not working is bad. I'm doing some
> > testing myself, but not systematic, so I didn't spot this until now.
> 
>   It doesn't look like it. I would imagine that many things are
>   not getting that thoroughly tested... :(

Yes, I suppose so. I'm doing some LDAP tests once in a while, but
not thoroughly.

> > $ds=ldap_connect("158.38.60.76");
> > ldap_bind($ds,"","");
> > $sr=ldap_search($ds,"dc=uninett,dc=no", "objectclass=person",
> > array("cn","mail")); $entry = ldap_first_entry($ds, $sr);
> > echo ldap_first_attribute($ds, $entry, $ber);
> > echo ldap_next_attribute($ds, $entry, $ber);
> >
> > If it works, you should get "cnmail" as output. As it is now, you
> > will get an error that $ber is not a valid resource, since neither
> > of the functions set $ber. This works with latest CVS and if you
> > apply my latest ldap.c change to 4.1.0.
> 
>   Anyone want to step up and test this?

Of course I've tested this myself. It's now in the 4.0.7 branch, and
should be in RC5. It would be reassuring if this and other LDAP things
were tested by the QA team though. I'll try to do more LDAP testing
myself with future releases.

Stig

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] ldap_first_attribute() and ldap_next_attribute() broken in 4.1.0 RCs

[Stig Venaas]

On Sat, Dec 01, 2001 at 03:00:44PM +0200, Zeev Suraski wrote:
> This is so unbelievable.  It looks as if there's a higher force putting all 
> its weight to prevent 4.1.0 from ever coming out.

Yes, I really wish I noticed this before.

> Did you MFH the fix?

I've now committed it to the PHP_4_0_7 branch (v 1.94.2.3)). It hasn't
got any tags though, not sure how to do that. I suppose I should have
given it the tags php_4_1_0RC5 and php_4_1_0. Maybe you could tell me
how?

And I'm a bit curious what MFH is (merge ...?).

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] 4.1.0RC4

[Stig Venaas]

On Fri, Nov 30, 2001 at 10:25:14PM -0700, Zak Greant wrote:
> On November 30, 2001 09:12 pm, Zeev Suraski wrote:
> > http://www.php.net/~zeev/php-4.1.0RC4.tar.gz
> >
> > The plan is to release Monday, unless a real earth quaker is found...
> 
>   Builds and runs on SuSE 7.1 as CGI
>   See http://fooassociates.com/phpqa/index.php?ZakGreantBuilds4.1.0RC4

Isn't there anyone on the QA team doing LDAP tests? I hope you agree
that ldap_first/next_attribute() not working is bad. I'm doing some
testing myself, but not systematic, so I didn't spot this until now.

Here's a script that illustrates how they don't work:

$ds=ldap_connect("158.38.60.76");
ldap_bind($ds,"","");
$sr=ldap_search($ds,"dc=uninett,dc=no", "objectclass=person", array("cn","mail"));
$entry = ldap_first_entry($ds, $sr);
echo ldap_first_attribute($ds, $entry, $ber);
echo ldap_next_attribute($ds, $entry, $ber);

If it works, you should get "cnmail" as output. As it is now, you
will get an error that $ber is not a valid resource, since neither
of the functions set $ber. This works with latest CVS and if you
apply my latest ldap.c change to 4.1.0.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] ldap_first_attribute() and ldap_next_attribute() broken in 4.1.0 RCs

[Stig Venaas]

On Sat, Dec 01, 2001 at 06:18:14AM +0200, Zeev Suraski wrote:
> If it was broken for 6 months, it was broken in 4.0.6.  It will be broken 
> in 4.1.0, it's not grounds for breaking a final RC...

No, it wasn't broken in 4.0.6. 4.0.6 was based on ldap.c 1.82 from
February, this happened in 1.85 on June 1. So 4.1.0 would be the
first release. As it is they don't work at all, and there are
definitely a lot of people using them.

Stig


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] ldap_first_attribute() and ldap_next_attribute() broken in 4.1.0 RCs

[Stig Venaas]

I was by accident looking at the ldap_first_attribute() code and
realized that something was wrong. Turns out that it has been
broken for 6 months without anyone noticing! I've done a lot of
LDAP testing, but I've not been using ldap_first_attribute() and
ldap_next_attribute(). I know accidents easily happens, but I
wish people would test when they change things.

I think the patch below fixes it. Could we apply the same patch to
4.1.0? I don't think we can release 4.1.0 without these functions
working, and this fix shouldn't affect anything but those functions.

Stig

- Forwarded message from Stig Venaas <[EMAIL PROTECTED]> -

Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
list-help: <mailto:[EMAIL PROTECTED]>
list-unsubscribe: <mailto:[EMAIL PROTECTED]>
list-post: <mailto:[EMAIL PROTECTED]>
Delivered-To: mailing list [EMAIL PROTECTED]
From: "Stig Venaas" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Fri, 30 Nov 2001 23:37:44 -
Subject: [PHP-CVS] cvs: php4 /ext/ldap ldap.c  

venaas  Fri Nov 30 18:37:44 2001 EDT

  Modified files:  
/php4/ext/ldap  ldap.c 
  Log:
  ldap_first_attribute and ldap_next_attribute has been completely broken
  for 6 months!! Fixed (I think), might be a memory leak there...
  
  
Index: php4/ext/ldap/ldap.c
diff -u php4/ext/ldap/ldap.c:1.107 php4/ext/ldap/ldap.c:1.108
--- php4/ext/ldap/ldap.c:1.107  Thu Nov 29 15:26:20 2001
+++ php4/ext/ldap/ldap.cFri Nov 30 18:37:43 2001
@@ -22,7 +22,7 @@
+--+
  */
  
-/* $Id: ldap.c,v 1.107 2001/11/29 20:26:20 venaas Exp $ */
+/* $Id: ldap.c,v 1.108 2001/11/30 23:37:43 venaas Exp $ */
 #define IS_EXT_MODULE
 
 #ifdef HAVE_CONFIG_H
@@ -232,6 +232,7 @@
le_result = zend_register_list_destructors_ex(_free_ldap_result, NULL, "ldap 
result", module_number);
le_link = zend_register_list_destructors_ex(_close_ldap_link, NULL, "ldap 
link", module_number);
le_result_entry = zend_register_list_destructors_ex(NULL, NULL, "ldap result 
entry", module_number);
+   le_ber_entry = zend_register_list_destructors_ex(NULL, NULL, "ldap ber entry", 
+module_number);
 
Z_TYPE(ldap_module_entry) = type;
 
@@ -275,7 +276,7 @@
 
php_info_print_table_start();
php_info_print_table_row(2, "LDAP Support", "enabled" );
-   php_info_print_table_row(2, "RCS Version", "$Id: ldap.c,v 1.107 2001/11/29 
20:26:20 venaas Exp $" );
+   php_info_print_table_row(2, "RCS Version", "$Id: ldap.c,v 1.108 2001/11/30 
+23:37:43 venaas Exp $" );
php_info_print_table_row(2, "Total Links", maxl );
 
 #ifdef LDAP_API_VERSION
@@ -1001,7 +1002,7 @@
if ((attribute = ldap_first_attribute(ld->link, ldap_result_entry, &ber)) == 
NULL) {
RETURN_FALSE;
} else {
-   ZEND_REGISTER_RESOURCE(return_value, ber, le_ber_entry);
+   ZEND_REGISTER_RESOURCE(*berp, ber, le_ber_entry);
 
RETVAL_STRING(attribute, 1);
 #if ( LDAP_API_VERSION > 2000 ) || HAVE_NSLDAP || WINDOWS
@@ -1032,7 +1033,7 @@
if ((attribute = ldap_next_attribute(ld->link, ldap_result_entry, ber)) == 
NULL) {
RETURN_FALSE;
} else {
-   ZEND_REGISTER_RESOURCE(return_value, ber, le_ber_entry);
+   ZEND_REGISTER_RESOURCE(*berp, ber, le_ber_entry);
 
RETVAL_STRING(attribute, 1);
 #if ( LDAP_API_VERSION > 2000 ) || HAVE_NSLDAP || WINDOWS



-- 
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

- End forwarded message -

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Patch: Nested comments

[Stig Venaas]

On Tue, Nov 27, 2001 at 09:41:46PM +0100, Anders Johannsen wrote:
> The submitted patch does not break any existing code (the same way one
> would expect ZE2 to run all ZE1 code, but not necessarily the other way
> around)

Are you sure? Being used to code not being nested, it's not uncommon
for people to do things like:

/*  $a = 1 /* This is a comment */

Okay, it is a bit weird, but people do things like this. Wouldn't
those scripts break?

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Patch: Nested comments

[Stig Venaas]

On Tue, Nov 27, 2001 at 10:16:15PM +0200, Andi Gutmans wrote:
> It's not like I don't want to keep BC as much as possible for ZE2 too. Sure 
> that for important stuff BC is less important but I don't see nested 
> comments being very important to ppl. This is one of the only times it has 
> come up in the past few years so it must not be such a big deal to ppl.
> If everyone *really* wants nested comments we could think of a solution. I 
> would still prefer a non-BC breaking alternative way.

Agree, it's not that important. It would not be BC and also a bit
confusing. If really necessary I would prefer a new type of comments
for this, actually I would prefer adding simple #define and #ifdef.
But I think I'm against it.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] maybe serious error in RC3 memory manager

[Stig Venaas]

On Mon, Nov 26, 2001 at 11:38:52AM +0200, Oleg Khimich wrote:
> On my FreeBSD 4.3 php4.1.0rc3 not failing, but message "maximum execution time..." 
>appeared.
> PHP4.2.0-dev core dumped after some time.

Good to see I'm not the only one. I see now that I should have read the
"CGI quick cleanup" thread. I think this should be fixed, but actually
when running as CGI/standalone it would be good to just exit without
freeing all the memory the nice way. In that thread it's suggested to
turn off fast cache, but couldn't we by default exit quickly when run
as standalone? Except when debugging (--enable-debug?), then it is use-
ful to do it the nice way and get report on leaks.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] maybe serious error in RC3 memory manager

[Stig Venaas]

Bug #13437 seems to be the same problem. I think it might be solved
like I said in my previous mail.

Stig


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] maybe serious error in RC3 memory manager

[Stig Venaas]

Hi

I don't know for sure yet, but wanted to warn you. I'm digging into
this, but right now I have a script that runs for a long time after
the last line in the script is executed, and then it segfaults with:

Fatal error:  Maximum execution time of 30 seconds exceeded in Unknown 
on line 0

Program received signal SIGSEGV, Segmentation fault.
0x40124df0 in chunk_free (ar_ptr=0x401cdf00, p=0x15f2e560) at malloc.c:3131
3131malloc.c: No such file or directory.
in malloc.c
(gdb) bt
#0  0x40124df0 in chunk_free (ar_ptr=0x401cdf00, p=0x15f2e560) at malloc.c:3131
#1  0x40124d59 in __libc_free (mem=0x15f2e5a0) at malloc.c:3054
#2  0x080bd370 in _efree (ptr=0x15f2e5ac) at zend_alloc.c:246
#3  0x080bd703 in shutdown_memory_manager (silent=1, clean_cache=1)
at zend_alloc.c:469
#4  0x0805c3ba in php_module_shutdown () at main.c:1007
#5  0x0805b05d in main (argc=2, argv=0xbb5c) at cgi_main.c:788
#6  0x400c1177 in __libc_start_main (main=0x805a748 , argc=2,
ubp_av=0xbb5c, init=0x80595b0 <_init>, fini=0x80e7f90 <_fini>,
rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbb4c)
at ../sysdeps/generic/libc-start.c:129

Also note that the program runs for many minutes (I've set the time
limit to 0), but it still gives an execution time error after the
last line is executed, but then it runs for a long time after that
error.

Reproduced this on two different computers.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] status of openssl fn in php 4.1

[Stig Venaas]

On Fri, Nov 23, 2001 at 10:19:17AM +0100, Pavol Cvengros wrote:
> Hi all.
> 
> please I need to know the status (functionality) of openssl support in 
> next version of php ( php-4.1 ??? )
> (because I work on new free national CA)

The following functions are implemented:

PHP_FUNCTION(openssl_get_privatekey);
PHP_FUNCTION(openssl_get_publickey);
PHP_FUNCTION(openssl_free_key);
PHP_FUNCTION(openssl_x509_read);
PHP_FUNCTION(openssl_x509_free);
PHP_FUNCTION(openssl_sign);
PHP_FUNCTION(openssl_verify);
PHP_FUNCTION(openssl_seal);
PHP_FUNCTION(openssl_open);
PHP_FUNCTION(openssl_private_encrypt);
PHP_FUNCTION(openssl_private_decrypt);
PHP_FUNCTION(openssl_public_encrypt);
PHP_FUNCTION(openssl_public_decrypt);

PHP_FUNCTION(openssl_pkcs7_verify);
PHP_FUNCTION(openssl_pkcs7_decrypt);
PHP_FUNCTION(openssl_pkcs7_sign);
PHP_FUNCTION(openssl_pkcs7_encrypt);

PHP_FUNCTION(openssl_error_string);
PHP_FUNCTION(openssl_x509_parse);
PHP_FUNCTION(openssl_x509_checkpurpose);

This includes S/MIME.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] bug report update submitted twice

[Stig Venaas]

I updated bug #14148. It was submitted twice (the 3rd was because I forgot
to change status). When I submitted, I got an error from Mozilla that the
post data was expired or something, and then I guess it posted the data
another time. Not sure where the problem lies.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] LDAP schema support

[Stig Venaas]

On Tue, Nov 20, 2001 at 07:01:08PM +0300, Kachalov Anton wrote:
> Good day & hi 2 all!
> 
> I want to know, will you (LDAP developers) add schema support into ldap module ?

Maybe. I'm not quite sure what you are thinking of. Could you tell me what
you have in mind?

BTW I've started studying Russian a few months ago. I'm now going to start
experimenting with Cyrillic, Unicode, OpenLDAP, PHP and web.. I'm sure
it's a lot of fun (: Right now I'm trying to get my UNIX environment to
work well.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] LDAP module globals

[Stig Venaas]

Currently the module has globals for default_link and base_dn. Neither
are used AFAICS, any reason why I shouldn't remove them?

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RE: Bug #12740 Updated: LDAP modify functions do not handle special characters

[Stig Venaas]

On Thu, Nov 08, 2001 at 08:30:39PM +0100, Christian Chateauvieux wrote:
> No,
> 
> it still does not fix my problem.
> I don't know if I am missing the point but I don't see how my locale
> settings could help.

Your code looks okay, but I don't trust it 100%, could you please do
something like:

$info["objectclass"][] = "top";
$info["objectclass"][] = "person";
$info["cn"][] = "Test Person";
$info["sn"][] = "Person";

and check you can add the entry. Then replace say Person with a string
$sn that contains at least one special character, and add:

$info["objectclass"][] = "top";
$info["objectclass"][] = "person";
$info["cn"][] = utf8_encode("Test $sn");
$info["sn"][] = utf8_encode($sn);

If this fails, give me the entire script that fails, if it works, the
problem is probably in your own code. Try to move gradually from this
simple code, to what you have below. It might help you to check the
contents of the array right before you call ldap_add(). var_dump() is
nice for printing contents of an array. BTW, your problem could also
be that an attribute is defined to be IA5 (plain ascii) only.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] making mail() funtion work without sendmail on UNIX systems

[Stig Venaas]

On Fri, Oct 19, 2001 at 09:24:51AM +0200, Hartmut Holzgraefe wrote:
> Stig Venaas wrote:
> well, the current SMTP implementation in win/sendmail.c is,
> lets say, at least suboptimal
> 
> it misses a lot of requirements from the RFCs (821/822 or the
> newer 2821/2822), e.g. case insensitive headers, handling of
> lines beginning with a '.', limited message size ...
> 
> so while having a common codebase for mail() using SMTP on
> UNIX *and* Win32 is definetly a good thing it might be worth
> to have a look at different SMTP implementations to integrate
> for that
> 
> improving this situation has been on my list for quite a while
> (see the error assignments on bugs.php.net) but i still have
> no working Win32 dev. system :(

Same here. I didn't change anything for Windows (except moving the
file), since I haven't got a Windows dev system. The implementation
could certainly be improved, that would be much easier for me to do
by also using it for UNIX. While I do agree to some extent with
Rasmus, the changes are relatively small, and the default will be
to use external mailer.

The reason I'm looking at this now, is to avoid having separate
sendmail setup for webservers chroot environment. I suppose could
use something more trivial than sendmail as the external mailer.
This is no big thing to me, I'll help implement it if people want
it, otherwise I'll go on to more useful things.

> hope to get that installed and configured on the conference
> next month, there should be enugh man and brain power around
> in Frankfurt by that time ...

Hmm, maybe I should do that...

Stig

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] making mail() funtion work without sendmail on UNIX systems

[Stig Venaas]

Hi

I have a patch ready for this. I, and also some others I know, would
like to send mail from PHP without help of sendmail or other external
programs on UNIX, similar to what is done on windows. I have made a
patch that makes the sendmail.c for windows, also work with unix, with
relatively small changes.

Since I want the current sendmail.c to be used for unix also, I would
like current sendmail.c to be moved from win32 to ext/standard. It
would be good if someone with access on the CVS box could move it so
that all current history can be maintained.

As far as I can see, the windows build should work well after the move
by just changing the path to sendmail.c in win32/php4dll.dsp and
win32/php4dllts.dsp, can someone confirm this? If we move sendmail.c
it will happen also for all tags so the dsp changes should also be
included there. If we don't want this, we would have to either copy
the file or wait until after 4.1 is released I guess.

Comments?

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RC3

[Stig Venaas]

On Wed, Oct 03, 2001 at 11:24:08PM -0700, Rasmus Lerdorf wrote:
> Ok, I have merged it and tested it on one of my servers.  Didn't break

Thanks. Now I see your commit and the 4.0.7 branch, maybe I made some
silly mistake or the cvsweb page for ldap.c was cached or something.

> anything.  But where exactly is the ldap_result_entry freed?  I am
> guessing that it is actually the same memory as ldap_result points to and
> when we free ldap_result there is no need to free the nested
> ldap_result_entry?  Is this true for nsldap as well?
> 
> Seems logical though.

Yes, that is my conclusion. I got crashes with OpenLDAP libs when first
freeing individual entries and next freeing the entire result. There
could be differences between libs but I suspect it is common to not
copy result_entries out of the result. For now I would rather see leaks
with some libs than crashes with OpenLDAP libs. If there are differences
I'll try to make it better for 4.0.8.

Thanks Rasmus,

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RC3

[Stig Venaas]

On Thu, Oct 04, 2001 at 02:04:27AM +0200, Zeev Suraski wrote:
> Finally, it's out.
> www.php.net/~zeev/php-4.0.7RC3.tar.gz

I see that my LDAP fix didn't make it. Can someone please explain
how this works? I can't see any tags for ldap.c since May but
ldap.c in RC3 is 1.94, I would like 1.96 to be in the release.

Could someone other than me please test LDAP in RC3 and also
try with ldap.c 1.96? As said earlier I can easily make things
crash with 1.94, 1.96 should fix it with no side effects. It
would still be good if people tested it though.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Apache 2.0.18 API does not match sapi_apache2.c code

[Stig Venaas]

On Sun, Sep 30, 2001 at 04:03:02PM +0200, Sebastian Bergmann wrote:
> Stig Venaas wrote:
> > Or is it possible for mortals to download more recent Apache somehow 
> > (CVS access?)?
> 
>   Sure, the latest is Apache 2.0.26-dev.

Thanks, maybe it was a stupid question, haven't followed Apache
developments that much. I haven't seen any CVS info, but after
reading your mail I made a wild guess and tried cvs.apache.org (:
Right now I have Apache 2.0.18 with PHP and IPv6 and are quite
happy (: I suppose I should try something more recent soon.

Stig

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Apache 2.0.18 API does not match sapi_apache2.c code

[Stig Venaas]

In Apache 2.0.18 alpha released on June 13, I find
apache2/include/util_filter.h with ap_save_brigade() defined with only 3
parameters while we increased it from 3 to 4 on June 23. ap_get_brigade()
was changed from 3 to 4 parameters in Apache earlier on, so I guess our
change might be for Apache 2 newer than 2.0.18, but 2.0.18 is the latest
I can find. I think we should support the latest Apache 2 that people are
able to download, which seems to be from June. Or is it possible for
mortals to download more recent Apache somehow (CVS access?)?

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [PATCH] fix gethostbyname() to return false when hostname not resolved

[Stig Venaas]

On Wed, Sep 26, 2001 at 01:17:55AM +0200, Markus Fischer wrote:
> On Tue, Sep 25, 2001 at 01:56:28PM -0700, Jim Winstead wrote : 
> > here's a patch to fix bug #13423. think anyone is relying on the
> > current (vastly lame, imho) behavior?
> 
> Because this was the behaviour for a long time now its obvious
> that this will break all scripts ;-)
> 
> But of course it should be changed. Better earlier than later
> 'til never.

Yes, I'm afraid existing scripts will do something like:

$address = gethostbyname($hostname);
if ($address == $hostname) {
echo "Error";
...
} 
ok...

I think perhaps the reason for current behavior is that gethostbyname()
on some systems may not return the IP address when called with an IP
address, the current PHP code would hide that bug. Well, just a theory
I don't like the current code either.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] In C, how do I access an associative array?

[Stig Venaas]

On Tue, Sep 25, 2001 at 09:00:18AM -0400, [EMAIL PROTECTED] wrote:
> 
> If I do this in PHP:
> 
>$array = array();
> 
>   $array["foo"] = "bar";
>   $array["hey"] = "you";
>   $array["pink"]="floyd";
> 
>   myext_function($array);
> ?>
> 
> 
> How do I find all the keys and values out of that array in my extension? 
> Is there a way?

You can do something like:

if (zend_hash_find(Z_ARRVAL_PP(input), "pink", sizeof("pink"), (void **) &val) == 
SUCCESS) {
convert_to_string_ex(val);
...
}

to look for pink, if you just want to iterate through the keys you can do
something like:

zend_hash_internal_pointer_reset_ex(Z_ARRVAL_PP(input), &pos);
while(zend_hash_get_current_data_ex(Z_ARRVAL_PP(input), (void **)&entry, &pos) == 
SUCCESS) {
zend_hash_get_current_key_ex(Z_ARRVAL_PP(input), &string_key, &string_key_len, 
&num_key, 0, &pos)
...
}

See docs or sources for details/examples

Stig


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RC3

[Stig Venaas]

On Mon, Sep 24, 2001 at 10:40:04PM +0200, Zeev Suraski wrote:
> If it's a bug fix you believe to be important and the chances, in your 
> opinion, of it screwing things up more than it fixes are slim, go ahead and 
> commit it...

Maybe I've already done what's needed, I'm not quite sure how this
works. I thought there would be a php_4_0_7 tag for ldap.c but I
can't find any. Does that mean that what I added will be in? In
RC2 1.94 of ldap.c is used, my change is 1.96 and 1.95 is just
vim cosmetics, no code change.

So, my guess is that latest ldap.c will be in 4.0.7 since no branch.
Let me know if I should do anything, and sorry for my poor CVS skills.

Are there any LDAP testing done on the RCs? I'm surprised no problem
was detected. We do have a set of automated tests, right? I can make
some LDAP tests if needed. One problem is that there are many LDAP
APIs, the best is perhaps to test with OpenLDAP 2 which I think is
the most widely used.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RC3

[Stig Venaas]

On Wed, Sep 19, 2001 at 10:05:24PM +0200, Stig Venaas wrote:
> On Tue, Sep 18, 2001 at 06:13:54PM +0300, Zeev Suraski wrote:
> > Does anybody still have anything pending for RC3?
> 
> There seems to be a serious LDAP bug. For instance the following
> simple script crashes (you should be able to test it):

I never got any feedback on this, what is the right procedure? Do I
ask you Zeev or anyone else if this can be done, or am I supposed
myself to commit changes with the right tag? At least I think this
fix is important, would be nice to get some confirmation that it
gets in, or reasons for not doing it.

Stig

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RC3

[Stig Venaas]

On Tue, Sep 18, 2001 at 06:13:54PM +0300, Zeev Suraski wrote:
> Does anybody still have anything pending for RC3?

There seems to be a serious LDAP bug. For instance the following
simple script crashes (you should be able to test it):

$ds=ldap_connect("garibaldi.venaas.no"); 
ldap_bind($ds,"","");
$sr=ldap_search($ds,"dc=venaas,dc=no", "relativeDomainname=www");
ldap_first_entry($ds, $sr);

I just made the following change in ldap.c (1.96)

-   le_result_entry = zend_register_list_destructors_ex(_free_ldap_result, NULL, 
"ldap result entry", module_number);
+   le_result_entry = zend_register_list_destructors_ex(NULL, NULL, "ldap result 
+entry", module_number);

to fix it. Someone added the destructor the last few months. It leads to
a crash because the same memory is freed twice (or more, depends on script).
I don't think it is needed, please let me know if you think otherwise. I
would rather have a memory leak than a crash anyway.

This should be a safe change, it makes things like they used to be until a
few months ago. So, I advise changing this in RC3.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] gethostbyaddr, IPv6 mapped IPv4 and native IPv6 addresses

[Stig Venaas]

Hi

On Tue, Sep 18, 2001 at 06:28:08PM +0200, Matthias Wimmer wrote:
> Hi!
> 
> I just noticed that the php function gethostbyaddr is not able to lookup
> IPv6 mapped IPv4 or native IPv6 addresses.
> 
> Because I get such addresses from the apache 1.3.19 when it is patched
> with the KAME IPv6 patch (that's the normal way to IPv6 enable apache
> 1.3) I noticed the problem.
> 
> Attached is a patch that enables php to lookup such addresses too.

Committed, I had to change it a bit though. It looks like your inet_pton
will also accept IPv4 when called with AF_INET6, this is not the standard.
Please try the latest from CVS or the next snapshot.

Glad to see there are others interested in PHP and IPv6 (:

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] cvs socket extension

[Stig Venaas]

On Tue, Jul 24, 2001 at 05:16:05AM +0200, Markus Fischer wrote:
> Great :-)
> 
> So we're seeing this getting implemented soon ?
> 
> Volunteers, anyone ? :-))

Is this select stuff so brand new that it's okay to change the API?
If it is, we should do it quickly before too many people get to
play with it.

I think I agree now with just using the max, we can always optimize
more later if we feel it's necessary, I think the most important
thing now is to get rid of that argument if possible (:

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] cvs socket extension

[Stig Venaas]

On Mon, Jul 23, 2001 at 05:16:13PM +0200, Markus Fischer wrote:
> On Mon, Jul 23, 2001 at 07:20:34AM -0700, Chris Vandomelen wrote : 
> > > Since socket_select() always wants highest +1, couldn't this be
> > > implemented into socket_select() to go through all socket sets
> > > and get the number itself ?

Why all sets? Isn't it enough to use max for the set that got passed to
socket_select()?

> > The best way around this (IMHO) is to define a php_fd_set something like:
> > 
> > struct php_fd_set {
> > fd_set the_set;
> > intmax_fd;
> > };
> 
> Btw, is this really enough information ?

Yes, that's my doubt as well, I'm not sure how much of a problem
it is though.

> Consider this:
> You use FD_SET() to add a socket to the set (you just bump_up
> max_fd if socket > max_Fd)
> 
> But when using FD_CLR() to remove a socket how do we know
> which socket in this set has the highest number now
> and whats the number anyway (beside 42) then ?
> 
> Seems like we need a list for every set containing the current
> socket numbers in the set (if I'm not totally wrong :) because
> AFAIK if you don't keep a list of the numbers of a set without
> brute force you can't retrieve the list.

In order to be portable we can't inspect the actual bits in the
set I think, so the only way I see is to have a list of the
numbers. So for every call to socket_fd_set(), you add to the
list, and in socket_fd_clear() you remove. In order to not look
for max every time you call select, you might also store the
max somewhere maybe. I think you should have one such list per
set, and create an empty list in socket_fd_alloc().

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] cvs socket extension

[Stig Venaas]

On Mon, Jul 23, 2001 at 11:57:44PM +0200, Markus Fischer wrote:
> On Mon, Jul 23, 2001 at 11:15:49PM +0200, Stig Venaas wrote : 
> Chris mentioned something that its not needed to restore the last
> highest value for the max_fd if you drop the current highest one.

I agree, it would only be for efficiency. I think now that the
best solution is to just store the max. If clear.. is called
with the current max, we can start at max and going downwards
we can do FD_ISSET on each number until we find something that
is set. Then we have the new max.

> This makes me wondering why we not ever pass something like
> 0x to select() [of course there is some legal reason not
> to do this, i'm just curious now].

Maybe, but I don't like it. Are you sure there are may not be bad
things happening if the number is outside the size of the set?

> One the other hand, Daniel [afaik??] suggested to let the user
> retrieve the handle id for a socket and calculate the hightest
> value on its own. Something like
> 
>   $fd = socket_get_fd( $socket);
> 
> comes into my mind.
> 
> 
> The first one would be more nice for the users while the later is
> much less programming effort :-)

Yes, I think we should be nice to the users though (: There's less
time wasted by doing it once in C than having many PHP programmers
doing it over and over again...

> I'm just wondering if there can be ever any drawback if we don't
> let the user specify the first parameter to the select() call.
> 
> As I'm not an expert I can't tell.

I'm no expert, but I really can't see why it's needed (:

Stig

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #6778 Updated: fsockopen: timeout does not work when nameserver unreachable

[Stig Venaas]

I don't think we do this anywhere. I've thought of doing it, but I'm
not at all sure what's the best way. Ideas anyone? Ideally it should
be possible to specify the resolvers timeout but I haven't seen any
good ways. Only other solutions I can think of are rather ugly using
threads or maybe alarm(2)?

Stig

On Sun, Jul 22, 2001 at 01:56:37AM -, [EMAIL PROTECTED] wrote:
> ID: 6778
> Updated by: andy
> Reported By: [EMAIL PROTECTED]
> Status: Closed
> Bug Type: Sockets related
> Operating System: Debian 2.2
> PHP Version: 4.0.1pl2
> New Comment:
> 
> Please upgrade to the latest version of PHP.  Re-open if
> still exists.
> 
> Previous Comments:
> 
> 
> [2001-07-21 21:55:50] [EMAIL PROTECTED]
> 
> Please upgrade to the latest version of PHP.  Re-open if
> still exists.
> 
> 
> 
> [2000-09-16 16:20:46] [EMAIL PROTECTED]
> 
> When doing a plain
> fsockopen ("www.anyhost.com",$port,&$errno,&$errstr,$timeout) ...
> and the nameserver for this host does not respond, is unreachable or at least 
>extremely slow (host www.anyhost.com produces 'A record not found'), fsockopen won't 
>return after $timeout (3secs for example)!
> It hangs for at least 100-120 s.
> 
> 
> 
> 
> 
> Edit this bug report at http://bugs.php.net/?id=6778&edit=1
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Help on LDAP and PHP4

[Stig Venaas]

On Sun, Jul 15, 2001 at 05:17:40PM -0500, osman.bayona wrote:
> Hi...
> 
> I have this issue that is killing me. I installed PHP 4.0.4 with Solaris
> 8 and Apache. I want to use LDAP connecting to a server in the net (not
> the same server where i'm working on) And i configure PHP with:
> 
> configure --with-apxs=/usr/apache/bin/apxs --with-pgsql=/usr/local/pgsql
>  --with-ldap

Which LDAP library? iPlanet coming with Solaris?

> then 'make install' and everything works fine until i try:
> 
> /usr/apache/bin/apachectl start
> 
> then i have this &@!% message:
> 
> Syntax error on line 236 of /etc/apache/httpd.conf:
>  Cannot load /usr/apache/libexec/libphp4.so into server: ld.so.1:
>  /usr/apache/bin/httpd: fatal: relocation error: file
>  /usr/apdap_unbind_s: referenced symbol not found

Does it really say /usr/apdap_unbind_s? What on earth is that...
ldap_unbind_s would have been more normal (without /usr...)
Should it be:
/usr/apache/bin/httpd: ldap_unbind_s: referenced symbol not found
or something perhaps?

What do you see if you do ldd /usr/apache/libexec/libphp4.so?
I suspect that the LDAP library found is not found at run time. ldd
should show you something. Where do you have your library? Look for
libldap...

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Str enhancement, final run

[Stig Venaas]

On Sun, Jul 15, 2001 at 01:13:04AM +0200, Cynic wrote:
> As for the Andre's suggestions, I like Python's ranges in both 
> lists and strings (they use colon instead of two dots). I 
> some details of it unintuitive, but don't remember what it was 
> exactly as it's been some time since I touched Python though.
> I can look it up if anyone's interested.

Yes, I think that for strings we should limit it to ranges
like $foo{4..6}, and it would be neat if we for arrays could
do $foo[4..6]. ":" might be just as well as "..". It is more
intuitive with ".." I think, but I also kind of like having a
single character.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: Str enhancement, final run

[Stig Venaas]

On Tue, Jul 10, 2001 at 08:04:42PM +0200, Jeroen van Wolffelaar wrote:
> I've said it before, but I *really* am convinced now, that we should:
> 
> - At least allow $str{index} (while _deprecating_ the array $str[ ] indices)
> - _possibly_ also allowing $str{start..end}
> - and if the above is allowed, then I think you should also allow
> $str{..end} and $str{start..}
> 
> But *nothing else*.

+1

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Scripting Shootout - PHP ranked 24/29

[Stig Venaas]

On Sat, Jun 23, 2001 at 04:45:22PM +0200, Sascha Schumann wrote:
> On Sat, 23 Jun 2001, John Lim wrote:
> 
> > Thought you all might be interested in this benchmarking shootout:
> 
> I've talked to the author of the "benchmark" a couple of
> weeks ago and he of course did not build PHP with
> enabled optimizations.  Those optimizations affect primarily
> the speed of executing scripts and that is the main reason
> why PHP scored the way it did.

Could someone please list these possible optimizations? Could be
useful to me and others. From the top of my head I can think of
compiler optimizations (anything except -O and -m ?) and use of
Zend optimizer and cache.

I find it a bit amusing that Bash ranks higly (:

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] sockets extension

[Stig Venaas]

On Thu, May 17, 2001 at 01:48:06AM -0400, Sterling Hughes wrote:
> Well, it probably could be done anyway (abstract it another step). 
> However, I don't see it really being that beneficial.  The socket 
> functions provide *low level* access to the system socket features. 
> There's no real point in abstracting that (I think it gets a bit to 
> confusing if you do) any further.

The only thing I would want, is that the type of the socket is stored
in some internal datastructure. That is if the socket is PF_INET,
PF_INET6 or PF_LOCAL. The old code and maybe yours, used getsockname()
to check the type, but you can't really trust getsockname() to get the
appropriate info unless the socket has been bound. I've checked this on
a few systems some months ago.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] LDAP V3 Server Side Sorting

[Stig Venaas]

On Wed, May 16, 2001 at 08:52:52AM -0700, David Giffin wrote:
> 
> 
> If we are to follow the Netscape API then we should have a
> ldap_search_ext() function which we can pass the results of the
> ldap_create_sort_control(), other server side and client side controls.
> We can then incorporate "Virtual List View Control" and "Entry Change
> Notification Control" along with the rest of LDAP Version 3
> functionality.

Yes, I think it might be better to have separate functions for the
controls like I suggested in my last mail though. We then make sure to
pass the necessary controls to ldap_search_ext() in our internal C
function. Also in some cases people can set necessary controls with
the existing ldap_set_control() function.

This is easier for PHP users than having to first call
ldap_create_sort_control() etc. and call ldap_search_ext() with
results from those. They would also have to free the resources that
ldap_search_ext() will have to create. What I propose is that we
only keep the resources internally, and that they are freed in the
sort case by calling the set_server_sort.. function with an empty
attribute array. This is a matter of taste. I can try to explain
my thinking in more detail, but I don't have time for that until
next week.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] LDAP V3 Server Side Sorting

[Stig Venaas]

On Tue, May 15, 2001 at 06:17:11PM -0700, David Giffin wrote:
> 
> Hello,
> 
> I added in a function to provide server side sorting on searches. This is
> a LDAP version 3 specific function, and uses the Netscape API so I have
> ifdef'ed the new function. It adds a "sortstr" attriubte to the 
> ldap_search() function that already exists in php. There might be a better
> way to incorporate the code into php, but here is my first attempt.
> 
> proto int ldap_sort_search(int link, string base_dn, string filter
> [, array attrs [, string sortstr [, int attrsonly [, int sizelimit
> [, int timelimit [, int deref])

First of all, in order to be backwards compatible, the argument must be
added to the end. I'm a bit worried that the search function is
getting rather complicated.

Sorting could be done using ldap_set_option() which we already got, the
problem is that the argument has a complicated structure. It's BER
encoded sequence of sequence. ldap_set_option() could perhaps be made
to take array a value and do BER encoding etc. but that's complicated.

The solution I prefer I think, is to mirror the Netscape API and do
something like
ldap_create_sort_control(ldap, sortkeylist, 1, &sortctrl);

How about

proto int ldap_server_sort(int link, array attrs, int
reverse)

All subsequent searches should then use this. We could turn it off if
it's called with empty attrs array. When it is on, searches should then
include this control, like you did.

Maybe my solution sounds ugly, it is more complicated to implement.
I'm just starting to get concerned with all the arguments to ldap_search()
and I think to have it close to the C API if possible. And if you are to
have backwards compatibility, adding it as final argument to ldap_search()
means that users always must supply all the other optional arguments.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Patch: provides SSL capability for sockets in PHP 4.0.1pl2

[Stig Venaas]

Oops, that mail was 9 months old, I thought it was strange that it was
a patch for 4.0.1... Sorry, ignore this and my previous post.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Patch: provides SSL capability for sockets in PHP 4.0.1pl2

[Stig Venaas]

On Tue, Aug 22, 2000 at 02:42:43PM +0100, Wez Furlong wrote:
> To enable the code, you need to pass --with-ssl to configure; this will
> check for openssl using the same method in the snmp extension, but with a
> different macro name so it doesn't conflict.  You may want to move the SSL
> check somewhere more centralized.

with-openssl is centralized can can be used, that's from 4.0.3 or
something though.

> I don't know how thread-safe the SSL library is.

I can't say for sure, but for instance the OpenLDAP server (slapd) is
threaded and supports OpenSSL, I don't think there are any locks around
the SSL code.

> The code I have contributed is based on the cli.cpp example that comes with
> the openssl distribution.
> If you integrate this patch into the main distribution, please credit my
> employer for the time I have spent this morning: Ryland Technology Ltd
> (www.ryltech.net).

So you don't consider integrating it yourself?

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Dynamic Update of DNS ??

[Stig Venaas]

On Tue, May 08, 2001 at 08:35:37AM -0400, Stig Sæther Bakken wrote:
> [Stig Venaas <[EMAIL PROTECTED]>]
> > the LDAP back-end, see http://www/dns/bind/bind-sdb/. If you look at
> ^^^
> I guess this will take most people to somewhere else than they
> expect. :-)
> 
>  - Stig

Yes, I've got a few mails on this, I was in a hurry and just did a
cut'n'paste. Almost as fun as telling people to go to localhost...
The correct URL is http://www.venaas.no/dns/bind/bind-sdb/

Stig

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Dynamic Update of DNS ??

[Stig Venaas]

On Mon, May 07, 2001 at 06:54:53PM +0200, Vincen Pujol wrote:
>  Hi,
>  Sorry for the crossposting but I don't know where to find a 
> solution for this. I need to be able to update dynamically entries in a DNS 
> (Bind 9). My DNS supports dynamic updates but how to do dynamic updates in 
> my DNS server from a PHP Script ??

Might be interesting to add such a thing to PHP as a PEAR extension
maybe, but you could use a separate program for that, and just execute
it from PHP. Another possibility is to use my LDAP back-end for BIND
rather than dynamic updates. The effect is mostly the same. BIND will
look up the data in LDAP every time (lose some performance, normally
not a problem), and you can modify the data at any time from for
instance PHP by accessing the LDAP server. If anyone wants to look at
the LDAP back-end, see http://www/dns/bind/bind-sdb/. If you look at
it, please look at version .4 and the dnsZone. Versions prior to .4
shouldn't be used any more, I'll change the web page shortly.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] credits

[Stig Venaas]

On Sat, May 05, 2001 at 12:37:56PM +0100, Wez Furlong wrote:
> I've added your name to ext/openssl/CREDITS.
> 
> Actually while doing this, I've noticed that the
> "ext/standard/credits_ext.h" (which is a generated file) is also checked
> into CVS.
> 
> Is that deliberate ?  I get the impression that it is only generated and
> checked in when a release is made.

I asked the same some months ago, I was wondering too. AFAIR the reason
was that not everyone has the tools to generate it when building PHP,
think windows...

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] openssl module for php

[Stig Venaas]

On Fri, May 04, 2001 at 09:09:51PM +0100, Wez Furlong wrote:
> On 2001-05-04 20:47:25, "Stig Venaas" <[EMAIL PROTECTED]> wrote:
> > Even though it is 4 functions, I think users will find it easier to
> > work with functions called openssl_public_encrypt,
> > openssl_private_decrypt etc. It also separates them from possible
> > symmetric enryption later on.
> 
> So are we looking at openssl_asym_public_encrypt() (or is the asym part
> redundant by implication?).

I think that's pretty clear, but...
> 
> IMHO, I prefer to spell it out - especially to those new to openssl (I'm
> fairly new to it!) it helps to have things spelled out.  That way, you
> don't have to be an openssl hacker to benefit from the PHP interface.
>  
> > I think it's generally better to not alter arguments, better return it
> > this way. Is it good enough to report errors by returning an empty
> > string? I think so.
> 
> Can an empty string become an non-empty string when encrypted?
> If so, when we decrypt it, we will not be able to distinguish the correctly
> decrypted empty string from an error condition.

Good point

> We could return false (as is the convention), but then everyone would have
> to use === to check it correctly.

Yes, and not everyone will...

Sascha also has a point regarding consistency with the existing
functions, and I was the one who chose that interface... The reason
was to have something that looked a bit like the C API, and to make
the interface as clear as possible.

So, I withdraw that comment (:

I don't know for sure and I don't care to check right now, do you know
if we always can see if the key is public or private? In that case, we
don't need separate functions. Rather than showing my ignorance, I
should investigate myself I guess (:

Well, I think I'll leave this to you, haven't got that much sensible
to say, and I'm busy with something else...

Stig

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] openssl module for php

[Stig Venaas]

On Fri, May 04, 2001 at 09:21:28PM +0200, Sascha Kettler wrote:
> > On 2001-05-04 17:59:03, "Stig Venaas" <[EMAIL PROTECTED]> wrote:
> > > followed up on that. It would be good if you and Sascha Kettler could
> > > agree on how the API should be
> > 
> > How about:
> > 
> > openssl_key_encrypt(
> >   string data,  // to encrypt
> >   string &crypted,  // encrypted result
> >   mixed key, // key to use
> >   bool public, // true if you want public key, false for private key
> >   [int padding] // optional padding
> > );

Even though it is 4 functions, I think users will find it easier to
work with functions called openssl_public_encrypt,
openssl_private_decrypt etc. It also separates them from possible
symmetric enryption later on.

How about returning the result like this:

string openssl_public_encrypt(
  string data,
  mixed key,
  [int padding]
);

I think it's generally better to not alter arguments, better return it
this way. Is it good enough to report errors by returning an empty
string? I think so.

Stig

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] openssl module for php

[Stig Venaas]

On Fri, May 04, 2001 at 07:22:03PM +0200, Sascha Kettler wrote:
> You won't need to pass the algorithm by an arg, as the key already contains
> the algorithm identification (pkey->type). I haven't used any DSA encryption
> yet, but maybe you can just add the code to the switch statements.

Ah yes, I was a bit quick there. Anyway, I wanted to make sure you talked
to each other so that we might get the best possible API. It's nice to see
that so many of you want to extend the OpenSSL extension I started on. I
only put in what I needed hoping that others would pick up (:

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] openssl module for php

[Stig Venaas]

On Thu, Apr 26, 2001 at 11:42:24AM -0400, spencer 'sporty' portee wrote:
> As of late, the company I work for, Community Connect, needs to extend the
> openssl php module and might be able to release the source.  It is for RSA
> encryption, but in my own interest, i would like to add on the other types
> of algorithms to it too. 

This sounds good, please have a look at bug report 10665 by
[EMAIL PROTECTED], he has implemented RSA encryption, and [EMAIL PROTECTED]
followed up on that. It would be good if you and Sascha Kettler could
agree on how the API should be, Wez and maybe I also might have some
thoughts. I'm not sure, but rather than having separate functions for
each algorithm, it might be better to have encrypt and decrypt functions
that take algorithm as a parameter. I'm Cc'ing Sascha and Wez.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Stig Venaas]

On Tue, Apr 17, 2001 at 09:43:06PM +0100, Wez Furlong wrote:
> Hi Stig (the other one), 
> 
> I would like to end up with a "definitive" hostconnect call - something like a blend 
>between the fsockopen code in fsock.c and php_hostconnect in network.c
> 
> If you could make me aware of any gotchas I should look out for while coming up with 
>the code, I would appreciate it!

The main idea anyway is to pass a hostname to connect to, and have the
function sort out what addresses are available and try them in turn with
IPv6-addresses first. As you can see in hostconnect I have a high level
routine php_network_getaddresses() abstracting the lookup so that it's
the same whether getaddrinfo() is available or not. I think the current
hostconnect can be re-used in fsockopen when the timeout has been
implemented, I've been planning to do that for a while, but wanted to get
thorough testing of the current hostconnect() before I made it more complex.
As you see hostconnect() already takes a time-out argument, but it's
ignored at the moment. BTW if you look in fsock.c there is some socket
structure there and functions with php_sockcreate(), php_sockdestroy()
etc. It might be that can add room for address family in there. We need
something that can also be used in socket.c.

> 
> > with some input regarding how important you think IPv6 support is, and how
> > much breakage we can allow and ideas for how to cope with it.
> 
> Since I don't know of or have access to a network running IPv6 (or I'm too isolated 
>from the real world to have realized how to do it ;-), I'm not sure just how 
>important it is.

If you want to, I could tell you how, and you could be up and running
pretty quickly. You don't really need it to do any work though.

> 
> The perfectionist in me would like to see it in PHP; I have no problems running PHP 
>without having IPv6 configured, and if the people that ARE having problems are using 
>bad implementations/configurations, it should really be down to them to fix them.

Yes, and it is I think. The problem though is that some people may be put
off and don't use PHP because of our change.

> What kind of problems are showing up in the bug DB?

Some of the problems with fopen() are because of this, it's often hard to
know if this is the problem or other things. But there are a couple of
cases where it's been tracked down to getaddrinfo() bugs or broken
installations.

> Any idea how many people are using IPv6?

Not really, it's going to increase quicker and quicker though. Actually
RedHat 7.1, Solaris 8, recent BSD's etc. got IPv6 out of the box.

> Are the problems apparent on systems with IPv6 support (in the libs and headers), 
>but not yet configured?

The problem is that we use getaddrinfo() if it exists, but on some systems
the getaddrinfo() implementation is broken. getaddrinfo() is a bit complex
and changed a bit before it stabilized.

> We might be able to get away with a note in the installation instructions about 
>using IPv6 and how to resolve simple issues, or advise to upgrade, as appropriate?

Actually that's a good and simple idea. I'll add a note there.

BTW, for some reason I've used the same IPv6 code other places without
that many bug reports, but PHP has got quite a lot of users...

Your OpenSSL extension work looks good,

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Stig Venaas]

On Wed, Apr 18, 2001 at 12:22:47AM +0300, Zeev Suraski wrote:
> Cool - it looks very good!  That's exactly what I meant in the 'something 
> similar to C++'s virtual classes' :)

It looks good, but it also looks like it doesn't solve my problem. Well
I guess that's my problem not yours (:

To do sockets with different families properly I need to store some
place what family it is when it's created. So I want all sockets in
PHP to have an associated datastructure with this and perhaps other
data in it (this is not needed when the socket is created and destroyed
inside some low level function). Well, I'll look into that at some point.
Well, it's going to be at least some months before I'll look into that I
guess, it's probably something I'll do for 4.1. There are also other IPv6
things I could do before, as I wrote earlier today though, I'm a bit
discouraged by some of the problems people are having with getaddrinfo().

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Stig Venaas]

On Tue, Apr 17, 2001 at 05:22:55PM +0100, Wez Furlong wrote:
> I'm on the verge of checking-in my work-so-far (it can be enabled by 
>--enable-php-streams) so that others can try it and comment.  In particular, I would 
>like someone who knows buffers to review the buffering - I've borrowed code from 
>fsock.c but it looks like a memory hog to me, and doesn't allow buffered writes.

And I need this for IPv6 work. I've also been waiting with further IPv6
work since there seems some people have problems with getaddrinfo() which
is used for fopen(). I'm not quite sure how much attention the bug reports
deserves. It's hard to know if it's caused by broken installations bad
implementations on some systems or whatever. Anyway I'm tempted to go on
with the IPv6 implementation anyway, perhaps it's best to do that in 4.1
and leave 4.0 like it is now. Other applications are also starting to use
getaddrinfo() so I expect people will have to fix their setups anyway soon,
or that bad implementations will be fixed and people upgrade. We could of
course have a configure option for turning it on. Switching to getaddrinfo()
is good in other ways too though, the main point perhaps is that it's thread
safe. Hope this made some sense, just some quick thoughts. Would be nice
with some input regarding how important you think IPv6 support is, and how
much breakage we can allow and ideas for how to cope with it.

One thing I'm planning to do RSN, hopefully in 4.0, is persistent LDAP
connections.

Stig
(the other one)

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] documenting extensions

[Stig Venaas]

On Mon, Apr 02, 2001 at 02:07:27PM +0100, Wez Furlong wrote:
> On 2001-04-02 13:43:18, "Stig Venaas" <[EMAIL PROTECTED]> wrote:
> > On Mon, Apr 02, 2001 at 01:42:40PM +0100, Wez Furlong wrote:
> > > Can anyone give me some pointers on how I might go about documenting the openSSL 
>extension?
> > > ATM, there is a readme, but I would like to put this stuff in the manual, with 
>some examples.
> > There are some docs, see http://www.php.net/manual/en/ref.openssl.php
> > Perhaps more info should be added.
> 
> It's time I updated my local copy of the docs - I didn't know those existed!
> 
> OK, so how do I add docs for my new functions?  Should I pass them on to you?
> 
> > How's your OpenSSL work going?
> 
> Pretty good - I just added some S/MIME functions to CVS (I don't know if you saw the 
>commit messages; I sent a mail to the list too).

Great! I didn't see it, have been too busy. I was thinking slightly of doing
it some time, glad you did it. There's been a few asking for it.

Don't you have CVS access to the manual? I think the tree is called manual,
just try to check out manual instead of php4.

> Those big changes to the file handling for the whole of PHP we discussed a couple of 
>weeks ago are on temporary hold - I might get time to make a start at the weekend.  
>It's a big job and I don't want to interfere with ongoing development here right at 
>this moment in time.

Right. I was just wondering, no hurry...

Stig

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] documenting extensions

[Stig Venaas]

Hi

On Mon, Apr 02, 2001 at 01:42:40PM +0100, Wez Furlong wrote:
> Can anyone give me some pointers on how I might go about documenting the openSSL 
>extension?
> 
> ATM, there is a readme, but I would like to put this stuff in the manual, with some 
>examples.

There are some docs, see http://www.php.net/manual/en/ref.openssl.php
Perhaps more info should be added.

How's your OpenSSL work going?

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #9808 Updated: crypt function not supported

[Stig Venaas]

On Sat, Mar 17, 2001 at 04:20:47PM -, [EMAIL PROTECTED] wrote:
> ID: 9808
> User Update by: [EMAIL PROTECTED]
> Status: Open
> Bug Type: Feature/Change Request
> Description: crypt function not supported
> 
> what other option to crypt function 
> that would be compactable with windows system.

If you use PHP with the OpenSSL extension you get crypt() with the
OpenSSL library.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #9794: array_keys resets the array pointer and can not be used when looping

[Stig Venaas]

On Fri, Mar 16, 2001 at 11:21:39AM -0600, Andrei Zmievski wrote:
> On Fri, 16 Mar 2001, Daniel Beckham wrote:
> > Awesome.  Are you planning to just fix the array_keys function, or will
> > there be a change as to how the array functions work with the array
> > pointers?
> 
> It'll be on a case-by-case basis. Some functions do need to move the
> pointers.

It seems like this is a common problem, I think perhaps most of the
PHP code (the C code) could be made cleaner if the Zend API separated
pointers from the array structure. So that one could create a pointer
and pass it as an argument to Zend hash functions, or something like
that. It could be useful to have several pointers at once. One other
option could be to have a pointer stack per hash, with two hash
functions for pushing and popping the current pointer on/off the
stack.

A final option. It's easy for the C code using the Zend API to save the
hash key for the element that the pointer currently points to. If there
was a Zend function for setting the pointer (taking hash key as argument),
it would be easier for the PHP C code to save and restore the pointer.

Well, just some quick thoughts written down in a couple of minutes, there
might be better alternatives, but I think one should consider some general
ways of solving this problem.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #8856 Updated: gethostbyname returns hostname instead of adress

[Stig Venaas]

On Sun, Mar 11, 2001 at 10:28:00PM -0800, [EMAIL PROTECTED] wrote:
> > For at least some months, gethostbyname() in sockets.c has
> > been replaced by gethostbyname() in ext/standard/dns.c
> > which does
> 
> sockets.c in ext/sockets? That has been #if 0'd out ever since it was
> originally written in there (I wrote it, not noticing that there was
> already one in the standard base. Oops.)

I wrote at least, because I didn't bother to check older sources.
Makes me wonder how the report could point to gethostbyname in
sockets.c

Thanks for the clarification,

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: SV: [PHP-DEV] The new design

[Stig Venaas]

On Thu, Mar 08, 2001 at 07:17:42PM +0100, Björn Schotte wrote:
> * Jim Winstead wrote:
> > the reason i don't mind seeing it gone from the main page is that i think
> > having two search-like boxes on the same page that behave differently is
> > confusing.
> 
> Have a look at http://www.php-center.de/ - on the left
> side, there's the normal search box, on the right side
> the "Quickref"-Box.

I would prefer one search box, less confusing and you can then also in
many browsers just press  to start searching. I like the way it
is now with a list to select search target. What I think perhaps should
be added, is simply a link to http://www.php.net/manual-lookup.php. One
can get there by searching for a non-existing function, but a link could
be good.

I generally like the new cleaner design.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SSL -> joining sockets and files

[Stig Venaas]

On Thu, Mar 01, 2001 at 07:14:18AM +0200, Andi Gutmans wrote:
> This sounds pretty good. I'll try and look at the code this weekend. Some 
> of the code is really ugly especially the legacy code.

Yes, I like it too, and it is something I've been halfway thinking of
myself because of IPv6. Some of this will help IPv6 since I need to
know if a socket is AF_INET, AF_LOCAL or AF_INET6 when it's passed
around. Currently getsockname is used in socket.c, Sascha and me were
thinking of a solution a bit like this.

I also like the thought of modularizing fopen-wrappers completely,
in the future it could be possible to say dynamically load modules
(PEAR or whatever) depending on the URL scheme.

Busy with other fun programming projects at the moment,

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SSL -> joining sockets and files (resent)

[Stig Venaas]

On Wed, Feb 28, 2001 at 05:12:55PM +, Wez Furlong wrote:
> I think what we need depends on how far we are willing to go to make
> the codebase nicer.  Andi Gutmans suggested that it would be nice
> to nuke all the checks for sockets in the code; depending on how far
> we go towards that ideal, we might need to approach this in a different
> way.

Yes, and I think it's a good idea.
> 
> The problem we have is that file handles in php can be regular files
> or sockets, but we have to use either stdio FILEs or unix/posix sockets
> to represent them, and the php code has to take special steps whenever
> it needs to write to a file.
> 
> This causes a conflict in the case of SSL enabled sockets because the
> thing that is passed back is neither a socket nor a FILE, but does
> have an underlying socket, hence the "cookie" and socketd parameters/
> returns from the abstraction.
> 
> If we expand the abstraction to cover regular files as well as sockets,
> would it be worth it?

I don't think it's that hard, but I haven't really thought it through.
What you called sockbuf could contain both socket and file stuff by
either put it all together in one large structure, or use union or a
pointer to either a file or a socket structure.

Basically you could have something like:

php_iobuf {
struct php_io_ops * ops;
void * cookie;
};

where cookie can be a pointer to file or socket structure or something
else. The code can do say ops->write(cookie, data) for both files and
sockets. You have different write functions for files, normal tcp,
SSL etc, and the cookie points to php_filebuf, php_sockbuf or what-
ever is needed for that type. The write function for files is declared
like say write(struct * php_filebuf, char *data). I think it might be
enough to have php_io_ops contain read(), write() and close() but I'm
not sure. If you do all this you can have very different code and data
for files, sockets, SSL etc. while the code that uses them simply
passes around a pointer to a php_iobuf structure (that is set up when
file is opened or socket is created (and possibly connected etc.), and
calls the write/read/close functions with the cookie.

I could try to describe it more carefully, but I think you understand
my point.

> I'm going to look into it in more depth and come back with more info
> about where we are using this stuff and where we check for sockets,
> and think some more about the open/connect/construct part of it.

Great,

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SSL socket support (LONG!)

[Stig Venaas]

On Mon, Feb 26, 2001 at 11:39:51PM +, Wez Furlong wrote:
> When opening a socket there are 3 stages (and thus operations on the socket):
> 
> 1. Create a socketd of appropriate domain/type/family (socket(2))
> 2. resolve the address to connect to (domain specific)
> 3. make the connection (connect_nonb)

The resolving isn't always done with a socket.

> If we bring this together (and borrow from fopen_wrappers) we can have an extensible 
>socket abstraction, where the protocol part of the hostname from the fsockopen call 
>determines which underlying socket family to use.

But with for instance IPv6, you won't know what socket you need until
you're done with the resolving. That's why hostconnect() is like it
is. It even needs to connect before it knows what socket to use. That
is, it creates a socket for each connect (which may be AF_LOCAL,
AF_INET, AF_INET6), but returns with one socket in the end, after a
successfull connect. I think hostconnect() shouldn't use sockbuf
for it's work, but should return a sockbuf, probably with default
ops filled in, the caller can if it likes replace the ops with
it's own, currently only SSL perhaps. Some future use could be
compression perhaps, don't know.

I'm not convinced we should put socket(), resolve() etc. into the
structure. I agree that we need those, and others, but I don't see
the value of putting them in a structure.

For SSL it should be possible to connect() as usual using
hostconnect() and then do the SSL negotiation, right?

> The protocol name would map to a php_socket_ops structure, which might look 
>something like this:
> 
> struct php_socket_ops {
> int (*socket)(void ** cookie, socklen_t * addrlen);
> int (*resolve)(void * cookie, struct sockaddr * addr, char * hostname, unsigned 
>short port);
> int (*connect)(void * cookie, struct sockaddr * addr, struct timeval * timeout);
> int (*strerror)(void * cookie, int errno, char * buf, size_t buflen);
> int (*close)(void * cookie);
> size_t (*read)(void * cookie, char * buf, size_t buflen);
> size_t (*write)(void * cookie, char * buf, size_t buflen);
> };

close, read and write is fine, we need that abstraction. I think
perhaps we should have destruct() rather than close() where close()
first calls destruct to let for instance SSL clean up whatever is
needed, and then do the normal socket close and free the php_sockbuf
structure. By abstracting read and write, it could be possible to
put fopen_wrappers in extensions (completely modularized), seems
sensible to me to put the SSL wrapper in the openssl extension.

I think we need the sockbuf abstraction, so I agree on the general
lines.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SSL socket support

[Stig Venaas]

On Mon, Feb 26, 2001 at 01:31:05AM -, Wez Furlong wrote:
> I've been reviewing my relatively crude patch from September last year that
> provided transparent SSL socket access to PHP via the php functions
> fsockopen, fread etc. etc.

Great, I was wondering what happened, was considering doing something
myself.

> Would it be worthwhile making my changes more future proof by making an
> abstraction layer, in the
> same vein as fopen cookie (used by the zlib extension) ?
> 
> php_sockbuf {
>   ...
>   void * cookie;
>   size_t (*reader)(void * cookie, char * buffer, size_t size);
>   size_t (*writer)(void * cookie, char * buffer, size_t size);
>   void (*closer)(void * cookie);
> }
> 
> For normal sockets, cookie would be set to the descriptor and the
> reader/writer/closer functions
> set to the regular calls.  For SSL sockets the cookie would be the SSL
> pointer and the reader/writer/closer functions would be the SSL equivalents
> etc.

Sounds good to me. It's also impossible in a portable way to know if a
socket is AF_INET, AF_INET6 or AF_LOCAL, so for socket() function etc.
I've been thinking of doing something like this to store what domain
a socket is in (maybe type and protocol too). So I think that all
sockets created should have an associated structure, for the low level
PHP socket functions, we only need type at the moment, but it doesn't
hurt that much if there are some extra fields. I've been thinking of
proposing (and doing) this for a while, but I haven't had time to study
the code carefully enough to determine what's the best way.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RE: PHP 4.0 Bug #9351 Updated: LDAP_SEARCH

[Stig Venaas]

On Wed, Feb 21, 2001 at 08:49:25AM +0800, nikony wrote:
> I have thought about that but as you know, it's now a fault of LDAP Server. I use 
>open ldap and when i use command line:
> ldapsearch -p 999 -h localhost -b ...  "(date >=20010116)"
> it works! and even more:
> ldapsearch -p 999 -h localhost -b ...  "(&(date >=20010116)(date<=20010120))"
> It's puzzling,right?

Yes. I just did a test and it worked well for me! PHP doesn't do anything
with the string you pass as filter, it's simply passed to the ldap_search
function of the LDAP library. I did a test with OpenLDAP 2.0.x libraries
and server and it worked well. What is important is that the attribute
has defined ORDERING in the schema, for example:

ORDERING caseIgnoreOrderingMatch

If it isn't, it shouldn't work neither with PHP nor ldapsearch. Anyway,
it worked, and I can't see any reason it shouldn't.

I have a server up and running that you could test against if you like.
Here's the PHP code I used:

$ds=ldap_connect("ldap://silkesvarten.uninett.no/");
if ($ds) {
$sr=ldap_search($ds,"dc=my-domain,dc=com", "ttl<=14400");
echo "Search result is $sr \n";
echo "Number of entires returned is ", ldap_count_entries($ds,$sr), "\n";
$info = ldap_get_entries($ds, $sr);
echo "Data for ", $info["count"], " items returned:\n";
for ($i=0; $i<$info["count"]; $i++) {
  echo "dn is: ", $info[$i]["dn"], "\n";
  echo "dc : ", $info[$i]["dc"][0], "\n";
  echo "ttl: ", $info[$i]["ttl"][0], "\n\n";
}
ldap_close($ds);
} else {
echo "Unable to connect to LDAP server";
}

If this fails I suspect the LDAP library (which one?), if it works it's
your LDAP server (which one?) and the attribute definition is the most
likely cause. But if your ldapsearch worked it can't be the server, so
I'm puzzled. Please try my script anyway. Could I test against your
server?

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found

[Stig Venaas]

On Tue, Feb 20, 2001 at 08:27:59AM -0600, Andrei Zmievski wrote:
> in_array() used to move the pointer to the entry found, but people
> complained about it so I remove it... :)

And I thought it was neat, can't please everyone I guess (:

There seems to be a general problem with array functions and people
that want the pointer to be preserved. Rather than making functions
always do this (which makes them slower and is generally a pain) or
adding extra options to a lot of functions, how about a function
for setting the pointer?

I could in order to save the position do $key = key($arr). To
restore it later, I could then do something like array_setpos($key).
I'm not sure if the Zend API allows for setting the position without
looping through the array though. If array_setpos() is passed a non-
existing key it should return FALSE, else TRUE.

What do you think?

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]