[PHP-DEV] Bug #12034 Updated: A type-error and a coding-error.
ID: 12034
Updated by: lobbin
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Compile Warning
Operating System:
PHP Version: 4.0.6
New Comment:
What os/compiler are you using?
I'm not getting this with the latest CVS.
R.
Previous Comments:
[2001-07-11 01:58:25] [EMAIL PROTECTED]
1. php_ticks.c, line 55.53: 1506-280 (W) Function argument assignment between types
void* and void(*)(int) is not allowed.
main/php_ticks.c:
PHPAPI void php_remove_tick_function(void (*func)(int))
{
PLS_FETCH();
zend_llist_del_element(PG(tick_functions), (void *)func,
(int(*)(void*,void*))php_compare_tick_functions);
}
I think the 2nd arg of zend_llist_del_element() shoud be:
(void *)func
Not
func
2. output.c, line 154.140: 1506-280 (W) Function argument assignment between types
unsigned int* and int* is not allowed.
ext/standard/output.c:
The final_buffer_len should be defined as uint, not int.
3. zend_extensions.c, line 33.16: 1506-068 (W) Operation between types void* and
int is not allowed.
4. main.c, line 1166.17: 1506-068 (W) Operation between types unsigned char* and
int is not allowed.
5. dl.c, line 136.16: 1506-068 (W) Operation between types void* and int is not
allowed.
All are caused by zend.h - dlfcn.h is not included.
I will report these to Zend.
Edit this bug report at http://bugs.php.net/?id=12034edit=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 #14607 Updated: Nested foreach (on the same array variable) don't work as should
ID: 14607
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows 98
PHP Version: 4.0.6
New Comment:
$tree = Array(
[1] = Array ( [parentid] = 0, [name] = '1' )
[2] = Array ( [parentid] = 0, [name] = '2' )
[3] = Array ( [parentid] = 1, [name] = '1_1' )
[4] = Array ( [parentid] = 3, [name] = '1_1_1' )
[5] = Array ( [parentid] = 3, [name] = '1_1_2' )
[6] = Array ( [parentid] = 4, [name] = '1_1_1_1' )
[7] = Array ( [parentid] = 1, [name] = '1_2' )
[8] = Array ( [parentid] = 7, [name] = '1_2_1' )
[9] = Array ( [parentid] = 2, [name] = '2_1' )
);
// Recursion using a copy of the variable each time
// WORKS
function funktzia1($base,$dir)
{
foreach($dir as $id = $item)
{
if ($item[parentid]==$base)
{
echo
UL\nLI.$item[name]./LIBR\n;
funktzia1($id,$dir);
echo /UL\n;
}
}
}
// Print the tree using the first function
funktzia1(0,$tree);
// Recursion using the same variable - pass by reference (note the before the
$dir)
// DOESN'T WORK
function funktzia2($base,$dir)
{
foreach($dir as $id = $item)
{
if ($item[parentid]==$base)
{
echo
UL\nLI.$item[name]./LIBR\n;
funktzia2($id,$dir);
echo /UL\n;
}
}
}
// Print the tree using the second function
funktzia2(0,$tree);
Previous Comments:
[2001-12-19 18:31:46] [EMAIL PROTECTED]
Please provide a compelte self-contained copypaste ready script.
Feedback.
[2001-12-19 15:17:21] [EMAIL PROTECTED]
1. Actually doing a reset() doesn't work at all.
2. I thought that this was a duplicate of #5052 - but now I see that there's too
different variables there for each level of the nested foreach() - and I use the
same variable.
So it seems that this is not a duplicate after all (corrent me if I'm wrong).
[2001-12-19 15:00:55] [EMAIL PROTECTED]
It seems that this has been pointed out before... Sorry.
But this is still not solved (although the other bug reports about this are already
marked as closed). :(
I only saw a solution of using reset() in the end of the loop, but this doesn't seem
to be a good solution.
Any chances that each foreach() will be made to work on a new copy of the array, so
that nested foreach() will work?
[2001-12-19 14:46:50] [EMAIL PROTECTED]
I have a tree, which is loaded into a variable into the following (hopefully
self-explanatory) structure:
Array(
[1] = Array ( [parentid] = 0, [name] = 1 )
[2] = Array ( [parentid] = 0, [name] = 2 )
[3] = Array ( [parentid] = 1, [name] = 1_1 )
[4] = Array ( [parentid] = 3, [name] = 1_1_1 )
[5] = Array ( [parentid] = 3, [name] = 1_1_2 )
[6] = Array ( [parentid] = 4, [name] = 1_1_1_1 )
[7] = Array ( [parentid] = 1, [name] = 1_2 )
[8] = Array ( [parentid] = 7, [name] = 1_2_1 )
[9] = Array ( [parentid] = 2, [name] = 2_1 )
)
This results in the following three:
+ 1
+ 1_1
+ 1_1_1
+ 1_1_1_1
+ 1_1_2
+ 1_2
+ 1_2_1
+ 2
+ 2_1
I have the following recursive function to draw this tree:
function funktzia($base,$dir)
{
foreach($dir as $id = $item)
{
if ($item[parentid]==$base)
{
echo UL\nLI.$item[name]./LIBR\n;
funktzia($id,$dir);
echo /UL\n;
}
}
}
where `$base' is the current tree node id, and `$dir' is the variable which holds the
tree, as described above.
The function is initially called funktzia(0,$tree);, and the recursively calls
itself.
So far so good.
But if the `$dir' variable is a by-reference parameter (i.e. [...] $dir [...]
instead of [...] $dir [...] as now), or it is defined global within the function
instead of being passed as a parameter (in either way, all recursion level use the
same variable) - it doesn't work.
It draw the tree only while going up levels, but stop when it's time to go back to a
lower level. Or in short, the following tree is drawn instead of the full one:
+ 1
+ 1_1
+ 1_1_1
+ 1_1_1_1
It seems that when we go back to the lower foreach loop, the array pointer it uses
already points to the end of the array (since we just finished doing a foreach loop
on that array in the higher level).
Edit this bug report at http://bugs.php.net/?id=14607edit=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 #14612 Updated: session save handler module uses php_session_register_module() does not work.
ID: 14612 Updated by: derick Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Session related Operating System: Linux PHP Version: 4.0CVS-2001-12-19 New Comment: Move the stuff in MINIT to GINIT, and it shold work again. I was looking into that, but forgot it afterwards. Derick Previous Comments: [2001-12-19 23:50:37] [EMAIL PROTECTED] My description is not correct. There is a way to use external session save handler module. i.e. session_module_name() [2001-12-19 22:01:10] [EMAIL PROTECTED] Addiotinal info: Since session module is initilized at first, there is no way to register external session module. This is critical, I think. Changed status = Critical. [2001-12-19 21:46:07] [EMAIL PROTECTED] Ok. I found the reason and can fix it now. It try to find session module *before* registering. I guess it is due to module initilization order has been changed. (I could use mm module at leat with 4.0.6, IIRC). Questin is: Should it be fixed in session module or module initilization order should be fixed... [2001-12-19 21:10:21] [EMAIL PROTECTED] Starting httpd: Unknown(0) : Fatal error - Cannot find save handler mm /usr/sbin/apachectl startssl: httpd started './configure' \ '--with-apxs' \ '--without-mysql' \ '--without-pear' \ '--enable-debug' \ '--with-mm' \ $@ php.ini session.save_handler=mm files and user modules works, since they are statically defined in ps_modules. Edit this bug report at http://bugs.php.net/?id=14612edit=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 #13378 Updated: Auto session start + obejct
ID: 13378 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.0.6 New Comment: This is already implemented, we have a undocumented functinno for that, but I can't recall the name now :) Derick Previous Comments: [2001-12-19 22:44:45] [EMAIL PROTECTED] Many users want to unserialize/initilize object after session is started, I suppose. Type = Feature Request [2001-09-21 12:42:30] [EMAIL PROTECTED] Well, this is not really a bug , but: When using session.auto_start , there is no way to load a class first, so session objects are pretty much not usable that way. I may be wrong, but I couldn't find any way to do it but doing a session_write_close(); session_start(); However this is not a solution because it wastes resources - writing the session files and opening it again for nothing. I belive that a session_reload() (or another solution for this case) should exist. Edit this bug report at http://bugs.php.net/?id=13378edit=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 #12474 Updated: possible incorrect strtotime handling of -1Month
ID: 12474 Updated by: lobbin Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Date/time related Operating System: Linux (should happen on any) PHP Version: 4.0.4pl1 New Comment: Confirmed with php 4.2.0-dev. print date(d/m/Y, strtotime(1 month ago, strtotime(31 July 2001))).\n; Gives the same error, and that should be correct GNU date syntax? R. Previous Comments: [2001-07-30 20:53:49] [EMAIL PROTECTED] when running ?PHP print date(d/m/Y, strtotime(31 July 2001)).\n; print date(d/m/Y, strtotime(-1 month, strtotime(31 July 2001))).\n; ? it replies with X-Powered-By: PHP/4.0.3pl1 Content-type: text/html 31/07/2001 01/07/2001 of course what it's doing is turning it into 31 june which is then being considered to be the 1 of july.. Should this be right or should strtotime realise that there are 30 days in june and truncate the 31st day? Edit this bug report at http://bugs.php.net/?id=12474edit=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] Re: Bug #14612 Updated: session save handler module uses php_session_register_module() does not work.
Bug Database wrote: ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=14612edit=2 ID: 14612 Updated by: derick Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Session related Operating System: Linux PHP Version: 4.0CVS-2001-12-19 New Comment: Move the stuff in MINIT to GINIT, and it shold work again. I was looking into that, but forgot it afterwards. Derick Thank you. It seems I'm missing something. [yohgaki@dev DEV]$ grep GINIT `find . -name *.[ch]` ./Zend/zend_modules.h:#define GINIT_FUNC_ARGS void ./Zend/zend_modules.h:#define GINIT_FUNC_ARGS_PASSTHRU and #define GINIT_FUNC_ARGS void #define GINIT_FUNC_ARGS_PASSTHRU in zend_modules.h Any clue is appreciated :) -- Yasuo Ohgaki -- 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 #14614: lastchild();
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4.1.0 PHP Bug Type: DOM XML related Bug description: lastchild(); Under PHP 4.06 this works fine : return $parent-lastchild(); Under PHP 4.10 it gives an error: unknown function Did you rename this function or what went wrong ? / Mads -- Edit bug report at: http://bugs.php.net/?id=14614edit=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 #14615: PHP log does not contain proper CRLF's
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4.1.0 PHP Bug Type: Unknown/Other Function Bug description: PHP log does not contain proper CRLF's In the PHP log, new lines are defined only with ASCII 10 (LF), but Windows only recognizes ASCII 13 + ASCII 10 (CRLF) as a new line. This makes the PHP log look like a mess on Windows systems. -- Edit bug report at: http://bugs.php.net/?id=14615edit=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 #13378 Updated: Auto session start + obejct
ID: 13378 Updated by: bernd Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.0.6 New Comment: This is already documented, too http://www.php.net/manual/en/function.unserialize.php (if you thought of that feature.) ATTENTION: for 4.2.0-dev only... Bernd Previous Comments: [2001-12-20 03:48:09] [EMAIL PROTECTED] This is already implemented, we have a undocumented functinno for that, but I can't recall the name now :) Derick [2001-12-19 22:44:45] [EMAIL PROTECTED] Many users want to unserialize/initilize object after session is started, I suppose. Type = Feature Request [2001-09-21 12:42:30] [EMAIL PROTECTED] Well, this is not really a bug , but: When using session.auto_start , there is no way to load a class first, so session objects are pretty much not usable that way. I may be wrong, but I couldn't find any way to do it but doing a session_write_close(); session_start(); However this is not a solution because it wastes resources - writing the session files and opening it again for nothing. I belive that a session_reload() (or another solution for this case) should exist. Edit this bug report at http://bugs.php.net/?id=13378edit=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 #14614 Updated: lastchild();
ID: 14614 Updated by: mfischer Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: DOM XML related Operating System: Windows PHP Version: 4.1.0 New Comment: Yep, its called last_child(). Closing. Previous Comments: [2001-12-20 04:02:01] [EMAIL PROTECTED] Under PHP 4.06 this works fine : return $parent-lastchild(); Under PHP 4.10 it gives an error: unknown function Did you rename this function or what went wrong ? / Mads Edit this bug report at http://bugs.php.net/?id=14614edit=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] Re: Bug #14613: Implement Function/Feature Conformity Tests
Great, Zak!! I was hoping someone start this. I really hope there is a BNF. Simplied one is preferred, it helps to understand what zend expects. (Well I can read lex(flex)/yacc(bison) source, but I'm just lazy enough to understand BNF from them. I guess many programmers are as lazy as me ;) [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Operating system: PHP version: 4.1.0 PHP Bug Type: Feature/Change Request Bug description: Implement Function/Feature Conformity Tests I strongly believe that PHP needs to continue evolving and improving. However, I also recognise the importance of maintaining backwards compatibility. To help balance these two conflicting desires, I have been kicking around the idea of implementing a set of tests to help determine when the behavior of a function changes. The basic idea is to run the tests against the various version of PHP, compare the output and flag when differences crop up. Users would be able to run these tests using a make target. The data from these tests could be used by a utility program that walks a directory structure, reading php files and looking for functions/features that have changed behavior. I would like to call these 'Lemosian Conformity Tests' in honor of Manuel's consistent and vociferous work on preserving BC. :) While I don't like his approach, I agree that it is a valid concern. Personally, rather than being chained to BC, I would rather that we actively work to help users deal with changes more effectively. Additionally, these changes would help developers and the QA team spot unintentional changes to function behavior. -- Yasuo Ohgaki -- 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 #14496 Updated: session.save_handler = mm - error when apache starting
ID: 14496 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Duplicate Bug Type: Session related Operating System: Linux PHP Version: 4.1.0 New Comment: Bug with ID 14612(this) can not be duplicate for bug with ID 14612 :) Previous Comments: [2001-12-19 22:56:15] [EMAIL PROTECTED] I created new one reported by me which contains the reason why this happens. I make this report as duplicate of my report. #14612. [2001-12-14 06:24:16] [EMAIL PROTECTED] RedHat 6.2 #uname -a Linux 2.4.16 #1 SMP Sat Dec 8 18:14:02 EET 2001 i686 unknown I repeat: If i set save_handler to 'mm' in php.ini and start apache I see the error message BUT SESSION WORK WITH MM HANDLER [2001-12-14 06:03:53] [EMAIL PROTECTED] Try a make clean. [2001-12-14 04:20:28] [EMAIL PROTECTED] What distribution are you using of Linux? [2001-12-14 04:18:19] [EMAIL PROTECTED] This is bug, not bogus. Pls change status. 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=14496 Edit this bug report at http://bugs.php.net/?id=14496edit=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 #14615 Updated: PHP log does not contain proper CRLF's
ID: 14615 Updated by: mfischer Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Old Bug Type: Unknown/Other Function Bug Type: Feature/Change Request Operating System: Windows PHP Version: 4.1.0 New Comment: Your sentence doesn't compute: [...] but Windows only recognizes ASCII 13 + ASCII 10 (CRLF) as a new line.. You mean, your editor is broken and does not support it. No bug, bogusifying. Previous Comments: [2001-12-20 04:02:15] [EMAIL PROTECTED] In the PHP log, new lines are defined only with ASCII 10 (LF), but Windows only recognizes ASCII 13 + ASCII 10 (CRLF) as a new line. This makes the PHP log look like a mess on Windows systems. Edit this bug report at http://bugs.php.net/?id=14615edit=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 #14614 Updated: lastchild();
ID: 14614 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: DOM XML related Operating System: Windows PHP Version: 4.1.0 New Comment: thanx. Btw. where can I see the list of changes ? like : [4.06][4.10] lastchild() last_child() / Mads Previous Comments: [2001-12-20 04:07:46] [EMAIL PROTECTED] Yep, its called last_child(). Closing. [2001-12-20 04:02:01] [EMAIL PROTECTED] Under PHP 4.06 this works fine : return $parent-lastchild(); Under PHP 4.10 it gives an error: unknown function Did you rename this function or what went wrong ? / Mads Edit this bug report at http://bugs.php.net/?id=14614edit=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 #14615 Updated: PHP log does not contain proper CRLF's
ID: 14615 Updated by: hholzgra Reported By: [EMAIL PROTECTED] Old Status: Bogus Status: Feedback Bug Type: Feature/Change Request Operating System: Windows PHP Version: 4.1.0 New Comment: well, different systems *have* different default line ending styles, so we might want to write whatever is considered 'native' on a certain platform but i'm not really sure what log we are talking about here, as the default log mechanism (as i know it on Linux/Apache) is to pass log messages to the webserver for logging? Previous Comments: [2001-12-20 04:10:07] [EMAIL PROTECTED] Your sentence doesn't compute: [...] but Windows only recognizes ASCII 13 + ASCII 10 (CRLF) as a new line.. You mean, your editor is broken and does not support it. No bug, bogusifying. [2001-12-20 04:02:15] [EMAIL PROTECTED] In the PHP log, new lines are defined only with ASCII 10 (LF), but Windows only recognizes ASCII 13 + ASCII 10 (CRLF) as a new line. This makes the PHP log look like a mess on Windows systems. Edit this bug report at http://bugs.php.net/?id=14615edit=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 #14615 Updated: PHP log does not contain proper CRLF's
ID: 14615 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Bogus Old Bug Type: Feature/Change Request Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 4.1.0 New Comment: There's nothing wrong with the editor. I have used Notepad to view the PHP log. I have also viewed the PHP log with Visual C++ which *converts* (note the word convert) the LF to CRLF. Appearently, CRLF is the preferred format in Windows for new lines above LF. Besides, CRLF is the new line format which practically every editor in Windows supports. And besides everything: CRLF *is* the Windows newline, LF is not. So it would not make sense to use LF as a new line in Windows environments. Previous Comments: [2001-12-20 04:23:14] [EMAIL PROTECTED] well, different systems *have* different default line ending styles, so we might want to write whatever is considered 'native' on a certain platform but i'm not really sure what log we are talking about here, as the default log mechanism (as i know it on Linux/Apache) is to pass log messages to the webserver for logging? [2001-12-20 04:10:07] [EMAIL PROTECTED] Your sentence doesn't compute: [...] but Windows only recognizes ASCII 13 + ASCII 10 (CRLF) as a new line.. You mean, your editor is broken and does not support it. No bug, bogusifying. [2001-12-20 04:02:15] [EMAIL PROTECTED] In the PHP log, new lines are defined only with ASCII 10 (LF), but Windows only recognizes ASCII 13 + ASCII 10 (CRLF) as a new line. This makes the PHP log look like a mess on Windows systems. Edit this bug report at http://bugs.php.net/?id=14615edit=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 #14615 Updated: PHP log does not contain proper CRLF's
ID: 14615 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 4.1.0 New Comment: but i'm not really sure what log we are talking about here I am talking about the PHP log file which can be defined with the directive error_log = ... in the PHP.INI file. Previous Comments: [2001-12-20 04:23:54] [EMAIL PROTECTED] There's nothing wrong with the editor. I have used Notepad to view the PHP log. I have also viewed the PHP log with Visual C++ which *converts* (note the word convert) the LF to CRLF. Appearently, CRLF is the preferred format in Windows for new lines above LF. Besides, CRLF is the new line format which practically every editor in Windows supports. And besides everything: CRLF *is* the Windows newline, LF is not. So it would not make sense to use LF as a new line in Windows environments. [2001-12-20 04:23:14] [EMAIL PROTECTED] well, different systems *have* different default line ending styles, so we might want to write whatever is considered 'native' on a certain platform but i'm not really sure what log we are talking about here, as the default log mechanism (as i know it on Linux/Apache) is to pass log messages to the webserver for logging? [2001-12-20 04:10:07] [EMAIL PROTECTED] Your sentence doesn't compute: [...] but Windows only recognizes ASCII 13 + ASCII 10 (CRLF) as a new line.. You mean, your editor is broken and does not support it. No bug, bogusifying. [2001-12-20 04:02:15] [EMAIL PROTECTED] In the PHP log, new lines are defined only with ASCII 10 (LF), but Windows only recognizes ASCII 13 + ASCII 10 (CRLF) as a new line. This makes the PHP log look like a mess on Windows systems. Edit this bug report at http://bugs.php.net/?id=14615edit=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]
Re: [PHP-DEV] Bug #14614 Updated: lastchild();
On Thu, Dec 20, 2001 at 09:17:44AM -, [EMAIL PROTECTED] wrote : ID: 14614 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: DOM XML related Operating System: Windows PHP Version: 4.1.0 New Comment: thanx. Btw. where can I see the list of changes ? In the source. And thats not a joke. There aren't any docs as of now (a doc bug has already ben opened). - Markus -- Please always Cc to me when replying to me on the lists. -- 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 #14615 Updated: PHP log does not contain proper CRLF's
On Thu, Dec 20, 2001 at 09:23:54AM -, [EMAIL PROTECTED] wrote : ID: 14615 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Bogus Old Bug Type: Feature/Change Request Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 4.1.0 New Comment: There's nothing wrong with the editor. I have used Notepad to view the PHP log. Notepad is crap because it doesn't support any other line endings. Anyway, I see your point and hartmut changed it to a feature request so you are where you wanted to be ;) - Markus -- Please always Cc to me when replying to me on the lists. -- 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 #14615 Updated: PHP log does not contain proper CRLF's
ID: 14615 Updated by: mfischer Reported By: [EMAIL PROTECTED] Old Status: Bogus Status: Open Old Bug Type: Unknown/Other Function Bug Type: Feature/Change Request Operating System: Windows PHP Version: 4.1.0 New Comment: Reopen, leave Type: to Feature Request. Previous Comments: [2001-12-20 04:28:40] [EMAIL PROTECTED] but i'm not really sure what log we are talking about here I am talking about the PHP log file which can be defined with the directive error_log = ... in the PHP.INI file. [2001-12-20 04:23:54] [EMAIL PROTECTED] There's nothing wrong with the editor. I have used Notepad to view the PHP log. I have also viewed the PHP log with Visual C++ which *converts* (note the word convert) the LF to CRLF. Appearently, CRLF is the preferred format in Windows for new lines above LF. Besides, CRLF is the new line format which practically every editor in Windows supports. And besides everything: CRLF *is* the Windows newline, LF is not. So it would not make sense to use LF as a new line in Windows environments. [2001-12-20 04:23:14] [EMAIL PROTECTED] well, different systems *have* different default line ending styles, so we might want to write whatever is considered 'native' on a certain platform but i'm not really sure what log we are talking about here, as the default log mechanism (as i know it on Linux/Apache) is to pass log messages to the webserver for logging? [2001-12-20 04:10:07] [EMAIL PROTECTED] Your sentence doesn't compute: [...] but Windows only recognizes ASCII 13 + ASCII 10 (CRLF) as a new line.. You mean, your editor is broken and does not support it. No bug, bogusifying. [2001-12-20 04:02:15] [EMAIL PROTECTED] In the PHP log, new lines are defined only with ASCII 10 (LF), but Windows only recognizes ASCII 13 + ASCII 10 (CRLF) as a new line. This makes the PHP log look like a mess on Windows systems. Edit this bug report at http://bugs.php.net/?id=14615edit=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] Re: [PEAR-DEV] [FRC]Session module related issues
On Thu, 20 Dec 2001 14:41:43 +0900, Yasuo Ohgaki wrote: 4) Where document should be? If your session handler will be part of PECL, it should be documented in the upcoming PEAR manual. Have a look at the CVS module peardoc to get a feeling for it. Basically I think it would be nice to have this in PECL, since it is no real 'core' part of PHP and so it does not really fit in php4/ext, eventhough it requires the session extension to be enabled. - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- 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 #13378 Updated: Auto session start + obejct
Hi derick! On Thu, 20 Dec 2001, [EMAIL PROTECTED] wrote: ID: 13378 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.0.6 New Comment: This is already implemented, we have a undocumented functinno for that, but I can't recall the name now :) do you mean __sleep() / __wakeup()? [2001-12-19 22:44:45] [EMAIL PROTECTED] Many users want to unserialize/initilize object after session is started, I suppose. Type = Feature Request -- teodor -- 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 #14615 Updated: PHP log does not contain proper CRLF's
ID: 14615
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Feature/Change Request
Operating System: Windows
PHP Version: 4.1.0
New Comment:
now this is strange ...
the following snippet from php4/main/main.c
(around line 300) does the actual logging
and as it does *not* open the logfile in
binary mode it should automaticly convert
'\n' to whatever the local platform prefers???
log_file = VCWD_FOPEN(PG(error_log), a);
if (log_file != NULL) {
time(error_time);
strftime(error_time_str, 128
, %d-%b-%Y %H:%M:%S
, php_localtime_r(error_time, tmbuf));
fprintf(log_file, [%s] , error_time_str);
fprintf(log_file, %s, log_message);
fprintf(log_file, \n);
fclose(log_file);
return;
}
Previous Comments:
[2001-12-20 04:36:06] [EMAIL PROTECTED]
Reopen, leave Type: to Feature Request.
[2001-12-20 04:28:40] [EMAIL PROTECTED]
but i'm not really sure what log we are talking about here
I am talking about the PHP log file which can be defined with the directive error_log
= ... in the PHP.INI file.
[2001-12-20 04:23:54] [EMAIL PROTECTED]
There's nothing wrong with the editor. I have used Notepad to view the PHP log.
I have also viewed the PHP log with Visual C++ which *converts* (note the word
convert) the LF to CRLF. Appearently, CRLF is the preferred format in Windows for new
lines above LF.
Besides, CRLF is the new line format which practically every editor in Windows
supports.
And besides everything: CRLF *is* the Windows newline, LF is not. So it would not make
sense to use LF as a new line in Windows environments.
[2001-12-20 04:23:14] [EMAIL PROTECTED]
well, different systems *have* different default
line ending styles, so we might want to write
whatever is considered 'native' on a certain
platform
but i'm not really sure what log we are talking
about here, as the default log mechanism (as i
know it on Linux/Apache) is to pass log messages
to the webserver for logging?
[2001-12-20 04:10:07] [EMAIL PROTECTED]
Your sentence doesn't compute: [...] but Windows only recognizes ASCII 13 + ASCII 10
(CRLF) as a new line.. You mean, your editor is broken and does not support it.
No bug, bogusifying.
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=14615
Edit this bug report at http://bugs.php.net/?id=14615edit=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]
Re: [PHP-DEV] Bug #13378 Updated: Auto session start + obejct
Hello Teodor, I meant the callback at http://www.php.net/manual/en/function.unserialize.php regaards, Derick On Thu, 20 Dec 2001, Teodor Cimpoesu wrote: Hi derick! On Thu, 20 Dec 2001, [EMAIL PROTECTED] wrote: ID: 13378 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.0.6 New Comment: This is already implemented, we have a undocumented functinno for that, but I can't recall the name now :) do you mean __sleep() / __wakeup()? [2001-12-19 22:44:45] [EMAIL PROTECTED] Many users want to unserialize/initilize object after session is started, I suppose. Type = Feature Request -- teodor -- 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 #14616: Linking PHP with external static Libtool libraries fails.
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.0 PHP Bug Type: Compile Failure Bug description: Linking PHP with external static Libtool libraries fails. This bug exists when PHP is linked with external static Libtool library and PHP itself is shared. Compile external support library as static. YAZ in this example: cd yaz-1.8.3 ./configure --prefix=/usr make make install cd ../php-4.1.0: ./configure --with-apxs=... --with-yaz and you'd get an output like this: .. /bin/sh ../libtool --silent --mode=link gcc -g -O2 -prefer-pic -o libZend.la -ldl -lyaz -lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt zend_language_parser.lo zend_language_scanner.lo zend_ini_parser.lo zend_ini_scanner.lo zend_alloc.lo zend_compile.lo zend_c onstants.lo zend_dynamic_array.lo zend_execute.lo zend_execute_API.lo zend_highlight.lo zend_llist.lo zend_opcode.lo zend_operators.l o zend_ptr_stack.lo zend_stack.lo zend_variables.lo zend.lo zend_API.lo zend_extensions.lo zend_hash.lo zend_list.lo zend_indent.lo z end_builtin_functions.lo zend_sprintf.lo zend_ini.lo make[1]: Leaving directory `/home/adam/proj/php-4.1.0/Zend' ... /bin/sh /home/adam/proj/php-4.1.0/libtool --silent --mode=link gcc -I. -I/home/adam/proj/php-4.1.0/ -I/home/adam/proj/php-4.1.0/main -I/home/adam/proj/php-4.1.0 -I/home/adam/proj/apache/include -I/home/adam/proj/php-4.1.0/Zend -I/home/adam/proj/php-4.1.0/ext/mysql/ libmysql -I/home/adam/proj/php-4.1.0/ext/xml/expat -DLINUX=22 -DUSE_HSREGEX -DUSE_EXPAT -I/home/adam/proj/php-4.1.0/TSRM -g -O2 -pre fer-pic -o libphp4.la -rpath /home/adam/proj/php-4.1.0/libs -avoid-version stub.lo Zend/libZend.la sapi/apache/libsapi.la main/l ibmain.la regex/libregex.la ext/mysql/libmysql.la ext/pcre/libpcre.la ext/posix/libposix.la ext/session/libsession.la ext/standard/li bstandard.la ext/xml/libxml.la ext/yaz/libyaz.la TSRM/libtsrm.la -ldl -lyaz -lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt /usr/lib/libyaz.a(odr_bool.o): In function `odr_bool': /home/adam/proj/yaz/odr/odr_bool.c(.text+0x0): multiple definition of `odr_bool' Zend/.libs/libZend.al(odr_bool.o)(.text+0x0):/home/adam/proj/yaz/odr/odr_bool.c: first defined here /usr/lib/libyaz.a(ber_bool.o): In function `ber_boolean': [many more multiple symbols] The log indicates that all YAZ symbols are included twice. Apparenly the Zend link step includes YAZ verbatim even though no symbols should be needed to built that. Fixes: 1) removing /usr/lib/libyaz.la makes it work. Now the Zend link step doesn't include YAZ and it works. 2) removing the linkage of yaz from the Zend link step obviously makes it work too (and fixes the problem for all libraries). 3) build shared YAZ library is a fix too. (./configure --enabled-shared for YAZ). The problem doesn't occur with PHP 4.0.6. It is a problem with latest CVS (16 Dec 2001). This problem persists for other libraries than YAZ. Andrew Sitnikov reports he had trouble with linking of '-lmm -lmhash' (had to remove them from Zend/Makefile). If this is a libtool bug and there's no fix for that, my suggestion would be that Zend doesn't link with YAZ or other extension libraries. That is the value of libZend_la_LDFLAGS in Zend/Makefile.am should not include @EXTRA_LIBS@. -- Edit bug report at: http://bugs.php.net/?id=14616edit=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 #14617: socket_recv() arguments
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.1.0 PHP Bug Type: Sockets related Bug description: socket_recv() arguments According to http://www.php.net/manual/en/function.socket-recv.php the socket_recv() parameters are as follows: mixed socket_recv (resource socket, int len, int flags) An attempt with: $row = socket_recv($handle, 1024, PHP_NORMAL_READ); Says Warning: socket_recv() expects exactly 2 parameters, 3 given in xxx on line 103 $row = socket_recv($handle, 1024); Says Warning: socket_recv() expects parameter 2 to be resource, integer given in xxx on line 103 $row = socket_recv(1024, $handle); Says Warning: socket_recv() expects parameter 1 to be resource, integer given in xxx on line 103 -- Edit bug report at: http://bugs.php.net/?id=14617edit=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 #14618: Undefined Symbol: ldap_parse_reference
From: [EMAIL PROTECTED] Operating system: Solaris 2.8 PHP version: 4.1.0 PHP Bug Type: Compile Failure Bug description: Undefined Symbol: ldap_parse_reference This is the same problem as in Bug #11873 Configure options: --enable-force-cgi-redirect --enable-trans-sid --enable-memory-limit --with-ldap Operating system: SunOS myHost 5.8 Generic_108528-12 sun4u sparc SUNW,Ultra-250 The original Solaris LDAP library is used, no other library is installed. -rwxr-xr-x 1 root bin 224200 Jan 5 2000 /usr/lib/libldap.so.4* There is no ldap_parse_reference() in this library. (Solaris 9 comes with libldap.so.5 including ldap_parse_reference() ). LDAP_API_VERSION is defined as 2004 (2005 on Solaris 9) in /usr/include/ldap.h HAVE_NSLDAP is not defined in main/config_php.h I looked for references on the web about what API function has to be present in the different API versions. It's definitely possible that Sun wrongly labeled their library in Solaris 8 with 2004 but didn't supply the needed ldap_parse_reference() method. But it would be useful to make PHP ignore that problem and undefine ldap_parse_reference() on Solaris 8 or at least check for its existance during configure. -- Edit bug report at: http://bugs.php.net/?id=14618edit=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 #14576 Updated: documention out of date
ID: 14576 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Sockets related Operating System: Windows 2000 PHP Version: 4.1.0 New Comment: Documentation has been updated i see :) Previous Comments: [2001-12-18 08:23:58] [EMAIL PROTECTED] the documention on the socket extenion is very out of date, a bunch of the bogus bug reports on sockets is about socket() and other functions that now have different names Edit this bug report at http://bugs.php.net/?id=14576edit=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] Re: [FRC]Session module related issues
Martin Jansen wrote: On Thu, 20 Dec 2001 14:41:43 +0900, Yasuo Ohgaki wrote: 4) Where document should be? If your session handler will be part of PECL, it should be documented in the upcoming PEAR manual. Have a look at the CVS module peardoc to get a feeling for it. Thank you for your reply. It may be OK to put document for modules that does not have function at all and does not work with certain modules is not compiled in. :) Any objection for this? We can live with undefined symbol errors also. However, I really don't want undefined symbol error because I'm sure users will submit bug reports for this. Besides, it's not the right way to manage software. IMHO. Basically I think it would be nice to have this in PECL, since it is no real 'core' part of PHP and so it does not really fit in php4/ext, eventhough it requires the session extension to be enabled. I should explicitly have written about technical issues. You missed issues here 1) It highly depends on Session module. 2) It does not work as standalone module at all. 3) It will fail to load with undefined symbol when PHP is compiled with --disable-session. 3) It does not provide any function to users. 4) Where document should be? 5) How to handle include files required for session save handler module? Session save handler modules are not a usual modules, but modules in a module. We need to address technical issues also. Technically, it is possible to separate session save handlers from session module. However, it does not mean, it's good idea to do that. If we decide to separate session save handlers to PECL, there must be *clean* way to separate them. If PHP has *clean* way to provide modules in a module, it will be realistic to place session save handlers to PECL. I expect changes in current *module* initilization code for this. Anyone has comment on this? (Compilation and initialization for modules in a module. We can put php_session.h in standard header location. Do we really want this? Undefined Symbol error is not acceptable at least for me, also. It's possible to have required globals always in PHP. Do we really want this?) BTW, currently, mm save handler support is broken partially. Clue for proper session save handler module initialization with current code is also appreciated :) -- Yasuo Ohgaki -- 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] Re: [FRC]Session module related issues
Yasuo Ohgaki wrote: Martin Jansen wrote: On Thu, 20 Dec 2001 14:41:43 +0900, Yasuo Ohgaki wrote: 4) Where document should be? If your session handler will be part of PECL, it should be documented in the upcoming PEAR manual. Have a look at the CVS module peardoc to get a feeling for it. Thank you for your reply. It may be OK to put document for modules that does not have function at all and does not work with certain modules is not compiled in. :) Any objection for this? We can live with undefined symbol errors also. However, I really don't want undefined symbol error because I'm sure users will submit bug reports for this. Besides, it's not the right way to manage software. IMHO. I'll try be more clear on this. Do you want CGI version to fail to run just because GCI version does not have session module? (i.e. session save handler is loaded in php.ini for other SAPI, and there is line for loading session save handler, or modules for a module) -- Yasuo Ohgaki Basically I think it would be nice to have this in PECL, since it is no real 'core' part of PHP and so it does not really fit in php4/ext, eventhough it requires the session extension to be enabled. I should explicitly have written about technical issues. You missed issues here 1) It highly depends on Session module. 2) It does not work as standalone module at all. 3) It will fail to load with undefined symbol when PHP is compiled with --disable-session. 3) It does not provide any function to users. 4) Where document should be? 5) How to handle include files required for session save handler module? Session save handler modules are not a usual modules, but modules in a module. We need to address technical issues also. Technically, it is possible to separate session save handlers from session module. However, it does not mean, it's good idea to do that. If we decide to separate session save handlers to PECL, there must be *clean* way to separate them. If PHP has *clean* way to provide modules in a module, it will be realistic to place session save handlers to PECL. I expect changes in current *module* initilization code for this. Anyone has comment on this? (Compilation and initialization for modules in a module. We can put php_session.h in standard header location. Do we really want this? Undefined Symbol error is not acceptable at least for me, also. It's possible to have required globals always in PHP. Do we really want this?) BTW, currently, mm save handler support is broken partially. Clue for proper session save handler module initialization with current code is also appreciated :) -- Yasuo Ohgaki -- 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 #14617 Updated: socket_recv() arguments
ID: 14617 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Sockets related Operating System: Windows 2000 PHP Version: 4.1.0 New Comment: Fixed in CVS Previous Comments: [2001-12-20 05:54:17] [EMAIL PROTECTED] According to http://www.php.net/manual/en/function.socket-recv.php the socket_recv() parameters are as follows: mixed socket_recv (resource socket, int len, int flags) An attempt with: $row = socket_recv($handle, 1024, PHP_NORMAL_READ); Says Warning: socket_recv() expects exactly 2 parameters, 3 given in xxx on line 103 $row = socket_recv($handle, 1024); Says Warning: socket_recv() expects parameter 2 to be resource, integer given in xxx on line 103 $row = socket_recv(1024, $handle); Says Warning: socket_recv() expects parameter 1 to be resource, integer given in xxx on line 103 Edit this bug report at http://bugs.php.net/?id=14617edit=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 #14610 Updated: configure script looks in the wrong place for httpd.h
ID: 14610 Updated by: sander Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Apache2 related Operating System: Linux PHP Version: 4.1.0 New Comment: If you want to compile PHP as a static module (that's what you're trying) you should point PHP to the source of Apache, not to the installation dir. Previous Comments: [2001-12-19 18:20:19] [EMAIL PROTECTED] I'm trying to configure php 4.1.0 on my server running turbolinux 6.0 with Apache 2.0.28 By default Apache 2.0.x installs to /usr/local/apache2 php 4.1.0 configure --with-apache defaults to /usr/include/apache no biggy, I do configure --with-apache=/usr/local/apache2 but it still can't find httpd.h I have a look at configure and it's looking for httpd.h like this # For Apache 2.0.x elif test -f $withval/src/include/httpd.h Which doesn't exist because httpd.h is in /usr/local/apache2/include/ I know perl pretty good, but I don't have a lot of experience with regular old shell scripting. I've done a little hacking of the configure script to correct this, but it's still not working right as I've most likely missed something of did something wrong in my hacking. Edit this bug report at http://bugs.php.net/?id=14610edit=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 #14609 Updated: window not closed if this script ended
ID: 14609
Updated by: sander
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Old Bug Type: Scripting Engine problem
Bug Type: Other web server
Operating System: Windows 98 SE
PHP Version: 4.1.0
New Comment:
How do you run PHP? Via CGI? Via commandline??? Via which webserver?
Previous Comments:
[2001-12-19 15:50:20] [EMAIL PROTECTED]
Hello
run this script with php.exe script.php3
in php4.06 ... this window closed if this script ended, but php410 not
PS:sorry for my very bad English
=start===
?
for($i=0;$i1;$i++)
{
$a1[$i] = a;b;c;
}
for($i=0;$i(count($a1));$i++)
{
$tmp_a1[$i] = explode (;, $a1[$i],3);
}
?
THIS WINDOWS NOT CLOSED ???
=end===
Edit this bug report at http://bugs.php.net/?id=14609edit=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]
Re: [PHP-DEV] Bug #13378 Updated: Auto session start + obejct
Derick Rethans wrote: Hello Teodor, I meant the callback at http://www.php.net/manual/en/function.unserialize.php regaards, Derick Thank you Derick, I should have known that ;) -- Yasuo Ohgaki -- 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] Re: Bug #14613: Implement Function/Feature Conformity Tests
On December 20, 2001 02:09 am, Yasuo Ohgaki wrote: Great, Zak!! I was hoping someone start this. I really hope there is a BNF. Simplied one is preferred, it helps to understand what zend expects. (Well I can read lex(flex)/yacc(bison) source, but I'm just lazy enough to understand BNF from them. I guess many programmers are as lazy as me ;) I don't think that I will be trying to do a BNF! :) For now, I only hope to tackle what I had outlined in my feature request. --zak -- 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 #14496 Updated: session.save_handler = mm - error when apache starting
ID: 14496 Updated by: yohgaki Reported By: [EMAIL PROTECTED] Status: Duplicate Bug Type: Session related Operating System: Linux PHP Version: 4.1.0 New Comment: This is actually a duplicate of bug http://bugs.php.net/bug.php?id=14612 You got the same error message. This problem is caused by incorrect order of sub module initialization :) If you use session_module_name(), mm handler works well :) Previous Comments: [2001-12-20 04:09:48] [EMAIL PROTECTED] Bug with ID 14612(this) can not be duplicate for bug with ID 14612 :) [2001-12-19 22:56:15] [EMAIL PROTECTED] I created new one reported by me which contains the reason why this happens. I make this report as duplicate of my report. #14612. [2001-12-14 06:24:16] [EMAIL PROTECTED] RedHat 6.2 #uname -a Linux 2.4.16 #1 SMP Sat Dec 8 18:14:02 EET 2001 i686 unknown I repeat: If i set save_handler to 'mm' in php.ini and start apache I see the error message BUT SESSION WORK WITH MM HANDLER [2001-12-14 06:03:53] [EMAIL PROTECTED] Try a make clean. [2001-12-14 04:20:28] [EMAIL PROTECTED] What distribution are you using of Linux? 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=14496 Edit this bug report at http://bugs.php.net/?id=14496edit=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] Re: [PEAR-DEV] Re: [FRC]Session module related issues
Just for curious, do you have some speed comparations over the other handlers and perhaps also with a postgres handler in php? Tomas V.V.Cox El jue, 20-12-2001 a las 12:38, Yasuo Ohgaki escribió: Yasuo Ohgaki wrote: Martin Jansen wrote: On Thu, 20 Dec 2001 14:41:43 +0900, Yasuo Ohgaki wrote: 4) Where document should be? If your session handler will be part of PECL, it should be documented in the upcoming PEAR manual. Have a look at the CVS module peardoc to get a feeling for it. Thank you for your reply. It may be OK to put document for modules that does not have function at all and does not work with certain modules is not compiled in. :) Any objection for this? We can live with undefined symbol errors also. However, I really don't want undefined symbol error because I'm sure users will submit bug reports for this. Besides, it's not the right way to manage software. IMHO. I'll try be more clear on this. Do you want CGI version to fail to run just because GCI version does not have session module? (i.e. session save handler is loaded in php.ini for other SAPI, and there is line for loading session save handler, or modules for a module) -- Yasuo Ohgaki Basically I think it would be nice to have this in PECL, since it is no real 'core' part of PHP and so it does not really fit in php4/ext, eventhough it requires the session extension to be enabled. I should explicitly have written about technical issues. You missed issues here 1) It highly depends on Session module. 2) It does not work as standalone module at all. 3) It will fail to load with undefined symbol when PHP is compiled with --disable-session. 3) It does not provide any function to users. 4) Where document should be? 5) How to handle include files required for session save handler module? Session save handler modules are not a usual modules, but modules in a module. We need to address technical issues also. Technically, it is possible to separate session save handlers from session module. However, it does not mean, it's good idea to do that. If we decide to separate session save handlers to PECL, there must be *clean* way to separate them. If PHP has *clean* way to provide modules in a module, it will be realistic to place session save handlers to PECL. I expect changes in current *module* initilization code for this. Anyone has comment on this? (Compilation and initialization for modules in a module. We can put php_session.h in standard header location. Do we really want this? Undefined Symbol error is not acceptable at least for me, also. It's possible to have required globals always in PHP. Do we really want this?) BTW, currently, mm save handler support is broken partially. Clue for proper session save handler module initialization with current code is also appreciated :) -- Yasuo Ohgaki -- PEAR Development Mailing List (http://pear.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: Should exit() print out the integer exit-status?
Markus Fischer wrote: Actually, a good idea to keep BC. Its now just a matter if its really worth to keep BC for exit. I agree with Markus. However, since there are people who want strong compatibility. I think we can wait exit() to return status code, a litle more. As I posted already, it would be good idea to notify users for BC changes expected a few version later. Since die() is the same as exit(), transition would be very easy. There are many BC issues version to version anyway. It's called bug :) Nobody should complain about BC changes if changes are notified early enough and there is alternative way to do the same thing. IMHO. (This has been done for some features such as track vars ;) I suppose we can change exit() for 4.3.0, or even for 4.2.0, since we have different branch for 4.1.x and 4.2.0. There will be 4.1.1 and/or even 4.1.2, 4.1.3. 4.2.0 may not be released any time soon. :) -- Yasuo Ohgaki -- 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 #14608 Updated: problem with ./configure --with-apxs
ID: 14608 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache related Operating System: linux PHP Version: 4.1.0 New Comment: I tried this by pointing --with-apxs=path and by putting the apxs script in my path and it died both ways. besides had it not been in my path the script would not have been able to make up the usage output from it unless someone coded that into the configure script as a joke. Previous Comments: [2001-12-19 15:31:18] [EMAIL PROTECTED] Does it crash or just die? Anyway, you should point PHP to the apxs file, unless it's in your path. Use i.e. --with-apxs=/usr/local/apache/bin/apxs If it really crashes, reopen this report. [2001-12-19 14:52:44] [EMAIL PROTECTED] ./configure --with-mysql=/path/ --with-apxs it crashes and gives the usage of apxs as if bad arguments are being sent by the script. apache is v1.3.12 and the only modules loaded by checking httpd -l are http_core.c and mod_so.c Edit this bug report at http://bugs.php.net/?id=14608edit=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 #11986 Updated: the problem of php and sybase connection has not been fixed
ID: 11986 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Sybase-ct (ctlib) related Operating System: windows 2000 PHP Version: 4.0.6 New Comment: give up Previous Comments: [2001-12-20 08:40:11] [EMAIL PROTECTED] I have already given up to use php with Sybase, because 1. Sybase ASE 11.9.2 is obsoleted, 2. I tried to install php 4.10 with Sybase ASE 12.0.1 on HP-UX 11.0, it failed due to function not found. I suggest to remove the bug report as well as the feature or claim that php support Sybase. Wish you a merry Christmas tomcwh [2001-12-20 02:56:13] [EMAIL PROTECTED] Can you verify this on 4.1.0? R. [2001-07-09 13:48:13] [EMAIL PROTECTED] Dear all, I have searched for more than 3 months for the solution of the connection problem on using php to connect sybase on the windows 2000 with IIS5 installed. However, in this bug report system, I found a number of closed cases, in which the solution providers said that the connection problem was fixed in php4.06, however after an intensive testing, I give up! If there is any sucessful case, please post the solution here in detail. Thank you very much. tomcwh Edit this bug report at http://bugs.php.net/?id=11986edit=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] Re: [PEAR-DEV] Re: [FRC]Session module related issues
Jani Taskinen wrote: Why not make it standalone extension? Just check the ext/msession/ extension which has done this same thing. --Jani Then msession may have the same problem that I mentioned. Since session module can be disabled, if users load extension depands on session module, it will end up with undefined symbol error. This is not nice... This is expected when user compile CGI verion with --disable-session and compile with other SAPI without --disable-session. (There is work around as both of us already knows, though) Since extension for session module is rather simpile one, it can be avoided by defining globals for all builds. However, it may not be the case for yet known new modules that have child modules.(Even with smart installer, there will be users notice this problem.) We can live with undefined symbol error, but we know users will submit bug reports for that. :) My opinion is, if module has parent module, child module should be compiled with parent module unless the child module is used not often. I think pgsql session handler will be used by a lots of users. I hope ;) I hope everyone agrees on this, since I don't want to reply all bug report like Hey, I got undefined symbol error! Why? for all modules that has child modules... -- Yasuo Ohgaki On Thu, 20 Dec 2001, Yasuo Ohgaki wrote: Yasuo Ohgaki wrote: Martin Jansen wrote: On Thu, 20 Dec 2001 14:41:43 +0900, Yasuo Ohgaki wrote: 4) Where document should be? If your session handler will be part of PECL, it should be documented in the upcoming PEAR manual. Have a look at the CVS module peardoc to get a feeling for it. Thank you for your reply. It may be OK to put document for modules that does not have function at all and does not work with certain modules is not compiled in. :) Any objection for this? We can live with undefined symbol errors also. However, I really don't want undefined symbol error because I'm sure users will submit bug reports for this. Besides, it's not the right way to manage software. IMHO. I'll try be more clear on this. Do you want CGI version to fail to run just because GCI version does not have session module? (i.e. session save handler is loaded in php.ini for other SAPI, and there is line for loading session save handler, or modules for a module) -- Yasuo Ohgaki Basically I think it would be nice to have this in PECL, since it is no real 'core' part of PHP and so it does not really fit in php4/ext, eventhough it requires the session extension to be enabled. I should explicitly have written about technical issues. You missed issues here 1) It highly depends on Session module. 2) It does not work as standalone module at all. 3) It will fail to load with undefined symbol when PHP is compiled with --disable-session. 3) It does not provide any function to users. 4) Where document should be? 5) How to handle include files required for session save handler module? Session save handler modules are not a usual modules, but modules in a module. We need to address technical issues also. Technically, it is possible to separate session save handlers from session module. However, it does not mean, it's good idea to do that. If we decide to separate session save handlers to PECL, there must be *clean* way to separate them. If PHP has *clean* way to provide modules in a module, it will be realistic to place session save handlers to PECL. I expect changes in current *module* initilization code for this. Anyone has comment on this? (Compilation and initialization for modules in a module. We can put php_session.h in standard header location. Do we really want this? Undefined Symbol error is not acceptable at least for me, also. It's possible to have required globals always in PHP. Do we really want this?) BTW, currently, mm save handler support is broken partially. Clue for proper session save handler module initialization with current code is also appreciated :) -- Yasuo Ohgaki -- 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] Re: [PEAR-DEV] Re: [FRC]Session module related issues
Tomas V.V.Cox wrote: Just for curious, do you have some speed comparations over the other handlers and perhaps also with a postgres handler in php? Not yet. But, I've written PostgreSQL session handler with PHP script and I know how Zend executes PHP scripts. Therefore, it supposed to be much faster. If GC is moved to RSHUTDOWN, it will be even faster since I can use async query for session write without additional DB connection. Besides, I can do more complex operation with C module. I'll add automatic fail over in case of DB failure and automatic DB load balancing to the session save handler ;) I hope lot of users will like it. -- Yasuo Ohgaki _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.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: Should exit() print out the integer exit-status?
No offense Benjamin, but you don't understand the conversation. This is about running PHP apps in consoles, mail pre-processors and as cron jobs where exit status is needed. The only way to get an exit status is with exit. wow i just tried it... i never realized that return wasn't setting the exit code. ok then - i guess i'm all for system_exit() or similar, but why wouldn't we want return to set it like it's C counterpart? -benjamin -- 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: Should exit() print out the integer exit-status?
On Thu, 20 Dec 2001, benjamin yates wrote: No offense Benjamin, but you don't understand the conversation. This is about running PHP apps in consoles, mail pre-processors and as cron jobs where exit status is needed. The only way to get an exit status is with exit. wow i just tried it... i never realized that return wasn't setting the exit code. ok then - i guess i'm all for system_exit() or similar, but why wouldn't we want return to set it like it's C counterpart? Actually, most ppl want to do that. Derick -- 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 #14120 Updated: libtool needs help.
ID: 14120 Updated by: lobbin Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: OpenUNIX8 PHP Version: 4.0CVS-2001-11-19 New Comment: Derick? Previous Comments: [2001-12-12 11:07:52] [EMAIL PROTECTED] Is anyone going to look at this? [2001-11-19 16:59:48] [EMAIL PROTECTED] See also comments in bug #14014 re: the libtool changes. [2001-11-19 12:06:13] [EMAIL PROTECTED] the snap from today (php4-20090600) DOES recognize OpenUNIX8. the libtool generated does NOT handle dependencies. I hand-tweaked the config parameters AFTER it was built. The generated libphp4.so works (see http://www.lerctr.org/~ler/php.php). Derick Rethans has an account on this box. Could someone (Derick?) look into this, and see why the libtool doesn't recognize OpenUNIX 8? Also, can the config.guess/config.sub files be updated in the 4.1.0RC branch (if they haven't been already)? The changes I made to libtool are: $ diff -c libtool libtool.ler *** libtool Mon Nov 19 11:03:13 2001 --- libtool.ler Mon Nov 19 10:52:46 2001 *** *** 47,53 build_old_libs=no # Whether or not to add -lc for building shared libraries. ! build_libtool_need_lc=yes # Whether or not to optimize for fast installation. fast_install=yes --- 47,53 build_old_libs=no # Whether or not to add -lc for building shared libraries. ! build_libtool_need_lc=no # Whether or not to optimize for fast installation. fast_install=yes *** *** 70,76 with_gcc= # The linker used to build libraries. ! LD=/usr/bin/ld # Whether we need hard or soft links. LN_S=ln -s --- 70,76 with_gcc= # The linker used to build libraries. ! LD=/usr/bin/ld # Whether we need hard or soft links. LN_S=ln -s --- 70,76 with_gcc= # The linker used to build libraries. ! LD=/usr/bin/cc # Whether we need hard or soft links. LN_S=ln -s *** *** 192,198 striplib= # Method to check whether dependent libraries are shared objects. ! deplibs_check_method=unknown # Command to use when deplibs_check_method == file_magic. file_magic_cmd=\$MAGIC_CMD --- 192,198 striplib= # Method to check whether dependent libraries are shared objects. ! deplibs_check_method=pass_all # Command to use when deplibs_check_method == file_magic. file_magic_cmd=\$MAGIC_CMD If you want, I can put the real diff up for ftp/http. Edit this bug report at http://bugs.php.net/?id=14120edit=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 #14230 Updated: configure fail cross-compiler check with gcc 3.0.1
ID: 14230 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.0.6 New Comment: Can you provide some usefull information from the configure script? R. Previous Comments: [2001-11-26 08:59:50] [EMAIL PROTECTED] On Solaris 8 SPARC, with gcc 3.0.1 from the solaris freeware site (binaries), php 4.0.6 configure script incorrectly detects gcc as a cross compiler and fail the int8 test later on because of this. The cross-compiler check seems a bit flacky. Reverting to the experimental m64 capable gcc in the 2.96.. snapshot list, (but without asking for 64 bit code generation) correctly runs configure and detects gcc as beeing a native compiler. configure was run with all default: ./configure gcc 3.0.1 from sunfreeware.com for sol 8 SPARC in /usr/local. Greetings from Switzerland Francois Edit this bug report at http://bugs.php.net/?id=14230edit=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 #12384 Updated: Can't connect to Ingres II
ID: 12384 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: *Database Functions Operating System: Redhat Linux 6.2 PHP Version: 4.0.6 New Comment: Can you please try this with PHP 4.1.0? R. Previous Comments: [2001-07-25 20:39:30] [EMAIL PROTECTED] PHP compiled as an APXS module into apache 1.3.14 with Ingres II v2.5. Although connecting through sql from the unix command line works, I can't get a connect to the Ingres database through PHP. ingtest.php ? $dbname = kramer::imdb; $dbuser = webmastr; $dbpass = ; ingres_connect($dbname, $dbuser, $dbpass); ? The error returned always is: Jul 25 18:36:38 zcalb00d httpd: PHP Warning: Ingres II: Server or API error : Unable to authenticate client's user ID. in /data/www/htdocs/mdq3/ingtest.php on line 7 Jul 25 18:36:38 zcalb00d httpd: PHP Warning: Ingres II: SQLSTATE : 08004 in /data/www/htdocs/mdq3/ingtest.php on line 7 Jul 25 18:36:38 zcalb00d httpd: PHP Warning: Ingres II: Unable to connect to database (kramer::imdb) in /data/www/htdocs/mdq3/ingtest.php on line 7 Here is the configure line used to compile although I have tried shrinking the enable list down to do without the java, oracle, ldap etc with no change. #!/bin/sh CC=gcc II_SYSTEM=/opt/ca/caingres ORACLE_HOME=/u01/home/oracle/dist/8.1.5 LD_LIBRARY_PATH=/u01/home/oracle/dist/8.1.5/lib:$LD_LIBRARY_PATH PATH=$PATH:/usr/java/jdk1.3.1/bin export CC II_SYSTEM ORACLE_HOME LD_LIBRARY_PATH PATH ./configure --prefix=/local/apps/fw/php \ --exec-prefix=/local/apps/fw/php\ --with-apxs=/usr/sbin/apxs \ --enable-track-vars \ --enable-yp \ --enable-sysvsem\ --enable-sysvshm\ --enable-sockets\ --enable-debug \ --with-java=/usr/java/jdk1.3.1 \ --with-oci8 \ --with-oracle \ --without-mysql \ --with-ldap \ --with-gd \ --with-gdbm \ --enable-sigchild \ --enable-versioning \ --with-ingres \ --enable-ftp Edit this bug report at http://bugs.php.net/?id=12384edit=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 #13787 Updated: custom sess_write not called to start session
ID: 13787 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: Linux 2.4.7 glibc 2.2.2 PHP Version: 4.0.6 New Comment: I don't think it is a bug in my session handler because everything works properly with register globals turned on. Another PHP user read my bug report and said he is having the same problem even after upgrading to PHP version 4.1.0. The code I am using is basically the code posted at PHPBuilder http://www.phpbuilder.com/columns/ying2602.php3 I have done some testing by writing to a log file from the sess_write handler and it is never called if a session does not already exist. Thanks, Billy Previous Comments: [2001-12-19 22:52:00] [EMAIL PROTECTED] It should be bugs in your session save handlers. Search zend.com code exchange for PosrgreSQL session save handler as an example. (Under HTTP category). -- Yasuo Ohgaki [2001-10-22 09:26:46] [EMAIL PROTECTED] Bug #9002 describing problems with custom session handlers still appears to be unresolved in PHP v4.0.6. The problem that still persists is the sess_write handler is never called to create a new session when register globals is turned off. An interesting behavior is that after a session is successfully started by a script with register globals turned on, you can turn register globals off and the sess_write handler will be called properly for the life of the session. The sess_write handler is never called unless a session already exists. As a workaround we have one script that has register globals turned on with an ini_set call and we start the session in the script. After the session is started by the script with register_globals enabled all of our other scripts with register_globals disabled work fine with our custom session handlers. our PHP configure options: './configure' '--with-mysql=/usr/local' '--with-gd=/usr/local' '--with-xml' '--with-ttf=/usr/local' '--disable-debug' '--enable-inline-optimizations' Edit this bug report at http://bugs.php.net/?id=13787edit=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]
Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?
Zeev Suraski writes:
At 15:18 20/12/2001, Yasuo Ohgaki wrote:
Nobody should complain about BC changes if changes are notified
early enough and there is alternative way to do the same thing.
IMHO. (This has been done for some features such as track vars ;)
That's a very impractical statement in my opinion... Breaking
compatibility hurts (almost) regardless of when you announce you're going
to break it. Users would still have to go over their code and fix it.
What I *really* fail to understand is the gain we get by modifying exit()'s
behavior, as opposed to adding a new function or adding a new $silent
argument. Giving a WFF to several people? Consistency with other
languages that have nothing to do with the Web environment (which is why we
got so little complaints about this over *5* years)?
What would the problem be with the attached patch (against PHP
4.1.0rc3)? This patch meets the following criteria:
o Backward compatibility is maintained, since strings passed to
exit() will still be output. BC will only break in those instances
where something depends on the fact that PHP will not set the exit
code when exiting with a string--very unlikely. This should keep
the BC people happy and not introduce any new surprises.
o No new functions need to be created, and no new arguments need to
be added to exit(). This should keep the No New Functions or
Arguments For Small Functionalities people happy.
o exit() will now behave like other PHP functions wrt its argument
type. Whereas a PHP programmer expects the calls
somefunc('2') and somefunc(2) to behave identically, exit() breaks
this mould. This patch rectifies that, so that exit('2') and
exit(2) will now behave the same. Again, the only time BC is broken
is in cases where something depends on i.e. exit('2') outputting
'0'--which is likely to be *very* rare since it doesn't make any
sense.
Of course, the criterium which this patch does not fulfil is that of
killing the output from exit(), which would break BC. However, it
would still be possible to add an option second argument to exit()
which would suppress this output, but be off by default.
I see this as very similar to the case sensitivity issue, even though this
is obviously on a much smaller scale. It's possibly a bad decision that
was made 5 years ago, but it was made all the same. Since it does *not*
have far-reaching negative implications, it shouldn't be changed.
Zeev
The current behaviour may not be earthshatteringly bad, but it does
break language consistency and so introduces a higher memory load on
the user (gotta remember that everything works the same 'cept
exit()). It also tends to keep some people (OK, at least me) from
doing much non-web scripting in PHP since it's a fairly fundamental
bit of functionality which is something of a bother to work
around. Not a major bother, but enough.
My point is this: we don't break, lose, or complicate anything with
this patch, and it makes the language more consistent and generally
usable.
Just my $0.02 for the night.
Torben
--- zend_execute.bakWed Dec 19 16:19:44 2001
+++ zend_execute.c Wed Dec 19 16:37:29 2001
@@ -2379,11 +2379,16 @@
case ZEND_EXIT:
if (opline-op1.op_type != IS_UNUSED) {
zval *ptr;
+ zval exit_code;
ptr = get_zval_ptr(opline-op1, Ts,
EG(free_op1), BP_VAR_R);
- if (Z_TYPE_P(ptr) == IS_LONG) {
- EG(exit_status) = Z_LVAL_P(ptr);
- }
+
+ exit_code = *ptr;
+ zval_copy_ctor(exit_code);
+ convert_to_long(exit_code);
+
+ EG(exit_status) = Z_LVAL_P(exit_code);
+
zend_print_variable(ptr);
FREE_OP(opline-op1, EG(free_op1));
}
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
http://www.hybrid17.com
http://www.inflatableeye.com
+1.604.709.0506
--
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: Should exit() print out the integer exit-status?
This patch is fine with me, but as it would still print out the error
message, I think it's not fine with some other people...
At 16:29 20/12/2001, Lars Torben Wilson wrote:
Zeev Suraski writes:
At 15:18 20/12/2001, Yasuo Ohgaki wrote:
Nobody should complain about BC changes if changes are notified
early enough and there is alternative way to do the same thing.
IMHO. (This has been done for some features such as track vars ;)
That's a very impractical statement in my opinion... Breaking
compatibility hurts (almost) regardless of when you announce you're going
to break it. Users would still have to go over their code and fix it.
What I *really* fail to understand is the gain we get by modifying
exit()'s
behavior, as opposed to adding a new function or adding a new $silent
argument. Giving a WFF to several people? Consistency with other
languages that have nothing to do with the Web environment (which is
why we
got so little complaints about this over *5* years)?
What would the problem be with the attached patch (against PHP
4.1.0rc3)? This patch meets the following criteria:
o Backward compatibility is maintained, since strings passed to
exit() will still be output. BC will only break in those instances
where something depends on the fact that PHP will not set the exit
code when exiting with a string--very unlikely. This should keep
the BC people happy and not introduce any new surprises.
o No new functions need to be created, and no new arguments need to
be added to exit(). This should keep the No New Functions or
Arguments For Small Functionalities people happy.
o exit() will now behave like other PHP functions wrt its argument
type. Whereas a PHP programmer expects the calls
somefunc('2') and somefunc(2) to behave identically, exit() breaks
this mould. This patch rectifies that, so that exit('2') and
exit(2) will now behave the same. Again, the only time BC is broken
is in cases where something depends on i.e. exit('2') outputting
'0'--which is likely to be *very* rare since it doesn't make any
sense.
Of course, the criterium which this patch does not fulfil is that of
killing the output from exit(), which would break BC. However, it
would still be possible to add an option second argument to exit()
which would suppress this output, but be off by default.
I see this as very similar to the case sensitivity issue, even though this
is obviously on a much smaller scale. It's possibly a bad decision that
was made 5 years ago, but it was made all the same. Since it does *not*
have far-reaching negative implications, it shouldn't be changed.
Zeev
The current behaviour may not be earthshatteringly bad, but it does
break language consistency and so introduces a higher memory load on
the user (gotta remember that everything works the same 'cept
exit()). It also tends to keep some people (OK, at least me) from
doing much non-web scripting in PHP since it's a fairly fundamental
bit of functionality which is something of a bother to work
around. Not a major bother, but enough.
My point is this: we don't break, lose, or complicate anything with
this patch, and it makes the language more consistent and generally
usable.
Just my $0.02 for the night.
Torben
--- zend_execute.bakWed Dec 19 16:19:44 2001
+++ zend_execute.c Wed Dec 19 16:37:29 2001
@@ -2379,11 +2379,16 @@
case ZEND_EXIT:
if (opline-op1.op_type != IS_UNUSED) {
zval *ptr;
+ zval exit_code;
ptr = get_zval_ptr(opline-op1,
Ts, EG(free_op1), BP_VAR_R);
- if (Z_TYPE_P(ptr) == IS_LONG) {
- EG(exit_status) =
Z_LVAL_P(ptr);
- }
+
+ exit_code = *ptr;
+ zval_copy_ctor(exit_code);
+ convert_to_long(exit_code);
+
+ EG(exit_status) =
Z_LVAL_P(exit_code);
+
zend_print_variable(ptr);
FREE_OP(opline-op1, EG(free_op1));
}
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
http://www.hybrid17.com
http://www.inflatableeye.com
+1.604.709.0506
--
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 #14292 Updated: Bare LF Issue - This time with DETAIL!
ID: 14292
Updated by: lobbin
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: *Mail Related
Operating System: Windows 2000 Server/XP
PHP Version: 4.0.6
New Comment:
Any feedback of this?
R.
Previous Comments:
[2001-12-02 02:22:47] [EMAIL PROTECTED]
The code that handles sending messages for Win32 uses
proper CRLF sequences.
Do the most basic test email messages fail? Have you tried
sending something like?
mail ('[EMAIL PROTECTED]', 'test', 'test');
If so, does it get rejected as well?
[2001-11-29 19:12:37] [EMAIL PROTECTED]
I would like to add that I have tried a perl script to send emails and it works fine.
No bare LF. However, I tried to install Sendmail for Windows and I could not get that
to run from php. So... we are back to square 1. Trying to get the Bare LF out of SMTP.
[2001-11-29 18:29:46] [EMAIL PROTECTED]
I am running an apache web server using PHP 4.06 on Windows 2000 Server and Windows XP
(so we know it doesn't matter the OS as long as it's MS and PHP). Now here's my
delima.
I can send emails through MS Outlook to my specified mail address just fine. There's
no problems and it gets delivered right away. But when I try sending an email through
a web form, the unix mail server running QMail rejects it with an error 451 Bare LF.
Here's an example:
This email was sent from my Outlook Client through Postcast Email Server Succesfully
(I have out server names for my protection):
Thread 1: 23:51:23 [---] : HELO .xx.net
Thread 1: 23:51:23 [---] : 220 gambit.xx.net ESMTP
Thread 1: 23:51:23 [---] : MAIL FROM: [EMAIL PROTECTED]
Thread 1: 23:51:23 [---] : 250 gambit.xx.net
Thread 1: 23:51:23 [---] : RCPT TO: [EMAIL PROTECTED]
Thread 1: 23:51:23 [---] : 250 ok
Thread 1: 23:51:23 [---] : DATA
Thread 1: 23:51:23 [---] : 250 ok
Thread 1: 23:51:23 [---] : 354 go ahead
Thread 1: 23:51:23 [---] : QUIT
Thread 1: 23:51:24 [---] : 250 ok 1007074661 qp 3355
Now, this email was sent via a php script form through Postcast (I have out
server names for my protection):
Thread 1: 23:37:55 [---] : HELO xx.xx.net
Thread 1: 23:37:55 [---] : 220 gambit.xx.net ESMTP
Thread 1: 23:37:55 [---] : MAIL FROM: [EMAIL PROTECTED]
Thread 1: 23:37:55 [---] : 250 gambit.x.net
Thread 1: 23:37:55 [---] : RCPT TO: [EMAIL PROTECTED]
Thread 1: 23:37:55 [---] : 250 ok
Thread 1: 23:37:55 [---] : DATA
Thread 1: 23:37:55 [---] : 250 ok
Thread 1: 23:37:56 [---] : 354 go ahead
Thread 1: 23:37:56 [---] : QUIT
Thread 1: 23:37:56 [---] : 451 See http://pobox.com/~djb/docs/smtplf.html.
So what's the problem here? Do you think it could be that PHP 4.06 is spitting out
these bare LF or what? I mean it's obvious that Postmaster Email Server is sending the
mails just fine from Outlook and Outlook is the source of the mail that sent
succesfully, and the PHP script is the one that sent Unsuccessfully.
I have tried at least 6 different SMTP servers for the win32 operating systems. They
all do the same thing. This is very bad for me because I am having extreme
difficulties running my site if every member signs up that has a unix email account
running on Qmail, pukes on me and I have to send the emails directly to them. It's
strange.
I hope we can figure this one out. I have researched the net but not any information
on this particular configuration.
Thanks,
Eric Rosebrock
http://wolfenstein.3dhavoc.net
Edit this bug report at http://bugs.php.net/?id=14292edit=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 #14619: Number doesn't fit the data type
From: [EMAIL PROTECTED] Operating system: AIX (probably not OS specific) PHP version: 4.1.0 PHP Bug Type: Compile Warning Bug description: Number doesn't fit the data type zend_alloc.c, line 635.22: 1506-419 (E) Converting 2576696087 to type long int does not preserve its value. zend_alloc.c, line 643.22: 1506-419 (E) Converting 4219631580 to type long int does not preserve its value. Using 32 bit long these values won't fit. Changing the declaration on line 36 of Zend/zend_alloc.h from 'long magic' to 'unsigned long magic,' or lowering the constant codes might be worth considering. Yours, lars-owe -- Edit bug report at: http://bugs.php.net/?id=14619edit=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]
Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?
On Thu, 20 Dec 2001, Zeev Suraski wrote:
This patch is fine with me, but as it would still print out the error
message, I think it's not fine with some other people...
This solves nothing IMO. The problem is that exit (5) displays '5', and
that must be fixed.
Derick
At 16:29 20/12/2001, Lars Torben Wilson wrote:
Zeev Suraski writes:
At 15:18 20/12/2001, Yasuo Ohgaki wrote:
Nobody should complain about BC changes if changes are notified
early enough and there is alternative way to do the same thing.
IMHO. (This has been done for some features such as track vars ;)
That's a very impractical statement in my opinion... Breaking
compatibility hurts (almost) regardless of when you announce you're going
to break it. Users would still have to go over their code and fix it.
What I *really* fail to understand is the gain we get by modifying
exit()'s
behavior, as opposed to adding a new function or adding a new $silent
argument. Giving a WFF to several people? Consistency with other
languages that have nothing to do with the Web environment (which is
why we
got so little complaints about this over *5* years)?
What would the problem be with the attached patch (against PHP
4.1.0rc3)? This patch meets the following criteria:
o Backward compatibility is maintained, since strings passed to
exit() will still be output. BC will only break in those instances
where something depends on the fact that PHP will not set the exit
code when exiting with a string--very unlikely. This should keep
the BC people happy and not introduce any new surprises.
o No new functions need to be created, and no new arguments need to
be added to exit(). This should keep the No New Functions or
Arguments For Small Functionalities people happy.
o exit() will now behave like other PHP functions wrt its argument
type. Whereas a PHP programmer expects the calls
somefunc('2') and somefunc(2) to behave identically, exit() breaks
this mould. This patch rectifies that, so that exit('2') and
exit(2) will now behave the same. Again, the only time BC is broken
is in cases where something depends on i.e. exit('2') outputting
'0'--which is likely to be *very* rare since it doesn't make any
sense.
Of course, the criterium which this patch does not fulfil is that of
killing the output from exit(), which would break BC. However, it
would still be possible to add an option second argument to exit()
which would suppress this output, but be off by default.
I see this as very similar to the case sensitivity issue, even though this
is obviously on a much smaller scale. It's possibly a bad decision that
was made 5 years ago, but it was made all the same. Since it does *not*
have far-reaching negative implications, it shouldn't be changed.
Zeev
The current behaviour may not be earthshatteringly bad, but it does
break language consistency and so introduces a higher memory load on
the user (gotta remember that everything works the same 'cept
exit()). It also tends to keep some people (OK, at least me) from
doing much non-web scripting in PHP since it's a fairly fundamental
bit of functionality which is something of a bother to work
around. Not a major bother, but enough.
My point is this: we don't break, lose, or complicate anything with
this patch, and it makes the language more consistent and generally
usable.
Just my $0.02 for the night.
Torben
--- zend_execute.bakWed Dec 19 16:19:44 2001
+++ zend_execute.c Wed Dec 19 16:37:29 2001
@@ -2379,11 +2379,16 @@
case ZEND_EXIT:
if (opline-op1.op_type != IS_UNUSED) {
zval *ptr;
+ zval exit_code;
ptr = get_zval_ptr(opline-op1,
Ts, EG(free_op1), BP_VAR_R);
- if (Z_TYPE_P(ptr) == IS_LONG) {
- EG(exit_status) =
Z_LVAL_P(ptr);
- }
+
+ exit_code = *ptr;
+ zval_copy_ctor(exit_code);
+ convert_to_long(exit_code);
+
+ EG(exit_status) =
Z_LVAL_P(exit_code);
+
zend_print_variable(ptr);
FREE_OP(opline-op1, EG(free_op1));
}
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
http://www.hybrid17.com
http://www.inflatableeye.com
+1.604.709.0506
--
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
[PHP-DEV] Bug #8865 Updated: App launching with hotkeys delayed
ID: 8865 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Apache related Operating System: Windows 95b, 98 PHP Version: 4.0.4pl1 New Comment: Can you try this with 4.1.0? R. Previous Comments: [2001-07-02 17:47:30] [EMAIL PROTECTED] No. It only happens when PHP is loaded as a module. If it happens when used as CGI it is not noticeable, since it runs for just a few moments. Probably a web server with lots of traffic could cause the same problem, but mine is a small intranet so I wouldn't notice. [2001-06-14 20:40:36] [EMAIL PROTECTED] Does this happen if you comment out the PHP loadmodule statement in apache conf? (and stop / start apache) [2001-05-12 20:02:11] [EMAIL PROTECTED] I just tried with 4.0.5, and it happens just the same. Also the condition I explained in bug 8864 still holds constant. More info: -Win95 SR-2, Winsock 2 patch, IP (for ws2) patch, TCP (for ws2) patch, comdlg401 patch, DCOM95 installed. -Apache 1.3.12, no bells, no whistles, just out-of-the-box -PHP 4.0.5 (binary download from php.net) -NO extensions loaded, just plain PHP. -Not related to any particular code, this is is a condition on windows itself: apache and php run beautifully. The trouble occurs for other apps when apache runs with the apache-php module. -The slowing down of apps launched using hotkeys is NOT related to any particular application, but is a windows delay. The delay is for the launching (5-7 sec. delay with freeze-up), not for normal running once an app has been launched. If I get things running, everything works ok. -No apparent relation to any other running app: I've tried shutting down everything (yhat is, only explorer running), and then launching apache with php as a module, and the condition persists just the same. I'll try 4.0.6dev on a win98 box and report back. Hope this helps. Gonzalo. [2001-05-12 12:49:46] [EMAIL PROTECTED] Can you please try it with 4.0.5, or preferrable php-4.0.6dev ? [2001-05-12 10:53:48] [EMAIL PROTECTED] Sure does! I haven't tried php 4.0.5-dev on this, but 4.0.4 pl1 does. I still think it must be related to bug 8864 (which died as I didn't give any prompt feedback, but is also real). It's not a Win95 issue only, it also happens on Win98 (haven't tried Win Me). 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=8865 Edit this bug report at http://bugs.php.net/?id=8865edit=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 #14622: Broken SERVER_SIGNATURE
From: [EMAIL PROTECTED] Operating system: Linux knl2.4 and Win2K Server PHP version: 4.1.0 PHP Bug Type: PHP options/info functions Bug description: Broken SERVER_SIGNATURE Both $SERVER_SIGNATURE and $HTTP_SERVER_VARS[SERVER_SIGNATURE] return a malformed result when Apache 1.3.2 has ServerSignature directive set to EMail. phpinfo returns the correct result under the heading Apache Environment but the malformed one under PHP Variables. The malformed result for my installation is: ADDRESSApache-AdvancedExtranetServer/1.3.20 Server at A HREF=\mailto:root@localhost\;gabriel.conchango.com/A Port 80/ADDRESS The problem seems to be that the \ characters are not being interpolated and are thus corrupting the mailto: link in the resulting HTML page-source. I suspect (although I have not tested) that the same problem would occur under other OSs/WebServers that use a server signature. -- Edit bug report at: http://bugs.php.net/?id=14622edit=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 #14621: popen() never returns false
From: [EMAIL PROTECTED] Operating system: PHP version: 4.1.0 PHP Bug Type: Documentation problem Bug description: popen() never returns false popen() doesn't return false on non-existent file. Bug#9043 says that it is intentional, but probably it's not the expected behavior and should be noted in the manual. if (popen(/i/dont/exist,r)) echo OK; results in OK (and no warning is issued). Also applies to exec(), system() and backtick operator. -- Edit bug report at: http://bugs.php.net/?id=14621edit=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] Ext Lotus
Hello, Have to import data from a lotus notes application, have seen a lotus EXT has been added (Zeev always on it ?), does anyone experience to use it to simply import data ? Or not enough stable to do the job ? Else have to use odbc :(. Zeev :) ? Any restriction about lotus version, platform or something like that ? Infos will be very appreciated. pa -- Pierre-Alain Joye Freelance Developpements et Services web/intranet [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] Bug #13787 Updated: custom sess_write not called to start session
This is exactly the problem I was talking about with Bug #14497. There are a lot of session handlers out there that try to use return false; in the session_read function, which makes 4.0.6 act strange, and causes 4.1.0 to crash with a segfault. I don't think it would be too difficult (would it?) to check for a false return and assume no data. Jaime Bozza -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 20, 2001 8:23 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Bug #13787 Updated: custom sess_write not called to start session ID: 13787 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: Linux 2.4.7 glibc 2.2.2 PHP Version: 4.0.6 New Comment: I don't think it is a bug in my session handler because everything works properly with register globals turned on. Another PHP user read my bug report and said he is having the same problem even after upgrading to PHP version 4.1.0. The code I am using is basically the code posted at PHPBuilder http://www.phpbuilder.com/columns/ying2602.php3 I have done some testing by writing to a log file from the sess_write handler and it is never called if a session does not already exist. Thanks, Billy Previous Comments: [2001-12-19 22:52:00] [EMAIL PROTECTED] It should be bugs in your session save handlers. Search zend.com code exchange for PosrgreSQL session save handler as an example. (Under HTTP category). -- Yasuo Ohgaki [2001-10-22 09:26:46] [EMAIL PROTECTED] Bug #9002 describing problems with custom session handlers still appears to be unresolved in PHP v4.0.6. The problem that still persists is the sess_write handler is never called to create a new session when register globals is turned off. An interesting behavior is that after a session is successfully started by a script with register globals turned on, you can turn register globals off and the sess_write handler will be called properly for the life of the session. The sess_write handler is never called unless a session already exists. As a workaround we have one script that has register globals turned on with an ini_set call and we start the session in the script. After the session is started by the script with register_globals enabled all of our other scripts with register_globals disabled work fine with our custom session handlers. our PHP configure options: './configure' '--with-mysql=/usr/local' '--with-gd=/usr/local' '--with-xml' '--with-ttf=/usr/local' '--disable-debug' '--enable-inline-optimizations' Edit this bug report at http://bugs.php.net/?id=13787edit=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 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 #14623: get_meta_tags only looks in begin of file
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.0.6 PHP Bug Type: Strings related Bug description: get_meta_tags only looks in begin of file get_meta_tags() seems to look only in the beginning of a file, meaning that e.g. if there is a lot of PHP code before the HTML header it will return nothing ... Tested using get_meta_tags() on local files with about 9000 characters of PHP code before HTML HEADER. Might be by design (speed), but then a warning is needed in doc: when adding working code, things (get_meta_tags()) stop working ... Workaround: if possible move code after header or if not include a file :( -- Edit bug report at: http://bugs.php.net/?id=14623edit=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 #14624: is_link() fail with error if the link is not found
From: [EMAIL PROTECTED] Operating system: Redhat Linux 7.2 PHP version: 4.1.0 PHP Bug Type: Filesystem function related Bug description: is_link() fail with error if the link is not found Hi, tested on the cvs-4.1 from 20 december 2001, not 4.1 release. it should just return false, seems to be like the previous is_dir() bug in 4.1 release. bye -- Edit bug report at: http://bugs.php.net/?id=14624edit=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] CVS Account Request: albaity
Translate php documntation to arabic -- 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 #8865 Updated: App launching with hotkeys delayed
ID: 8865 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Apache related Operating System: Windows 95b, 98 PHP Version: 4.0.4pl1 New Comment: Still happens. Just exactly like 4.0.6. My actual setup: Apache 1.3.20 (release 10320100), PHP 4.1.0 downloaded from www.php.net, MySQL 3.23.29 (tried also stopping MySQL, and still happens). No extra modules loaded on PHP, nothing special on Apache (default instalation) besides PHP loaded as module, Win 98 SE in spanish. All this on a Pentium II 450, 128 MB RAM Anything else I could test to help? Previous Comments: [2001-12-20 09:51:27] [EMAIL PROTECTED] Can you try this with 4.1.0? R. [2001-07-02 17:47:30] [EMAIL PROTECTED] No. It only happens when PHP is loaded as a module. If it happens when used as CGI it is not noticeable, since it runs for just a few moments. Probably a web server with lots of traffic could cause the same problem, but mine is a small intranet so I wouldn't notice. [2001-06-14 20:40:36] [EMAIL PROTECTED] Does this happen if you comment out the PHP loadmodule statement in apache conf? (and stop / start apache) [2001-05-12 20:02:11] [EMAIL PROTECTED] I just tried with 4.0.5, and it happens just the same. Also the condition I explained in bug 8864 still holds constant. More info: -Win95 SR-2, Winsock 2 patch, IP (for ws2) patch, TCP (for ws2) patch, comdlg401 patch, DCOM95 installed. -Apache 1.3.12, no bells, no whistles, just out-of-the-box -PHP 4.0.5 (binary download from php.net) -NO extensions loaded, just plain PHP. -Not related to any particular code, this is is a condition on windows itself: apache and php run beautifully. The trouble occurs for other apps when apache runs with the apache-php module. -The slowing down of apps launched using hotkeys is NOT related to any particular application, but is a windows delay. The delay is for the launching (5-7 sec. delay with freeze-up), not for normal running once an app has been launched. If I get things running, everything works ok. -No apparent relation to any other running app: I've tried shutting down everything (yhat is, only explorer running), and then launching apache with php as a module, and the condition persists just the same. I'll try 4.0.6dev on a win98 box and report back. Hope this helps. Gonzalo. [2001-05-12 12:49:46] [EMAIL PROTECTED] Can you please try it with 4.0.5, or preferrable php-4.0.6dev ? 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=8865 Edit this bug report at http://bugs.php.net/?id=8865edit=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 #14625: socket servers expect more data from PHPCGI
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.1.0 PHP Bug Type: Sockets related Bug description: socket servers expect more data from PHPCGI Standard sequence of single fsockopen, fputs, fgets, fclose hangs servers. Our own C++-servers and several samples of socket-servers we found in the Internet work with other clients, but when being used by PHP scripts in the standard way described all around try to recv(eive) more data from the PHP script, that itself waits at the fgets statement. Finally this locking situation is resolved by some timer running up at client or server side. Data sent by PHP script is received by the servers in the correct length and echo servers or others do send data back before going back to the recv the actually hangs the (non-blocking server or thread). So from PHP side some information like end of transmission seems to be missing at the server side. Same behavior using PHP 4.0.6 -- Edit bug report at: http://bugs.php.net/?id=14625edit=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 #14626: calling a method magically turns the object into a reference to itself
From: [EMAIL PROTECTED]
Operating system: linux Suse
PHP version: 4.1.0
PHP Bug Type: Class/Object related
Bug description: calling a method magically turns the object into a reference to
itself
Calling an object's method turn the object into a reference to itself. When
the object is itself an array's value (or an object's instance variable)
this shows up when copying (with simple assignement) the surrounding array
(or object).
class bar{
var $my_var = 'bar';
function buggy(){/*nothing needed here*/}
}
$foo[0] = new bar();
$foo[0]-buggy(); // turns the array's value into a reference to the
object
$new = $foo;
$new[0]-my_var = 'new';
echo $foo[0]-my_var;// echoes 'new' !!
Comment out the call to buggy(), or use var_dump before and after this call
to see the magic transformation of $foo[0] from object(bar) to
object(bar).
Tested with 4.0.3 and 4.1.
The same bug has been reported under #11543 (open but unanswered). The code
above is much simpler than that in the original bug report. (I could not
edit that one :))
best regards
Ivan
--
Edit bug report at: http://bugs.php.net/?id=14626edit=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] SID Problem
Hi, ?php session_start(my); session_register(test); $test++; echo SID; ? Can one help me, why does it not print PHPSESSID=kasdf... ?? -- Marco -- 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: Should exit() print out the integer exit-status?
Zeev Suraski wrote: At 15:18 20/12/2001, Yasuo Ohgaki wrote: Nobody should complain about BC changes if changes are notified early enough and there is alternative way to do the same thing. IMHO. (This has been done for some features such as track vars ;) That's a very impractical statement in my opinion... Breaking compatibility hurts (almost) regardless of when you announce you're going to break it. Users would still have to go over their code and fix it. I agree with your opinion also. I think compatibility is one of the most important aspect of successful software/hardware. (All of us know how Microsoft and Intel is successful :) What I *really* fail to understand is the gain we get by modifying exit()'s behavior, as opposed to adding a new function or adding a new $silent argument. Giving a WFF to several people? Consistency with other languages that have nothing to do with the Web environment (which is why we got so little complaints about this over *5* years)? That's too bad If I (probably, Markus, Derick and Jani also) was using PHP at that time, I would strongly object that... I see this as very similar to the case sensitivity issue, even though this is obviously on a much smaller scale. It's possibly a bad decision that was made 5 years ago, but it was made all the same. Since it does *not* have far-reaching negative implications, it shouldn't be changed. Zeev I understand your opinion. I'm not strongly againt to have other function for retuning exit status. It is just like ?php= ? to me. (Better to have one for consistency, but it's not strictly required. It will not be a reason for many bug reports also :) BTW, did you notice my proposal for error level and error message handling? It will break a *LOT* of scripts, but it will give us a *LOT* of benefits/consistency. Parhaps, we should discuss how/when/what breaking compatibility(BC) features should be added/deleted/modified, instead of little spec like exit()? I have sevral proposals that require BC. I suppose many people have them, just like you would like to have case sensitivity for functions :) PS: I *strongly* agree with you to have case sensitivity for function names. -- Yasuo Ohgaki _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.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]
[PHP-DEV] Re: SID Problem
Marco Kaiser [EMAIL PROTECTED] wrote in message 002d01c18975$a24ed9a0$420aa8c0@skotty">news:002d01c18975$a24ed9a0$420aa8c0@skotty... ?php session_start(my); session_register(test); $test++; echo SID; ? Can one help me, why does it not print PHPSESSID=kasdf... ?? This type of qestions goes to php-general mailinglist. This list is only for discussion regarding the development _of_ PHP, not _with_ PHP. -- Mvh./Best Regards Jonas Delfs, http://delfs.dk -- 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: Should exit() print out the integer exit-status?
[EMAIL PROTECTED] writes:
On Thu, 20 Dec 2001, Zeev Suraski wrote:
This patch is fine with me, but as it would still print out the error
message, I think it's not fine with some other people...
This solves nothing IMO. The problem is that exit (5) displays '5', and
that must be fixed.
Derick
This does solve a problem, just not that one. :) I did actually
address that one as well in my message, with the suggestion of an
optional second parameter to suppress the output. Something like:
void exit($status[, $suppress_output = false])
Existing scripts would behave as they always have but coders would
have the option to not have any output generated. My personal
suggestion would be to do this, actually:
void exit($status[, $suppress_output = true])
void die($status[, $suppress_output = false])
...but that first one would reintroduce the BC problem. :)
Anyway, the whole output/not output thing isn't that important to me
personally; I was more concerned about the inconsistency in the
argument usage. At least with that patch it would be
language-consistent, even if one doesn't like the output.
At 16:29 20/12/2001, Lars Torben Wilson wrote:
Zeev Suraski writes:
At 15:18 20/12/2001, Yasuo Ohgaki wrote:
Nobody should complain about BC changes if changes are notified
early enough and there is alternative way to do the same thing.
IMHO. (This has been done for some features such as track vars ;)
That's a very impractical statement in my opinion... Breaking
compatibility hurts (almost) regardless of when you announce you're going
to break it. Users would still have to go over their code and fix it.
What I *really* fail to understand is the gain we get by modifying
exit()'s
behavior, as opposed to adding a new function or adding a new $silent
argument. Giving a WFF to several people? Consistency with other
languages that have nothing to do with the Web environment (which is
why we
got so little complaints about this over *5* years)?
What would the problem be with the attached patch (against PHP
4.1.0rc3)? This patch meets the following criteria:
o Backward compatibility is maintained, since strings passed to
exit() will still be output. BC will only break in those instances
where something depends on the fact that PHP will not set the exit
code when exiting with a string--very unlikely. This should keep
the BC people happy and not introduce any new surprises.
o No new functions need to be created, and no new arguments need to
be added to exit(). This should keep the No New Functions or
Arguments For Small Functionalities people happy.
o exit() will now behave like other PHP functions wrt its argument
type. Whereas a PHP programmer expects the calls
somefunc('2') and somefunc(2) to behave identically, exit() breaks
this mould. This patch rectifies that, so that exit('2') and
exit(2) will now behave the same. Again, the only time BC is broken
is in cases where something depends on i.e. exit('2') outputting
'0'--which is likely to be *very* rare since it doesn't make any
sense.
Of course, the criterium which this patch does not fulfil is that of
killing the output from exit(), which would break BC. However, it
would still be possible to add an option second argument to exit()
which would suppress this output, but be off by default.
I see this as very similar to the case sensitivity issue, even though this
is obviously on a much smaller scale. It's possibly a bad decision that
was made 5 years ago, but it was made all the same. Since it does *not*
have far-reaching negative implications, it shouldn't be changed.
Zeev
The current behaviour may not be earthshatteringly bad, but it does
break language consistency and so introduces a higher memory load on
the user (gotta remember that everything works the same 'cept
exit()). It also tends to keep some people (OK, at least me) from
doing much non-web scripting in PHP since it's a fairly fundamental
bit of functionality which is something of a bother to work
around. Not a major bother, but enough.
My point is this: we don't break, lose, or complicate anything with
this patch, and it makes the language more consistent and generally
usable.
Just my $0.02 for the night.
Torben
--- zend_execute.bakWed Dec 19 16:19:44 2001
+++ zend_execute.c Wed Dec 19 16:37:29 2001
@@ -2379,11 +2379,16 @@
case ZEND_EXIT:
if (opline-op1.op_type != IS_UNUSED) {
zval *ptr;
+ zval exit_code;
ptr = get_zval_ptr(opline-op1,
Ts, EG(free_op1), BP_VAR_R);
- if (Z_TYPE_P(ptr) == IS_LONG)
[PHP-DEV] Bug #14627: Nested output buffering fails when nested buffers are inside methods
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.6 PHP Bug Type: Output Control Bug description: Nested output buffering fails when nested buffers are inside methods Nested output buffering fails when nested buffers are inside methods in a class instance and the class is instantiated after an ob_start() call. Seemingly, -all- output is just printed unceremoniously to the screen in this situation... -- Edit bug report at: http://bugs.php.net/?id=14627edit=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 #14627 Updated: Nested output buffering fails when nested buffers are inside methods
ID: 14627 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Output Control Operating System: Linux PHP Version: 4.0.6 New Comment: Can you provide a small script which demostrates this? R. Previous Comments: [2001-12-20 12:02:31] [EMAIL PROTECTED] Nested output buffering fails when nested buffers are inside methods in a class instance and the class is instantiated after an ob_start() call. Seemingly, -all- output is just printed unceremoniously to the screen in this situation... Edit this bug report at http://bugs.php.net/?id=14627edit=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] Re: Bug #14624: is_link() fail with error if the link is not found
G Tanzilli wrote: From: [EMAIL PROTECTED] Operating system: Redhat Linux 7.2 PHP version: 4.1.0 PHP Bug Type: Filesystem function related Bug description: is_link() fail with error if the link is not found Hi, tested on the cvs-4.1 from 20 december 2001, not 4.1 release. it should just return false, seems to be like the previous is_dir() bug in 4.1 release. bye Yet another bug report for the issue... Please not again... I wish. -- Yasuo Ohgaki -- 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 #14628: Session functions block on lock
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.6 PHP Bug Type: Unknown/Other Function Bug description: Session functions block on lock When running php with fastcgi, php gets stuck on call to open session file. Strace output gives following; open(/www/external/sessions/sess_7cd8fc3921075f6f1483f052619e44e8,O_RDWR) = 4 flock(4, LOCK_EX -- Edit bug report at: http://bugs.php.net/?id=14628edit=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 #14276 Updated: users behind proxy get gibrish on page when compression is used
ID: 14276 Updated by: sander Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Zlib Related Operating System: RedHat PHP Version: 4.0.6 New Comment: No feedback. Closing. Previous Comments: [2001-11-29 06:26:05] [EMAIL PROTECTED] Can you test this with the latest RC (http://www.php.net/~zeev/php-4.1.0RC3.tar.gz) or a CVS-version? BTW, if this only happens with certain browsers, it might not be a PHP-problem, but a browser-problem. [2001-11-29 02:05:59] [EMAIL PROTECTED] Hi, bug # 10070 says it's closed, however this problem still exists. I will explain: When a user is behind a firewall or a proxy, a compressed page is often served to him with gibrish or broken html source code. If the page is displayed fine and you refresh it, it ALWAYS returns a broken HTML output. If you look at the page source, it appears fine. But the actual page is opened with the header/header HTML content outputted on screen and thus not working (css, javascript, etc). To reiterate: this only happens with Proxy servers. Tested and always repeated with IE 5.5, IE 6.0. Doesn't happen with Netscape 4.7 Thanks, Bira http://bugs.php.net/bug.php?id=10070 Edit this bug report at http://bugs.php.net/?id=14276edit=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 #14278 Updated: % and / bug with INTEGERs!
ID: 14278
Updated by: sander
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Math related
Operating System: Linux 2.2.19
PHP Version: 4.0.6
New Comment:
No feedback. Closing.
Previous Comments:
[2001-11-29 15:42:41] [EMAIL PROTECTED]
E:\phpphp -v
4.0.6
E:\phpphp -q test.php
101110 22
3888 14
149 19
5 5
0 0
0 0
AAFTOW
No matter how many times I run this script I always get this. Also tested it on Linux
(2.4), with PHP 4.2.0-dev and it works.
Please try a newer version and see if that fixes the problem you're having.
http://www.php.net/~zeev/php-4.1.0RC3.tar.gz or
http://snaps.php.net/php4-latest.tar.gz
-Chris
[2001-11-29 05:27:51] [EMAIL PROTECTED]
Sometimes (1 - 10 times a day) I get a strange error on one of my production servers.
See this function:
function MakeHash($num) {
$ret = ;
$ca = array();
for ($i = 0; $i 6; $i++) {
$c = $num % 26;
$ca[] = $num $c;
$ret = sprintf(%c, 65+$c).$ret;
$num = ($num-$c)/ 26;
}
// Send $ca array via email to me (removed)
return $ret;
}
Sometimes calling this function with an INT it calculates wired results... If that
happens I mail the $ca array to myself and see what it does:
101110 19 (MEANS: 101110 % 26 is 19!? That's wrong, it is 22)
3588 24 (MEANS 101110 / 26 is 3588, but it is 3888)
1495714 12...
57527 15
2212 2
85 7
What goes wrong? In the beginning the % result is wrong, and then the division result
is wrong too... any suggestions!?
/mike
Edit this bug report at http://bugs.php.net/?id=14278edit=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]
Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?
Zeev Suraski wrote: [snip] What I *really* fail to understand is the gain we get by modifying exit()'s behavior, as opposed to adding a new function or adding a new $silent argument. Giving a WFF to several people? Consistency with other languages that have nothing to do with the Web environment (which is why we got so little complaints about this over *5* years)? If something has been broken for 5 years, and nobody complained, that doesn't mean it does not have to get fixed. Maybe people just haven't cared enough until now. Making several exit()-like functions, one for each bugfix to what should really be the only exit() function is IMHO not very good. Making exit() accept two parameters... well, it's probably not quite as bad, but... well, this will be the first exit() with two arguments I know of... Vlad -- 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 #14629: request link_target()
From: [EMAIL PROTECTED] Operating system: debian PHP version: 4.1.0 PHP Bug Type: Feature/Change Request Bug description: request link_target() As a sister function to is_link($f), link_target($f) would return the target of the link $f, NULL if it's a dead link, or false if $f isn't a link. - Colin -- Edit bug report at: http://bugs.php.net/?id=14629edit=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 #14630: integers wrapping around rather than being promoted into floats on overflow
From: [EMAIL PROTECTED]
Operating system: Solaris 8, 64-bit
PHP version: 4.1.0
PHP Bug Type: *General Issues
Bug description: integers wrapping around rather than being promoted into floats on
overflow
This problem causes all tests in ext/standard/tests/math to fail:
?php
define('LONG_MAX', is_int(50)? 9223372036854775807
: 0x7FFF);
define('LONG_MIN', -LONG_MAX - 1);
printf(%d,%d,%d,%d\n,is_int(LONG_MIN ),is_int(LONG_MAX ),
is_int(LONG_MIN-1),is_int(LONG_MAX+1));
printf( LONG_MIN = %ld, LONG_MIN - 1 = %ld\n,
LONG_MIN, LONG_MIN - 1 );
printf( LONG_MAX = %ld, LONG_MAX + 1 = %ld\n,
LONG_MAX, LONG_MAX + 1 );
?
This script gives the following results on my system:
1,1,1,1
LONG_MIN = -9223372036854775808, LONG_MIN - 1 = 9223372036854775807
LONG_MAX = 9223372036854775807, LONG_MAX + 1 = -9223372036854775808
Here's my setup:
PHP 4.1.0 compiled as a 64-bit stand-alone interpreter (CGI).
Hardware: Sun Blade 1000 (750MHz UltraSparc III processor)
OS:Solaris 8 07/01, running a 64-bit kernel
Compiler: Sun Forte 6 update 2
env CC=cc -fast -xtarget=generic64 CFLAGS=-v -I/opt/include \
CXX=CC -fast -xtarget=generic64 -v \
LDFLAGS=-R/opt/lib/sparcv9 -R/opt/lib -L/opt/lib/sparcv9 -L/opt/lib
\
ac_cv_path_install='/usr/sbin/install' \
./configure --prefix=/opt/packages/php-4.1.0 \
--enable-force-cgi-redirect --enable-discard-path --enable-trans-sid
\
--with-config-file-path=/opt/www/etc \
--with-exec-dir=/opt/packages/php-4.1.0/bin --with-mm=/opt --with-zlib
\
--with-zlib-dir=/opt --with-expat-dir=/opt --with-mysql
--with-gdbm=/opt \
--with-gd=yes --enable-gd-native-ttf --with-xpm-dir=/opt \
--with-jpeg-dir=/opt --with-png-dir=/opt --with-freetype-dir=/opt \
--enable-freetype-4bit-antialias-hack
I hope this helps. Any thoughts as to what the problem could be?
If I can be of help in fixing it, just let me know.
Thanks!
--
Edit bug report at: http://bugs.php.net/?id=14630edit=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] Re: [PEAR-DEV] Re: [FRC]Session module related issues
On Thu, 20 Dec 2001 22:38:03 +0900, Yasuo Ohgaki wrote: Then msession may have the same problem that I mentioned. Since session module can be disabled, if users load extension depands on session module, it will end up with undefined symbol error. This is not nice... But that's actually the problem of the developer: If he want's to use your module, he simply has to ensure that the session module is compiled in his PHP version. Basically, this is the same with PEAR DB e.g.: If I want to use it's abstraction layer for Oracle, I have to make sure that Oracle is available within PHP. - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- 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] Re: [PEAR-DEV] Re: [FRC]Session module related issues
On Thu, 20 Dec 2001 19:58:10 +0900, Yasuo Ohgaki wrote: You missed issues here 1) It highly depends on Session module. I don't see a problem here. The developer has to take care that session is available when he wants to use your module. That's what dependencies are for :-). 2) It does not work as standalone module at all. Note this down in the documentation and you are done. 3) It will fail to load with undefined symbol when PHP is compiled with --disable-session. See my answer for 2) 3) It does not provide any function to users. I can't see a reason here that is speaking against integrating your module in PECL. 4) Where document should be? See my reply to your first mail. 5) How to handle include files required for session save handler module? I can't really answer that question since I'm not familiar enough with PHP's internals. - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- 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] Re: [PEAR-DEV] Re: [FRC]Session module related issues
Martin Jansen wrote: On Thu, 20 Dec 2001 19:58:10 +0900, Yasuo Ohgaki wrote: You missed issues here 1) It highly depends on Session module. I don't see a problem here. The developer has to take care that session is available when he wants to use your module. That's what dependencies are for :-). Placing modules which have its parent is a cause of Undefined symbol error as I mentioned in other mail. If someone volanteer for answering all the bug reports like Hey, PHP don't run my scripts with 'Undefined symbol', why? I don't have problem :) BTW, technically, it is possible not to raise undefined symbol error even if child modules are in PECL. It's not clean way. IMHO. 2) It does not work as standalone module at all. Note this down in the documentation and you are done. If module is gracefully raise error, it is acceptable. 3) It will fail to load with undefined symbol when PHP is compiled with --disable-session. See my answer for 2) Same :) 3) It does not provide any function to users. I can't see a reason here that is speaking against integrating your module in PECL. It's ok to me also for this reason ;) 4) Where document should be? See my reply to your first mail. Will do. 5) How to handle include files required for session save handler module? I can't really answer that question since I'm not familiar enough with PHP's internals. Ok. The issue is decent code management. Well designed software should not raise undefined symbol error with usual installation. IMHO. I also think source code shouldn't be a messy :) -- Yasuo Ohgaki _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.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]
[PHP-DEV] Bug #14629 Updated: request link_target()
ID: 14629 Updated by: jimw Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Feature/Change Request Operating System: debian PHP Version: 4.1.0 New Comment: http://www.php.net/readlink Previous Comments: [2001-12-20 13:23:43] [EMAIL PROTECTED] As a sister function to is_link($f), link_target($f) would return the target of the link $f, NULL if it's a dead link, or false if $f isn't a link. - Colin Edit this bug report at http://bugs.php.net/?id=14629edit=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]
Re: [PHP-DEV] PHP 4.0.6 IMAP BUG
On Thu, Dec 20, 2001 at 10:32:43AM +0100, Markus Fischer wrote: Glad I didn't, its a bug in ext/imap. Due the pointer juggling we're accidantly calling fs_free() on something which was never explicetely malloced. I've a patch here which takes care of this but I'm not too familiar with imap code. Your patch looks sound enough, although I'm not very familiar with that code, either. I don't see any harm committing it to the HEAD branch. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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 #14631: is_file : Same function, different behavior?
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.0.5
PHP Bug Type: Filesystem function related
Bug description: is_file : Same function, different behavior?
Hi gurus and Fellows.
I've been through the Bug Database but didn't find out a related bug.
I use a function that is common to two different pages.
(see code Below). These two pages are located in the same directory on my
website.
For a given reason , (which I would like to know), the function is not
working any longer (but it USED to) on one of this page.
Actually I can point out where (what) it is not working :
- if (is_file(upload/.$ZeFiles-file_name)){ ...
In one PHP page it says OK it is a file (and yes it is, if I type the
address directly in the address bar) on the other page, it
says the opposite!!
If I take this condition off this condition it displays :
Warning: Unable to open upload/1_o_alum_off.gif
where 1_o_alum_off.gif is the name of the (existing) picture...
The consequence being, I just cannot used the GetImageSize() function to
retrieve the picture dimensions...
Any idea anyone ?
ThanX.
olivier aKa Cypher.
//___
function listFilesFromDB($Ze_mydir, $connexion)
{//extract FileName from DB , gets its size and generate the
//Javascript code for a fitted Pop Up window.
$appendIt=;
$resultat = ExecRequete (select * from Files where us_id=.$Ze_mydir,
$connexion);
if (mysql_num_rows($resultat)) {
while ($ZeFiles = LigneSuivante ($resultat))
{
if (!eregi(.mp3,$ZeFiles-file_name)){
if (is_file(upload/.$ZeFiles-file_name)){ //just in
case...//that's where the problem lies...
$imagehw = GetImageSize(upload/.$ZeFiles-file_name); //let's
create
PopUp to the Picture Dimensions...
$imagewidth = $imagehw[0]+60;//let's add an extra margin...
$imageheight = $imagehw[1]+75;
$zePopUpScript = \na href=\javascript:
window.open('showPortFolio.php?idFile=.$ZeFiles-file_id.','','resizable=y
es, scrollbars=yes, width=.$imagewidth .,height=.$imageheight.');
void('');\;
$appendIt.=
TRTD$ZeFiles-file_title/TDTD.$zePopUpScript.View/a/TDTDa
href=\#\
onClick=\javascript:ConfDel(.$Ze_mydir.,.$ZeFiles-file_id.);\Delete
/a/TD/TR\n;
}
}
else {// it is a mp3 file : no need for PopUp...A link should do...
$zePopUpScript = link to Mp3 file .$ZeFiles-file_name;
$appendIt.=
TRTD$ZeFiles-file_title/TDTD.$zePopUpScript.View/a/TDTDa
href=\?action=deletefile_id=.$ZeFiles-file_id.id=.$Ze_mydir.\Delet
e/a/TD/TR\n;
}
}
echo center\ntable width=360trtd
colspan=3h1-Your
Files-/h1/td/tr\n$appendIt\n/table\n/center;
}else{
echo center\nh1No Files so far/h1\n/center;
}
}
// calling the function :
listFilesFromDB($id,$connexion);
//___
PS : Code for both page available upon Request.
PHPinfo :
http://nfrance.com/~am17204/pont/brouillon/test.php
--
Edit bug report at: http://bugs.php.net/?id=14631edit=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] Apology
All, The discussions have been running quite heated on this and engine2 lists, and I certainly did my share. I would like to apologize if any of my comments have hurt your feelings or made you think that I don't care about this language, its users, and developers. I've been having some issues in my personal and professional life, and a lot has been on my mind, so this may have affected my behavior on the lists, undeservedly so. My goal from the beginning has been to extend, improve, and advance PHP, but I understand that sometimes you can't fit a square peg into a round hole. Perhaps it would help if I took a couple of months off to reevaluate my current situation and future goals while the current issues get worked out. Good day and happy holidays, -Andrei * How would this sentence be different if Pi was equal to three? * -- 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 #14632: missing -lz symbol in Makefile
From: [EMAIL PROTECTED] Operating system: Linux 2.2.17 PHP version: 4.1.0 PHP Bug Type: *Compile Issues Bug description: missing -lz symbol in Makefile Greetings, Apache Error: Cannot load /usr/local/apache/libexec/libphp3.so into server: /usr/local/apache/libexec/libphp3.so: undefined symbol: uncompress compiling --with-mysql=/... will result in Apache spitting out an error when trying to load the php module. This is because the APXS_LDFLAGS is missing the -lz symbol. This should either be noted in the INSTALL.* directions or be included. NOTE: this is in 3.x and 4.x. FYI, the APXS_LDFLAGS variable should be called LDLIBRARIES. Sorry to gripe. =) Thanks, Michael Howell -- Edit bug report at: http://bugs.php.net/?id=14632edit=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 #14399 Updated: eregi_replace does not handle upercase scandinavian characters
ID: 14399 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.1.0 New Comment: i have tryed setlocale(LC_ALL, swedish); setlocale(LC_ALL, sv_SE); setlocale(LC_ALL, se); none affects eregi_replace behaivor If it was a localize problem why then would lowercase caracters work ?? Kindest Regards Jonas Isaelsson Previous Comments: [2001-12-11 17:14:55] [EMAIL PROTECTED] Try setting your locale first with setlocale() Feedback. [2001-12-10 05:39:51] [EMAIL PROTECTED] It seem to be so that eregi_replace can´t handle uppercase scandinavian characters (ÅÄÖ). Lowercase works fine. Edit this bug report at http://bugs.php.net/?id=14399edit=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 #14632 Updated: missing -lz symbol in Makefile
ID: 14632 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: *Compile Issues Operating System: Linux 2.2.17 PHP Version: 4.1.0 New Comment: --with-zlib RTFM. RTFBDB. Previous Comments: [2001-12-20 15:03:34] [EMAIL PROTECTED] Greetings, Apache Error: Cannot load /usr/local/apache/libexec/libphp3.so into server: /usr/local/apache/libexec/libphp3.so: undefined symbol: uncompress compiling --with-mysql=/... will result in Apache spitting out an error when trying to load the php module. This is because the APXS_LDFLAGS is missing the -lz symbol. This should either be noted in the INSTALL.* directions or be included. NOTE: this is in 3.x and 4.x. FYI, the APXS_LDFLAGS variable should be called LDLIBRARIES. Sorry to gripe. =) Thanks, Michael Howell Edit this bug report at http://bugs.php.net/?id=14632edit=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]
Re: [PHP-DEV] Apology
I don't think you should be apologizing. Nobdoy should. Anyways, I'm now really going 'away' for a while too and not stir this soup anymore. I hope that some people here stop and think a bit what is wrong here as it's quite obvious that something definately needs to be changed. And I don't mean any techical issues now. Merry Christmas and hopefully happier New Year than this one was.. --Jani On Thu, 20 Dec 2001, Andrei Zmievski wrote: All, The discussions have been running quite heated on this and engine2 lists, and I certainly did my share. I would like to apologize if any of my comments have hurt your feelings or made you think that I don't care about this language, its users, and developers. I've been having some issues in my personal and professional life, and a lot has been on my mind, so this may have affected my behavior on the lists, undeservedly so. My goal from the beginning has been to extend, improve, and advance PHP, but I understand that sometimes you can't fit a square peg into a round hole. Perhaps it would help if I took a couple of months off to reevaluate my current situation and future goals while the current issues get worked out. Good day and happy holidays, -Andrei * How would this sentence be different if Pi was equal to three? * -- 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 #14602 Updated: Compilation of PHP 4.1.0 with libiodbc 3.0.5 support failed
ID: 14602 Updated by: ahill Reported By: [EMAIL PROTECTED] Old Status: Open Status: Analyzed Bug Type: ODBC related Operating System: FreeBSD 4.3, RedHat 7.1 PHP Version: 4.1.0 Old Assigned To: Assigned To: ahill New Comment: I was unable to reproduce, using Redhat 7.1, PHP 4.1.0 and libiobc 3.0.5 with the following configure: ./configure \ --with-iodbc=/dbs/openlink/v41/odbcsdk --with-apache=../apache_1.3.22 \ --enable-track-vars Previous Comments: [2001-12-19 07:55:38] [EMAIL PROTECTED] I am unable to compile PHP 4.1.0 with libiodbc 3.0.5 Here is what I did: $ ls libiodbc-3.0.5.tar.gz php-4.1.0.tar.gz $ tar xzf libiodbc-3.0.5.tar.gz $ cd libiodbc-3.0.5 $ ./configure --prefix=/home/kan/tmp --disable-shared --disable-gui . $ gmake . $ gmake install . $cd .. $ tar xzf php-4.1.0.tar.gz $ cd php-4.1.0 $ ./configure --with-apxs=/usr/local/apache/bin/apxs --with-iodbc=/home/kan/tmp --without-mysql --without-xml $ make . Making all in . /bin/sh /usr/home/kan/tmp/test/php-4.1.0/libtool --silent --mode=compile gcc -I. -I/usr/home/kan/tmp/test/php-4.1.0/ -I/usr/home/kan/tmp/test/php-4.1.0/main -I/usr/home/kan/tmp/test/php-4.1.0 -I/home/kan/tmp/include -I/usr/local/psa/apache/include -I/usr/home/kan/tmp/test/php-4.1.0/Zend -I/home/kan/tmp/include -DHARD_SERVER_LIMIT=2048 -DDEFAULT_PATH=/usr/local/psa/apache/bin:/bin:/usr/bin -DMOD_SSL=208105 -DMOD_PERL -DUSE_PERL_SSI -DEAPI -DEAPI_MM -DUSE_EXPAT -I/usr/home/kan/tmp/test/php-4.1.0/TSRM -g -O2 -prefer-pic -c stub.c /bin/sh /usr/home/kan/tmp/test/php-4.1.0/libtool --silent --mode=link gcc -I. -I/usr/home/kan/tmp/test/php-4.1.0/ -I/usr/home/kan/tmp/test/php-4.1.0/main -I/usr/home/kan/tmp/test/php-4.1.0 -I/home/kan/tmp/include -I/usr/local/psa/apache/include -I/usr/home/kan/tmp/test/php-4.1.0/Zend -I/home/kan/tmp/include -DHARD_SERVER_LIMIT=2048 -DDEFAULT_PATH=/usr/local/psa/apache/bin:/bin:/usr/bin -DMOD_SSL=208105 -DMOD_PERL -DUSE_PERL_SSI -DEAPI -DEAPI_MM -DUSE_EXPAT -I/usr/home/kan/tmp/test/php-4.1.0/TSRM -g -O2 -prefer-pic -o libphp4.la -rpath /usr/home/kan/tmp/test/php-4.1.0/libs -avoid-version -L/home/kan/tmp/lib -R /home/kan/tmp/lib stub.lo Zend/libZend.la sapi/apache/libsapi.la main/libmain.la regex/libregex.la ext/odbc/libodbc.la ext/pcre/libpcre.la ext/posix/libposix.la ext/session/libsession.la ext/standard/libstandard.la TSRM/libtsrm.la -L/home/kan/tmp/lib -liodbc -lpam -liodbc -lcrypt -lm -lcrypt Zend/.libs/libZend.al(catalog.o): In function `SQLGetTypeInfo': /usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/catalog.c(.text+0xd0): multiple definition of `SQLGetTypeInfo' Zend/.libs/libZend.al(catalog.o)(.text+0xd0):/usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/catalog.c: first defined here Zend/.libs/libZend.al(catalog.o): In function `SQLSpecialColumns': /usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/catalog.c(.text+0x2b4): multiple definition of `SQLSpecialColumns' Zend/.libs/libZend.al(catalog.o)(.text+0x2b4):/usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/catalog.c: first defined here Zend/.libs/libZend.al(catalog.o): In function `SQLStatistics': /usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/catalog.c(.text+0x5dc): multiple definition of `SQLStatistics' Zend/.libs/libZend.al(catalog.o)(.text+0x5dc):/usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/catalog.c: first defined here Zend/.libs/libZend.al(catalog.o): In function `SQLTables': /usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/catalog.c(.text+0x8c4): multiple definition of `SQLTables' Zend/.libs/libZend.al(catalog.o)(.text+0x8c4):/usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/catalog.c: first defined here . (many such strings) .. /home/kan/tmp/lib/libiodbc.a(odbc3.o): In function `SQLBindParam': /usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/odbc3.c(.text+0x4484): multiple definition of `SQLBindParam' Zend/.libs/libZend.al(odbc3.o)(.text+0x4484):/usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/odbc3.c: first defined here /home/kan/tmp/lib/libiodbc.a(odbc3.o): In function `SQLCloseCursor': /usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/odbc3.c(.text+0x44bc): multiple definition of `SQLCloseCursor' Zend/.libs/libZend.al(odbc3.o)(.text+0x44bc):/usr/home/kan/tmp/test/libiodbc-3.0.5/iodbc/odbc3.c: first defined here *** Error code 1 Stop in /usr/home/kan/tmp/test/php-4.1.0. *** Error code 1 Stop in /usr/home/kan/tmp/test/php-4.1.0. $ I am supposing that libZend.la library contains libiodbc.a library functions. And in the last compile command both libZend and libiodbc are presents. So conflict with multiply definition somewhere here. Thanks, defencer. Edit this
[PHP-DEV] Bug #14632 Updated: missing -lz symbol in Makefile
ID: 14632 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: Linux 2.2.17 PHP Version: 4.1.0 New Comment: Greetings, Apache Error: Cannot load /usr/local/apache/libexec/libphp3.so into server: /usr/local/apache/libexec/libphp3.so: undefined symbol: uncompress compiling --with-mysql=/... will result in Apache spitting out an error when trying to load the php module. This is because the APXS_LDFLAGS is missing the -lz symbol. This should either be noted in the INSTALL.* directions or be included. NOTE: this is in 3.x and 4.x. FYI, the APXS_LDFLAGS variable should be called LDLIBRARIES in version 3.x Previous Comments: [2001-12-20 15:16:25] [EMAIL PROTECTED] --with-zlib RTFM. RTFBDB. [2001-12-20 15:03:34] [EMAIL PROTECTED] Greetings, Apache Error: Cannot load /usr/local/apache/libexec/libphp3.so into server: /usr/local/apache/libexec/libphp3.so: undefined symbol: uncompress compiling --with-mysql=/... will result in Apache spitting out an error when trying to load the php module. This is because the APXS_LDFLAGS is missing the -lz symbol. This should either be noted in the INSTALL.* directions or be included. NOTE: this is in 3.x and 4.x. FYI, the APXS_LDFLAGS variable should be called LDLIBRARIES. Sorry to gripe. =) Thanks, Michael Howell Edit this bug report at http://bugs.php.net/?id=14632edit=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]
Re: [PHP-DEV] Apology
Andrei Zmievski wrote: Perhaps it would help if I took a couple of months off to reevaluate my current situation and future goals while the current issues get worked out. This makes me sad, really. Recently several people 'took off' from PHP, first Sascha, then Jani and you. I really hope that you return, Sebastian -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- 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] Apology
On Thu, 20 Dec 2001, Sebastian Bergmann wrote: This makes me sad, really. Recently several people 'took off' from PHP, first Sascha, then Jani and you. I really hope that you return, Well, I didn't say I was exiting the PHP development. Rather, I think I should take a breather, because I discovered that I've been dedicating a lot of time to it at the expense of other areas of my life. Some discussions in the past and lately have been causing unnecessary stress, which I could justify if I got paid for working on PHP, but I'm not. So, call it a sabbatical, to think and make plans. Regards, -Andrei The most exciting phrase to hear in science, the one that heralds new discoveries, is not Eureka! but That's funny... -- Isaac Asimov. -- 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] Light musings
http://www.advogato.org/article/395.html -Andrei Computers are useless. They can only give you answers. --Pablo Picasso -- 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] CVS Account Request: desclub
Translating the documentation Maintaining www.php.net -- 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 #14633: get_meta_tags does not work under php4.1.0; works with php4.0.6
From: [EMAIL PROTECTED] Operating system: Slackware Linux 8.0 on L2.4.16 PHP version: 4.1.0 PHP Bug Type: Unknown/Other Function Bug description: get_meta_tags does not work under php4.1.0; works with php4.0.6 We recently upgraded to PHP4.1.0, and found that our jobs listing page at Human Resources no longer listed the jobs. After examining the code in detail, looking for bad EOL marks in the metatag files, and finding nothing wrong, we re-installed PHP4.0.6 and the problem went away. Since we depend on this function for our scripts for job postings, we'll need to remain with PHP4.0.6 for the time being. Here is the configure line that we used for both PHP4.1.0 and PHP4.0.6: ./configure --with-mysql=/usr/local/mysql --with-apache=../apache_1.3.x --with-openssl --enable-track-vars --with-mm --with-pspell --enable-ftp --with-imap --with-imap-ssl --enable-memory-limit --enable-inline-optimization --disable-debug --enable-safe-mode --enable-magic-quotes Additionally, we suspect that the imap related functions may be problematic with 4.1.0; however we have not been able to verify this as our priority was to get our jobs page up and working again, with 4.0.6. Regards, David Lechnyr Network Mgr, Human Resources University of Oregon [EMAIL PROTECTED] -- Edit bug report at: http://bugs.php.net/?id=14633edit=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] ]RFC] Do we want/allow undefined symbol error or not?
Hi all, As you might already notice my RFC for session save handler module, There is a issue how to deal with undefined symbol error for rather usual configuration. It seems I need to establish agreement issue by issue. Here is first one. Do we want/allow undefined symbol error for usual configration? I hope everyone agree, it's not acceptable. Technically, it is possible not to have undefined symbol errors for sub modules. (Don't you think stupid, if Windows app dies at start up and spits strange error message with rather usual usage. Don't you think it is a design flaw? ;) I'll post other issues later, see if we can agree on how to handle modules in a module. I'll take no reply as implicit 'undefined symbol' error should not be allowed for usual configuration :) Other issues coming are: 1) header file location 2) dealing with globals and function reference 3) module initilization order control 4) location of sub module 5) other, may be. PS: I've said yes to locate save handlers to PECL at first, so I'm not against to place sub modules to other locations, if all issue is cleared. -- Yasuo Ohgaki -- 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] ]RFC] Do we want/allow undefined symbol error ornot?
On Fri, 21 Dec 2001, Yasuo Ohgaki wrote: Hi all, As you might already notice my RFC for session save handler module, There is a issue how to deal with undefined symbol error for rather usual configuration. If a user wants to use the mod_pgsql session module, he must be very stupid not to enable sessions. BTW, about which undefined symbol are you talking here. Anyway... it doesn't matter that much if the module doesn't load. Just put it in the docs and hope somebody will read it :) (Don't you think stupid, if Windows app dies at start up and spits strange error message with rather usual usage. Don't you think it is a design flaw? ;) windows doesn't have such a great documentation as PHP has :) Derick -- 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] Re: ]RFC] Do we want/allow *RUNTIME* undefined symbol error or not?
I forgot to mention explicitly ;) Do we want/allow *RUNTIME* undefined symbol error? -- Yasuo Ohgaki -- 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 #14633 Updated: get_meta_tags does not work under php4.1.0; works with php4.0.6
ID: 14633 Updated by: mfischer Reported By: [EMAIL PROTECTED] Old Status: Open Status: Duplicate Bug Type: Unknown/Other Function Operating System: Slackware Linux 8.0 on L2.4.16 PHP Version: 4.1.0 New Comment: Duplicate of #14623 Previous Comments: [2001-12-20 17:09:30] [EMAIL PROTECTED] We recently upgraded to PHP4.1.0, and found that our jobs listing page at Human Resources no longer listed the jobs. After examining the code in detail, looking for bad EOL marks in the metatag files, and finding nothing wrong, we re-installed PHP4.0.6 and the problem went away. Since we depend on this function for our scripts for job postings, we'll need to remain with PHP4.0.6 for the time being. Here is the configure line that we used for both PHP4.1.0 and PHP4.0.6: ./configure --with-mysql=/usr/local/mysql --with-apache=../apache_1.3.x --with-openssl --enable-track-vars --with-mm --with-pspell --enable-ftp --with-imap --with-imap-ssl --enable-memory-limit --enable-inline-optimization --disable-debug --enable-safe-mode --enable-magic-quotes Additionally, we suspect that the imap related functions may be problematic with 4.1.0; however we have not been able to verify this as our priority was to get our jobs page up and working again, with 4.0.6. Regards, David Lechnyr Network Mgr, Human Resources University of Oregon [EMAIL PROTECTED] Edit this bug report at http://bugs.php.net/?id=14633edit=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]
Re: [PHP-DEV] ]RFC] Do we want/allow undefined symbol error or not?
[EMAIL PROTECTED] wrote: On Fri, 21 Dec 2001, Yasuo Ohgaki wrote: Hi all, As you might already notice my RFC for session save handler module, There is a issue how to deal with undefined symbol error for rather usual configuration. If a user wants to use the mod_pgsql session module, he must be very stupid not to enable sessions. BTW, about which undefined symbol are you talking here. Anyway... it doesn't matter that much if the module doesn't load. Just put it in the docs and hope somebody will read it :) Hi Derick, Thank you for your reply. Here is a most common case that I can think of. User compiles session and save hanlder with Apache SAPI, but user compile CGI SAPI without session and user has ini entry for loading save handler. With current source, it ends up with runtime undefined symbol error. And it will be true for other sub modules if there is. I'll address issue preventing runtime undefined symbol error later, so don't worry :) (Don't you think stupid, if Windows app dies at start up and spits strange error message with rather usual usage. Don't you think it is a design flaw? ;) windows doesn't have such a great documentation as PHP has :) Derick Yes. However, both of us know well that users will submit bugs for runtime undefined symbol error ;) -- Yasuo Ohgaki _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.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]
