Re: [PHP-DEV] Question about socket ext. file descriptors

2001-03-30 Thread chrisv

On Thu, 29 Mar 2001, Lars Torben Wilson wrote:

 Zeev Suraski writes:
  Note that the situation isn't as bad as you thought - it's not that it's 
  not using the resource mechanism.  It is, if it wasn't, we'd be getting 
  loads of complaints from people running out of descriptors very 
  quickly.  It just uses old, PHP 3 style resources, of type 
  IS_LONG.  They're still destroyed when the request ends, so it's all safe 
  and all.  It simply doesn't use the PHP 4 style, of type IS_RESOURCE, which 
  are actually destroyed when they're no longer needed.  It's a good idea to 
  update this code, but it's not very dangerous the way it is now.
 
 This doesn't look like what I remember from PHP...for instance, send()
 definitely isn't using any form of resources.
 
  Lars - apparently you got it wrong;  The integers you are getting are *not* 
  file descriptors.  They're resource handles, of type IS_LONG.  They might 
  accidentally correspond to the file descriptors, but it'd be complete 
  coincidence.  In short, regardless of whether we upgrade the file functions 
  to use IS_RESOURCE resources or not, what they return cannot be relied upon 
  as file descriptor numbers, simply because they're not.
  
  I hope that clears it up...
  
  Zeev
 
 I hate to argue with you :) but this sure looks like it's passing back
 the descriptor (I could be missing something so if I am just shoot
 me):
 
snip

Nope, you aren't missing anything. The extension, I admit, is breaking
some rules -- negative values instead of false for return values for
example. OTOH, it *is* perfectly possible, for example, that
socket() might return 0, which evaluates to false and is yet a valid file
descriptor.

The reason for returning file descriptors instead of resources was
primarily select(). One thing I was considering doing was writing a file
descriptor table (an fd_set perhaps) that keeps track of the open file
descriptors, and at the end of the request (PHP_RSHUTDOWN...) closes all
of the open sockets.

I'm currently updating my CVS tree so I can update the current source with
something to make sure that stuff opened here is closed at the end of
it. For this, I'm not too fond of going the resource route for it, simply
because I know people are more familiar with the C interfaces to
socket() and friends (I know I'm not alone in this, but if I seem to be,
feel free to speak up now).. so it makes the interfaces more familiar to
people who would want to use it (and since I tried to keep the interfaces
as similar as possible, it also means that people don't have to go running
to the manual for everything except for the few oddities .. 'man socket'
will tell you all you need to know about socket() on any decent *nix
system.)

I'm attempting to compile my fix for it now, will commit soon if compile
goes well.

Chris



-- 
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] Question about socket ext. file descriptors

2001-03-30 Thread Zeev Suraski

At 20:11 30/3/2001, [EMAIL PROTECTED] wrote:
I'm currently updating my CVS tree so I can update the current source with
something to make sure that stuff opened here is closed at the end of
it. For this, I'm not too fond of going the resource route for it, simply
because I know people are more familiar with the C interfaces to
socket() and friends (I know I'm not alone in this, but if I seem to be,
feel free to speak up now).. so it makes the interfaces more familiar to
people who would want to use it (and since I tried to keep the interfaces
as similar as possible, it also means that people don't have to go running
to the manual for everything except for the few oddities .. 'man socket'
will tell you all you need to know about socket() on any decent *nix
system.)

It's a pretty clear cut here - keeping the rules of PHP comes before 
similarity to the C interface.  This covers the fact that failure should be 
denoted by a false return value, and that that things such as file or 
socket descriptors should be returned as resource handles.  Having people 
use the UNIX 2/3 man pages to understand what the PHP functions do isn't 
considered a significant benefit - people are likely to check the PHP 
manual and not the UNIX manual anyway (man pages are just another type of a 
manual, hence their name :)
Moving this code to use the standard PHP interface is something that should 
be done for 4.0.6.

Zeev


-- 
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] Question about socket ext. file descriptors

2001-03-29 Thread Andi Gutmans

Why do you need to rely on such behavior? Are you trying to do something 
naught? :)
I think in general it's not a good idea to rely on the value and type of 
resources (even though this is an integer).
I'm not quite sure why it returns integers and not resources. Looks like a 
bad thing to me as the extension can easily have file descriptor leaks. The 
socket should really be saved either in the resource list or in a socket 
extension local list in order to be able to cleanup at shutdown.
I think in the meanwhile you should assume it might change to using resources.

Andi

At 10:56 PM 3/28/2001 -0800, Lars Torben Wilson wrote:

At present, the sockets extension uses integers as file descriptors
(e.g. socket() return value). At first I thought maybe they should
have been resources until I tried writing some socket code, when I
realized that it's easier under many circumstances for them to be
ints. Is this going to be behaviour that can be relied upon?

Thanks,

Torben


--
++
|Torben Wilson [EMAIL PROTECTED]Adcore Finland|
|http://www.coastnet.com/~torbenhttp://www.adcore.com|
|Ph: 1.604.709.0506 [EMAIL PROTECTED]|
++

--
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 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] Question about socket ext. file descriptors

2001-03-29 Thread Andi Gutmans

Lars,

I understand what you're saying but there is one important problem with the 
current implementation which I think outweighs everything else. The fact 
that right now you are likely to leak file descriptors. This is very bad 
especially as Apache processes live for many requests. If the person 
forgets to close the socket(), his program exits before it reaches that 
code, or someone presses the STOP button on his browser PHP will leak file 
descriptors. Very quickly the Apache process will have no file descriptors 
left. This has to be fixed. I prefer seeing it fixed with resources but in 
the least it should be fixed not to leak fd's even if you go with the 
integer fix implementation. But it is not very PHP to do that. You already 
have an fd resource as far as I know in ext/standard so you can use that.

Andi

At 02:02 AM 3/29/2001 -0800, Lars Torben Wilson wrote:
Andi Gutmans writes:
  Why do you need to rely on such behavior? Are you trying to do something
  naught? :)
  I think in general it's not a good idea to rely on the value and type of
  resources (even though this is an integer).
  I'm not quite sure why it returns integers and not resources. Looks like a
  bad thing to me as the extension can easily have file descriptor leaks. 
 The
  socket should really be saved either in the resource list or in a socket
  extension local list in order to be able to cleanup at shutdown.
  I think in the meanwhile you should assume it might change to using 
 resources.
 
  Andi

That was what I had been thinking, until I started using
select(). Since select() needs to know the max fd # you're working
with, it's easy to have it as an int. Unless, of course, select()'s
PHP implementation is updated to automatically take this into
account. I could always parse the 'Resource #n' string, but that is
clumsy. There are other things as well, but this is the first one to
come to mind.

I totally agree that in general it's a good idea to use resources and
leave the housekeeping to PHP, but in situations like this I wonder if
the usefulness of the int descriptor doesn't outweight the benefit of
turning it into a resource.

Basically, I guess I'm approaching socket programming in PHP from a C
perspective, and thinking that others might as well. Having the
descriptors as ints does tend to relieve some aches, but it might be
more PHP-like to move that behind a resourse type and let PHP keep
track of the highest fd (for stuff like select()).

I guess I also sorta think that when you start messing around with
stuff like fd_set() and select(), you expect to be given enough rope
to hang yourself with. :)

I've no particular leaning to one side or the other, but I'd like to
know what people think about this.


Thanks again,

Torben

  At 10:56 PM 3/28/2001 -0800, Lars Torben Wilson wrote:
 
  At present, the sockets extension uses integers as file descriptors
  (e.g. socket() return value). At first I thought maybe they should
  have been resources until I tried writing some socket code, when I
  realized that it's easier under many circumstances for them to be
  ints. Is this going to be behaviour that can be relied upon?
  
  Thanks,
  
  Torben
  
  
  --
  ++
  |Torben Wilson [EMAIL PROTECTED]Adcore Finland|
  |http://www.coastnet.com/~torben   http://www.adcore.com|
  |Ph: 1.604.709.0506 [EMAIL PROTECTED]|
  ++
  
  --
  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]
 

--
++
|Torben Wilson [EMAIL PROTECTED]Adcore Finland|
|http://www.coastnet.com/~torben   http://www.adcore.com|
|Ph: 1.604.709.0506 [EMAIL PROTECTED]|
++


-- 
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] Question about socket ext. file descriptors

2001-03-29 Thread Zeev Suraski

Note that the situation isn't as bad as you thought - it's not that it's 
not using the resource mechanism.  It is, if it wasn't, we'd be getting 
loads of complaints from people running out of descriptors very 
quickly.  It just uses old, PHP 3 style resources, of type 
IS_LONG.  They're still destroyed when the request ends, so it's all safe 
and all.  It simply doesn't use the PHP 4 style, of type IS_RESOURCE, which 
are actually destroyed when they're no longer needed.  It's a good idea to 
update this code, but it's not very dangerous the way it is now.

Lars - apparently you got it wrong;  The integers you are getting are *not* 
file descriptors.  They're resource handles, of type IS_LONG.  They might 
accidentally correspond to the file descriptors, but it'd be complete 
coincidence.  In short, regardless of whether we upgrade the file functions 
to use IS_RESOURCE resources or not, what they return cannot be relied upon 
as file descriptor numbers, simply because they're not.

I hope that clears it up...

Zeev

At 14:06 29/3/2001, Andi Gutmans wrote:
Lars,

I understand what you're saying but there is one important problem with 
the current implementation which I think outweighs everything else. The 
fact that right now you are likely to leak file descriptors. This is very 
bad especially as Apache processes live for many requests. If the person 
forgets to close the socket(), his program exits before it reaches that 
code, or someone presses the STOP button on his browser PHP will leak file 
descriptors. Very quickly the Apache process will have no file descriptors 
left. This has to be fixed. I prefer seeing it fixed with resources but in 
the least it should be fixed not to leak fd's even if you go with the 
integer fix implementation. But it is not very PHP to do that. You already 
have an fd resource as far as I know in ext/standard so you can use that.

Andi

At 02:02 AM 3/29/2001 -0800, Lars Torben Wilson wrote:
Andi Gutmans writes:
  Why do you need to rely on such behavior? Are you trying to do something
  naught? :)
  I think in general it's not a good idea to rely on the value and type of
  resources (even though this is an integer).
  I'm not quite sure why it returns integers and not resources. Looks like a
  bad thing to me as the extension can easily have file descriptor 
 leaks. The
  socket should really be saved either in the resource list or in a socket
  extension local list in order to be able to cleanup at shutdown.
  I think in the meanwhile you should assume it might change to using 
 resources.
 
  Andi

That was what I had been thinking, until I started using
select(). Since select() needs to know the max fd # you're working
with, it's easy to have it as an int. Unless, of course, select()'s
PHP implementation is updated to automatically take this into
account. I could always parse the 'Resource #n' string, but that is
clumsy. There are other things as well, but this is the first one to
come to mind.

I totally agree that in general it's a good idea to use resources and
leave the housekeeping to PHP, but in situations like this I wonder if
the usefulness of the int descriptor doesn't outweight the benefit of
turning it into a resource.

Basically, I guess I'm approaching socket programming in PHP from a C
perspective, and thinking that others might as well. Having the
descriptors as ints does tend to relieve some aches, but it might be
more PHP-like to move that behind a resourse type and let PHP keep
track of the highest fd (for stuff like select()).

I guess I also sorta think that when you start messing around with
stuff like fd_set() and select(), you expect to be given enough rope
to hang yourself with. :)

I've no particular leaning to one side or the other, but I'd like to
know what people think about this.


Thanks again,

Torben

  At 10:56 PM 3/28/2001 -0800, Lars Torben Wilson wrote:
 
  At present, the sockets extension uses integers as file descriptors
  (e.g. socket() return value). At first I thought maybe they should
  have been resources until I tried writing some socket code, when I
  realized that it's easier under many circumstances for them to be
  ints. Is this going to be behaviour that can be relied upon?
  
  Thanks,
  
  Torben
  
  
  --
  ++
  |Torben Wilson [EMAIL PROTECTED]Adcore Finland|
  |http://www.coastnet.com/~torben  http://www.adcore.com|
  |Ph: 1.604.709.0506 [EMAIL PROTECTED]|
  ++
  
  --
  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]
 

--
++
|Torben Wilson [EMAIL PROTECTED]Adcore Finland|

Re: [PHP-DEV] Question about socket ext. file descriptors

2001-03-29 Thread Andi Gutmans

At 03:35 PM 3/29/2001 +0200, Zeev Suraski wrote:
Note that the situation isn't as bad as you thought - it's not that it's 
not using the resource mechanism.  It is, if it wasn't, we'd be getting 
loads of complaints from people running out of descriptors very 
quickly.  It just uses old, PHP 3 style resources, of type 
IS_LONG.  They're still destroyed when the request ends, so it's all safe 
and all.  It simply doesn't use the PHP 4 style, of type IS_RESOURCE, 
which are actually destroyed when they're no longer needed.  It's a good 
idea to update this code, but it's not very dangerous the way it is now.

I think you are wrong. Look at the function accept_connect(). You are 
creating a new file descriptor and not saving it anywhere!


Lars - apparently you got it wrong;  The integers you are getting are 
*not* file descriptors.  They're resource handles, of type IS_LONG.  They 
might accidentally correspond to the file descriptors, but it'd be 
complete coincidence.  In short, regardless of whether we upgrade the file 
functions to use IS_RESOURCE resources or not, what they return cannot be 
relied upon as file descriptor numbers, simply because they're not.

I hope that clears it up...

Not for me :)

Andi


-- 
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] Question about socket ext. file descriptors

2001-03-29 Thread Andi Gutmans

At 03:47 PM 3/29/2001 +0200, Zeev Suraski wrote:
At 15:41 29/3/2001, Andi Gutmans wrote:
At 03:35 PM 3/29/2001 +0200, Zeev Suraski wrote:
Note that the situation isn't as bad as you thought - it's not that it's 
not using the resource mechanism.  It is, if it wasn't, we'd be getting 
loads of complaints from people running out of descriptors very 
quickly.  It just uses old, PHP 3 style resources, of type 
IS_LONG.  They're still destroyed when the request ends, so it's all 
safe and all.  It simply doesn't use the PHP 4 style, of type 
IS_RESOURCE, which are actually destroyed when they're no longer 
needed.  It's a good idea to update this code, but it's not very 
dangerous the way it is now.

I think you are wrong. Look at the function accept_connect(). You are 
creating a new file descriptor and not saving it anywhere!

So this function may be an exception to the rule.  But generally, all of 
the file/socket functions use ZEND_REGISTER_RESOURCE() or 
zend_list_insert(), so they're fine.

Well we were talking about the ext/socket extension and all functions there 
which create file descriptors are leaking. It's not an exception. Check 
open_listen_sock() and accept_connect().
You were probably looking at the fd set functions which are just 
emalloc()'ed memory. The happen to use resources but even if they hadn't it 
would be a leak which the Zend memory manager would clean up. The file 
descriptors is the real problem.

Andi


-- 
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] Question about socket ext. file descriptors

2001-03-29 Thread Zeev Suraski

ext/sockets does indeed appear to be broken;  It doesn't obey the standard 
PHP return value rules at all (errors are negative numbers instead of 
false, resource are passed back as-is instead of as resources).

I was actually looking at the other socket functions, fsockopen() and 
friends.  They're ok.

Zeev

At 15:52 29/3/2001, Andi Gutmans wrote:
Well we were talking about the ext/socket extension and all functions 
there which create file descriptors are leaking. It's not an exception. 
Check open_listen_sock() and accept_connect().
You were probably looking at the fd set functions which are just 
emalloc()'ed memory. The happen to use resources but even if they hadn't 
it would be a leak which the Zend memory manager would clean up. The file 
descriptors is the real problem.

Andi

--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] Question about socket ext. file descriptors

2001-03-29 Thread Lars Torben Wilson

Zeev Suraski writes:
 Note that the situation isn't as bad as you thought - it's not that it's 
 not using the resource mechanism.  It is, if it wasn't, we'd be getting 
 loads of complaints from people running out of descriptors very 
 quickly.  It just uses old, PHP 3 style resources, of type 
 IS_LONG.  They're still destroyed when the request ends, so it's all safe 
 and all.  It simply doesn't use the PHP 4 style, of type IS_RESOURCE, which 
 are actually destroyed when they're no longer needed.  It's a good idea to 
 update this code, but it's not very dangerous the way it is now.

This doesn't look like what I remember from PHP...for instance, send()
definitely isn't using any form of resources.

 Lars - apparently you got it wrong;  The integers you are getting are *not* 
 file descriptors.  They're resource handles, of type IS_LONG.  They might 
 accidentally correspond to the file descriptors, but it'd be complete 
 coincidence.  In short, regardless of whether we upgrade the file functions 
 to use IS_RESOURCE resources or not, what they return cannot be relied upon 
 as file descriptor numbers, simply because they're not.
 
 I hope that clears it up...
 
 Zeev

I hate to argue with you :) but this sure looks like it's passing back
the descriptor (I could be missing something so if I am just shoot
me):

PHP_FUNCTION(socket)
{
zval **domain, **type, **protocol;
int ret;

if (ZEND_NUM_ARGS() != 3 || 
zend_get_parameters_ex(3, domain, type, protocol) == FAILURE) {
WRONG_PARAM_COUNT;
}
multi_convert_to_long_ex(3, domain, type, protocol);

if (Z_LVAL_PP(domain) != AF_INET  Z_LVAL_PP(domain) != AF_UNIX) {
php_error(E_WARNING, "invalid socket domain specified - assuming 
AF_INET");
Z_LVAL_PP(domain) = AF_INET;
}

if (Z_LVAL_PP(type)  10) {
php_error(E_WARNING, "invalid socket type specified - assuming 
SOCK_STREAM");
Z_LVAL_PP(type) = SOCK_STREAM;
}

ret = socket(Z_LVAL_PP(domain), Z_LVAL_PP(type), Z_LVAL_PP(protocol));

RETURN_LONG(((ret  0) ? -errno : ret));
}

 At 14:06 29/3/2001, Andi Gutmans wrote:
 Lars,
 
 I understand what you're saying but there is one important problem with 
 the current implementation which I think outweighs everything else. The 
 fact that right now you are likely to leak file descriptors. This is very 
 bad especially as Apache processes live for many requests. If the person 
 forgets to close the socket(), his program exits before it reaches that 
 code, or someone presses the STOP button on his browser PHP will leak file 
 descriptors. Very quickly the Apache process will have no file descriptors 
 left. This has to be fixed. I prefer seeing it fixed with resources but in 
 the least it should be fixed not to leak fd's even if you go with the 
 integer fix implementation. But it is not very PHP to do that. You already 
 have an fd resource as far as I know in ext/standard so you can use that.
 
 Andi
 
 At 02:02 AM 3/29/2001 -0800, Lars Torben Wilson wrote:
 Andi Gutmans writes:
   Why do you need to rely on such behavior? Are you trying to do something
   naught? :)
   I think in general it's not a good idea to rely on the value and type of
   resources (even though this is an integer).
   I'm not quite sure why it returns integers and not resources. Looks like a
   bad thing to me as the extension can easily have file descriptor 
  leaks. The
   socket should really be saved either in the resource list or in a socket
   extension local list in order to be able to cleanup at shutdown.
   I think in the meanwhile you should assume it might change to using 
  resources.
  
   Andi
 
 That was what I had been thinking, until I started using
 select(). Since select() needs to know the max fd # you're working
 with, it's easy to have it as an int. Unless, of course, select()'s
 PHP implementation is updated to automatically take this into
 account. I could always parse the 'Resource #n' string, but that is
 clumsy. There are other things as well, but this is the first one to
 come to mind.
 
 I totally agree that in general it's a good idea to use resources and
 leave the housekeeping to PHP, but in situations like this I wonder if
 the usefulness of the int descriptor doesn't outweight the benefit of
 turning it into a resource.
 
 Basically, I guess I'm approaching socket programming in PHP from a C
 perspective, and thinking that others might as well. Having the
 descriptors as ints does tend to relieve some aches, but it might be
 more PHP-like to move that behind a resourse type and let PHP keep
 track of the highest fd (for stuff like select()).
 
 I guess I also sorta think that when you start messing around with
 stuff like fd_set() and select(), you expect to be given enough rope
 to hang yourself with. :)
 
 I've no particular leaning to one side or the other, 

Re: [PHP-DEV] Question about socket ext. file descriptors

2001-03-29 Thread Lars Torben Wilson

Zeev Suraski writes:
 ext/sockets does indeed appear to be broken;  It doesn't obey the standard 
 PHP return value rules at all (errors are negative numbers instead of 
 false, resource are passed back as-is instead of as resources).
 
 I was actually looking at the other socket functions, fsockopen() and 
 friends.  They're ok.
 
 Zeev

Ah. Please to be disregarding my last post then. :)

I guess sockets can be considered 'likely to change somewhat' before
it becomes non-experimental, then. Which is actually the info I was
after. Thanks for the explanations from both of you guys, though.

Slightly different topic--is it a problem that call-time pass-by-ref
is being deprecated but several functions require it in order to work?

 At 15:52 29/3/2001, Andi Gutmans wrote:
 Well we were talking about the ext/socket extension and all functions 
 there which create file descriptors are leaking. It's not an exception. 
 Check open_listen_sock() and accept_connect().
 You were probably looking at the fd set functions which are just 
 emalloc()'ed memory. The happen to use resources but even if they hadn't 
 it would be a leak which the Zend memory manager would clean up. The file 
 descriptors is the real problem.
 
 Andi
 
 --
 Zeev Suraski [EMAIL PROTECTED]
 CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/
 
 
 -- 
 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]
 

-- 
++
|Torben Wilson [EMAIL PROTECTED]Adcore Finland|
|http://www.coastnet.com/~torbenhttp://www.adcore.com|
|Ph: 1.604.709.0506 [EMAIL PROTECTED]|
++

-- 
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] Question about socket ext. file descriptors

2001-03-29 Thread Lars Torben Wilson

Andi Gutmans writes:
 At 12:44 PM 3/29/2001 -0800, Lars Torben Wilson wrote:
 
 Slightly different topic--is it a problem that call-time pass-by-ref
 is being deprecated but several functions require it in order to work?
 
 It is possible. Functions which require their argument by reference should 
 ask for it to be sent by reference and not expect the calling person to 
 write foo($bar). The BY_REF_ALLOW is a remainder of PHP 3 and is obsolete 
 with today's reference counting (I'm pretty sure about this but I just woke 
 up so I might be saying BS :).
 
 Andi

OK, thanks. I keep getting bitten by functions which don't work
without calling them like foo($bar), but PHP complains about
that. 'Course I can always tell PHP to cope with it in php.ini, but
that seems more like ignoring the problem than fixing it. :)

Thanks for all the info,

Torben


-- 
++
|Torben Wilson [EMAIL PROTECTED]Adcore Finland|
|http://www.coastnet.com/~torbenhttp://www.adcore.com|
|Ph: 1.604.709.0506 [EMAIL PROTECTED]|
++

-- 
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]