[PHP-DEV] Re: [PEAR-DEV] PECL: is it ok to commit to php4 source tree?

[Yasuo Ohgaki]

Tomas V.V.Cox wrote:

> Yasuo Ohgaki wrote:
> 
>>Anyway, I'll just use "session_pgsql" for now. Module name differ
>>from actual module name, but names like "mod_pgsql" may conflict
>>other other modules. e.g. pgsql sub module for auth module, etc.
>>
> 
> imho "session_pgsql" is just perfect :)
> 
> 
> Tomas V.V.Cox
> 

Thank you for let me know.
I'll commit it as "session_pgsql" after make clear about config.m4.:)

-- 
Yasuo Ohgaki


-- 
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: [PEAR-DEV] Re: PECL: is it ok to commit to php4 source tree?

[Yasuo Ohgaki]

Yasuo Ohgaki wrote:

> Tomas V.V.Cox wrote:

*SNIP*

>> I can't tell you much about PECL, but yes for PEAR. Open this url:
>> http://pear.php.net/?devme
>>
>> Then open this:
>> http://pear.php.net and go to the package browser. There the people will
>> be able to download the packages or directly remote install with the
>> "pear" script.
>>
>>
>> Tomas V.V.Cox
>>
> 
> Thanks, I didn't know login is required :)
> 

Now I understand what you mean. There is no PECL there.
So I have to ask users to check out repository to test PECL modules?
I hope there is a better way :)

-- 
Yasuo Ohgaki


-- 
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: [PEAR-DEV] PECL: is it ok to commit to php4 source tree?

[Tomas V.V.Cox]

Yasuo Ohgaki wrote:
> 
> Anyway, I'll just use "session_pgsql" for now. Module name differ
> from actual module name, but names like "mod_pgsql" may conflict
> other other modules. e.g. pgsql sub module for auth module, etc.

imho "session_pgsql" is just perfect :)


Tomas V.V.Cox

-- 
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: [PEAR-DEV] PECL: is it ok to commit to php4 source tree?

[Yasuo Ohgaki]

Tomas V.V.Cox wrote:

> Yasuo Ohgaki wrote:
> 
>>Hi all,
>>
>>I understand /pear has separate repository for pear development.
>>What is the current rule for commiting /pear/PECL/some_module
>>to /php4/pear/PECL/some_module?
>>
>>
> 
> pear/PECL/some_module, no more rules :-) php4/pear has nothing to do
> with PECL.
> 
> 
> Tomas V.V.Cox
> 
> 

Hmm I prefer to locate sub(child) modules under parent module
directory. Since it is easier to find sub module for a module.

Anyway, I'll just use "session_pgsql" for now. Module name differ
from actual module name, but names like "mod_pgsql" may conflict
other other modules. e.g. pgsql sub module for auth module, etc.

If you have comment or better idea, let me know now :)
I'll wait a little more committing it.

-- 
Yasuo Ohgaki


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.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] Re: [PEAR-DEV] Re: PECL: is it ok to commit to php4 source tree?

[Yasuo Ohgaki]

Tomas V.V.Cox wrote:

> Yasuo Ohgaki wrote:
> 
>>Yasuo Ohgaki wrote:
>>
>>
>>>Hi all,
>>>
>>>I understand /pear has separate repository for pear development.
>>>What is the current rule for commiting /pear/PECL/some_module
>>>to /php4/pear/PECL/some_module?
>>>
>>>Thank you.
>>>
>>>
>>Oops, PECL supposed to have different place for downloading.
>>There user can download modules? Cannot find link for download
>>in pear.php.net.
>>
>>
> 
> I can't tell you much about PECL, but yes for PEAR. Open this url:
> http://pear.php.net/?devme
> 
> Then open this:
> http://pear.php.net and go to the package browser. There the people will
> be able to download the packages or directly remote install with the
> "pear" script.
> 
> 
> Tomas V.V.Cox
> 

Thanks, I didn't know login is required :)

-- 
Yasuo Ohgaki


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.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] Apology

[Sebastian Bergmann]

Yasuo Ohgaki wrote:
> I didn't know Sascha took off from this project. I saw his update for
> bug reports/cvs commits recently...

  Well, he took a time off, AFAIK.

-- 
  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 
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: PECL: is it ok to commit to php4 source tree?

[Tomas V.V.Cox]

Yasuo Ohgaki wrote:
> 
> Yasuo Ohgaki wrote:
> 
> > Hi all,
> >
> > I understand /pear has separate repository for pear development.
> > What is the current rule for commiting /pear/PECL/some_module
> > to /php4/pear/PECL/some_module?
> >
> > Thank you.
> >
> 
> Oops, PECL supposed to have different place for downloading.
> There user can download modules? Cannot find link for download
> in pear.php.net.
> 

I can't tell you much about PECL, but yes for PEAR. Open this url:
http://pear.php.net/?devme

Then open this:
http://pear.php.net and go to the package browser. There the people will
be able to download the packages or directly remote install with the
"pear" script.


Tomas V.V.Cox

-- 
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: [PEAR-DEV] PECL: is it ok to commit to php4 source tree?

[Tomas V.V.Cox]

Yasuo Ohgaki wrote:
> 
> Hi all,
> 
> I understand /pear has separate repository for pear development.
> What is the current rule for commiting /pear/PECL/some_module
> to /php4/pear/PECL/some_module?
> 

pear/PECL/some_module, no more rules :-) php4/pear has nothing to do
with PECL.


Tomas V.V.Cox

-- 
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: PECL: is it ok to commit to php4 source tree?

[Yasuo Ohgaki]

Yasuo Ohgaki wrote:

> Hi all,
> 
> I understand /pear has separate repository for pear development.
> What is the current rule for commiting /pear/PECL/some_module
> to /php4/pear/PECL/some_module?
> 
> Thank you.
> 

Oops, PECL supposed to have different place for downloading.
There user can download modules? Cannot find link for download
in pear.php.net.

-- 
Yasuo Ohgaki


-- 
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] PECL: is it ok to commit to php4 source tree?

[Yasuo Ohgaki]

Hi all,

I understand /pear has separate repository for pear development.
What is the current rule for commiting /pear/PECL/some_module
to /php4/pear/PECL/some_module?

Thank you.

-- 
Yasuo Ohgaki


-- 
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] Moving session handler to PECL

[Yasuo Ohgaki]

Hi all,

php4 source should be changed for moving session handler
to PECL.

1) php_session.h must be accesible as standard header.
2) session.c must be changed so that it loads save
handler module.
(Real solution requires zend source change, I hope/
 expect someone who has access to zend source to change
 module loader to understand initilization order smartly ;)

I'll make a changes needed to make save handlers to
compile as standalone module and runs/compiles
without problem.

If you have comment or objects expected changes, please
let me know ASAP.

-- 
Yasuo Ohgaki


-- 
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] Where to locate child module?

[Yasuo Ohgaki]

Hi all,

I change my mind ;)

I'll place session save handler to PECL.
I hope/expect someone to write smart ini parser/module
loader that understands module dependency to prevent
runtime undefined symbol errors. Hopefully soon.

There are sevral issues still.
Here is one. (Other issues will be mailed separately)

Since session save handlers are child modules, is
there any defined location for child modules?

Is it /pear/PECL/session/mod_pgsql or /pear/PECL/mod_pgsql?
Or anything else?

I don't closely follow PEAR development. I've read
pear-web, FAQ, but there aren't much info there.

Thanks for your input.

-- 
Yasuo Ohgaki


-- 
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 #14634 Updated: php causes iplanet to crash

[ian]

ID: 14634
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: Solaris 8
PHP Version: 4.1.0
New Comment:

i finally found it, i was missing the following line in magnus.conf:

Init fn="php4_init" LateInit="yes"


now both 4.0.6 and 4.1.0 at least give me phpinfo() output, i'll have to verify that 
everything else is ok, but this bug can be closed.

thx.

Previous Comments:


[2001-12-20 19:29:50] [EMAIL PROTECTED]

dewalt:ian[72] ...servers/https-iwww> sudo gdb ns-httpd 8428
GNU gdb 5.0
Copyright 2000 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 "sparc-sun-solaris2.8"...ns-httpd: No such file or 
directory.

/var/iplanet/servers/https-iwww/8428: No such file or directory.
Attaching to process 8428
Error reading attached process's symbol file.
ns-httpd: No such file or directory.
Reading symbols from /var/iplanet/servers/bin/https/lib/libsmartheap_smp.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libsmartheap_smp.so
Reading symbols from /var/iplanet/servers/bin/https/lib/liblibdbm.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/liblibdbm.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libns-httpd40.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libns-httpd40.so
Reading symbols from /var/iplanet/servers/bin/https/lib/liblibsi18n.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/liblibsi18n.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libgetprop.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libgetprop.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libnsprwrap.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libnsprwrap.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libldap50.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libldap50.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libldappr50.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libldappr50.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libxerces-c.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libxerces-c.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libnsres30.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libnsres30.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libnsuni30.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libnsuni30.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libnscnv30.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libnscnv30.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libnscol30.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libnscol30.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libnsbrk30.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libnsbrk30.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libnsfmt30.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libnsfmt30.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libplc4.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libplc4.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libplds4.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libplds4.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libnspr4.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libnspr4.so
Reading symbols from /usr/lib/libsocket.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libsocket.so.1
Reading symbols from /usr/lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libnsl.so.1
Reading symbols from /usr/lib/libdl.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libdl.so.1
Reading symbols from /usr/lib/libposix4.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libp

[PHP-DEV] Bug #14635 Updated: last week in october Monday displays twice!

[jimw]

ID: 14635
Updated by: jimw
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Date/time related
Operating System: Windows 2000 Professional
PHP Version: 4.0.6
New Comment:

october 28 was 25 hours long. daylight savings time.

Previous Comments:


[2001-12-20 20:36:49] [EMAIL PROTECTED]

When iterating from a start mktime to another using the date() function the First Day 
of the Last Week in October messes up.

The same problem appears when using Apache or IIS.

Just cut and paste below to see what I mean.

".full_calendar_month ($today,$PHP_SELF, 
null);
$today = getdate();
print "Notice No Problem".full_calendar_month ($today,$PHP_SELF, null);


/*
DISPLAY A FULL MONTH CALENDAR
*/

function full_calendar_month ($today,$url, $arrevent) {
GLOBAL $cbouser;
$user = null;
if ($cbouser) { $user = "&cbouser=$cbouser";}//display the userid
if (!$today) {$today = getdate();}
//NEED TO CONVERT $today to midnight!
$today = getdate(mktime(0,0,0,$today["mon"],$today["mday"],$today["year"]));
$mktoday = mktime (0,0,0,$today["mon"],1,$today["year"]);
$mkday = 86400; //1 day in mktime 24 hr * 60 min * 60 sec.
$fday = date("w",$mktoday); //first day of the month w - day of the week, 
numeric, i.e. "0" (Sunday) to "6" (Saturday) 
$mth_num = date("n",$mktoday);  //the month number ie. Nov 11
$cell_bgcolor = "#C0C0C0";
/*
DETERMINE THE FIRST DAY OF THE MONTH
*/
if ($fday == 0) {   //SUNDAY NEED TO GET TO MONDAY
$mkstart = $mktoday - $mkday * 6;
} elseif ($fday != 1) {//need to make the last part of last week.
$mkstart = $mktoday - $mkday * ($fday-1);
} else {//THE MONTH STARTS WITH MONDAY
$mkstart = $mktoday;
}

//FIND THE LAST DAY OF THE MONTH
$mkend = $mktoday + $mkday * (date("t",$mktoday)-1);//t - number of days 
in the given month; i.e. "28" to "31" 

if (date("w",$mkend) != 0) {$mkend = $mkend + $mkday * (7-date("w",$mkend));}
#echo date("w D M j Y ",$mkend)."";

//BEGIN THE OUTPUT
/* FOR DROP BOX
".month_dropbox($mth_num)."  
".year_dropbox(date("Y",$mktoday))."
 
*/

 $table = "

".date("F Y",$mktoday)."
 
>\">

MondayTuesdayWednesdayThursdayFridaySat/Sun";

//SHADE THE DAYS THAT ARE NOT IN THE MONTH
if ($today[0] == $mkstart) { 
$bgcolor = "bgcolor=\"#00\" bordercolor=\"#FF\"";
} elseif ($mth_num != date("n",$mkstart)) { 
$bgcolor = "bgcolor=\"$cell_bgcolor\""; 
} else {
$bgcolor = "";
}
$event_date = "".date("F 
j",$mkstart)."";
//THE FIRST DAY
 $table .= "$event_date";

for ($i=$mkstart+$mkday;$i<$mkend;$i+=$mkday) {
$event_date = 
"event_date=".date("Y-m-d",$i)."&rdocalendar_view=30$user";
//background color
if ($today[0] == $i) { 
$bgcolor = "bgcolor=\"#00\" bordercolor=\"#FF\" 
border=1";
} elseif ($mth_num != date("n",$i)) { 
$bgcolor = "bgcolor=\"$cell_bgcolor\" border=0"; 
} else {
$bgcolor = "";
}
//date display
if (date("j",$i) == 1) { $the_day = date("F j",$i); } else { $the_day 
= date("j",$i);}

switch (date("w",$i)) { // day of the week, numeric, i.e. "0" (Sunday) 
to "6" (Saturday) 
case 1: #monday
$table .= "$the_day";
break;
case 6: #saturday - sunday
$table .= "

$the_day
";
$i+=$mkday;
//background color
if ($today[0] == $i) { 
$bgcolor = "bgcolor=\"#00\" 
bordercolor=\"#FF\" border=1";
} elseif ($mth_num != date("n",$i)) { 
$bgcolor = "bgcolor=\"$cell_bgcolor\" 
border=0"; 
} else {
$bgcolor = "";
}
$event_date = 
"event_date=".date("Y-m-d",$i)."

[PHP-DEV] Bug #14635: last week in october Monday displays twice!

[jberall]

From: [EMAIL PROTECTED]
Operating system: Windows 2000 Professional
PHP version:  4.0.6
PHP Bug Type: Date/time related
Bug description:  last week in october Monday displays twice!

When iterating from a start mktime to another using the date() function the
First Day of the Last Week in October messes up.

The same problem appears when using Apache or IIS.

Just cut and paste below to see what I mean.

".full_calendar_month
($today,$PHP_SELF, null);
$today = getdate();
print "Notice No Problem".full_calendar_month ($today,$PHP_SELF,
null);


/*
DISPLAY A FULL MONTH CALENDAR
*/

function full_calendar_month ($today,$url, $arrevent) {
GLOBAL $cbouser;
$user = null;
if ($cbouser) { $user = "&cbouser=$cbouser";}//display the userid
if (!$today) {$today = getdate();}
//NEED TO CONVERT $today to midnight!
$today =
getdate(mktime(0,0,0,$today["mon"],$today["mday"],$today["year"]));
$mktoday = mktime (0,0,0,$today["mon"],1,$today["year"]);
$mkday = 86400; //1 day in mktime 24 hr * 60 min * 60 sec.
$fday = date("w",$mktoday); //first day of the month w - day of the week,
numeric, i.e. "0" (Sunday) to "6" (Saturday) 
$mth_num = date("n",$mktoday);  //the month number ie. Nov 11
$cell_bgcolor = "#C0C0C0";
/*
DETERMINE THE FIRST DAY OF THE MONTH
*/
if ($fday == 0) {   //SUNDAY NEED TO GET TO MONDAY
$mkstart = $mktoday - $mkday * 6;
} elseif ($fday != 1) {//need to make the last part of last week.
$mkstart = $mktoday - $mkday * ($fday-1);
} else {//THE MONTH STARTS WITH MONDAY
$mkstart = $mktoday;
}

//FIND THE LAST DAY OF THE MONTH
$mkend = $mktoday + $mkday * (date("t",$mktoday)-1);//t - number of days
in the given month; i.e. "28" to "31" 

if (date("w",$mkend) != 0) {$mkend = $mkend + $mkday *
(7-date("w",$mkend));}
#echo date("w D M j Y ",$mkend)."";

//BEGIN THE OUTPUT
/* FOR DROP BOX
".month_dropbox($mth_num)."  
".year_dropbox(date("Y",$mktoday))."
 
*/

 $table = "

".date("F Y",$mktoday)."
 

>\">

MondayTuesdayWednesdayThursdayFridaySat/Sun";

//SHADE THE DAYS THAT ARE NOT IN THE MONTH
if ($today[0] == $mkstart) { 
$bgcolor = "bgcolor=\"#00\" bordercolor=\"#FF\"";
} elseif ($mth_num != date("n",$mkstart)) { 
$bgcolor = "bgcolor=\"$cell_bgcolor\""; 
} else {
$bgcolor = "";
}
$event_date = "".date("F
j",$mkstart)."";
//THE FIRST DAY
 $table .= "$event_date";

for ($i=$mkstart+$mkday;$i<$mkend;$i+=$mkday) {
$event_date =
"event_date=".date("Y-m-d",$i)."&rdocalendar_view=30$user";
//background color
if ($today[0] == $i) { 
$bgcolor = "bgcolor=\"#00\" bordercolor=\"#FF\" 
border=1";
} elseif ($mth_num != date("n",$i)) { 
$bgcolor = "bgcolor=\"$cell_bgcolor\" border=0"; 
} else {
$bgcolor = "";
}
//date display
if (date("j",$i) == 1) { $the_day = date("F j",$i); } else { $the_day =
date("j",$i);}

switch (date("w",$i)) { // day of the week, numeric, i.e. "0" (Sunday) 
to
"6" (Saturday) 
case 1: #monday
$table .= "$the_day";
break;
case 6: #saturday - sunday
$table .= "

$the_day
";
$i+=$mkday;
//background color
if ($today[0] == $i) { 
$bgcolor = "bgcolor=\"#00\" 
bordercolor=\"#FF\" border=1";
} elseif ($mth_num != date("n",$i)) { 
$bgcolor = "bgcolor=\"$cell_bgcolor\" 
border=0"; 
} else {
$bgcolor = "";
}
$event_date =
"event_date=".date("Y-m-d",$i)."&rdocalendar_view=30$user";
//date display
if (date("j",$i) == 1) { $the_day = date("F j",$i); } 
else { $the_day =
date

[PHP-DEV] Bug #14623 Updated: get_meta_tags only looks in begin of file

[elixer]

ID: 14623
Updated by: elixer
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Strings related
Operating System: linux
PHP Version: 4.0.6
Assigned To: elixer
New Comment:

Can you please provide me with a small example of a file that get_meta_tags is failing 
on? The only time I am seeing this fail is if the text "http://bugs.php.net/?id=14623&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 #14634 Updated: php causes iplanet to crash

[ian]

ID: 14634
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Reproducible crash
Operating System: Solaris 8
PHP Version: 4.1.0
New Comment:

dewalt:ian[72] ...servers/https-iwww> sudo gdb ns-httpd 8428
GNU gdb 5.0
Copyright 2000 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 "sparc-sun-solaris2.8"...ns-httpd: No such file or 
directory.

/var/iplanet/servers/https-iwww/8428: No such file or directory.
Attaching to process 8428
Error reading attached process's symbol file.
ns-httpd: No such file or directory.
Reading symbols from /var/iplanet/servers/bin/https/lib/libsmartheap_smp.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libsmartheap_smp.so
Reading symbols from /var/iplanet/servers/bin/https/lib/liblibdbm.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/liblibdbm.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libns-httpd40.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libns-httpd40.so
Reading symbols from /var/iplanet/servers/bin/https/lib/liblibsi18n.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/liblibsi18n.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libgetprop.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libgetprop.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libnsprwrap.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libnsprwrap.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libldap50.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libldap50.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libldappr50.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libldappr50.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libxerces-c.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libxerces-c.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libnsres30.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libnsres30.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libnsuni30.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libnsuni30.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libnscnv30.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libnscnv30.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libnscol30.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libnscol30.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libnsbrk30.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libnsbrk30.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libnsfmt30.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libnsfmt30.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libplc4.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libplc4.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libplds4.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libplds4.so
Reading symbols from /var/iplanet/servers/bin/https/lib/libnspr4.so...
(no debugging symbols found)...done.
Loaded symbols for /var/iplanet/servers/bin/https/lib/libnspr4.so
Reading symbols from /usr/lib/libsocket.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libsocket.so.1
Reading symbols from /usr/lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libnsl.so.1
Reading symbols from /usr/lib/libdl.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libdl.so.1
Reading symbols from /usr/lib/libposix4.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libposix4.so.1
Reading symbols from /usr/lib/libkstat.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libkstat.so.1
---Type  to continue, or q  to quit---
Reading symbols from /usr/lib/libC.so.5...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libC.so.5
Reading symbols from /usr/lib/libm.so.1...(no debugging symbols found)...

[PHP-DEV] Re: Light musings

[Yasuo Ohgaki]

Andrei Zmievski wrote:

> http://www.advogato.org/article/395.html
> 
> -Andrei
> 
> "Computers are useless. They can only give you answers."
>--Pablo Picasso
> 


I like following rules and I think this is true.


22. Backward compatiblity is your worst enemy.
23. Backward compatiblity is your users' best friend.

All developers have problem with them ;)

-- 
Yasuo Ohgaki


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

[Yasuo Ohgaki]

Sebastian Bergmann wrote:

> 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 didn't know Sascha took off from this project. I saw his update for
bug reports/cvs commits recently...

> 
>   I really hope that you return,
> Sebastian
> 

I wish so, too.
I hope all of you will be back soon...

-- 
Yasuo Ohgaki


-- 
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 #14628 Updated: Session functions block on lock

[yohgaki]

ID: 14628
Updated by: yohgaki
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Session related
Operating System: Linux
PHP Version: 4.0.6
New Comment:

Could you try 4.1.0 and/or 4.2.0-dev see if it's fixed?
http://www.php.net/downloads.php (4.1.0)
http://snaps.php.net/ (4.2.0-dev)

Please report the result and update PHP version.

--
Yasuo Ohgaki


Previous Comments:


[2001-12-20 12:40:04] [EMAIL PROTECTED]

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 this bug report at http://bugs.php.net/?id=14628&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 #14634 Updated: php causes iplanet to crash

[yohgaki]

ID: 14634
Updated by: yohgaki
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Reproducible crash
Operating System: Solaris 8
PHP Version: 4.1.0
New Comment:

Could you send backtrace?
Refer to following URL for getting backtrace with gdb.

http://bugs.php.net/bugs-generating-backtrace.php

--
Yasuo Ohgaki

Previous Comments:


[2001-12-20 18:20:14] [EMAIL PROTECTED]

using either 4.1.0 or 4.0.6 as NSAPI on iplanet 6.0sp1 on solaris 8, iplanet crashes 
whenever accessing any php scripts. iplanet logs:

catastrophe (  360): Server crash detected (signal SIGSEGV)
info (  360): Crash occurred in NSAPI SAF php4_execute
info (  360): Crash occurred in function _pthread_mutex_lock from module 
/usr/lib/libthread.so.1



this behavior occurs whenever any php script is run, including things as simple as the 
following (this is the o.php script that's called in the truss below):




i compiled php using:

env \
CC=gcc \
CXX=g++ \
CFLAGS="-O2 -I/local/include -I/local/include/openssl -I/local/include/ucd-snmp 
-I/local/include/c-client" \
CPPFLAGS="-I/local/include" \
LDFLAGS="-L/local/lib -R/local/lib -L/local/ssl/lib -R/local/ssl/lib 
-L/local/lib/c-client -R/local/lib/c-client" \
TMPDIR="/tmp" \
./configure  \
--prefix=/local \
--sysconfdir=/etc \
--localstatedir=/var \
--with-config-file-path=/etc/php/ \
--with-nsapi=/var/iplanet/servers \
--with-openssl=/local \
--with-db3=/local/BerkeleyDB-3.2 \
--with-imap-ssl=/local \
--with-imap=/local \
--with-ldap=/local \
--with-zlib=/usr \
--enable-sysvshm \
--enable-sysvsem \
--enable-track-vars \
--enable-force-cgi-redirect \
--with-gettext \
--with-regex=system


a truss of the web server shows the following:

accept(8, 0xFE2D1B58, 0xFE2D1AEC, 1)= 21
lwp_sema_post(0xFE291E30)   = 0
lwp_sema_wait(0xFE291E30)   = 0
lwp_mutex_wakeup(0xFEB955B0)= 0
lwp_mutex_lock(0xFEB955B0)  = 0
getsockname(21, 0x0049E4D0, 0xFB6D1B8C, 1)  = 0
read(21, " G E T   / o . p h p   H".., 8191)= 273
poll(0xFCC07A48, 0, 10) = 0
stat64("/export/http/i001", 0xFB6D13C0) = 0
stat64("/export/http/i001/o.php", 0xFB6D1450)   = 0
Incurred fault #6, FLTBOUNDS  %pc = 0xFEB6B73C
  siginfo: SIGSEGV SEGV_MAPERR addr=0x0005
Received signal #11, SIGSEGV [caught]
  siginfo: SIGSEGV SEGV_MAPERR addr=0x0005
sigprocmask(SIG_SETMASK, 0xFEB8EFE8, 0x) = 0
sigaction(SIGSEGV, 0xFB6D0E08, 0xFB6D0F08)  = 0
time()  = 1008890166
getpid()= 456 [359]
write(9, " [ 2 0 / D e c / 2 0 0 1".., 83)  = 83
time()  = 1008890166
getpid()= 456 [359]
write(9, " [ 2 0 / D e c / 2 0 0 1".., 78)  = 78
time()  = 1008890166
getpid()= 456 [359]
write(9, " [ 2 0 / D e c / 2 0 0 1".., 120) = 120
sigprocmask(SIG_SETMASK, 0xFEB9ADB8, 0xFB6D0E10) = 0
sigprocmask(SIG_SETMASK, 0xFB6D0E10, 0x) = 0
sigprocmask(SIG_SETMASK, 0xFEB9ADB8, 0xFB6D0EB0) = 0
sigprocmask(SIG_SETMASK, 0xFB6D0EB0, 0x) = 0
sigprocmask(SIG_SETMASK, 0xFEB9ADB8, 0x) = 0
sigprocmask(SIG_SETMASK, 0xFEB9ADB8, 0xFB6D10C0) = 0
lwp_kill(13, SIGSEGV)   = 0
sigprocmask(SIG_SETMASK, 0xFB6D10C0, 0x) = 0
setcontext(0xFB6D1010)
Received signal #11, SIGSEGV [caught]
  siginfo: SIGSEGV pid=456 uid=2147483042 code=-1
sigprocmask(SIG_SETMASK, 0xFEB8EFE8, 0x) = 0
sigaction(SIGSEGV, 0xFB6D1150, 0x)  = 0
sigprocmask(SIG_SETMASK, 0xFEB9ADB8, 0x) = 0
setcontext(0xFB6D1010)
Incurred fault #6, FLTBOUNDS  %pc = 0xFEB6B73C
  siginfo: SIGSEGV SEGV_MAPERR addr=0x0005
Received signal #11, SIGSEGV [default]
  siginfo: SIGSEGV SEGV_MAPERR addr=0x0005
*** process killed ***






Edit this bug report at http://bugs.php.net/?id=14634&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] New Object Oriented Programming (OOP) mailing list for PHP programmers

[Manuel Lemos]

Hello,

Despite I already created this list a long time ago, only now I am
announcing it as a general purpose forum for discussing matters related
with Object Oriented Programming done in PHP.

Everybody is invited and to join all you need to do is to send a message
to [EMAIL PROTECTED] or go to the page
http://groups.yahoo.com/group/php-objects/ . If you send the message to
the above address I think you do not need to have a Yahoo account if you
don't have one and don't want to subscribe to it.

Regards,
Manuel Lemos

-- 
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 #14634: php causes iplanet to crash

[ian]

From: [EMAIL PROTECTED]
Operating system: Solaris 8
PHP version:  4.1.0
PHP Bug Type: Reproducible crash
Bug description:  php causes iplanet to crash

using either 4.1.0 or 4.0.6 as NSAPI on iplanet 6.0sp1 on solaris 8,
iplanet crashes whenever accessing any php scripts. iplanet logs:

catastrophe (  360): Server crash detected (signal SIGSEGV)
info (  360): Crash occurred in NSAPI SAF php4_execute
info (  360): Crash occurred in function _pthread_mutex_lock from module
/usr/lib/libthread.so.1



this behavior occurs whenever any php script is run, including things as
simple as the following (this is the o.php script that's called in the
truss below):




i compiled php using:

env \
CC=gcc \
CXX=g++ \
CFLAGS="-O2 -I/local/include -I/local/include/openssl
-I/local/include/ucd-snmp -I/local/include/c-client" \
CPPFLAGS="-I/local/include" \
LDFLAGS="-L/local/lib -R/local/lib -L/local/ssl/lib -R/local/ssl/lib
-L/local/lib/c-client -R/local/lib/c-client" \
TMPDIR="/tmp" \
./configure  \
--prefix=/local \
--sysconfdir=/etc \
--localstatedir=/var \
--with-config-file-path=/etc/php/ \
--with-nsapi=/var/iplanet/servers \
--with-openssl=/local \
--with-db3=/local/BerkeleyDB-3.2 \
--with-imap-ssl=/local \
--with-imap=/local \
--with-ldap=/local \
--with-zlib=/usr \
--enable-sysvshm \
--enable-sysvsem \
--enable-track-vars \
--enable-force-cgi-redirect \
--with-gettext \
--with-regex=system


a truss of the web server shows the following:

accept(8, 0xFE2D1B58, 0xFE2D1AEC, 1)= 21
lwp_sema_post(0xFE291E30)   = 0
lwp_sema_wait(0xFE291E30)   = 0
lwp_mutex_wakeup(0xFEB955B0)= 0
lwp_mutex_lock(0xFEB955B0)  = 0
getsockname(21, 0x0049E4D0, 0xFB6D1B8C, 1)  = 0
read(21, " G E T   / o . p h p   H".., 8191)= 273
poll(0xFCC07A48, 0, 10) = 0
stat64("/export/http/i001", 0xFB6D13C0) = 0
stat64("/export/http/i001/o.php", 0xFB6D1450)   = 0
Incurred fault #6, FLTBOUNDS  %pc = 0xFEB6B73C
  siginfo: SIGSEGV SEGV_MAPERR addr=0x0005
Received signal #11, SIGSEGV [caught]
  siginfo: SIGSEGV SEGV_MAPERR addr=0x0005
sigprocmask(SIG_SETMASK, 0xFEB8EFE8, 0x) = 0
sigaction(SIGSEGV, 0xFB6D0E08, 0xFB6D0F08)  = 0
time()  = 1008890166
getpid()= 456 [359]
write(9, " [ 2 0 / D e c / 2 0 0 1".., 83)  = 83
time()  = 1008890166
getpid()= 456 [359]
write(9, " [ 2 0 / D e c / 2 0 0 1".., 78)  = 78
time()  = 1008890166
getpid()= 456 [359]
write(9, " [ 2 0 / D e c / 2 0 0 1".., 120) = 120
sigprocmask(SIG_SETMASK, 0xFEB9ADB8, 0xFB6D0E10) = 0
sigprocmask(SIG_SETMASK, 0xFB6D0E10, 0x) = 0
sigprocmask(SIG_SETMASK, 0xFEB9ADB8, 0xFB6D0EB0) = 0
sigprocmask(SIG_SETMASK, 0xFB6D0EB0, 0x) = 0
sigprocmask(SIG_SETMASK, 0xFEB9ADB8, 0x) = 0
sigprocmask(SIG_SETMASK, 0xFEB9ADB8, 0xFB6D10C0) = 0
lwp_kill(13, SIGSEGV)   = 0
sigprocmask(SIG_SETMASK, 0xFB6D10C0, 0x) = 0
setcontext(0xFB6D1010)
Received signal #11, SIGSEGV [caught]
  siginfo: SIGSEGV pid=456 uid=2147483042 code=-1
sigprocmask(SIG_SETMASK, 0xFEB8EFE8, 0x) = 0
sigaction(SIGSEGV, 0xFB6D1150, 0x)  = 0
sigprocmask(SIG_SETMASK, 0xFEB9ADB8, 0x) = 0
setcontext(0xFB6D1010)
Incurred fault #6, FLTBOUNDS  %pc = 0xFEB6B73C
  siginfo: SIGSEGV SEGV_MAPERR addr=0x0005
Received signal #11, SIGSEGV [default]
  siginfo: SIGSEGV SEGV_MAPERR addr=0x0005
*** process killed ***

-- 
Edit bug report at: http://bugs.php.net/?id=14634&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 #14538 Updated: dirname fix broke behaviourthat it had since PHP 3

[Zeev Suraski]

At 03:43 16/12/2001, Manuel Lemos wrote:
>So, there why keep giving more reasons to not upgrade?

Because sometimes it's necessary.  The way dirname() behaved was buggy and 
unintended - it simply did not do what it was supposed to do.  Perhaps 
taking it to the extreme - it's kind of like pow(2,2) returning 4.01 
instead of 4.  If such a bug existed in pow() and we fixed it, we wouldn't 
have added an ini switch to turn it on/off.

register_globals is completely different.  register_globals is a concept 
which turned out to be very problematic, but people who bought into it 
should be allowed to go on using it.  We also have to be a bit realistic 
every now and then, and realize that the vast majority of PHP code today, 
and we're talking dozens of millions of lines of code, relies on 
register_globals being on.  That's not true for dirname().  It doesn't mean 
that BC breaks that only affect a small number of people should be taken 
lightly - but obviously, this plays a significant role.

>Admit it, you were not aware and not even documented the change that
>Andi made to the behaviour of a function that worked like that for 3
>years.



>Sure but they way it seems to me is that reporting the problem did not
>make any difference. So why bother reporting?

It's your decision.  Don't expect the dev-team to treat anything you put in 
the bugs database as the 11th commandment.  The dirname() example is 
relatively unique, because the new behavior is not a problem, but a fixed 
behavior which causes incompatibility.

>I am afraid that a lot of people simply do not bother to report
>problems, even when it affects their businesses, because they just get
>this kind of response and they certainly can use the time they spend
>making a useful report in things that can really result in something
>that the need.

Don't worry so much.  You're the first person to bring up this point in 5 
years :)

Zeev


-- 
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 #14602 Updated: Compilation of PHP 4.1.0 with libiodbc 3.0.5 support failed

[dickmeiss]

ID: 14602
Updated by: dickmeiss
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: ODBC related
Operating System: FreeBSD 4.3, RedHat 7.1
PHP Version: 4.1.0
Assigned To: ahill
New Comment:

This is probably the same as bug id #14616.

-- Adam

Previous Comments:


[2001-12-20 15:26:41] [EMAIL PROTECTED]

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








[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 
multip

Re: [PHP-DEV] ]RFC] Do we want/allow "undefined symbol" error or not?

[Yasuo Ohgaki]

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

[mfischer]

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=14633&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] Re: ]RFC] Do we want/allow *RUNTIME* "undefined symbol" error or not?

[Yasuo Ohgaki]

I forgot to mention explicitly ;)

Do we want/allow *RUNTIME* "undefined symbol" error?

-- 
Yasuo Ohgaki


-- 
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] ]RFC] Do we want/allow "undefined symbol" error ornot?

[derick]

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

[Yasuo Ohgaki]

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

[david]

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=14633&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: desclub

[Mazen A. Melibari]

Translating the documentation
&
Maintaining www.php.net

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

[Andrei Zmievski]

http://www.advogato.org/article/395.html

-Andrei

"Computers are useless. They can only give you answers."
   --Pablo Picasso

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

[Andrei Zmievski]

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

[Markus Fischer]

On Thu, Dec 20, 2001 at 02:26:26PM -0500, Jon Parise wrote : 
> 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.

Anton,

can you test the patch I mailed to you (and -dev) and see if
its ok?

- Markus

-- 
Please always Cc to me when replying to me on the lists.

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

[Sebastian Bergmann]

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

[michaelh]

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

Sorry to gripe. =)


Thanks,
Michael Howell

Previous Comments:


[2001-12-20 15:32:16] [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 in version 3.x



[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=14632&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 #14632 Updated: missing -lz symbol in Makefile

[michaelh]

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=14632&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 #14602 Updated: Compilation of PHP 4.1.0 with libiodbc 3.0.5 support failed

[ahill]

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 th

Re: [PHP-DEV] Apology

[Jani Taskinen]

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

[sniper]

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=14632&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 #14399 Updated: eregi_replace does not handle upercase scandinavian characters

[jonas]

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=14399&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 #14632: missing -lz symbol in Makefile

[michaelh]

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=14632&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] Apology

[Andrei Zmievski]

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

[azibutotal]

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 = "\n";
$appendIt.=
"$ZeFiles->file_title".$zePopUpScript."Viewfile_id.");\">Delete<
/a>\n";
}
   }
   else {// it is a mp3  file : no need for PopUp...A link should do...
   $zePopUpScript = "link to Mp3 file ".$ZeFiles->file_name;
   $appendIt.=
"$ZeFiles->file_title".$zePopUpScript."Viewfile_id."&id=".$Ze_mydir."\">Delet
e\n";

   }
  }
  echo "\n-Your
Files-\n$appendIt\n\n";

   }else{
  echo "\nNo Files so far\n";
   }

}


// 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=14631&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] PHP 4.0.6 IMAP BUG

[Jon Parise]

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 
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()

[jimw]

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=14629&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 #14630: integers wrapping around rather than being promoted into floats on overflow

[markmont]

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:



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=14630&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 #14629: request link_target()

[cmv]

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=14629&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] Question: Should exit() print out the integer exit-status?

[Vlad Krupin]

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

[sander]

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:\php>php -v
4.0.6

E:\php>php -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=14278&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 #14276 Updated: users behind proxy get gibrish on page when compression is used

[sander]

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  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=14276&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 #14628: Session functions block on lock

[chris]

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=14628&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] Re: Bug #14624: is_link() fail with error if the link is not found

[Yasuo Ohgaki]

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

[lobbin]

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=14627&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 #14627: Nested output buffering fails when nested buffers are inside methods

[chirsch]

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=14627&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] Question: Should exit() print out the integer exit-status?

[Lars Torben Wilson]

[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) {
> > >  

[PHP-DEV] Re: [PEAR-DEV] Re: [FRC]Session module related issues

[Yasuo Ohgaki]

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

[Jonas Delfs]

"Marco Kaiser" <[EMAIL PROTECTED]> wrote in message
002d01c18975$a24ed9a0$420aa8c0@skotty">news:002d01c18975$a24ed9a0$420aa8c0@skotty...

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

[Yasuo Ohgaki]

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

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

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

[Marco Kaiser]

Hi,



Can one help me, why does it not print PHPSESSID=kasdf... ??


-- Marco



-- 
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 #14626: calling a method "magically" turns the object into a reference to itself

[ivan . lamouret]

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=14626&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 #14625: socket servers expect more data from PHPCGI

[wolfgang . sprick]

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=14625&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 #8865 Updated: App launching with hotkeys delayed

[gvz]

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=8865&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: albaity

[albaity]

Translate php documntation to arabic 


-- 
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 #14624: is_link() fail with error if the link is not found

[g . tanzilli]

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=14624&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 #14623: get_meta_tags only looks in begin of file

[jeroen]

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=14623&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 #13787 Updated: custom sess_write not called to start session

[Jaime Bozza]

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=13787&edit=1


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




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

[PHP-DEV] Ext Lotus

[Pierre-Alain Joye]

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

[darren . shukri]

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:

Apache-AdvancedExtranetServer/1.3.20 Server at mailto:root@localhost\";>gabriel.conchango.com Port
80

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=14622&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 #14621: popen() never returns false

[petr]

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=14621&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 #8865 Updated: App launching with hotkeys delayed

[lobbin]

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=8865&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] Question: Should exit() print out the integer exit-status?

[derick]

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
>

[PHP-DEV] Bug #7641 Updated: cgi binary with "enable-discard-path" fails with empty doc_root value

[lobbin]

ID: 7641
Updated by: lobbin
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: *Web Server problem
Operating System: Linux 2.2.16 i686
PHP Version: 4.0 Latest CVS (04/11/2000)
New Comment:

Any luck with the testing?

PHP 4.1.0 might be a wise choice as well.


R.

Previous Comments:


[2001-08-20 12:28:41] [EMAIL PROTECTED]

Unfortunately, I am currently not able to test it due to time limitation.
Please do not close the bug report yet, I might have time to 
test ist in the next couple of weeks (this report is 8 months old anyway).




[2001-08-19 02:53:39] [EMAIL PROTECTED]

Does this happen with latest CVS snapshot:

http://snaps.php.net/ 





[2000-11-04 20:26:34] [EMAIL PROTECTED]

Similar Problems have been described in Bug id #5163 and Bug id #6201,
but obviously are still not resolved completely :

when compiling the cgi version,  even a simple phpinfo() doesn't work 
when called via Apache (while it works fine on the command line).

The error message in the browser shows up as:
Parse error: parse error in /usr/local/apache/cgi-bin/php on line NNN
(Apache 1.3.14 - other errors were reported by users of Netscape/iPlanet)

I have tried lots of different compilation settings, and found only one common 
element:  the problem only occurs if --enable-discard-path  is specified.

Any other combination of configure flags result in a binary that works
fine as long as --enable-discard-path is not used.

I tried both the download version 4.03pl1 and snapshot-200011041645,
the only difference with the snapshot version is that it shows a different
error message:
 Warning: Unexpected character in input: ' in
   /usr/local/apache/cgi-bin/php on line 116
   Warning: Unexpected character in input: ' in
   /usr/local/apache/cgi-bin/php on line 116
   Warning: Unexpected character in input: '' (ASCII=11) state=1 in
   /usr/local/apache/cgi-bin/php on line 116
   Warning: Unexpected character in input: '' (ASCII=8) state=1 in
   /usr/local/apache/cgi-bin/php on line 116
   Parse error: parse error in /usr/local/apache/cgi-bin/php on line 116

A temporary solution is to set the doc_root in php.ini to a non-empty value.
However, under some circumstances it is undesirable to explicitly set this
value - e.g. when sharing a single php binary among different virtual
servers, so php shouldn't fail even without doc_root set.





Edit this bug report at http://bugs.php.net/?id=7641&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] Question: Should exit() print out the integer exit-status?

[Lars Torben Wilson]

Zeev Suraski writes:
> 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...

Well, that'd still be doable with that optional 2nd param I
mentioned. But that's someone else's fight. :)


'night
 
> 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
>

[PHP-DEV] Bug #14619: Number doesn't fit the data type

[Lars-Owe . Ivarsson]

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=14619&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 #14292 Updated: Bare LF Issue - This time with DETAIL!

[lobbin]

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=14292&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] Question: Should exit() print out the integer exit-status?

[Zeev Suraski]

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

[Lars Torben Wilson]

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

[wcook]

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=13787&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 #12384 Updated: Can't connect to Ingres II

[lobbin]

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



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=12384&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 #14230 Updated: configure fail cross-compiler check with gcc 3.0.1

[lobbin]

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=14230&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 #14120 Updated: libtool needs help.

[lobbin]

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=14120&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] Question: Should exit() print out the integer exit-status?

[Zeev Suraski]

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)?

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


-- 
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] Question: Should exit() print out the integer exit-status?

[derick]

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

[benjamin yates]

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

[Yasuo Ohgaki]

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

[tomcwh]

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=11986&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 #11986 Updated: the problem of php and sybase connection has not been fixed

[tomcwh]

ID: 11986
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Sybase-ct (ctlib) related
Operating System: windows 2000
PHP Version: 4.0.6
New Comment:

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


Previous Comments:


[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=11986&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] Re: [PEAR-DEV] Re: [FRC]Session module related issues

[Yasuo Ohgaki]

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

[littonj]

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=14608&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] Question: Should exit() print out the integer exit-status?

[Yasuo Ohgaki]

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

[yohgaki]

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=14496&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] Re: Bug #14613: Implement Function/Feature Conformity Tests

[Zak Greant]

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

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

[Yasuo Ohgaki]

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

[sander]

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

THIS WINDOWS NOT CLOSED ???
=end===





Edit this bug report at http://bugs.php.net/?id=14609&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 #14610 Updated: configure script looks in the wrong place for httpd.h

[sander]

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=14610&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]