[PHP-DEV] Bug #14894: socket_read should return string, not int
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.0 PHP Bug Type: Documentation problem Bug description: socket_read should return string, not int http://www.php.net/manual/en/function.socket-read.php Claims to return an int. The prototype should be string socket_read. - AZ -- Edit bug report at: http://bugs.php.net/?id=14894edit=1 -- 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] Bug #14894 Updated: socket_read should return string, not int
ID: 14894 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Linux PHP Version: 4.1.0 New Comment: Examples in mainline socket text should also be updated, they use the bogus version. Previous Comments: [2002-01-06 18:07:39] [EMAIL PROTECTED] http://www.php.net/manual/en/function.socket-read.php Claims to return an int. The prototype should be string socket_read. - AZ Edit this bug report at http://bugs.php.net/?id=14894edit=1 -- 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] Bug #14698: pg_fetch_array() does not require row param
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.0 PHP Bug Type: Documentation problem Bug description: pg_fetch_array() does not require row param array pg_fetch_array (resource result, int row [, int result_type]) makes int row appear required, when it is actually optional. -- Edit bug report at: http://bugs.php.net/?id=14698edit=1 -- 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] Bug #14698 Updated: pg_fetch_array() does not require row param
ID: 14698
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Documentation problem
Operating System: Linux
PHP Version: 4.1.0
Old Assigned To: yohgaki
Assigned To:
New Comment:
Works wonderfully without the row. That's certainly a win convienence wise, especially
for folks coming over from mysql where the loop syntax is trivial
(while $row = fetch())
{}
I'd prefer to see the docs change then the functionality. I'll take a look at the code
itself but it is hard to see how this is a performance loss, most users end up keeping
a counter anyways.
Why do you prefer making the row required? It seems like a silly added restriction,
especially when I bet 80% of the cases where the function is called don't need it.
Previous Comments:
[2001-12-26 02:09:44] [EMAIL PROTECTED]
Additional comment:
All pg_fetch_* works as reporter mentioned, but
DO NOT take advantage of this.
I may change behavior after I check php3 and php4 CVS log :)
[2001-12-26 02:06:55] [EMAIL PROTECTED]
I've checked current code. Reporter is right.
I need to check when this has been changed and I think row should be required
parameter. I'll keep this behavior if and only if this was the implemented from the
beginning :)
(Current code internally advance row in result structure)
So DO NOT take advantage of this.
[2001-12-26 01:57:46] [EMAIL PROTECTED]
array pg_fetch_array (resource result, int row [, int result_type])
makes int row appear required, when it is actually optional.
Edit this bug report at http://bugs.php.net/?id=14698edit=1
--
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] Bug #14698 Updated: pg_fetch_array() does not require row param
ID: 14698
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Documentation problem
Operating System: Linux
PHP Version: 4.1.0
Old Assigned To: yohgaki
Assigned To:
New Comment:
Implemented 6 months ago by jon (1.112) pgsql.c.
Looks reasonable.
Previous Comments:
[2001-12-26 02:13:51] [EMAIL PROTECTED]
Works wonderfully without the row. That's certainly a win convienence wise, especially
for folks coming over from mysql where the loop syntax is trivial
(while $row = fetch())
{}
I'd prefer to see the docs change then the functionality. I'll take a look at the code
itself but it is hard to see how this is a performance loss, most users end up keeping
a counter anyways.
Why do you prefer making the row required? It seems like a silly added restriction,
especially when I bet 80% of the cases where the function is called don't need it.
[2001-12-26 02:09:44] [EMAIL PROTECTED]
Additional comment:
All pg_fetch_* works as reporter mentioned, but
DO NOT take advantage of this.
I may change behavior after I check php3 and php4 CVS log :)
[2001-12-26 02:06:55] [EMAIL PROTECTED]
I've checked current code. Reporter is right.
I need to check when this has been changed and I think row should be required
parameter. I'll keep this behavior if and only if this was the implemented from the
beginning :)
(Current code internally advance row in result structure)
So DO NOT take advantage of this.
[2001-12-26 01:57:46] [EMAIL PROTECTED]
array pg_fetch_array (resource result, int row [, int result_type])
makes int row appear required, when it is actually optional.
Edit this bug report at http://bugs.php.net/?id=14698edit=1
--
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] Bug #14698 Updated: pg_fetch_array() does not require row param
ID: 14698
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Documentation problem
Operating System: Linux
PHP Version: 4.1.0
Old Assigned To: yohgaki
Assigned To:
New Comment:
Sounds good. I think it would be silly to drop this change.
- It does not appear to impact existing code (patch switches based on argument count)
- The reason I discovered it because I was annoyed with what I thought the existing
behavior was.
Good luck with the new maintainership.
Previous Comments:
[2001-12-26 02:26:39] [EMAIL PROTECTED]
Thanks for checking the change :)
I'm the new module maintainer, so I'm asking previous module maintainers about it.
Since MySQL seems it does the same, I'll keep this behavior probably, but it is not a
promise yet. ;)
[2001-12-26 02:19:28] [EMAIL PROTECTED]
Implemented 6 months ago by jon (1.112) pgsql.c.
Looks reasonable.
[2001-12-26 02:13:51] [EMAIL PROTECTED]
Works wonderfully without the row. That's certainly a win convienence wise, especially
for folks coming over from mysql where the loop syntax is trivial
(while $row = fetch())
{}
I'd prefer to see the docs change then the functionality. I'll take a look at the code
itself but it is hard to see how this is a performance loss, most users end up keeping
a counter anyways.
Why do you prefer making the row required? It seems like a silly added restriction,
especially when I bet 80% of the cases where the function is called don't need it.
[2001-12-26 02:09:44] [EMAIL PROTECTED]
Additional comment:
All pg_fetch_* works as reporter mentioned, but
DO NOT take advantage of this.
I may change behavior after I check php3 and php4 CVS log :)
[2001-12-26 02:06:55] [EMAIL PROTECTED]
I've checked current code. Reporter is right.
I need to check when this has been changed and I think row should be required
parameter. I'll keep this behavior if and only if this was the implemented from the
beginning :)
(Current code internally advance row in result structure)
So DO NOT take advantage of this.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=14698
Edit this bug report at http://bugs.php.net/?id=14698edit=1
--
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] Bug #14675: ./configure line not properly reflected in phpinfo()
From: [EMAIL PROTECTED] Operating system: 2.4.7-10smp #1 SMP / RH 7.2 PHP version: 4.1.0 PHP Bug Type: *General Issues Bug description: ./configure line not properly reflected in phpinfo() When compiling PHP statically with Apache I've observed the following strange and very frustrating behavior. in /php ./configure OptionA in /apache ./configure --activate... make then phpinfo() reports the proper ./configure line it was compiled with. Then do something like in /php ./configure --without-mysql in /apache make (using earlier ./configure) now phpinfo() reports the old configuration line, but Mysql for example is now not present. removing config.cache between compiles in /php doesn't fix things, but a make clean does. Doesn't appear to depend on the /apache build process since make clean on the apache side changes nothing, not does a new /apache ./configure. The functionality changes properly in every case. A /php ./configure WITH mysql generates the mysql section in phpinfo(), but the phpinfo() configuration line might remain --without-mysql, even though the mysql extension is listed in the very same phpinfo. Now I'd call this so much nitpicking if I wasn't going to building php a couple of hundred times. I'd obviously like to avoid doing a make clean between each slightly changed build. Since the underlying functionality seems to change properly I'm assuming I either missed some obvious instruction, or that there is simple bug or documentation update that should happen to fix things up. -- Edit bug report at: http://bugs.php.net/?id=14675edit=1 -- 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] Bug #14537: fgetc fails to return single charachter immediatly
From: [EMAIL PROTECTED] Operating system: Linux 2.4.7-10smp i686 PHP version: 4.1.0 PHP Bug Type: Filesystem function related Bug description: fgetc fails to return single charachter immediatly fgetc should have at least the option of returning a single charachter immediatly upon its entry, or another function should be defined (such as getchar()) that achieves similar functionality to fgetc(stdin) which return a single charachter immediatly. The following script allows the user to type more than a single charachter and only returns when the user hits enter. fgetc should simply block until a single charachter is entered and then return. This is missing functionality that can not be worked around easily as far as I can tell. Script: $fp = fopen(php://stdin, r); $char = fgetc($fp); echo $char; -- Edit bug report at: http://bugs.php.net/?id=14537edit=1 -- 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
Sweet to see Apache 2 support availabe (--with-apxs2). Got it up and running under 2.0.16. What's the timeframe look like for this? There's really_silly, includes... Anything I can do to help? August -- 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]
