date:20010718

[PHP-DEV] Bug #12223: ldap rebind procedure implementation

2001-07-18 Thread enrik


From: [EMAIL PROTECTED]
Operating system: any
PHP version:  4.0.6
PHP Bug Type: LDAP related
Bug description:  ldap rebind procedure implementation

A ldap rebind procedure for automatical referral chase is
not provided in php4. The solution of #9704 doesn't work
for ldap_add et al., as these functions do not return a
"ldap result". This is an inherent problem with synchronous
ldap calls.

I have written an implementation of ldap_set_rebind_proc
registering a php rebind callback. A patch is available on
request (or would it be ok to attach a 240-line patch
here?). The patch is vs. ext/ldap/ldap.c 1.90 from CVS.

Enrik

-- 
Edit bug report at: http://bugs.php.net/?id=12223&edit=1


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

[PHP-DEV] Bug #12224: unsubscribe

2001-07-18 Thread irit-a


From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0.6
PHP Bug Type: *General Issues
Bug description:  unsubscribe

Hello, 
I'm doing all to unsubscribe from your list but I'm still getting mails
from you.
please unsubscribe me now.
my email: [EMAIL PROTECTED]

Thanks
Irit
-- 
Edit bug report at: http://bugs.php.net/?id=12224&edit=1


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

[PHP-DEV] Bug #12222 Updated: Unresolved symbol _umoddi3

2001-07-18 Thread rasmus


ID: 1
Updated by: rasmus
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: *Web Server problem
Operating System: HPUX 10.20
PHP Version: 4.0.6
New Comment:

This happens on systems where you have some libraries linked by a native 
compiler/linker and others linked by gcc and you try to create a single binary from 
the jumble of stuff.  Your best bet is to compile and link everything with the same 
compiler, but if you can't do that, try simply adding --enable-libgcc to PHP's 
configure line.

Previous Comments:


[2001-07-18 02:14:26] [EMAIL PROTECTED]

Software:

HPUX 10.20
gcc 2.8.1 

apache 1.3.19
( ./configure \
"--with-layout=Apache" \
"--prefix=/usr/local/apache1319" \
"--enable-module=most" \
"--enable-shared=max" \
"--add-module=mod_frontpage.c" \
"--activate-module=src/modules/jserv/mod_jserv" \ )

php 4.0.6
./configure  --with-mysql=/usr/local/mysql ( Version 3.22.32 )
--enable-track-vars --prefix=/usr3/php4.0.6
--with-apxs=/usr/local/apache1319/bin/apxs

Compile is OK !

http.test :
LoadModule php4_modulelibexec/libphp4.sl
AddModule mod_php4.c

Start Apache :
./src/httpd -f /usr/local/apache1319/conf/httpd.test

Error:
/usr/lib/dld.sl: Unresolved symbol: __umoddi3 (code)  from 
/usr/local/mysql/lib/mysql/libmysqlclient.sl.6
Syntax error on line 58 of /usr/local/apache1319/conf/httpd.test:
Cannot load /usr/local/apache1319/libexec/libphp4.sl into server: No such file or
directory

Without PHP4 is all OK !
Can you help me ?

R.K.






Edit this bug report at http://bugs.php.net/?id=1&edit=1


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

[PHP-DEV] Bug #12225: [XML] support for other encoding in utf8_decode , utf8_encode

2001-07-18 Thread M . Hankus


From: [EMAIL PROTECTED]
Operating system: linux
PHP version:  4.0.6
PHP Bug Type: Feature/Change Request
Bug description:  [XML] support for other encoding in utf8_decode , utf8_encode 

Functions utf8_encode utf8_decode support only ISO-8859-1. Support for
other encodings would be a great feature, especially for people who does
not use ISO-8859-1. Without 
those encodings all XML functions are useless (at least for XML which
contains national characters). Maybe there will be a way to make user
specified encoding ???
-- 
Edit bug report at: http://bugs.php.net/?id=12225&edit=1


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

Re: [PHP-DEV] Bug #12220: help

2001-07-18 Thread Hartmut Holzgraefe


[EMAIL PROTECTED] wrote:
> 09  10 $dir="username";
> 11 if(is_dir($dir))
> [...]
> php return a error...NO SUCH DIRECTORY OR FILE ON LINE 11 ...

you have to check for file existance with file_exists() before you
try to probe for its filetype

-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77

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

Re: [PHP-DEV] Bug #12223: ldap rebind procedure implementation

2001-07-18 Thread Ron Chmara

[EMAIL PROTECTED] wrote:
> 
> From: [EMAIL PROTECTED]
> Operating system: any
> PHP version:  4.0.6
> PHP Bug Type: LDAP related
> Bug description:  ldap rebind procedure implementation
> 
> A ldap rebind procedure for automatical referral chase is
> not provided in php4. The solution of #9704 doesn't work
> "ldap result". This is an inherent problem with synchronous
> ldap calls.
> 
> I have written an implementation of ldap_set_rebind_proc
> registering a php rebind callback. A patch is available on
> request (or would it be ok to attach a 240-line patch
> here?). The patch is vs. ext/ldap/ldap.c 1.90 from CVS.

We have seen bigger patches, however, for something of
this size you should:
a) post the patch to thE PHP-DEV list.
b) apply for a CVS account to /ext/ldap
c) also create a patch for the documentation...  referral
chasing does no good if folks don't know what to do (or
how to chase it, or that it works now). The patch to allow
multiple servers never got documented, so many users
are still stuck with one server.

Because it is 240 lines, there might be some macros to speed
it up, which is another reason why peer review (on PHP-dev)
is a good idea.

-Ronastillwonderingaboutthe_mod_functionsbop

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

[PHP-DEV] Bug #12227: Output puffering causes Apache to SIGSEGV

2001-07-18 Thread brueckner


From: [EMAIL PROTECTED]
Operating system: Linux 2.2.16-SMP
PHP version:  4.0.6
PHP Bug Type: Output Control
Bug description:  Output puffering causes Apache to SIGSEGV

When using ob_start() with a script included via auto_prepend_file and then
doing something like this:

ob_start("my_flush");

function my_flush($buffer)
  {
$buffer = preg_replace("/()/e", "parse(\"\\1\")",
$buffer);

return $buffer;
  }

PHP 4.0.6 SIGSEGV's with this message in the error_log:

[Wed Jul 18 11:55:08 2001]  Script:  '/home/htdocs/test.php'
---
output.c(235) : Block 0x0824C940 status:
Beginning:  Overrun (magic=0x08294990, expected=0x7312F8DC)
  End:  Unknown
---
./zend_execute.c(334) :  Freeing 0x082A8CB4 (28131 bytes),
script=/home/htdocs/test.php
zend_variables.c(117) : Actual location (location was relayed)
[Wed Jul 18 11:55:08 2001] [notice] child pid 30192 exit signal
Segmentation fault (11)

If I replace the line
$buffer = preg_replace("/()/e", "parse(\"\\1\")",
$buffer);
with
$newbuffer = preg_replace("/()/e",
"parse(\"\\1\")",
$buffer);

it works fine.

Any ideas for a fix?

Harry

-- 
Edit bug report at: http://bugs.php.net/?id=12227&edit=1


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

[PHP-DEV] Bug #12227 Updated: Output puffering causes Apache to SIGSEGV

2001-07-18 Thread brueckner


ID: 12227
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Output Control
Operating System: Linux 2.2.16-SMP
PHP Version: 4.0.6
New Comment:

One more comment which I forgot before:

This does NOT happen when I do not use auto_prepend_file and call my function inside 
the main script instead.


Previous Comments:


[2001-07-18 06:07:05] [EMAIL PROTECTED]

When using ob_start() with a script included via auto_prepend_file and then doing 
something like this:

ob_start("my_flush");

function my_flush($buffer)
  {
$buffer = preg_replace("/()/e", "parse(\"\\1\")",
$buffer);

return $buffer;
  }

PHP 4.0.6 SIGSEGV's with this message in the error_log:

[Wed Jul 18 11:55:08 2001]  Script:  '/home/htdocs/test.php'
---
output.c(235) : Block 0x0824C940 status:
Beginning:  Overrun (magic=0x08294990, expected=0x7312F8DC)
  End:  Unknown
---
./zend_execute.c(334) :  Freeing 0x082A8CB4 (28131 bytes), 
script=/home/htdocs/test.php
zend_variables.c(117) : Actual location (location was relayed)
[Wed Jul 18 11:55:08 2001] [notice] child pid 30192 exit signal Segmentation fault 
(11)

If I replace the line
$buffer = preg_replace("/()/e", "parse(\"\\1\")",
$buffer);
with
$newbuffer = preg_replace("/()/e", "parse(\"\\1\")",
$buffer);

it works fine.

Any ideas for a fix?

Harry






Edit this bug report at http://bugs.php.net/?id=12227&edit=1


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

[PHP-DEV] Bug #12018 Updated: curl_exec() kills script

2001-07-18 Thread stas


ID: 12018
Updated by: stas
Reported By: [EMAIL PROTECTED]
Old Status: Assigned
Status: Closed
Bug Type: cURL related
Operating System: Debian (2.4.5)
PHP Version: 4.0.6
Assigned To: stas
New Comment:

Fix committed to the CVS

Previous Comments:


[2001-07-17 07:13:24] [EMAIL PROTECTED]

I think I know what's the problem.



[2001-07-15 19:17:50] [EMAIL PROTECTED]

After a few patches from Sterling (thanks), I no longer see the memory leak messages 
in the apache error log, and all the curl_exec() calls seem to work okay.

But:

The setting of CURLOPT_HEADER is treated oddly.  Specifically, when you ask for no 
HTTP header, it returns one.  When you do ask for one, it returns one, with each line 
duplicated.

To see what I mean go here:

http://devel.easydns.com/~cmv/curltest/phpnet.php?header=0
http://devel.easydns.com/~cmv/curltest/phpnet.php?header=1

The value of $header is passed to curl_setopt($ch, CURLOPT_HEADER, $header).  You can 
see the duplicatation.

Sterling has emailed me that he won't be able to look at this for a week or more ... 
so I'm hoping one of the other developers who is familiar with this extension can take 
a quick boo and see if it's an easy fix.  My C is limited, but I'm wondering if an 
extra condition is needed to the if statement on line 378 of curl.c ... something 
like:

int get_header;
curl_easy_getinfo(ch->cp, option, &get_header);
if (get_header && 
  ch->handlers->write->method == PHP_CURL_RETURN) {
...


- Colin



[2001-07-10 11:49:33] [EMAIL PROTECTED]

Okay,

I recompile PHP with --enable-debug, so I could get a backtrace.

Now the problem goes away. :/

This is good for me, but must indicate something weird in the cURL implementation, no?

- Colin



[2001-07-10 11:45:56] [EMAIL PROTECTED]

Every script I have that uses cURL never makes it past the curl_exec() line.  Apache 
just seems to die at that point.  Apache error log shows:

[Tue Jul 10 11:43:40 2001] [notice] child pid 27769 exit signal Segmentation fault 
(11)
[Tue Jul 10 11:43:40 2001] [notice] child pid 27768 exit signal Segmentation fault 
(11)

This is with PHP-4.0.6 Release, and cURL 7.8 final, on Debian (2.4.5-pre3).  cURL is 
configured:

configure --with-ssl

PHP is:

./configure \
--with-mysql=/usr/local \
--with-apxs=/usr/local/apache/bin/apxs \
--enable-track-vars \
--disable-magic-quotes \
--disable-debug \
--enable-ftp \
--with-gettext \
--with-xml \
--with-dom \
--enable-wddx \
--with-curl \
--with-pgsql \
--with-zlib \
--enable-versioning \
--enable-sockets \
--with-openssl \
--with-snmp \
--with-mcrypt

I was able to determine the following:

I have one script that cURL-posts to another URL on the same server, and that script 
then cURL-posts to a URL outside.  In this case, the first script dies.

I have another script that directly cURL-posts to the outside URL.  This script works 
fine.

So it only seems to die if there are 2 cURL processes running on the same server 
simultaneously (?).  This would explain the 2 segfaults in the Apache log.

Let me know what other info I can give to help track down the problem.

- Colin





Edit this bug report at http://bugs.php.net/?id=12018&edit=1


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

[PHP-DEV] Strange printf

2001-07-18 Thread Stanislav Malyshev


I have noticed that PHP printf threats non-decimal formats as signed. This
is pretty non-standard, since C printf, for example, has all non-decimal
formats as ungined, and so does Perl. The questions are:

1. What was the reason for this strange deviation from other languages?
2. Does anybody uses this feature and will someone object if it is
returned to the thing the rest of languages having printf do?

-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



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

[PHP-DEV] more printf oddity

2001-07-18 Thread Stanislav Malyshev


I have also noticed that all values in functions php_sprintf_append*int
are converted to int, though they were originally long. I know that on
some systems (like Linux ix86) int == long, but I'm not sure we should mix
those two types. Does anybody has an explanation for this?

-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



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

[PHP-DEV] Bug #12228: type convretion problem

2001-07-18 Thread noIdea


From: [EMAIL PROTECTED]
Operating system: Windows 98
PHP version:  4.0.4pl1
PHP Bug Type: *General Issues
Bug description:  type convretion problem

Easy to describe:

echo odbc_result($ref, "column");
$a = (double) odbc_result($ref, "column");
echo "   /   " . $a;

output:

55.25   /   55

If I assign result from odbc_result to some variable, it's ALWAYS convertet
to INTEGER.

(I'm used MS Access 2000.)

-- 
Edit bug report at: http://bugs.php.net/?id=12228&edit=1


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

[PHP-DEV] Bug #12229: implicit_flush (off) causes mysql to see into the future

2001-07-18 Thread php-man


From: [EMAIL PROTECTED]
Operating system: RedHat 7.1
PHP version:  4.0.6
PHP Bug Type: MySQL related
Bug description:  implicit_flush (off) causes mysql to see into the future

I'll be the first to admit that this is weird ... but, after 11hours of
debugging and recompiling I can safely say that while implicit_flush is
off, mysql_query returns some odd (pre-emptive) results;


I have run an old database system (php3.0.12/mysql3.22.26a (sitting on
RH6.0)) for a couple of years .. I wanted to put that onto a new RH7.1 box
(php4.04pl1-9/mysql3.23.36-1).  Whith the same database structure, and the
same
php code (bar the mysql_affected_rows() "link id" mod) I was seeing future
mysql updates being entered into the database before current php decisions,
ie;

Table "tbl" has 1 record.  In that record, field "fldx"=0, field
"fldt"=0.

if we query the database, in one instance, and do nothing more;
  select * from tbl, echo field "fldx"
.. the screen output is the value 0.


if we add to that php program/script a function call to a function
containing further mysql queries - including updates to the field we echo
at the top of this script (above);
 function whatever (condition parameters) {
  $time = 995454806
  update tbl set fldt=$time where (conditions) and fldt=0
  if affected rows > 0  {
   select * from tbl where (conditions)
   if number rows > 0  {
fetch array (to retrieve fldx)
if fldx == 2 {
  delete from tbl where (conditions)
  (interim work on other tables)
  return
 } else {
  update tbl set fldx=2 where (conditions)
  (interim work on other tables)
  update tbl set fldt=0 where (conditions) and
fldt=$time
  return
 }
}
}
return
 }


then the onscreen output for fldx is "2".

It is as though we had gone through the program with the stored fldx value
of "0", switching through the conditions appropriately, then updating our
record (fldx) with a "2", before we proceed through the php (from the
top),
outputting our "2" then randomly tripping condition 1 (no affected rows),
or randomly tripping condition fldx==2, 
causing the record to be prematurely deleted, or randomly (far less
frequently than the prior) occuring correctly.

 ... almost as if the output caching was occuring *between* PHP and MySQL
... not between PHP and the User .. (?)

Since I had thought it was version problems with PHP/MySQL, I have compiled
up and am now running php4.06 and mysql3.23.39 -- where the problem
persisted. I have since verified that the /etc/php.ini setting
"implicit_flush" when set to "on" under the newer software, does return my
code to the former php3/expected logic.

Very strange indeed.




-- 
Edit bug report at: http://bugs.php.net/?id=12229&edit=1


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

Re: [PHP-DEV] Strange printf

2001-07-18 Thread Lars Povlsen


Stanislav Malyshev wrote:
> 
> I have noticed that PHP printf threats non-decimal formats as signed. This
> is pretty non-standard, since C printf, for example, has all non-decimal
> formats as ungined, and so does Perl. The questions are:
> 
> 1. What was the reason for this strange deviation from other languages?
> 2. Does anybody uses this feature and will someone object if it is
> returned to the thing the rest of languages having printf do?
> 

IMHO, I think this is an artifact of PHP only supporting _signed_
integers.

Refer to http://www.php.net/manual/en/language.types.integer.php

Sincerely,

Lars Povlsen
Filanet Europe A/S

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

Re: [PHP-DEV] Strange printf

2001-07-18 Thread Stanislav Malyshev


LP>> IMHO, I think this is an artifact of PHP only supporting _signed_
LP>> integers.

But printing signed binary numbers or octals, etc. is pretty meaningless -
at least, I fail to see any use of it and no printf I know ever did that.
This also doesn't exactly works right - thus I ask, would it be OK to
remove it or anyone here uses this feature and objects to it?

-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



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

[PHP-DEV] Bug #12229 Updated: implicit_flush (off) causes mysql to see into the future

2001-07-18 Thread php-man


ID: 12229
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: MySQL related
Operating System: RedHat 7.1
PHP Version: 4.0.6
New Comment:

In addition;

  After removing debugging code (which included a top-of-script database open, loop'd 
fetch-array, close ... a heap
of "echo"s with relevant stages/values .. and a few var_dumps) the implicit_flush=On 
is no longer keeping the script predictable.  I can't believe I'm the only person 
experiencing these difficulties/bugs (if they are legitimate) ... have I done 
something catastrophically wrong?  I would suspect a php error (on my part) if the 
error was consistant/predictable .. but the only time this has been predictable has 
been either under php3 (where the code has existed for 2years) or with my own debug 
code and implicit_flush on in php4 (which I now can no longer reproduce) ... very 
frustrating.

Any help/info appreciated ... I can run test code if it will help.


Previous Comments:


[2001-07-18 07:22:24] [EMAIL PROTECTED]

I'll be the first to admit that this is weird ... but, after 11hours of debugging and 
recompiling I can safely say that while implicit_flush is off, mysql_query returns 
some odd (pre-emptive) results;


I have run an old database system (php3.0.12/mysql3.22.26a (sitting on RH6.0)) for a 
couple of years .. I wanted to put that onto a new RH7.1 box 
(php4.04pl1-9/mysql3.23.36-1).  Whith the same database structure, and the same
php code (bar the mysql_affected_rows() "link id" mod) I was seeing future mysql 
updates being entered into the database before current php decisions, ie;

Table "tbl" has 1 record.  In that record, field "fldx"=0, field "fldt"=0.

if we query the database, in one instance, and do nothing more;
  select * from tbl, echo field "fldx"
.. the screen output is the value 0.


if we add to that php program/script a function call to a function containing further 
mysql queries - including updates to the field we echo at the top of this script 
(above);
 function whatever (condition parameters) {
  $time = 995454806
  update tbl set fldt=$time where (conditions) and fldt=0
  if affected rows > 0  {
   select * from tbl where (conditions)
   if number rows > 0  {
fetch array (to retrieve fldx)
if fldx == 2 {
  delete from tbl where (conditions)
  (interim work on other tables)
  return
 } else {
  update tbl set fldx=2 where (conditions)
  (interim work on other tables)
  update tbl set fldt=0 where (conditions) and fldt=$time
  return
 }
}
}
return
 }


then the onscreen output for fldx is "2".

It is as though we had gone through the program with the stored fldx value of "0", 
switching through the conditions appropriately, then updating our record (fldx) with a 
"2", before we proceed through the php (from the top),
outputting our "2" then randomly tripping condition 1 (no affected rows), or randomly 
tripping condition fldx==2, 
causing the record to be prematurely deleted, or randomly (far less frequently than 
the prior) occuring correctly.

 ... almost as if the output caching was occuring *between* PHP and MySQL ... not 
between PHP and the User .. (?)

Since I had thought it was version problems with PHP/MySQL, I have compiled up and am 
now running php4.06 and mysql3.23.39 -- where the problem persisted. I have since 
verified that the /etc/php.ini setting "implicit_flush" when set to "on" under the 
newer software, does return my code to the former php3/expected logic.

Very strange indeed.









Edit this bug report at http://bugs.php.net/?id=12229&edit=1


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

[PHP-DEV] Batimat 2001---www.eurofo.com Time:17:02:24

2001-07-18 Thread jim_chen

Title: ÐÂÔö·þÎñÏîÄ¿¡ª¡ªÃâ·Ñ½¨Á¢×Ô¼ºµÄÆóÒµÍøÒ³ºÍ²úÆ·¿â




 
  ÐÂÔö·þÎñÏîÄ¿¡ª¡ªÃâ·Ñ½¨Á¢×Ô¼ºµÄÆóÒµÍøÒ³ºÍ²úÆ·¿â
  Ø  ÄúÊÇ·ñÒòÎªÓÊ¼Ä½¨²ÄÑùÆ·µÄ·ÑÊ±¡¢·ÑÁ¦¡¢·ÑÇ®¶øÍ·ÌÛ£¿
  Ø  ÄúÊÇ·ñÒòÔÚµç»°ÀïÎÞ·¨ÈÃ¶Ô·½Ã÷°××Ô¼º²úÆ·µÄÌØÉ«¶ø¼±µÃÖ¸ÊÖ»®½Å£¬ÉùË»Á¦½ß£¿ 
  ÏÖÔÚÓÐÁËÅ·ÂÞ¸£¹ú¼Ê½¨²Ä²É¹ºÍø£¬Äú²»±ØÔÙÎªÕâÐ©ÞÏÞÎ¶ø·³ÄÕÁË£¡
  Å·ÂÞ¸£¹ú¼Ê½¨²Ä²É¹º¼¯ÍÅ³¤ÆÚ´ÓÊÂÖÐ¹úÓëº£ÍâµÄ¹ú¼ÊÃ³Ò×£¬1992 ÄêÒÔÀ´£¬Å·ÂÞ¸£ÖÂÁ¦ÓÚ³ÉÎª¹µÍ¨ÖÐ¹ú½¨²Ä²úÆ·Óëº£Íâ½¨²ÄÊÐ³¡µÄÇÅÁº£¬ÕûºÏÁËÖÐ¹úÖÚ¶àµÄÖÐÐ¡ÐÍ½¨²ÄÉú²úÉÌ£¬¹©Ó¦ÉÌºÍ·ÖÏúÉÌ£¬´ú±íËûÃÇ½øÐÐ½¨²Ä½ø³ö¿ÚÃ³Ò×£¬»ýÀÛÁË·á¸»µÄÃ³Ò×¾Ñé²¢±ÙÍ¨ÁË¹ã·ºµÄÃ³Ò×ÇþµÀ¡£
  ÎªÁËÄÜ¸ü´ó³Ì¶ÈÉÏÈÃÕâÐ©ÖÐÐ¡ÐÍ½¨²ÄÉú²úÉÌÔÚµÚÒ»Ê±¼äÄÚ°Ñ×Ô¼ºµÄÆóÒµ½éÉÜºÍ²úÆ·ÌØÐÔ³ÊÏÖÔÚ²É¹ºÉÌÃæÇ°£¬ÎÒÃÇÌØµØÃâ·ÑÎªËûÃÇÔÚÍøÉÏ¿ª±ÙÁËÆóÒµºÍ²úÆ·µÄÕ¹Ê¾Ìü¡£ËûÃÇ½«²»±ØÔÙÎªÓÊ¼ÄÑùÆ·¶ø·³ÄÕ£»Ò²²»±ØÔÙÒò×Ô¼ºµÄ²úÆ·ÖÚ¶à£¬ÎÞ·¨Ïò¿Í»§×÷ÏêÏ¸½éÉÜ¶øµ£ÐÄ£»¸ü²»»áÎªÎÞ·¨ÃèÊöÄ³Ò»²úÆ·µÄÌØÐÔ¶øÞÏÞÎÁË¡£
  ¾ßÌå²Ù×÷ÈçÏÂ£º
  1.    
ÒòÎªÄúÒÑ¾ÊÇÎÒÃÇµÄ»áÔ±£¬ÇëÔÚÎÒÃÇÍøÕ¾ÖÐÎÄ°æµÇÂ¼£¬¼´¿É¿´µ½Ìí¼Ó¹ÜÀíÆóÒµÐÅÏ¢¹¦ÄÜ¡£
  2.    
¿¼ÂÇµ½Ã¿¸öÆóÒµÐÅÏ¢Ö»ÄÜÓÉÒ»¸öÓÃ»§ÕÊ»§¹ÜÀí£¬ËùÒÔÄúÌí¼Ó¹ÜÀíÆóÒµÐÅÏ¢Ðè¾ÎÒÃÇÉóºË£¬ÉóºË½«ÔÚÒ»¸ö¹¤×÷ÈÕÄÚÍê³É¡£
  3.    
µ±ÄúÊÕµ½ÎÒÃÇËù·¢³öµÄÈ·ÈÏº¯ºó,Äú¾Í¿ÉÒÔÌí¼ÓÆóÒµ²úÆ·ÐÅÏ¢£¬¸ü¿ÉÒÔ°ÑÄúµÄ²úÆ·Í¼Æ¬Ìí¼ÓÉÏÀ´£¬ÆäËûÓÃ»§¾Í¿ÉÒÔÔÚÎÒÃÇÍøÕ¾ÖÐËÑË÷µ½ÄúËù×¢²áµÄÆóÒµºÍ²úÆ·£¬Õâ½«¸üÓÐÀûÓÚ²úÆ·µÄÍÆ¹ã¡£ 
  4.    
ÈçÄúÔÚÖÆ×÷²úÆ·Í¼Æ¬ÖÐÓÐÎÊÌâ£¬ÎÒÃÇ½«½ß³ÏÌá¹©É¨Ãè¼°ÖÆ×÷Í¼Æ¬µÄ·þÎñ¡£ 
  5.    
¶ÔÓÚ»áÔ±ÆóÒµ£¬ÎÒÃÇ»á½«ÄúµÄÆóÒµ¼°²úÆ·ÓÐÕë¶ÔÐÔµØÓÅÏÈÍÆ¹ã¸øÎÒÃÇµÄ¹úÄÚÍâÓÃ»§£¬Ìá¹©¹ú¼ÊÃ³Ò×»ú»á¡£ 
  ÈçÔÚÊ¹ÓÃÖÐÓöµ½²»Çå³þµÄµØ·½£¬Çë²¦´ò¿Í·þµç»°£º£¨021£©62175306*825





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

[PHP-DEV] Bug #12230: Error with Object saved in Session

2001-07-18 Thread schmidt


From: [EMAIL PROTECTED]
Operating system: HP Unix 10
PHP version:  4.0.5
PHP Bug Type: Session related
Bug description:  Error with Object saved in Session

I have the follow Problem:

Fatal error:  The script tried to execute a method or access a property of
an incomplete object. Please ensure that the class definition test of the
object you are trying to operate on was loaded _before_ the session was
started in /u4_1/www/rf/includes/all_sicherheit.inc on line 3

Very simple:

In file 1:

class foo
{
...
}
$x=new foo
$x->... = 123;
session_register("x");

in 2. file:

class foo
{
...
}

echo $x->...;

When I do a session_register("x") befor I printed $x->...
it get the same error.

Is there a Workaround?
-- 
Edit bug report at: http://bugs.php.net/?id=12230&edit=1


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

[PHP-DEV] Bug #12231: about ldap_get_values_len

2001-07-18 Thread stsit


From: [EMAIL PROTECTED]
Operating system: redhat7.0
PHP version:  4.0.6
PHP Bug Type: LDAP related
Bug description:  about ldap_get_values_len

I have a binary data in LDAP,(the data is 570k)
when i use $data=ldap_get_values_len() to get the data,
i found that $data[0] has 33k,i think because it have "00" in the binary
data.
how can i do?
-- 
Edit bug report at: http://bugs.php.net/?id=12231&edit=1


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

[PHP-DEV] Bug #12232: Unresolved symbol: __umoddi3

2001-07-18 Thread r . kalemba


From: [EMAIL PROTECTED]
Operating system: HP 10.20
PHP version:  4.0.6
PHP Bug Type: Dynamic loading
Bug description:  Unresolved symbol: __umoddi3


Apache 1.3.20
Mysql 3.22.32
gcc 2.8.1
PHP 4.0.6 compile:
./configure --with-mysql=/usr/local/mysql --enable-track-
vars --prefix=/usr3/php4.0.6 --enable-libgcc 
--with-apxs=/usr/local/apache1320/bin/apxs

Notice:
i have modify apxs ( HPUX required .sl Suffix ! )

Start Apache -->
Error :
/usr/lib/dld.sl: Unresolved symbol: __umoddi3 (code)  from
/usr/local/mysql/lib/mysql/libmysqlclient.sl.6
Syntax error on line 58 of /usr/local/apache1320/conf/httpd.test:
Cannot load /usr/local/apache1320/libexec/libphp4.sl into server: No such
file or
directory

Part of config.status:
s%@CONFIGURE_COMMAND@% './configure' '--with-mysql=/usr/local/mysql'
'--enable-tra
ck-vars' '--prefix=/usr3/php4.0.6' '--enable-libgcc'
'--with-apxs=/usr/local/apach
e1319/bin/apxs'%g
s%@EXTRA_LIBS@%  -lmysqlclient -lcrypt -lm  -lgcc %g
s%@NATIVE_RPATHS@% -L/opt/gcc/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.8.1
-L/usr/local/
mysql/lib/mysql%g

File:
-rw-rw-rw-   1 root   sys 333402 Sep 15  1998
/opt/gcc/lib/gcc-lib/hppa1.1-hp-hpux10.20/
2.8.1/libgcc.a

This is the second question.
The first answer get from Asmus ( PHP-Group )
 ...
install php with '--enable-libgcc' 

--> the same error

Have you another tip ?

R.Kalemba
-- 
Edit bug report at: http://bugs.php.net/?id=12232&edit=1


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

[PHP-DEV] Bug #12219 Updated: Command Line Arguments not being passed correctly

2001-07-18 Thread cynic


ID: 12219
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old Status: Bogus
Status: Analyzed
Bug Type: Unknown/Other Function
Operating System: Redhat 7.0
PHP Version: 4.0.5
New Comment:

Zak, IIRC this _is_ a bug, or at least a misfeature. the TODO file says:

* when used in standalone (skell-script like) mode don't urldecode
  arguments passed to php. right now it's not possible to say
/usr/local/bin/php somescript.php dog+cat.txt
  as "dog+cat.txt" will arrive in php as "dog cat.txt". 

BTW, AFAICT the manual page you linked here contains _nothing_ about this particular 
issue (I even read all the notes on the page).


Previous Comments:


[2001-07-17 22:33:26] [EMAIL PROTECTED]

This is not a bug.
Review http://www.php.net/manual/en/language.variables.external.php



[2001-07-17 20:31:03] [EMAIL PROTECTED]

./grab_meta http://altavista.com/sites/search/web?q=task+management&pg=q&kl=XX 3

The following command line argument doesn't work because of the plus sign (+).  This 
also hold true when the second argument is enclosed in qutoes (") || (').
The plus sign (+) causes the second argument to split up into two smaller arguments.  
BUG?





Edit this bug report at http://bugs.php.net/?id=12219&edit=1


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

[PHP-DEV] Bug #12220 Updated: help

2001-07-18 Thread cynic


ID: 12220
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old Status: Bogus
Status: Open
Old Bug Type: Unknown/Other Function
Bug Type: Feature/Change Request
Operating System: windows 98
PHP Version: 4.0.6
New Comment:

Hartmut Holzgraefe:
you have to check for file existance with file_exists() before you
try to probe for its filetype


I think it'd be useful if the is_ functions in the FS category did that for the 
user, so moving to feature request.

I don't know enough about the underlying C stuff, but I don't think is_ checking 
the existence of the file/dir/whatever would be more expensive, would it?

Previous Comments:


[2001-07-18 01:37:06] [EMAIL PROTECTED]

Sorry! This is *not* a support forum.

Subscribe to the PHP General mailing list ([EMAIL PROTECTED]). 

Visit http://php.net/support.php for more information.



[2001-07-18 01:17:47] [EMAIL PROTECTED]

the problem is 
i want to check a directory ... 
09  
php return a error...NO SUCH DIRECTORY OR FILE ON LINE 11 ... 
my goals is to check is there a directory name "username" if there are not a directory 
name "username" i want to create it ..can anybody help me how i can solve this problem 



thanx before that.. 






Edit this bug report at http://bugs.php.net/?id=12220&edit=1


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

[PHP-DEV] call_user_function_ex problem.

2001-07-18 Thread BREGERAS Olivier


Hi

I developpe an extension for PHP. I need to use "preg_match_all" through
"call_user_function_ex" function. 
But the result of this function are returned by "reference". How can I
get the result through "call_user_function_ex" or any other function.

It's a very important step for my extension.
Thank for your help. 

Olivier


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

[PHP-DEV] Help wanted: Operator -> and a class in a PHP extension

2001-07-18 Thread David Eriksson


First, look att this piece of pure PHP code:



a = 42;

$s2 = new S();

$s2->a = 4711;
$s2->x = $s1;

echo $s1->a."\n";

$s3 = $s2->x;
echo $s3->a."\n";

echo $s2->x->a."\n";

?>



All three of the "echo" lines above will output the value 42.

Now consider the same code, but S is class in a PHP extension that has
implemented the handle_property_get function to retrieve properties.

This time, the last echo line will get the value of $s1->a and not $s2->a.

handle_property_get is only called on the $s1 instance and not on the $s2
instance of the object.

I will write a PHP extension that just shows this "feature".

Regards,

-\- David Eriksson -/-

"An expert in a particular computer language is really an expert
in the work-arounds necessary to use this language to perform
useful work." - Richard B. Johnson

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

[PHP-DEV] Bug #12219 Updated: Command Line Arguments not being passed correctly

2001-07-18 Thread zak


ID: 12219
Updated by: zak
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Unknown/Other Function
Operating System: Redhat 7.0
PHP Version: 4.0.5
New Comment:

Ack! What was I doing? :) Thanks for catching this!



Previous Comments:


[2001-07-18 10:21:42] [EMAIL PROTECTED]

Zak, IIRC this _is_ a bug, or at least a misfeature. the TODO file says:

* when used in standalone (skell-script like) mode don't urldecode
  arguments passed to php. right now it's not possible to say
/usr/local/bin/php somescript.php dog+cat.txt
  as "dog+cat.txt" will arrive in php as "dog cat.txt". 

BTW, AFAICT the manual page you linked here contains _nothing_ about this particular 
issue (I even read all the notes on the page).




[2001-07-17 22:33:26] [EMAIL PROTECTED]

This is not a bug.
Review http://www.php.net/manual/en/language.variables.external.php



[2001-07-17 20:31:03] [EMAIL PROTECTED]

./grab_meta http://altavista.com/sites/search/web?q=task+management&pg=q&kl=XX 3

The following command line argument doesn't work because of the plus sign (+).  This 
also hold true when the second argument is enclosed in qutoes (") || (').
The plus sign (+) causes the second argument to split up into two smaller arguments.  
BUG?





Edit this bug report at http://bugs.php.net/?id=12219&edit=1


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

[PHP-DEV] CVS Account Request

2001-07-18 Thread CVS Account Request


Full name: Sam McAdams
Email: [EMAIL PROTECTED]
ID:thyla
Purpose:   Assisting Documentation team with Documentation.
Assisting completing documention for CCVS Module per request of module author.

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

[PHP-DEV] missing symbol w/ current CVS && iconv

2001-07-18 Thread Cynic


Hi there,

last night I built php4-200107171035 on FreeBSD 4.3RELEASE.
The configure line included --with-iconv (iconv-2.0_1 installed
from package), and configure test for libiconv_open failed
(I've never touched libiconv before, but the page linked from 
the PHP manual mentions iconv_open, not libiconv_open):

configure:22870: checking for iconv support
configure:23018: checking for libiconv_open in -liconv
configure:23037: gcc -o conftest -g -O2  -DHARD_SERVER_LIMIT=512 
-DDOCUMENT_LOCATION="/usr/local/apache/www/" 
-DDEFAULT_PATH="/bin:/usr/bin:/usr/local/apache/bin" -DACCEPT_FILTER_NAME="httpready" 
-DUSE_EXPAT  -R/usr/local/lib -L/usr/local/lib conftest.c -liconv  -liconv -lgmp 
-lintl -lbz2 -lz -lcrypt -lm  1>&5
/tmp/ccP0RgHS.o: In function `main':
/usr/local/src/php4-200107171035/configure(.text+0x7): undefined reference to 
`libiconv_open'
configure: failed program was:
#line 23026 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char libiconv_open();
int main() {
libiconv_open()
; return 0; }

the built went on, however, and finished successfully. Apache 
failed to start with:

Syntax error on line 234 of /usr/local/etc/apache/httpd.conf:
Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/
libexec/libphp4.so: Undefined symbol "iconv_module_entry"


1) I don't know if these two things are related, but would think so.
Shouldn't the configure process bail out then?
2) If this a certain version of iconv is required, this should be
stated in the iconv section of manual.

The complete configure line was this:

./configure \
--with-mysql=/usr/local \
--with-apxs=/usr/local/apache/sbin/apxs \
--with-config-file-path=/usr/local/etc/apache \
--with-pear=/usr/local/apache/lib/php \
--with-zlib=/usr \
--with-zip \
--with-bz2 \
--with-gettext \
--with-iconv \
--with-gmp \
--enable-bcmath \
--enable-ctype \
--enable-dbx \
--enable-ftp \
--enable-mbstring \
--enable-shmop \
--enable-sysvsem \
--enable-sysvshm \
--enable-wddx \
--enable-trans-sid \
--enable-track-vars \
--enable-memory-limit \
--enable-inline-optimization

uname -a:
FreeBSD freepuppy.infosite.cz 4.3-RELEASE FreeBSD 4.3-RELEASE #0: 
Sat Apr 21 10:54:49 GMT 2001 [EMAIL PROTECTED]:/usr/src/sy
s/compile/GENERIC  i386



[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


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

[PHP-DEV] install failure w/ current CVS

2001-07-18 Thread Cynic


Me again,

built a snapshot from last night (php4-200107171035) on 
FreeBSD4.3-RELEASE (GENERIC). make install failed:

Making install in Zend
Making install in main
Making install in ext
Making install in zlib
Making install in bcmath
Making install in libbcmath
Making install in src
Making install in bz2
Making install in ctype
Making install in dbx
Making install in ftp
Making install in gettext
Making install in gmp
Making install in iconv
Making install in mbstring
Making install in mysql
Making install in pcre
Making install in pcrelib
Making install in posix
Making install in session
Making install in shmop
Making install in standard
Making install in sysvsem
Making install in sysvshm
Making install in wddx
Making install in xml
Making install in expat
Making install in zip
Making install in sapi
Making install in apache
Making install in TSRM
Making install in regex
Making install in .
/usr/local/src/php4-200107171035/build/shtool mkdir -p "/usr/local/apache/libexec" && 
/usr/local/apache/sbin/apxs -S LIBEXECDIR="/usr/local/apache/libexec" -i -a -n php4 
libs/libphp4.so
installing shared modules into /usr/local/lib/php/20001222
Making install in pear
[activating module `php4' in /usr/local/etc/apache/httpd.conf]
cp libs/libphp4.so /usr/local/apache/libexec/libphp4.so
chmod 755 /usr/local/apache/libexec/libphp4.so
cp /usr/local/etc/apache/httpd.conf /usr/local/etc/apache/httpd.conf.bak
cp /usr/local/etc/apache/httpd.conf.new /usr/local/etc/apache/httpd.conf
rm /usr/local/etc/apache/httpd.conf.new
shtool:mkdir:Error: invalid number of arguments (at least 1 expected)
shtool:mkdir:Hint:  run `/usr/local/src/php4-200107171035/build/shtool mkdir -h'
 or `man shtool' for details
+--+
| The installation process is incomplete. The following resources were |
| not installed:   |
|  |
|   Self-contained Extension Support   |
|   PEAR: PHP Extension and Add-on Repository  |
|  |
| To install these components, become the superuser and execute:   |
|  |
|   # make install-su  |
+--+
*** Error code 5
Stop in /usr/local/src/php4-200107171035/pear.
*** Error code 1
Stop in /usr/local/src/php4-200107171035/pear.
*** Error code 1
Stop in /usr/local/src/php4-200107171035.


[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


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

[PHP-DEV] Send array from php to dll make in vb 6

2001-07-18 Thread Luiz Fernando $Tuca$


I make a dll in Vb6 and it have a funcition that have a variable of type
VARIANT like parameter.
In the program php I call this dll and your method and send a array make in
php.
Occurs a error : Invoke Failed : "Occured a exception", but if I pass a
variable of type integer or string to other method of dll, it's OK.

Thanks

Luiz Fernando




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

[PHP-DEV] iconv related failure

2001-07-18 Thread Cynic


Hi there,

seems like I've just tracked the iconv failure to a dbeu's 
commit.

I'm not sure if ./configure should be looking for libiconv_open
at all: looks like the function is actually called iconv_open.

Now, I know nothing about the buildconf|autoconf|etc stuff,
but it looks like it was triggered this behavior w/ the following
commit:
http://marc.theaimsgroup.com/?l=php-cvs&m=98096027003970&w=2

specifically:

+#if HAVE_LIBICONV
+#define icv_open(a,b) libiconv_open(a,b)
+#define icv_close(a) libiconv_close(a)
+#define icv(a,b,c,d,e) libiconv(a,b,c,d,e)
+#else
+#define icv_open(a,b) iconv_open(a,b)
+#define icv_close(a) iconv_close(a)
+#define icv(a,b,c,d,e) iconv(a,b,c,d,e)
+#endif

can anyone tell me if this is actually right? I cannot test it 
right now, but I'll try to build the snapshot with only the "else"
branch of the if and report tomorrow.



[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


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

[PHP-DEV] Bug #12233: Result of Bzdecompress function

2001-07-18 Thread jose


From: [EMAIL PROTECTED]
Operating system: debian linux 2.3
PHP version:  4.0.4pl1
PHP Bug Type: Bzip2 Related
Bug description:  Result of Bzdecompress function

I don't know if this is really a bug but I don't have found any reference
to this problem in the web (phpbuilder, php.net...).

I execute the example found in the php4 manual reference of bzdecompress
function and the result string shows number-7, not the original and
uncompressed string... why?

Thank you.
-- 
Edit bug report at: http://bugs.php.net/?id=12233&edit=1


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

[PHP-DEV] Bug #12236: session_start() inside a function destroys reference to $HTTP_SESSION_VARS

2001-07-18 Thread b . erdmann


From: [EMAIL PROTECTED]
Operating system: any
PHP version:  4.0.6
PHP Bug Type: Session related
Bug description:  session_start() inside a function destroys reference to 
$HTTP_SESSION_VARS

The following code doesn't work



while this one does


Obviosly after session_start() $HTTP_SESSION_VARS is not
global any more.

(register_globals Off)

-- 
Edit bug report at: http://bugs.php.net/?id=12236&edit=1


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

[PHP-DEV] mail() and windows

2001-07-18 Thread colin mcdonald


hi there,

I've been reading about (and experiencing) the problems with sending 
mail on windows.

Question:  Are there any plans in the near future to clean/rewrite this 
code?  I keep seeing the comment that "mail() badly needs a rewrite on 
windows".

Question(s):  If there are no plans in the near future, how can I help? 
  What needs to be rewritten (besides the obvious handling Bcc header 
and making the header case-insensitive)?  I've been experiencing 
problems when sending attachments that are slightly longer than 2kb. 
What would need to be rewritten to get this working.  Is it a lower 
level than the code in php (ie win sockets)?

thanks and hope I can help!

colin


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

Re: [PHP-DEV] mail() and windows

2001-07-18 Thread Shane Caraveo


I recently submitted a patch to cvs that allows you to use an external
mailer, just as the unix builds use sendmail.  I tested using indigomail,
which has a compatible command line syntax to sendmail.  To use the external
mailer, you specify the sendmail_path option in the ini file (leave blank to
use the internal mailer).
Shane

- Original Message -
From: "colin mcdonald" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 18, 2001 1:33 PM
Subject: [PHP-DEV] mail() and windows


> hi there,
>
> I've been reading about (and experiencing) the problems with sending
> mail on windows.
>
> Question:  Are there any plans in the near future to clean/rewrite this
> code?  I keep seeing the comment that "mail() badly needs a rewrite on
> windows".
>
> Question(s):  If there are no plans in the near future, how can I help?
>   What needs to be rewritten (besides the obvious handling Bcc header
> and making the header case-insensitive)?  I've been experiencing
> problems when sending attachments that are slightly longer than 2kb.
> What would need to be rewritten to get this working.  Is it a lower
> level than the code in php (ie win sockets)?
>
> thanks and hope I can help!
>
> colin
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


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

[PHP-DEV] Bug #12237: date("T") returns null

2001-07-18 Thread JamesHeinrich


From: [EMAIL PROTECTED]
Operating system: Windows NT 4.0 Workstation (PWS)
PHP version:  4.0.6
PHP Bug Type: Date/time related
Bug description:  date("T") returns null

// this should print "EDT" or whatever
// but it prints nothing.
echo date("T");
-- 
Edit bug report at: http://bugs.php.net/?id=12237&edit=1


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

[PHP-DEV] artificial constraints in php_mysql_get_field_name

2001-07-18 Thread Cynic


Hi there,

could anyone tell me what is the reasoning behind the constraints
on the values returned by php_mysql_get_field_name()? I. e.:

...
1737case FIELD_TYPE_SHORT:
1738case FIELD_TYPE_LONG:
1739case FIELD_TYPE_LONGLONG:
1740case FIELD_TYPE_INT24:
1741return "int";
1742break;
1743case FIELD_TYPE_FLOAT:
1744case FIELD_TYPE_DOUBLE:
1745case FIELD_TYPE_DECIMAL:
1746return "real";
1747break;
...

why doesn't it return "short", "longlong", "double" etc. i. e. the
real value?

This has been so since php_mysql.c v1.1 (2yrs, Zeev), so there must be 
a good reason behind this, but I just see it. anyone care to enlighten
me?

TIA


[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


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

[PHP-DEV] Re: artificial constraints in php_mysql_get_field_name

2001-07-18 Thread Zeev Suraski


No good reason for that.  When I wanted to change that, it was already too 
late in the game.
It'd probably make good sense to add a mysql_get_field_name_ex() which 
returns a more accurate value.

Zeev

At 00:37 19/07/2001, Cynic wrote:
>Hi there,
>
>could anyone tell me what is the reasoning behind the constraints
>on the values returned by php_mysql_get_field_name()? I. e.:
>
>...
>1737case FIELD_TYPE_SHORT:
>1738case FIELD_TYPE_LONG:
>1739case FIELD_TYPE_LONGLONG:
>1740case FIELD_TYPE_INT24:
>1741return "int";
>1742break;
>1743case FIELD_TYPE_FLOAT:
>1744case FIELD_TYPE_DOUBLE:
>1745case FIELD_TYPE_DECIMAL:
>1746return "real";
>1747break;
>...
>
>why doesn't it return "short", "longlong", "double" etc. i. e. the
>real value?
>
>This has been so since php_mysql.c v1.1 (2yrs, Zeev), so there must be
>a good reason behind this, but I just see it. anyone care to enlighten
>me?
>
>TIA
>
>
>[EMAIL PROTECTED]
>-
>And the eyes of them both were opened and they saw that their files
>were world readable and writable, so they chmoded 600 their files.
> - Book of Installation chapt 3 sec 7

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


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

Re: [PHP-DEV] Re: artificial constraints in php_mysql_get_field_name

2001-07-18 Thread Cynic


Hi Zeev,

thanks for the prompt reply. I don't think another function
is necessary if this gets changed in 4.1. what do you think?
could you add this to the 4.1 TODO list?

At 23:36 7/18/2001, Zeev Suraski wrote the following:
-- 
>No good reason for that.  When I wanted to change that, it was already too late in 
>the game.
>It'd probably make good sense to add a mysql_get_field_name_ex() which returns a more 
>accurate value.
>
>Zeev
>
>At 00:37 19/07/2001, Cynic wrote:
>>Hi there,
>>
>>could anyone tell me what is the reasoning behind the constraints
>>on the values returned by php_mysql_get_field_name()? I. e.:
>>
>>...
>>1737case FIELD_TYPE_SHORT:
>>1738case FIELD_TYPE_LONG:
>>1739case FIELD_TYPE_LONGLONG:
>>1740case FIELD_TYPE_INT24:
>>1741return "int";
>>1742break;
>>1743case FIELD_TYPE_FLOAT:
>>1744case FIELD_TYPE_DOUBLE:
>>1745case FIELD_TYPE_DECIMAL:
>>1746return "real";
>>1747break;
>>...
>>
>>why doesn't it return "short", "longlong", "double" etc. i. e. the
>>real value?
>>
>>This has been so since php_mysql.c v1.1 (2yrs, Zeev), so there must be
>>a good reason behind this, but I just see it. anyone care to enlighten
>>me?



[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


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

Re: [PHP-DEV] Re: artificial constraints in php_mysql_get_field_name

2001-07-18 Thread Zeev Suraski


I think it'd break a huge amount of scripts, which is why I didn't even do 
it in the 3.0->4.0 move.

Zeev

At 00:55 19/07/2001, Cynic wrote:
>Hi Zeev,
>
>thanks for the prompt reply. I don't think another function
>is necessary if this gets changed in 4.1. what do you think?
>could you add this to the 4.1 TODO list?
>
>At 23:36 7/18/2001, Zeev Suraski wrote the following:
>--
> >No good reason for that.  When I wanted to change that, it was already 
> too late in the game.
> >It'd probably make good sense to add a mysql_get_field_name_ex() which 
> returns a more accurate value.
> >
> >Zeev
> >
> >At 00:37 19/07/2001, Cynic wrote:
> >>Hi there,
> >>
> >>could anyone tell me what is the reasoning behind the constraints
> >>on the values returned by php_mysql_get_field_name()? I. e.:
> >>
> >>...
> >>1737case FIELD_TYPE_SHORT:
> >>1738case FIELD_TYPE_LONG:
> >>1739case FIELD_TYPE_LONGLONG:
> >>1740case FIELD_TYPE_INT24:
> >>1741return "int";
> >>1742break;
> >>1743case FIELD_TYPE_FLOAT:
> >>1744case FIELD_TYPE_DOUBLE:
> >>1745case FIELD_TYPE_DECIMAL:
> >>1746return "real";
> >>1747break;
> >>...
> >>
> >>why doesn't it return "short", "longlong", "double" etc. i. e. the
> >>real value?
> >>
> >>This has been so since php_mysql.c v1.1 (2yrs, Zeev), so there must be
> >>a good reason behind this, but I just see it. anyone care to enlighten
> >>me?
>
>
>
>[EMAIL PROTECTED]
>-
>And the eyes of them both were opened and they saw that their files
>were world readable and writable, so they chmoded 600 their files.
> - Book of Installation chapt 3 sec 7

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


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

Re: [PHP-DEV] Re: artificial constraints in php_mysql_get_field_name

2001-07-18 Thread Cynic


Well, were talking about a pretty specialized function, probably
used only in programs like phpMyAdmin etc. On the other hand,
software like phpMyAdmin needs real info, so... Looks like the 
constraint makes the function pretty useless: you'll get far more
useful info from "show columns from table" today. Anyway, you 
could prolly get an idea how much welcome (or not) this change 
would be if you asked in php-general@. I could do it if you're
interested.


At 23:56 7/18/2001, Zeev Suraski wrote the following:
-- 
>I think it'd break a huge amount of scripts, which is why I didn't even do it in the 
>3.0->4.0 move.
>
>Zeev
>
>At 00:55 19/07/2001, Cynic wrote:
>>Hi Zeev,
>>
>>thanks for the prompt reply. I don't think another function
>>is necessary if this gets changed in 4.1. what do you think?
>>could you add this to the 4.1 TODO list?
>>
>>At 23:36 7/18/2001, Zeev Suraski wrote the following:
>>--
>>>No good reason for that.  When I wanted to change that, it was already too late in 
>the game.
>>>It'd probably make good sense to add a mysql_get_field_name_ex() which returns a 
>more accurate value.
>>>
>>>Zeev
>>>
>>>At 00:37 19/07/2001, Cynic wrote:
Hi there,

could anyone tell me what is the reasoning behind the constraints
on the values returned by php_mysql_get_field_name()? I. e.:

...
1737case FIELD_TYPE_SHORT:
1738case FIELD_TYPE_LONG:
1739case FIELD_TYPE_LONGLONG:
1740case FIELD_TYPE_INT24:
1741return "int";
1742break;
1743case FIELD_TYPE_FLOAT:
1744case FIELD_TYPE_DOUBLE:
1745case FIELD_TYPE_DECIMAL:
1746return "real";
1747break;
...

why doesn't it return "short", "longlong", "double" etc. i. e. the
real value?

This has been so since php_mysql.c v1.1 (2yrs, Zeev), so there must be
a good reason behind this, but I just see it. anyone care to enlighten
me?
>>
>>
>>
>>[EMAIL PROTECTED]
>>-
>>And the eyes of them both were opened and they saw that their files
>>were world readable and writable, so they chmoded 600 their files.
>>- Book of Installation chapt 3 sec 7
>
>--
>Zeev Suraski <[EMAIL PROTECTED]>
>CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
>
>
>-- 
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]
--end of quote-- 


[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


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

Re: [PHP-DEV] Re: artificial constraints in php_mysql_get_field_name

2001-07-18 Thread Zeev Suraski


I think it would have a much broader effect.  I used this function when I 
wrote a generic database interface years ago, so my guess is that quite a 
few people have used it since then as well.


At 01:25 19/07/2001, Cynic wrote:
>Well, were talking about a pretty specialized function, probably
>used only in programs like phpMyAdmin etc. On the other hand,
>software like phpMyAdmin needs real info, so... Looks like the
>constraint makes the function pretty useless: you'll get far more
>useful info from "show columns from table" today. Anyway, you
>could prolly get an idea how much welcome (or not) this change
>would be if you asked in php-general@. I could do it if you're
>interested.
>
>
>At 23:56 7/18/2001, Zeev Suraski wrote the following:
>--
> >I think it'd break a huge amount of scripts, which is why I didn't even 
> do it in the 3.0->4.0 move.
> >
> >Zeev
> >
> >At 00:55 19/07/2001, Cynic wrote:
> >>Hi Zeev,
> >>
> >>thanks for the prompt reply. I don't think another function
> >>is necessary if this gets changed in 4.1. what do you think?
> >>could you add this to the 4.1 TODO list?
> >>
> >>At 23:36 7/18/2001, Zeev Suraski wrote the following:
> >>--
> >>>No good reason for that.  When I wanted to change that, it was already 
> too late in the game.
> >>>It'd probably make good sense to add a mysql_get_field_name_ex() which 
> returns a more accurate value.
> >>>
> >>>Zeev
> >>>
> >>>At 00:37 19/07/2001, Cynic wrote:
> Hi there,
> 
> could anyone tell me what is the reasoning behind the constraints
> on the values returned by php_mysql_get_field_name()? I. e.:
> 
> ...
> 1737case FIELD_TYPE_SHORT:
> 1738case FIELD_TYPE_LONG:
> 1739case FIELD_TYPE_LONGLONG:
> 1740case FIELD_TYPE_INT24:
> 1741return "int";
> 1742break;
> 1743case FIELD_TYPE_FLOAT:
> 1744case FIELD_TYPE_DOUBLE:
> 1745case FIELD_TYPE_DECIMAL:
> 1746return "real";
> 1747break;
> ...
> 
> why doesn't it return "short", "longlong", "double" etc. i. e. the
> real value?
> 
> This has been so since php_mysql.c v1.1 (2yrs, Zeev), so there must be
> a good reason behind this, but I just see it. anyone care to enlighten
> me?
> >>
> >>
> >>
> >>[EMAIL PROTECTED]
> >>-
> >>And the eyes of them both were opened and they saw that their files
> >>were world readable and writable, so they chmoded 600 their files.
> >>- Book of Installation chapt 3 sec 7
> >
> >--
> >Zeev Suraski <[EMAIL PROTECTED]>
> >CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
>--end of quote--
>
>
>[EMAIL PROTECTED]
>-
>And the eyes of them both were opened and they saw that their files
>were world readable and writable, so they chmoded 600 their files.
> - Book of Installation chapt 3 sec 7

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


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

[PHP-DEV] Bug #12238: Double printing with echo and print

2001-07-18 Thread mahk


From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0.6
PHP Bug Type: Strings related
Bug description:  Double printing with echo and print

The following html/php script gives a duplicate of the last line.



System name:

 


returns the following html output.



System name:
kelsey
kelsey 


I've used the standard compile:
 './configure' '--with-mysql' '--with-apxs'

System: Linux kelsey 2.2.19-6.2.1 #1 Mon Apr 9 21:59:11 EDT 2001 i486
unknown



-- 
Edit bug report at: http://bugs.php.net/?id=12238&edit=1


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

[PHP-DEV] Bug #12239: crashes on Mail()

2001-07-18 Thread TheUnforgiven


From: [EMAIL PROTECTED]
Operating system: Debian Linux
PHP version:  4.0.6
PHP Bug Type: Reproducible crash
Bug description:  crashes on Mail()

it crashes when i run mail()
i have mysql.so and gd in my models list and i am running apache postfix
(changing to sendmail now to see if it fixes this) and php 4.0.6
-- 
Edit bug report at: http://bugs.php.net/?id=12239&edit=1


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

[PHP-DEV] Bug #12240: microtime.x

2001-07-18 Thread jiv


From: [EMAIL PROTECTED]
Operating system: Slackware 7.0
PHP version:  4.0.6
PHP Bug Type: Any
Bug description:  microtime.x

The problem:
_
microtime.c: In function `php_if_getrusage':
microtime.c:99: storage size of `usg' isn't known
microtime.c:102: `RUSAGE_SELF' undeclared (first use in this function)
microtime.c:102: (Each undeclared identifier is reported only once
microtime.c:102: for each function it appears in.)
microtime.c:108: `RUSAGE_CHILDREN' undeclared (first use in this
function)
make[3]: *** [microtime.lo] Error 1
make[3]: Leaving directory `/usr/local/src/php-4.0.6/ext/standard'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/src/php-4.0.6/ext/standard'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/php-4.0.6/ext'
make: *** [all-recursive] Error 1
___

A part from the ./configure output:
___
[root@jiv][01:39am] /usr/local/src/php-4.0.6 # ./configure 
--with-mysql=/usr/local/ --with-apxs=/var/lib/apache/sbin/apxs | grep
time
checking for sys/time.h... yes
checking for utime.h... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for asctime_r... yes
checking for ctime_r... yes
checking for gettimeofday... yes
checking for gmtime_r... yes
checking for localtime_r... yes
checking for setitimer... yes
checking for strftime... yes
checking for utime... yes
checking whether utime accepts a null argument... yes
checking for declared timezone... yes
checking for type of reentrant time-related functions... POSIX
configure: warning: You will need bison 1.28 if you want to regenerate the
Zend parser (found 1.27).

-- 
Edit bug report at: http://bugs.php.net/?id=12240&edit=1


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

[PHP-DEV] Bug #12238 Updated: Double printing with echo and print

2001-07-18 Thread cynic


ID: 12238
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Strings related
Operating System: 
PHP Version: 4.0.6
New Comment:

RTFM (Reading The Fine Manual) never killed anyone. You should try that. :)

"System() is just like the C version of the function in that it executes the given 
command and outputs the result. [...] Returns the last line of the command output on 
success, and false on failure."

Previous Comments:


[2001-07-18 18:39:04] [EMAIL PROTECTED]

The following html/php script gives a duplicate of the last line.



System name:

 


returns the following html output.



System name:
kelsey
kelsey 


I've used the standard compile:
 './configure' '--with-mysql' '--with-apxs'

System: Linux kelsey 2.2.19-6.2.1 #1 Mon Apr 9 21:59:11 EDT 2001 i486 unknown








Edit this bug report at http://bugs.php.net/?id=12238&edit=1


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

[PHP-DEV] Bug #12239 Updated: crashes on Mail()

2001-07-18 Thread TheUnforgiven


ID: 12239
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: Debian Linux
PHP Version: 4.0.6
New Comment:

i am getting these errors..[Wed Jul 18 18:48:52 2001] [notice] child pid 1251 exit 
signal Segmentation fault (11)
[Wed Jul 18 18:49:52 2001] [notice] child pid 1253 exit signal Segmentation fault (11)
[Wed Jul 18 18:50:17 2001] [notice] child pid 1255 exit signal Segmentation fault (11)
[Wed Jul 18 18:50:31 2001] [notice] child pid 1260 exit signal Segmentation fault (11)

Previous Comments:


[2001-07-18 18:40:46] [EMAIL PROTECTED]

it crashes when i run mail()
i have mysql.so and gd in my models list and i am running apache postfix (changing to 
sendmail now to see if it fixes this) and php 4.0.6





Edit this bug report at http://bugs.php.net/?id=12239&edit=1


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

[PHP-DEV] Bug #12239 Updated: crashes on Mail()

2001-07-18 Thread TheUnforgiven


ID: 12239
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: Debian Linux
PHP Version: 4.0.6
New Comment:

changing to exim/sendmail did not fix the problem i am qmail next.

Previous Comments:


[2001-07-18 18:49:36] [EMAIL PROTECTED]

i am getting these errors..[Wed Jul 18 18:48:52 2001] [notice] child pid 1251 exit 
signal Segmentation fault (11)
[Wed Jul 18 18:49:52 2001] [notice] child pid 1253 exit signal Segmentation fault (11)
[Wed Jul 18 18:50:17 2001] [notice] child pid 1255 exit signal Segmentation fault (11)
[Wed Jul 18 18:50:31 2001] [notice] child pid 1260 exit signal Segmentation fault (11)



[2001-07-18 18:40:46] [EMAIL PROTECTED]

it crashes when i run mail()
i have mysql.so and gd in my models list and i am running apache postfix (changing to 
sendmail now to see if it fixes this) and php 4.0.6





Edit this bug report at http://bugs.php.net/?id=12239&edit=1


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

[PHP-DEV] Bug #12241: imap.so: undefined symbol: mxdriver in Unknown on line 0

2001-07-18 Thread jmmele


From: [EMAIL PROTECTED]
Operating system: Linux core 2.4.0-test12
PHP version:  4.0.6
PHP Bug Type: IMAP related
Bug description:  imap.so: undefined symbol: mxdriver in Unknown on line 0

all the modules I compile are working but imap.so

PHP Warning:  Unable to load dynamic library
'/usr/local/lib/php/extensions/no-debug-non-zts-20001222/imap.so' -
/usr/local/lib/php/extensions/no-debug-non-zts-20001222/imap.so: undefined
symbol: mxdriver in Unknown on line 0

system info : Apache/1.3.20 (Unix) Debian/GNU PHP/4.0.6
: Linux 2.4.0-test12 i686

php config  : ./configure --with-recode=shared --enable-mbstring=shared
--with-apxs --with-mysql=shared --with-iconv=shared --with-sablot=shared
--with-zlib --with-dom=shared --with-gd=shared --with-imap=shared 
--enable-ftp --enable-track-vars --with-regex=system

(I alse tried with --with-imap or
--with-imap=/usr/src/imap-2001.BETA.SNAP-0107112053/)

c-client config : imap-2001.BETA.SNAP-0107112053 (also tested imap-2000c)
compiled with make lnx and also tried with make lnp 

I did the http://www.php.net/manual/en/ref.imap.php (cp c-client/c-client.a
to /usr/local/lib/libc-client.a and the others) (did the ldconfig too :)
-- 
Edit bug report at: http://bugs.php.net/?id=12241&edit=1


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

[PHP-DEV] Bug #12241 Updated: imap.so: undefined symbol: mxdriver in Unknown on line 0

2001-07-18 Thread jmmele


ID: 12241
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IMAP related
Operating System: Linux core 2.4.0-test12
PHP Version: 4.0.6
New Comment:

all the modules I compile are working but imap.so

PHP Warning:  Unable to load dynamic library
'/usr/local/lib/php/extensions/no-debug-non-zts-20001222/imap.so' -
/usr/local/lib/php/extensions/no-debug-non-zts-20001222/imap.so: undefined symbol:
mxdriver in Unknown on line 0

system info : Apache/1.3.20 (Unix) Debian/GNU PHP/4.0.6
: Linux 2.4.0-test12 i686

php config  : ./configure --with-recode=shared --enable-mbstring=shared --with-apxs
--with-mysql=shared --with-iconv=shared --with-sablot=shared --with-zlib 
--with-dom=shared
--with-gd=shared --with-imap=shared  --enable-ftp --enable-track-vars
--with-regex=system

(I alse tried with --with-imap or 
--with-imap=/usr/src/imap-2001.BETA.SNAP-0107112053/)

c-client config : imap-2001.BETA.SNAP-0107112053 (also tested imap-2000c) compiled 
with
make lnx and also tried with make lnp 

I did the http://www.php.net/manual/en/ref.imap.php
(cp c-client/c-client.a to /usr/local

best regards


Previous Comments:


[2001-07-18 20:47:02] [EMAIL PROTECTED]

all the modules I compile are working but imap.so

PHP Warning:  Unable to load dynamic library 
'/usr/local/lib/php/extensions/no-debug-non-zts-20001222/imap.so' - 
/usr/local/lib/php/extensions/no-debug-non-zts-20001222/imap.so: undefined symbol: 
mxdriver in Unknown on line 0

system info : Apache/1.3.20 (Unix) Debian/GNU PHP/4.0.6
: Linux 2.4.0-test12 i686

php config  : ./configure --with-recode=shared --enable-mbstring=shared --with-apxs 
--with-mysql=shared --with-iconv=shared --with-sablot=shared --with-zlib 
--with-dom=shared --with-gd=shared --with-imap=shared  --enable-ftp 
--enable-track-vars --with-regex=system

(I alse tried with --with-imap or 
--with-imap=/usr/src/imap-2001.BETA.SNAP-0107112053/)

c-client config : imap-2001.BETA.SNAP-0107112053 (also tested imap-2000c) compiled 
with make lnx and also tried with make lnp 

I did the http://www.php.net/manual/en/ref.imap.php (cp c-client/c-client.a to 
/usr/local/lib/libc-client.a and the others) (did the ldconfig too :)





Edit this bug report at http://bugs.php.net/?id=12241&edit=1


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

[PHP-DEV] Bug #12243: Large numbers not behaving as doubles

2001-07-18 Thread matysekj


From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.1.1-STABLE
PHP version:  4.0.6
PHP Bug Type: Variables related
Bug description:  Large numbers not behaving as doubles

$testnumber = 50;
echo $testnumber;

The result is 2147483647.  The variable is of type integer, even though it
was initialized with a double value.  I first noticed this with PHP 4.05
and it still occurs with 4.05.  I do not believe it behaved this way back
when I had 4.03PL1 installed.

My configure line is:
 './configure' '--with-gd=no' '--with-mysql=/usr/local'
'--with-config-file-path=/usr/home/priraise/phpini' '--enable-debug=no'
'--enable-track-vars=yes' '--enable-ftp=yes'
'--enable-force-cgi-redirect=yes' '--with-openssl' '--enable-trans-sid'
'--enable-xml'
-- 
Edit bug report at: http://bugs.php.net/?id=12243&edit=1


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

[PHP-DEV] Bug #12243 Updated: Large numbers not behaving as doubles

2001-07-18 Thread matysekj


ID: 12243
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Variables related
Operating System: FreeBSD 4.1.1-STABLE
PHP Version: 4.0.6
New Comment:

I've verified that this behavior is relatively new. It does not happen in 4.03PL1, but 
does in 4.05 and 4.06.

Previous Comments:


[2001-07-18 23:13:02] [EMAIL PROTECTED]

$testnumber = 50;
echo $testnumber;

The result is 2147483647.  The variable is of type integer, even though it was 
initialized with a double value.  I first noticed this with PHP 4.05 and it still 
occurs with 4.05.  I do not believe it behaved this way back when I had 4.03PL1 
installed.

My configure line is:
 './configure' '--with-gd=no' '--with-mysql=/usr/local' 
'--with-config-file-path=/usr/home/priraise/phpini' '--enable-debug=no' 
'--enable-track-vars=yes' '--enable-ftp=yes' '--enable-force-cgi-redirect=yes' 
'--with-openssl' '--enable-trans-sid' '--enable-xml'





Edit this bug report at http://bugs.php.net/?id=12243&edit=1


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

[PHP-DEV] Bug #12243 Updated: Large numbers not behaving as doubles

2001-07-18 Thread cynic


ID: 12243
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Variables related
Operating System: FreeBSD 4.1.1-STABLE
PHP Version: 4.0.6
New Comment:

1) longlong != double
2) the scale is HW-dependant, i. e. you need a 64-bit HW to get native support for 
64-bit numbers. that's how it's always been in PHP. there was no change WIRT this.

5,000,000,000 is clearly more than your HW can take, so it's clipped to the closest 
possible value.

Previous Comments:


[2001-07-18 23:34:07] [EMAIL PROTECTED]

I've verified that this behavior is relatively new. It does not happen in 4.03PL1, but 
does in 4.05 and 4.06.



[2001-07-18 23:13:02] [EMAIL PROTECTED]

$testnumber = 50;
echo $testnumber;

The result is 2147483647.  The variable is of type integer, even though it was 
initialized with a double value.  I first noticed this with PHP 4.05 and it still 
occurs with 4.05.  I do not believe it behaved this way back when I had 4.03PL1 
installed.

My configure line is:
 './configure' '--with-gd=no' '--with-mysql=/usr/local' 
'--with-config-file-path=/usr/home/priraise/phpini' '--enable-debug=no' 
'--enable-track-vars=yes' '--enable-ftp=yes' '--enable-force-cgi-redirect=yes' 
'--with-openssl' '--enable-trans-sid' '--enable-xml'





Edit this bug report at http://bugs.php.net/?id=12243&edit=1


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

[PHP-DEV] Bug #12243 Updated: Large numbers not behaving as doubles

2001-07-18 Thread matysekj


ID: 12243
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Variables related
Operating System: FreeBSD 4.1.1-STABLE
PHP Version: 4.0.6
New Comment:

If this is strictly hardware related, then how come when I run the exact same 2 lines 
on another box running linux, I get the correct 5 billion number displayed?  The linux 
box is using an AMD 450 Mhz K6, and the FreeBSD box is using a Pentium 3-600.  I am 
not able to back up to 4.03PL1 on the FreeBSD box, but I am quite sure that this 
problem did not occur back when it was loaded.

Previous Comments:


[2001-07-18 23:52:41] [EMAIL PROTECTED]

1) longlong != double
2) the scale is HW-dependant, i. e. you need a 64-bit HW to get native support for 
64-bit numbers. that's how it's always been in PHP. there was no change WIRT this.

5,000,000,000 is clearly more than your HW can take, so it's clipped to the closest 
possible value.



[2001-07-18 23:34:07] [EMAIL PROTECTED]

I've verified that this behavior is relatively new. It does not happen in 4.03PL1, but 
does in 4.05 and 4.06.



[2001-07-18 23:13:02] [EMAIL PROTECTED]

$testnumber = 50;
echo $testnumber;

The result is 2147483647.  The variable is of type integer, even though it was 
initialized with a double value.  I first noticed this with PHP 4.05 and it still 
occurs with 4.05.  I do not believe it behaved this way back when I had 4.03PL1 
installed.

My configure line is:
 './configure' '--with-gd=no' '--with-mysql=/usr/local' 
'--with-config-file-path=/usr/home/priraise/phpini' '--enable-debug=no' 
'--enable-track-vars=yes' '--enable-ftp=yes' '--enable-force-cgi-redirect=yes' 
'--with-openssl' '--enable-trans-sid' '--enable-xml'





Edit this bug report at http://bugs.php.net/?id=12243&edit=1


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

[PHP-DEV] Reworking DOMXML

2001-07-18 Thread Joey Smith


There needs to be a decision made in order to complete
the work on domxml, as it currently stands.

I think it is a good idea to keep both the "procedural"
and "object oriented" interfaces in the code.

The way the module is currently written, it will take
the least amount of work to just require the user to
pass a valid XML object to the procedural calls.

I would like to be consistent across the board on where
we expect this object to be passed, and I see to ways
to do it, each with their pro's and con's, so I thought
I would ask for input before I went too much farther down
the road I'm currently following.

Style #1:
The dom_document object is always the FIRST parameter to
the function, if called as a procedure and NOT as a method
on a dom_document object.

Pro:
This seems cleaner, as the user will ALWAYS know where
the object belongs.

Con:
This might confuse the oop users, as the documentation does
not currently clearly distinguish the two interfaces.


Style #2:
The dom_document object is always LAST.

Pros:
Simplest to implement with code as it currently stands.
Seems to be the way many other functions have been written.

Cons:
User will have to remember all arguments of all functions and
pass SOMEthing, even if that means passing NULLs or something.

Position of dom_document becomes a moving target.


Does anyone have any input? I'm currently leaning towards the
2nd style...



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

[PHP-DEV] Bug #12243 Updated: Large numbers not behaving as doubles

2001-07-18 Thread cynic


ID: 12243
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old Status: Bogus
Status: Feedback
Bug Type: Variables related
Operating System: FreeBSD 4.1.1-STABLE
PHP Version: 4.0.6
New Comment:

are you sure you don't initialize the variable with 5 Million on the Linux box?

Previous Comments:


[2001-07-19 00:03:32] [EMAIL PROTECTED]

If this is strictly hardware related, then how come when I run the exact same 2 lines 
on another box running linux, I get the correct 5 billion number displayed?  The linux 
box is using an AMD 450 Mhz K6, and the FreeBSD box is using a Pentium 3-600.  I am 
not able to back up to 4.03PL1 on the FreeBSD box, but I am quite sure that this 
problem did not occur back when it was loaded.



[2001-07-18 23:52:41] [EMAIL PROTECTED]

1) longlong != double
2) the scale is HW-dependant, i. e. you need a 64-bit HW to get native support for 
64-bit numbers. that's how it's always been in PHP. there was no change WIRT this.

5,000,000,000 is clearly more than your HW can take, so it's clipped to the closest 
possible value.



[2001-07-18 23:34:07] [EMAIL PROTECTED]

I've verified that this behavior is relatively new. It does not happen in 4.03PL1, but 
does in 4.05 and 4.06.



[2001-07-18 23:13:02] [EMAIL PROTECTED]

$testnumber = 50;
echo $testnumber;

The result is 2147483647.  The variable is of type integer, even though it was 
initialized with a double value.  I first noticed this with PHP 4.05 and it still 
occurs with 4.05.  I do not believe it behaved this way back when I had 4.03PL1 
installed.

My configure line is:
 './configure' '--with-gd=no' '--with-mysql=/usr/local' 
'--with-config-file-path=/usr/home/priraise/phpini' '--enable-debug=no' 
'--enable-track-vars=yes' '--enable-ftp=yes' '--enable-force-cgi-redirect=yes' 
'--with-openssl' '--enable-trans-sid' '--enable-xml'





Edit this bug report at http://bugs.php.net/?id=12243&edit=1


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

Re: [PHP-DEV] Bug #12243 Updated: Large numbers not behaving asdoubles

2001-07-18 Thread Sascha Schumann


On 19 Jul 2001 [EMAIL PROTECTED] wrote:

> ID: 12243
> Updated by: cynic
> Reported By: [EMAIL PROTECTED]
> Old Status: Bogus
> Status: Feedback
> Bug Type: Variables related
> Operating System: FreeBSD 4.1.1-STABLE
> PHP Version: 4.0.6
> New Comment:
>
> are you sure you don't initialize the variable with 5 Million on the Linux box?

The behaviour (automatic promotion to double) is intended to
work.  Stas has committed some patches in this area during
the last days, he can probably say whether the feature is
broken in 4.0.6.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


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

[PHP-DEV] Bug #12243 Updated: Large numbers not behaving as doubles

2001-07-18 Thread matysekj


ID: 12243
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Variables related
Operating System: FreeBSD 4.1.1-STABLE
PHP Version: 4.0.6
New Comment:

Absolutely. I've written just one test script with just those 2 lines in it.  I copied 
this same file to 3 servers now - the 2 that I've already mentioned plus another 
FreeBSD server (identical in hardware and OS config to the other) running 4.03PL1.  
The only one of these servers that prints out 2147483647 is the FreeBSD server running 
4.06 (also did it with 4.05).  The other 2 servers print out 50.  I also 
remember another location in my site that was affected by this bug, and I can 
GUARANTEE that it did not occur on the affected server until I updated it to 4.05. 
Please change the status of this bug report back to open.

Previous Comments:


[2001-07-19 00:15:34] [EMAIL PROTECTED]

are you sure you don't initialize the variable with 5 Million on the Linux box?



[2001-07-19 00:03:32] [EMAIL PROTECTED]

If this is strictly hardware related, then how come when I run the exact same 2 lines 
on another box running linux, I get the correct 5 billion number displayed?  The linux 
box is using an AMD 450 Mhz K6, and the FreeBSD box is using a Pentium 3-600.  I am 
not able to back up to 4.03PL1 on the FreeBSD box, but I am quite sure that this 
problem did not occur back when it was loaded.



[2001-07-18 23:52:41] [EMAIL PROTECTED]

1) longlong != double
2) the scale is HW-dependant, i. e. you need a 64-bit HW to get native support for 
64-bit numbers. that's how it's always been in PHP. there was no change WIRT this.

5,000,000,000 is clearly more than your HW can take, so it's clipped to the closest 
possible value.



[2001-07-18 23:34:07] [EMAIL PROTECTED]

I've verified that this behavior is relatively new. It does not happen in 4.03PL1, but 
does in 4.05 and 4.06.



[2001-07-18 23:13:02] [EMAIL PROTECTED]

$testnumber = 50;
echo $testnumber;

The result is 2147483647.  The variable is of type integer, even though it was 
initialized with a double value.  I first noticed this with PHP 4.05 and it still 
occurs with 4.05.  I do not believe it behaved this way back when I had 4.03PL1 
installed.

My configure line is:
 './configure' '--with-gd=no' '--with-mysql=/usr/local' 
'--with-config-file-path=/usr/home/priraise/phpini' '--enable-debug=no' 
'--enable-track-vars=yes' '--enable-ftp=yes' '--enable-force-cgi-redirect=yes' 
'--with-openssl' '--enable-trans-sid' '--enable-xml'





Edit this bug report at http://bugs.php.net/?id=12243&edit=1


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

[PHP-DEV] Bug #11716 Updated: Segmentation fault(coredump) in Apache(DSO-enabled) startup

2001-07-18 Thread cmlee


ID: 11716
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Apache related
Operating System: AIX 4.3.3
PHP Version: 4.0.6
New Comment:

I tried to make php4-200107181935 snapshot.
But now I have another problem which is an installation failure.

$ ./configure --enable-debug \
--with-apxs=/home/apache/bin/apxs \
--with-mysql=no
...
$ make
...
$ su
$ make install
...
Making install in .
make[1]: Entering directory `/home/cmlee/php4-200107181935'
/home/cmlee/php4-200107181935/build/shtool mkdir -p "/home/apache/libexec" 
&& /home/apache/bin/apxs -S LIBEXECDIR="/home/apache/libexec" -i -a -n php4 
libs/libphp4.so
[activating module `php4' in /home/apache/conf/httpd.conf]
cp libs/libphp4.so /home/apache/libexec/libphp4.so
cp: libs/libphp4.so: No such file or directory
apxs:Break: Command failed with rc=1
make[1]: *** [install-sapi] Error 1
make[1]: Leaving directory `/home/cmlee/php4-200107181935'
make: *** [install-recursive] Error 1





Previous Comments:


[2001-07-12 04:04:46] [EMAIL PROTECTED]

Please try the latest CVS snapshot from http://snaps.php.net/ as #4630 was reported to 
be fixed now.




[2001-06-26 21:52:10] [EMAIL PROTECTED]

IBM AIX 4.3.3
Apache 1.3.20
PHP 4.0.6 Release
GNU gcc 2.95.2 for AIX

$ export CFLAGS="-g"
$ ./configure --enable-debug \
--with-apxs=/home/apache/bin/apxs \
--with-mysql=no
...
$ make
...

$ make install-sapi

$ su

# cd /home/apache/bin
# ./httpd -X
Segmentation fault (core dumped)

# dbx httpd core
Type 'help' for help.
reading symbolic information ...
[using memory image in core]

Segmentation fault in php_if_apache_lookup_uri at 0xd14e5658 ($t1)
0xd14e5658 (php_if_apache_lookup_uri+0x554) 800clwz   r0,0x0(r12)
(dbx) where
php_if_apache_lookup_uri() at 0xd14e5658
php_create_dir(??, ??) at 0xd14e6b28
ap_single_module_configure(0x2001b0a8, 0x2001b0d0, 0x200612a0) at 0x10018f8c
load_module(0x2ff22620, 0x0, 0x2001c978, 0x2001c988) at 0x1006a974
invoke_cmd(0x20006d60, 0x2ff22620, 0x0, 0x2ff20600) at 0x10016738
ap_handle_command(0x2ff22620, 0x2001bc60, 0x2ff205d0) at 0x100175bc
ap_srm_command_loop(0x2ff22620, 0x2001bc60) at 0x100176ac
ap_process_resource_config(0x2001b0d0, 0x2001c7a8, 0x2001b0a8, 0x2001f0e8) at 
0x10018140
ap_read_config(0x2001b0a8, 0x2001f0e8, 0x20002f1c) at 0x10018e10
http_main.main(0x2, 0x2ff22804) at 0x10006bd8
(dbx) quit

# gdb httpd
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-ibm-aix4.3.2.0"...
(gdb) run -X
Starting program: /home/apache/bin/httpd -X
"/usr/lib/libpthreads.a": not in executable format: File format not recognized.
(gdb) c
Continuing.
"/usr/lpp/xlC/lib/libC.a": not in executable format: File format not recognized.
(gdb) c
Continuing.
"/usr/lib/libbind.a": not in executable format: File format not recognized.
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xd14e5658 in ?? () from (unknown load module)
(gdb) bt
#0  0xd14e5658 in ?? () from (unknown load module)
#1  
(gdb) quit


I think this is very similar to bug #4630.
What should I do?





Edit this bug report at http://bugs.php.net/?id=11716&edit=1


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

[PHP-DEV] Bug #12243 Updated: Large numbers not behaving as doubles

2001-07-18 Thread cynic


ID: 12243
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Variables related
Operating System: FreeBSD 4.1.1-STABLE
PHP Version: 4.0.6
New Comment:

at your service

Previous Comments:


[2001-07-19 00:23:14] [EMAIL PROTECTED]

Absolutely. I've written just one test script with just those 2 lines in it.  I copied 
this same file to 3 servers now - the 2 that I've already mentioned plus another 
FreeBSD server (identical in hardware and OS config to the other) running 4.03PL1.  
The only one of these servers that prints out 2147483647 is the FreeBSD server running 
4.06 (also did it with 4.05).  The other 2 servers print out 50.  I also 
remember another location in my site that was affected by this bug, and I can 
GUARANTEE that it did not occur on the affected server until I updated it to 4.05. 
Please change the status of this bug report back to open.



[2001-07-19 00:15:34] [EMAIL PROTECTED]

are you sure you don't initialize the variable with 5 Million on the Linux box?



[2001-07-19 00:03:32] [EMAIL PROTECTED]

If this is strictly hardware related, then how come when I run the exact same 2 lines 
on another box running linux, I get the correct 5 billion number displayed?  The linux 
box is using an AMD 450 Mhz K6, and the FreeBSD box is using a Pentium 3-600.  I am 
not able to back up to 4.03PL1 on the FreeBSD box, but I am quite sure that this 
problem did not occur back when it was loaded.



[2001-07-18 23:52:41] [EMAIL PROTECTED]

1) longlong != double
2) the scale is HW-dependant, i. e. you need a 64-bit HW to get native support for 
64-bit numbers. that's how it's always been in PHP. there was no change WIRT this.

5,000,000,000 is clearly more than your HW can take, so it's clipped to the closest 
possible value.



[2001-07-18 23:34:07] [EMAIL PROTECTED]

I've verified that this behavior is relatively new. It does not happen in 4.03PL1, but 
does in 4.05 and 4.06.



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=12243


Edit this bug report at http://bugs.php.net/?id=12243&edit=1


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

59 matches

Mail list logo