[PHP-DEV] PHP 4.0 Bug #10176 Updated: configurable cgi parameter separators

2001-04-04 Thread joey

ID: 10176
Updated by: joey
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Feature/Change Request
Assigned To: 
Comments:

Thank you. This is a known issue. 4.0.5 will have 2
ini parameters to deal with this:
arg_separator.input
arg_separator.output

Read the php-dev archives for more info. :)

Previous Comments:
---

[2001-04-05 02:14:10] [EMAIL PROTECTED]
It would be nice to have configurable cgi parameter separators for http get requests, 
because the commonly used & sign doesn't fullfill the HTML specification.

read more on this at: http://validator.w3.org/docs/errors.html#bad-entity

It would be nice if this could be configured on a directory/server/virtual server 
basis in .htaccess or httpd.conf files maybe in the following way:

php_value cgi_get_separator ;

for ; as an example

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10176&edit=2


-- 
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] PHP 4.0 Bug #10176: configurable cgi parameter separators

2001-04-04 Thread jan

From: [EMAIL PROTECTED]
Operating system: Any
PHP version:  4.0.4pl1
PHP Bug Type: Feature/Change Request
Bug description:  configurable cgi parameter separators

It would be nice to have configurable cgi parameter separators for http get requests, 
because the commonly used & sign doesn't fullfill the HTML specification.

read more on this at: http://validator.w3.org/docs/errors.html#bad-entity

It would be nice if this could be configured on a directory/server/virtual server 
basis in .htaccess or httpd.conf files maybe in the following way:

php_value cgi_get_separator ;

for ; as an example


-- 
Edit Bug report at: http://bugs.php.net/?id=10176&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] PHP 4.0 Bug #10175: date() reporting wrong timezone

2001-04-04 Thread jr

From: [EMAIL PROTECTED]
Operating system: solaris 2.7
PHP version:  4.0.4pl1
PHP Bug Type: Scripting Engine problem
Bug description:  date() reporting wrong timezone

doing a "date" from the console shows the timezone as PDT.  date("I") returns 1, but 
date("T") reports PST.  


-- 
Edit Bug report at: http://bugs.php.net/?id=10175&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 Bug #9930 Updated: only small psubset ofrfc1867 accepted

2001-04-04 Thread Jani Taskinen


The attached patch fixes (tested) some problems with
e.g. Lynx. Please try it and tell me if it can be
committed or not.

--Jani



Index: rfc1867.c
===
RCS file: /repository/php4/main/rfc1867.c,v
retrieving revision 1.60
diff -u -r1.60 rfc1867.c
--- rfc1867.c   2001/02/26 06:07:31 1.60
+++ rfc1867.c   2001/04/05 05:49:01
@@ -153,30 +153,39 @@
}
break;
case 1: /* Check content-disposition */
-   if (strncasecmp(ptr, "Content-Disposition: 
form-data;", 31)) {
+   while (strncasecmp(ptr, "Content-Disposition: 
+form-data;", 31)) {
if (rem < 31) {
SAFE_RETURN;
}
-   php_error(E_WARNING, "File Upload Mime headers 
garbled ptr: [%c%c%c%c%c]", *ptr, *(ptr + 1), *(ptr + 2), *(ptr + 3), *(ptr + 4));
-   SAFE_RETURN;
+   if (ptr[1] == '\n') {
+/* empty line as end of header found 
+*/
+   php_error(E_WARNING, "File Upload Mime 
+headers garbled ptr: [%c%c%c%c%c]", *ptr, *(ptr + 1), *(ptr + 2), *(ptr + 3), *(ptr + 
+4));
+   SAFE_RETURN;
+}
+   /* some other headerfield found, skip it */
+loc = (char *) memchr(ptr, '\n', rem)+1;
+   while (*loc == ' ' || *loc == '\t')
+   /* other field is folded, skip it */
+   loc = (char *) memchr(loc, '\n', 
+rem-(loc-ptr))+1;
+   rem -= (loc - ptr);
+   ptr = loc;
}
loc = memchr(ptr, '\n', rem);
+   while (loc[1] == ' ' || loc[1] == '\t')
+   /* field is folded, look for end */
+   loc = memchr(loc+1, '\n', rem-(loc-ptr)-1);
name = strstr(ptr, " name=");
if (name && name < loc) {
name += 6;
-   s = memchr(name, '\"', loc - name);
-   if ( name == s ) { 
+   if ( *name == '\"' ) { 
name++;
s = memchr(name, '\"', loc - name);
if(!s) {
php_error(E_WARNING, "File 
Upload Mime headers garbled name: [%c%c%c%c%c]", *name, *(name + 1), *(name + 2), 
*(name + 3), *(name + 4));
SAFE_RETURN;
}
-   } else if(!s) {
-   s = loc;
} else {
-   php_error(E_WARNING, "File Upload Mime 
headers garbled name: [%c%c%c%c%c]", *name, *(name + 1), *(name + 2), *(name + 3), 
*(name + 4));
-   SAFE_RETURN;
+   s = strpbrk(name, " 
+\t()<>@,;:\\\"/[]?=\r\n");
}
if (namebuf) {
efree(namebuf);
@@ -187,9 +196,13 @@
}
lbuf = emalloc(s-name + MAX_SIZE_OF_INDEX + 
1);
state = 2;
-   loc2 = memchr(loc + 1, '\n', rem);
-   rem -= (loc2 - ptr) + 1;
-   ptr = loc2 + 1;
+   loc2 = loc;
+   while (loc2[2] != '\n') {
+   /* empty line as end of header not yet 
+found */
+   loc2 = memchr(loc2 + 1, '\n', 
+rem-(loc2-ptr)-1);
+   }
+   rem -= (loc2 - ptr) + 3;
+   ptr = loc2 + 3;
/* is_arr_

[PHP-DEV] PHP 4.0 Bug #10157 Updated: fdf_next_field_name still not work.

2001-04-04 Thread sniper

ID: 10157
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: FDF related
Assigned To: 
Comments:

Fixed in CVS now. Thank you for reminding me.. :)

--Jani


Previous Comments:
---

[2001-04-04 08:50:12] [EMAIL PROTECTED]
fdf_next_field_name still won't return any strings what so ever.. (see bug #7549) 

??

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10157&edit=2


-- 
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] PHP 4.0 Bug #7549 Updated: fdf_next_field_name doesn't work

2001-04-04 Thread sniper

ID: 7549
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: FDF related
Assigned To: 
Comments:

Fixed in CVS.

--Jani


Previous Comments:
---

[2000-10-31 17:10:30] [EMAIL PROTECTED]
// Optain valid $fdf document
echo fdf_next_field_name($fdf);

this should return first field returned.  Never returns anything even if I pass valid
fields.  fdf_get_value does work so I know the fields are there.  

// Configuration as Module I am using
./configure --with-apache=../apache --with-mysql=../mysql --with-imap=../imap 
--enable-ftp
--with-gd=../gd --with-jpeg-dir=../jpeg --with-zlib=../zlib
--with-config-file-path=/www/conf --with-fdftk --with-dom=../../libxml 
--disable-short-tags

I am not getting undefined function error, the function returns empty string array.

I'm using hard-coded array to meet a deadline, but fixing this will go a long way in
getting others to successfully use FDF functionality in PHP.

Thanks



---

[2000-10-31 11:39:54] [EMAIL PROTECTED]
// Optain valid $fdf document
echo fdf_next_field($fdf);

this should return first field returned.  Never returns anything even if I pass valid 
fields.  fdf_get_value does work so I know the fields are there.  

// Configuration as Module I am using
./configure --with-apache=../apache --with-mysql=../mysql --with-imap=../imap 
--enable-ftp --with-gd=../gd --with-jpeg-dir=../jpeg --with-zlib=../zlib 
--with-config-file-path=/www/conf --with-fdftk --with-dom=../../libxml 
--disable-short-tags

I am not getting undefined function error, the function returns empty string array.

I'm using hard-coded array to meet a deadline, but fixing this will go a long way in 
getting others to successfully use FDF functionality in PHP.

Thanks


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=7549&edit=2


-- 
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] 4.0.5 Comments change (leads to inappropriate parse error based on contents of comments)

2001-04-04 Thread Andi Gutmans

This was fixed to be consistent with ?>.
One line comments end at a new line or at a closing bracket (?> or %>)

Andi

At 05:54 PM 4/4/2001 -0700, Steven Roussey wrote:
>Hi,
>
>I found our problem. In 4.0.5, comments seem to be parsed differently. We
>have ASP style tags enabled so we can use %> as well as ?>. But we had
>comments like this:
>
>
>//asdfasdf%>asdfasdf
>echo('');
>?>
>
>< 4.0.5 would ignore the whole line. 4.0.5 still parses it for open and
>close tags. The lines above get handled differently from 4.0.4 to 4.0.5. It
>is hard to track if the comment is inside a class, because there is no parse
>error until the end of the file, and the code is not spit out like HTML (as
>in the example above) because it is compiling the file. I think this is a
>bug. We can clean up our code to fix it (and will), but
>
>Sincerely,
>
>Steven Roussey
>Network54.com
>http://network54.com/?pp=e
>
>
>--
>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]




Re: [PHP-DEV] Re: [PHP-QA] What to do about 4.0.5

2001-04-04 Thread Jani Taskinen

On Wed, 4 Apr 2001, Richard Lynch wrote:

>Maybe I'm just a Luddite, but...
>
>Does *any* browser actually compose URLs with ; yet?
>
>If nobody's using the standard, why rush to implement?

Never heard of WAP? (I think it was wap that uses them..)
Anyway, the default is & for both new php.ini directives.

--Jani


-- 
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: [PHP-QA] What to do about 4.0.5

2001-04-04 Thread Richard Lynch

Maybe I'm just a Luddite, but...

Does *any* browser actually compose URLs with ; yet?

If nobody's using the standard, why rush to implement?

--
Visit the Zend Store at http://www.zend.com/store/
Wanna help me out?  Like Music?  Buy a CD: http://l-i-e.com/artists.htm
Volunteer a little time: http://chatmusic.com/volunteer.htm
- Original Message -
From: Andi Gutmans <[EMAIL PROTECTED]>
To: php-dev mailinglist <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, April 04, 2001 10:35 AM
Subject: [PHP-QA] What to do about 4.0.5


> OK guys,
>
> I feel VERY uncomfortable releasing 4.0.5 with this arg_separators
problem.
> Let's brainstorm and try to think of a nice, clean and constructive way of
> solving this problem. Let's try to ditch the "screw the user because he
> didn't read RFC foo.bar approach :)
> The issue is with the arg_separator of incoming URL's. If we think of a
> nice solution we should probably make it look&feel similar to the solution
> we will have with URL's which are created.
>
> Ideas? Thoughts?
>
> Andi
>
>
> --
> PHP Quality Assurance 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] PDF Code Fixes into Root of PHP

2001-04-04 Thread David Adams

I had some Cornell grads alter PHP to accomodate PDF and FDF inside of
Frames. They were able to get answers from some top people at Adobe.  I
believe the code was accepted by the powers that be a few versions back.
Does anyone know why the changes were not incorporated? Who do I need to
talk to in order to request that it be added?   Thanks in advance for any
answers.  We no longer have access to the Cornell talent to compile this
code into the Windows Binaries.   If there is anyone who can compile these
into the Windows binaries if it they are not added to 4.05 when it comes out
please contact me.  All estimates appreciated.  I would also like to find
someone in the Baltimore, MD area to work with us.  Please reply to me at
the email address above or call me at home (410) 662-1240.  THANKS IN
ADVANCE!  David
Source Code: 
main\config.w32.h 
13 Change: #define HAVE_BINDLIB 1 
To: #define HAVE_BINDLIB 0 
16 Change: #define WITH_BCMATH 1 
To: #undef WITH_BCMATH 
19 Change: #define HAVE_MYSQL 1 
To: #undef HAVE_MYSQL 

main\internal_functions_win32.c 
73 Ins: #ifdef HAVE_FTP 
75 Ins: #endif 
76 Ins: #ifdef HAVE_MYSQL 
78 Ins: #endif 

ext\odbc\php_odbc.h 
233 Ins: #define PHP_ODBC_MAX_FIELD_NAME_LEN 64 
234 Ins: 
234 Change: char name[32]; 
To: char name[PHP_ODBC_MAX_FIELD_NAME_LEN]; 

ext\odbc\php_odbc.c 
2225 Change: char tmp[32]; 
To: char tmp[PHP_ODBC_MAX_FIELD_NAME_LEN]; 
2253 Change: SQL_COLUMN_TYPE_NAME, tmp, 31, &tmplen, NULL); 
To: SQL_COLUMN_TYPE_NAME, tmp, 
PHP_ODBC_MAX_FIELD_NAME_LEN-1, &t 

ext\mysql\php_mysql.c 
26 Change: 
To: #ifdef HAVE_MYSQL 
1782 Ins: #endif 

ext\fdf\fdf.c 
563 Change: 
To: /* if saving to std out, make sure headers have been sent */ 
564 Ins: if (0==strcmp((*arg2)->value.str.val,"-")) { 
565 Ins: php_header(); 
566 Ins: sapi_flush(); 
567 Ins: } 



-- 
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] efree/emalloc in sapi

2001-04-04 Thread Boian Bonev

> Generally, the emalloc should be working all the way since
> start_memory_manager was called  - which means, from engine startup. The
> "request cleanup" (freeing all non-persistent memory blocks) happens on
> shutdown_memory_manager, which is called from php_request_shutdown,
> after calling request shutdown routines for all modules and extensions,
> including SAPI request shutdown.
>
> Giving second look on what I wrote, you code (from what I got from your
> description) generally should be safe to use emalloc... Maybe you have
> some other problem there?

first to tell you what exactly am i doing - a sapi module for a radius
server... (i have posted a note a while ago here)

the thing is not threaded and there are several processes calling external
stuff. i have replaced the exec call to process php files natively. my
future plan is to make some checks on file extension and process it both
ways but this is not important for my problem.

generally the radius server processes two types of requests:
- login (query) that goes in a single new process which dies afterwards
- accounting - start/alive and stop that is handled sequentially in a single
process that never exits

my first code used emalloc/efree in the following places:

sapi_startup...
php_module_startup...
  *  some emalloc
php_request_startup
php_execute_script
php_request_shutdown
  *  some efree
php_module_shutdown
sapi_shutdown

this works fine if called one time (login works ok). if an acct request
comes in - the first one works fine and the next one segfaults or infinitely
loops in libc's free.

the whole thing works fine again if i remove the efree calls. (with a small
leak but i am not sure if this isn't some cache) here i conclude that the
request_shutdown call is freeing my memory and when i free it again there is
a memory mess.

after replacing emalloc/efree with malloc/free the code works (with a small
leak but i am not sure if this isn't some cache)

i know that if i repeatedly execute php scripts from a single process it is
better to sapi/module startup once then execute_script and at exit
sapi/module shutdown. but i think it shall work both ways only with a
performance penalty in my case...

b.


-- 
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] PHP 4.0 Bug #10173 Updated: --with-bzip

2001-04-04 Thread sniper

ID: 10173
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Documentation problem
Assigned To: 
Comments:

Typo fixed. Thanks!

--Jani


Previous Comments:
---

[2001-04-04 21:00:21] [EMAIL PROTECTED]
The documentation available at
http://php.he.net/manual/en/install.configure.php

lists --with-bzip as the way to enable bzip support in php.

However, there is no --with-bzip configuration option. The proper option is 
--with-bz2. 



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10173&edit=2


-- 
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: ; arg seperator

2001-04-04 Thread Jani Taskinen

On Thu, 5 Apr 2001, Boian Bonev wrote:

>count of boxes broken if arg_separator is '&;'
>count of boxes that dont care about arg_separator default
>count of boxes that need arg_separator to be '&;'
>count of boxes relying on magic_quotes_gpc
>count of boxes that dont care about magic_quotes_gpc
>count of boxes that need magic_quotes_gpc set to off

And note that in CVS there are now two directives:

arg_separator.input
arg_separator.output

Both default to "&" thus were not gonna break anything.
I will MFH into 4_0_5 branch tomorrow evening (CET)
if nobody objects before that.

--Jani



-- 
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] PHP 4.0 Bug #10170 Updated: configure breaks with fdf support in version 4.0.4pl1

2001-04-04 Thread sniper

ID: 10170
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Install and Config
Assigned To: 
Comments:

Fixed in CVS.

--Jani


Previous Comments:
---

[2001-04-04 18:34:26] [EMAIL PROTECTED]
When I try to compile PHP 4.0.4pl1 with fdf support, it breaks from the configure.

My configure line:

 ./configure --with-mysql=/usr/ --with-pgsql --with-apache=../apache_1.3.19 
--enable-track-vars --with-imap --with-fdftk --with-gd



These are the last 4 lines of the result ...

checking for fdftk support... yes
checking for fdftk in default path... found in /usr/local
checking for FDFOpen in -lFdfTk... no
configure: error: fdftk module requires fdftk 2.0


I have compiled PHP with fdf support correctly with previous versions without any 
trouble. Now the common procedure doesn't work.

Thanks.

Jorge Reteguín

I installed FDF as usual:

tar -zvxf fdftk4_05_C.tar.Z
cp fdftk4_05/lib/C/fdftk.h /usr/local/include/FdfTk.h
cp fdftk4_05/lib/C/Unix/i586-linux/GNU3.0/libFdfTk.so.3.0 
/usr/local/lib/libFdfTk.so.3.0
cp -f fdftk4_05/lib/C/Unix/i586-linux/GNU3.0/libFdfTk.so.3.0 
/usr/local/lib/libFdfTk.so.a


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10170&edit=2


-- 
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: ; arg seperator

2001-04-04 Thread Boian Bonev

hi,

> > There was a discussion about things to break in 4.1. magic_quotes_gpc
would
> > definitely be my favourite. I'd like to see it set to off for good and
> > removed from php.ini.
>
> I'd be completely against removing the concept of magic_quotes altogether.
> We can discuss changing the default, but for someone writing simple sql
> pages, it is extremely handy to have PHP deal with escaping stuff for you
> so you don't have a bunch of addslashes() calls everywhere.

perhapse all those topics must be decided on a statistical basis. lets name
it:

count of boxes broken if arg_separator is '&;'
count of boxes that dont care about arg_separator default
count of boxes that need arg_separator to be '&;'
count of boxes relying on magic_quotes_gpc
count of boxes that dont care about magic_quotes_gpc
count of boxes that need magic_quotes_gpc set to off

the decision must break least possible count of php setups when they upgrade
to the newest version.

it would be a disaster for people who have a running server/site and
everything or even worse something somewhere goes wrong.

not to speak about hosting providers who upgrade farms of servers. their
users will have to track problems that occur depending on the input data and
mostly in rare cases. i think this will be a negative impact on many sites
making people reluctant to upgrade to newer php versions. php4.0.5 is not
that better that 4.0.x compared to the difference between 3 and 4 to afford
to break existing functionality...

b.


-- 
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] Unix timestamp maximum

2001-04-04 Thread Joe Brown

Excellent example Keith.

In order for PHP to gain acceptance in the commercial communities, a date
limitation will certainly prevent that.

Date limitation on "only" this or that operating system does not support any
argument.

Ideally it should not depend an operating system structure.

I propose #define PHP_DATE_SIZE _int64



"Keith Waters" <[EMAIL PROTECTED]> wrote in message
001501c0bd43$bd9215a0$d47cfea9@home">news:001501c0bd43$bd9215a0$d47cfea9@home...
> > AG>> By the time we close in on 2038 and UNIX is still around
> > AG>> (*smile*) then most UNIX systems will most probably have moved
> > AG>> to 64bit timestamps, thus requiring in the best place just a
> > AG>> recompilation of your PHP binary and in the worse case if you
> > AG>> saved binary file stamps to a file, some kind of conversion
> > AG>> script. It's not as bad as the Y2K bug (which wasn't too bad:)
> >
> > Well, seeing that most Unix concepts are alive from 60-70th till today,
> > they'll probably be there in 2038. And I'm not sure all systems will be
> > upgraded by then. But I would probably be retired already by then, so
why
> > should I care? ;)
>
> What happens to, for example, somebody who takes out a policy that matures
> in 40 years and the maturation date is stored in an Oracle database using
> PHP? To start with, if the date (>2038) was stored with PHP (using
> mktime), it would come out as -1   If it was stored some other way and
then
> retrieved with PHP (using date), it would show the incorrect date (2038).
>
> I know the bug is not PHP's fault, but surely the code for the date
related
> functions could be rewritten so as NOT to use the OS's built-in functions
> (which I suppose is what is happening at the moment?)
>
> Regards,
> Keith
>
>
>
>
> --
> 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]




Re: [PHP-DEV] RE: ; arg seperator

2001-04-04 Thread Rasmus Lerdorf

> Agreed that it's handy and easy, but it's a two-edged sword. If you write
> scripts that should be distributed on many different servers, it takes a lot
> of code to account for both settings.
>
> I'm one of those control freaks ;) that like to be in total charge about
> what data goes in and out of my application. magic_quotes most certainly
> messes with that. There are so many other converting methods in PHP that you
> need to use, magic_quotes or not, (eg. urlencode/decode), so why must
> addslashes be a default?

And that's fine.  Control freaks and people writing code for distribution
are the same people who can cope with calling get_magic_quotes_gpc() and
making their code work.

One of the main ideas behind PHP is to make it easy for new users without
limiting more experienced users.  Occasionally inconveniencing the
experienced users is unavoidable in certain cases.

-Rasmus


-- 
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] PHP 4.0 Bug #10173: --with-bzip

2001-04-04 Thread augustz

From: [EMAIL PROTECTED]
Operating system: N/A
PHP version:  4.0 Latest CVS (04/04/2001)
PHP Bug Type: Documentation problem
Bug description:  --with-bzip

The documentation available at
http://php.he.net/manual/en/install.configure.php

lists --with-bzip as the way to enable bzip support in php.

However, there is no --with-bzip configuration option. The proper option is 
--with-bz2. 




-- 
Edit Bug report at: http://bugs.php.net/?id=10173&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] 4.0.5 Comments change (leads to inappropriate parse error based oncontents of comments)

2001-04-04 Thread Steven Roussey

Hi,

I found our problem. In 4.0.5, comments seem to be parsed differently. We
have ASP style tags enabled so we can use %> as well as ?>. But we had
comments like this:

asdfasdf
echo('');
?>

< 4.0.5 would ignore the whole line. 4.0.5 still parses it for open and
close tags. The lines above get handled differently from 4.0.4 to 4.0.5. It
is hard to track if the comment is inside a class, because there is no parse
error until the end of the file, and the code is not spit out like HTML (as
in the example above) because it is compiling the file. I think this is a
bug. We can clean up our code to fix it (and will), but

Sincerely,

Steven Roussey
Network54.com
http://network54.com/?pp=e


-- 
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] PHP 4.0 Bug #10172: get_class() doesn't return lowercase for DomX objects

2001-04-04 Thread colin

From: [EMAIL PROTECTED]
Operating system: RH 7.0
PHP version:  4.0 Latest CVS (04/04/2001)
PHP Bug Type: DOM XML related
Bug description:  get_class() doesn't return lowercase for DomX objects

get_class() is documented to return the class/object name in lowercase.

This isn't the case for DomText, DomDocument, etc. objects.  In these cases, 
get_class() returns the StudyCaps version of the object name.

- Colin


-- 
Edit Bug report at: http://bugs.php.net/?id=10172&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: About arg_separator..

2001-04-04 Thread Steven Roussey

Hi,

Ax my last message. We deal with the ; in a URL in Apache before going to
PHP. However, 4.0.5 still breaks our site. It appears to be related to class
inheritance and/or included files. I'm working on a specific test case right
now to show the problem...

Be back in an hour or so...

Sincerely,

Steven Roussey
Network54.com
http://network54.com/?pp=e


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

2001-04-04 Thread Colin Viebrock

I noticed that you did a rewrite of the domxml code lately.  Would that be
why the following code I have doesn't work anymore?

$tree = xmltree($string);
if ($tree->root->name != 'foo') {
...
}

It appears that the DomDocument object doesn't have the ->root property
anymore.  Am I right?

Do I need to use $tree->children->0->name now, or will you add $tree->root
back in?

--
Colin Viebrock
Co-Founder, easyDNS Technologies Inc.
http://www.easyDNS.com/




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




Re: [PHP-DEV] Re: About arg_separator..

2001-04-04 Thread Steven Roussey

Hi,

4.0.5RC6 breaks our website due to the arg_separator change (we have special
meanings for it).

My $0.02...

Sincerely,

Steven Roussey
Network54.com
http://network54.com/?pp=e


-- 
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] PHP 4.0 Bug #10171: calling function before it is defined only works in same file

2001-04-04 Thread aboyd

From: [EMAIL PROTECTED]
Operating system: Windows NT 4 sp 5 & Solaris 8
PHP version:  4.0.4pl1
PHP Bug Type: Scripting Engine problem
Bug description:  calling function before it is defined only works in same file

Define a function.  Put a call to that function BEFORE it is defined.  That works, as 
documented.  Now put the function in an include()'d or require()'d file.  Call the 
function before the include() or require().  It fails.

Since the code is pre-compiled beforehand, shouldn't the function calls still work?  
If this is "as designed" it might be nice to place a caveat in the documentation that 
states "you can call a function before you define it ONLY if the function isn't buried 
in an include()."


-- 
Edit Bug report at: http://bugs.php.net/?id=10171&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] PHP 4.0 Bug #10170: configure breaks with fdf support in version 4.0.4pl1

2001-04-04 Thread jorge

From: [EMAIL PROTECTED]
Operating system: GNULinux RedHat 6.2
PHP version:  4.0.4pl1
PHP Bug Type: *Install and Config
Bug description:  configure breaks with fdf support in version 4.0.4pl1

When I try to compile PHP 4.0.4pl1 with fdf support, it breaks from the configure.

My configure line:

 ./configure --with-mysql=/usr/ --with-pgsql --with-apache=../apache_1.3.19 
--enable-track-vars --with-imap --with-fdftk --with-gd



These are the last 4 lines of the result ...

checking for fdftk support... yes
checking for fdftk in default path... found in /usr/local
checking for FDFOpen in -lFdfTk... no
configure: error: fdftk module requires fdftk 2.0


I have compiled PHP with fdf support correctly with previous versions without any 
trouble. Now the common procedure doesn't work.

Thanks.

Jorge Reteguín

I installed FDF as usual:

tar -zvxf fdftk4_05_C.tar.Z
cp fdftk4_05/lib/C/fdftk.h /usr/local/include/FdfTk.h
cp fdftk4_05/lib/C/Unix/i586-linux/GNU3.0/libFdfTk.so.3.0 
/usr/local/lib/libFdfTk.so.3.0
cp -f fdftk4_05/lib/C/Unix/i586-linux/GNU3.0/libFdfTk.so.3.0 
/usr/local/lib/libFdfTk.so.a



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



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




[PHP-DEV] CVS Account Request

2001-04-04 Thread CVS Account Request

Full name: Edgard Moreno
Email: [EMAIL PROTECTED]
ID: harrycool
Purpose: Authoring PHP documentation

-- 
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: About arg_separator..

2001-04-04 Thread Jani Taskinen

On Wed, 4 Apr 2001, Andi Gutmans wrote:

>Can we roll an RC7 soon and get this 4.0.5 over with? :)
>Maybe we should get people to test the latest CVS first to make sure your
>patch didn't break anything.
>We need a working 4.0.5.

True. But I'm pretty sure it's okay. :)
Anyway, everyone who can, please test the latest CVS.

I'll do MFH tomorrow evening if everything is ok.

--Jani


-- 
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 Bug #10169 Updated:

2001-04-04 Thread Chris Newbill

There are plenty of sinister and devious acts that can be done to those that
choose to defy our tranquility.  (too wordy)

**cough** perl -e 'for ($i=0; $i<$BIG_NUMBER; $i++) { `mail
[EMAIL PROTECTED] < really_big_file`; }' **cough**

:)

-Chris

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 04 April, 2001 3-50 pM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] PHP 4.0 Bug #10169 Updated:


ID: 10169
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Unknown/Other Function
Assigned To:
Comments:

Stop spamming our bug tracking system

Previous Comments:
---

[2001-04-04 17:48:10] [EMAIL PROTECTED]
There's a cockroach in my room.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=10169&edit=2


--
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] PHP 4.0 Bug #10163 Updated: rollback_transactions at pgsql doesn't work with postgres 6.5.3

2001-04-04 Thread thies

ID: 10163
Updated by: thies
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: PostgreSQL related
Assigned To: 
Comments:

fixed in CVS and 4.0.5 branch


Previous Comments:
---

[2001-04-04 12:31:39] [EMAIL PROTECTED]
i ran into a problem that neither the newest cvs nor the php4.0.5RCs compile on my 
system.
there were no problems till 4.0.4pl1



make[3]: Entering directory `/usr/src/redhat/SOURCES/php-4.0.5RC5/ext/pgsql'
/bin/sh /usr/src/redhat/SOURCES/php-4.0.5RC5/libtool --silent --mode=compile gcc  -I. 
-I/usr/src/redhat/SOURCES/php-4.0.5RC5/ext/pgsql 
-I/usr/src/redhat/SOURCES/php-4.0.5RC5/main -I/usr/src/redhat/SOURCES/php-4.0.5RC5 
-I/usr/include/apache -I/usr/src/redhat/SOURCES/php-4.0.5RC5/Zend -I/usr/local/include 
-I/usr/src/redhat/SOURCES/php-4.0.5RC5/ext/mysql/libmysql 
-I/usr/src/redhat/SOURCES/php-4.0.5RC5/ext/xml/expat/xmltok 
-I/usr/src/redhat/SOURCES/php-4.0.5RC5/ext/xml/expat/xmlparse 
-I/usr/src/redhat/SOURCES/php-4.0.5RC5/TSRM -I/usr/include/pgsql -DLINUX=2 -DEAPI 
-DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2  -c pgsql.c
pgsql.c: In function `_rollback_transactions':
pgsql.c:165: void value not ignored as it ought to be
make[3]: *** [pgsql.lo] Error 1
make[3]: Leaving directory `/usr/src/redhat/SOURCES/php-4.0.5RC5/ext/pgsql'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/redhat/SOURCES/php-4.0.5RC5/ext/pgsql'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/redhat/SOURCES/php-4.0.5RC5/ext'
make: *** [all-recursive] Error 1

#

found in cvs that rollback_transactions is new after php4.0.4 and there is the 
problem: maybe the new
postgres libs need the transactions but my version doesn't like this. (version 6.5.3)
the function is about 7 weeks old ...

i'm sorry, but i'm not such a good programmer to solve the problem on my own.

greetings,
Stefan Döhla


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10163&edit=2


-- 
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] PHP 4.0 Bug #10169 Updated:

2001-04-04 Thread derick

ID: 10169
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Unknown/Other Function
Assigned To: 
Comments:

Stop spamming our bug tracking system

Previous Comments:
---

[2001-04-04 17:48:10] [EMAIL PROTECTED]
There's a cockroach in my room.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10169&edit=2


-- 
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] PHP 4.0 Bug #10169:

2001-04-04 Thread packphour

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0.3pl1
PHP Bug Type: Unknown/Other Function
Bug description:  

There's a cockroach in my room.


-- 
Edit Bug report at: http://bugs.php.net/?id=10169&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] Unix timestamp maximum

2001-04-04 Thread Keith Waters

> AG>> By the time we close in on 2038 and UNIX is still around
> AG>> (*smile*) then most UNIX systems will most probably have moved
> AG>> to 64bit timestamps, thus requiring in the best place just a
> AG>> recompilation of your PHP binary and in the worse case if you
> AG>> saved binary file stamps to a file, some kind of conversion
> AG>> script. It's not as bad as the Y2K bug (which wasn't too bad:)
>
> Well, seeing that most Unix concepts are alive from 60-70th till today,
> they'll probably be there in 2038. And I'm not sure all systems will be
> upgraded by then. But I would probably be retired already by then, so why
> should I care? ;)

What happens to, for example, somebody who takes out a policy that matures
in 40 years and the maturation date is stored in an Oracle database using
PHP? To start with, if the date (>2038) was stored with PHP (using
mktime), it would come out as -1   If it was stored some other way and then
retrieved with PHP (using date), it would show the incorrect date (2038).

I know the bug is not PHP's fault, but surely the code for the date related
functions could be rewritten so as NOT to use the OS's built-in functions
(which I suppose is what is happening at the moment?)

Regards,
Keith




-- 
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] PHP 4.0 Bug #10168: openssl.c function uses an undeclared variable

2001-04-04 Thread martin

From: [EMAIL PROTECTED]
Operating system: Solaris
PHP version:  4.0 Latest CVS (04/04/2001)
PHP Bug Type: Compile Failure
Bug description:  openssl.c function uses an undeclared variable

openssl.c: In function `asn1_time_to_time_t':
openssl.c:459: `is_dst' undeclared (first use in this function)
openssl.c:459: (Each undeclared identifier is reported only once
openssl.c:459: for each function it appears in.)
make[1]: *** [openssl.lo] Error 1
make[1]: Leaving directory `/space/pruebas/php4/ext/openssl'
make: *** [all-recursive] Error 1

is_dst (as I saw in some other c files) should be defined at the begining of the 
function `asn1_time_to_time_t', but it's not.
So I declared it as int with default value -1 and looks like that fixed it.


-- 
Edit Bug report at: http://bugs.php.net/?id=10168&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 Bug #10165 Updated: install.txt doesn't mention copying DLLs to WINNT

2001-04-04 Thread Carsten Gehling

From: <[EMAIL PROTECTED]>
Sent: Wednesday, April 04, 2001 7:49 PM
Subject: [PHP-DEV] PHP 4.0 Bug #10165 Updated: install.txt doesn't mention
copying DLLs to WINNT


> ID: 10165
> Updated by: phildriscoll
> Reported By: [EMAIL PROTECTED]
> Old-Status: Open
> Status: Feedback
> Bug Type: Documentation problem
> Assigned To:
> Comments:
>
> It would be good to get to the bottom of this. If anyone out there
understands what Windows does in these circumstances, can they shed some
light on proceedings.



You don't need to copy ANY of the php dlls to \winnt\system32.

"php4ts.dll" runs fine from the php directory, as any dlls your application
tries to load is first searched for in the application's directory.

The extension-dlls can also stay where they are (in the "extensions"
directory), BUT you need to change a line in the "php.ini":

extension_dir = ./extensions

Maybe this should be a default value instead of

extension_dir = .

Just my suggestion anyway, especially sine the install.txt doesn't mention
this.

- Carsten




-- 
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: ; arg seperator

2001-04-04 Thread Carsten Gehling

From: "Rasmus Lerdorf" <[EMAIL PROTECTED]>
Sent: Wednesday, April 04, 2001 7:22 PM


> > There was a discussion about things to break in 4.1. magic_quotes_gpc
would
> > definitely be my favourite. I'd like to see it set to off for good and
> > removed from php.ini.
>
> I'd be completely against removing the concept of magic_quotes altogether.
> We can discuss changing the default, but for someone writing simple sql
> pages, it is extremely handy to have PHP deal with escaping stuff for you
> so you don't have a bunch of addslashes() calls everywhere.

Agreed that it's handy and easy, but it's a two-edged sword. If you write
scripts that should be distributed on many different servers, it takes a lot
of code to account for both settings.

I'm one of those control freaks ;) that like to be in total charge about
what data goes in and out of my application. magic_quotes most certainly
messes with that. There are so many other converting methods in PHP that you
need to use, magic_quotes or not, (eg. urlencode/decode), so why must
addslashes be a default?

- Carsten




-- 
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] PHP 4.0 Bug #10165 Updated: install.txt doesn't mention copying DLLs to WINNT

2001-04-04 Thread jhurshman

ID: 10165
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Documentation problem
Description: install.txt doesn't mention copying DLLs to WINNT

When I was having the problem, I could load certain extensions just fine (e.g., 
php_gd.dll and php_db.dll). However, the database extensions would not load.

My interpretation is that the database DLLs depend on one or more of the DLLs that are 
provided in the dll directory of the distribution. Perhaps there's another way to get 
Windows to find those DLLs without putting them in the WINNT directory (setting the 
path, maybe?).

Previous Comments:
---

[2001-04-04 13:49:48] [EMAIL PROTECTED]
It would be good to get to the bottom of this. If anyone out there understands what 
Windows does in these circumstances, can they shed some light on proceedings.

I don't have any of the databases that need extensions, so the only extension I 
routinely use is GD, however it is my experience on NT4 that I never have to stick any 
dll (php or otherwise) in winnt or winnt/system32 unless it is going to be shared by 
some other application. I can always just put them in the same directory as the 
program that calls them and all is well.

Is W2K different, or are the database extension dlls different.

We need to know, not only for the installation notes, but also for the installer 
software which sticks things in c:/php by default.

---

[2001-04-04 13:27:35] [EMAIL PROTECTED]
I have PHP running as CGI on IIS5.0 (Windows 2000 Advanced Server). I followed exactly 
the instructions in the install.txt document.

When I tried to load certain extensions (any database extensions, specifically), 
php.exe would hang, with the complaint that "Warning : Unable to load dynamic library 
'./php_mssql70.dll' - The specified module could not be found."

In searching the bug reports here, I found the suggestion to copy the contents of the 
php/dll directory to winntsystem32. That fixed the problem.

The "install.txt" document should mention this.

---


Full Bug description available at: http://bugs.php.net/?id=10165


-- 
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] PHP 4.0 Bug #10167: potential Bufferoverflow in extensions based on skeleton...

2001-04-04 Thread s . esser

From: [EMAIL PROTECTED]
Operating system: all
PHP version:  4.0 Latest CVS (04/04/2001)
PHP Bug Type: Unknown/Other Function
Bug description:  potential Bufferoverflow in extensions based on skeleton...

When i was looking through the CVS version of php, i discovered the following piece of 
code in skeleton.c

---snip---

PHP_FUNCTION(confirm_extname_compiled)
{
zval **arg;
int len;
char string[256];
...
...
...
len = sprintf(string, "Congratulations, you have successfully modified 
t/extname/config.m4, module %s is compiled into PHP", Z_STRVAL_PP(arg));

---snap---

of course the sprintf could be used to perform a standart bufferoverflow. It should be 
better changed into ... %.50s ... or similiar to do not create a potential 
vulnerability.

As far as i can see ircg and cybermut sources still have the compile confirmation in 
them...

ciao,
Stefan Esser



-- 
Edit Bug report at: http://bugs.php.net/?id=10167&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] PHP 4.0 Bug #10165 Updated: install.txt doesn't mention copying DLLs to WINNT

2001-04-04 Thread phildriscoll

ID: 10165
Updated by: phildriscoll
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Documentation problem
Assigned To: 
Comments:

It would be good to get to the bottom of this. If anyone out there understands what 
Windows does in these circumstances, can they shed some light on proceedings.

I don't have any of the databases that need extensions, so the only extension I 
routinely use is GD, however it is my experience on NT4 that I never have to stick any 
dll (php or otherwise) in winnt or winnt/system32 unless it is going to be shared by 
some other application. I can always just put them in the same directory as the 
program that calls them and all is well.

Is W2K different, or are the database extension dlls different.

We need to know, not only for the installation notes, but also for the installer 
software which sticks things in c:/php by default.

Previous Comments:
---

[2001-04-04 13:27:35] [EMAIL PROTECTED]
I have PHP running as CGI on IIS5.0 (Windows 2000 Advanced Server). I followed exactly 
the instructions in the install.txt document.

When I tried to load certain extensions (any database extensions, specifically), 
php.exe would hang, with the complaint that "Warning : Unable to load dynamic library 
'./php_mssql70.dll' - The specified module could not be found."

In searching the bug reports here, I found the suggestion to copy the contents of the 
php/dll directory to winntsystem32. That fixed the problem.

The "install.txt" document should mention this.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10165&edit=2


-- 
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] PHP 4.0 Bug #10166: read_exif_data loads whole image into memory

2001-04-04 Thread vvo

From: [EMAIL PROTECTED]
Operating system: Linux 2.2
PHP version:  4.0 Latest CVS (04/04/2001)
PHP Bug Type: Performance problem
Bug description:  read_exif_data loads whole image into memory

Some users observed that read_exif_data is too slow with 1MB image files, which is a 
typical size for digital camera output. I looked into the implementation 
(ext/exif/exif.c) and it looks like the whole compressed image data is always read 
into memory, even though read_exif_data should be concerned with just the file header.

Here's a line from function read_exif_data:

ret = php_read_jpeg_exif(&ImageInfo, (*p_name)->value.str.val,1);


The last parameter (ReadAll=1), causes the whole image data loaded into memory inside 
function scan_JPEG_header:


if (ReadAll) {
int cp, ep, size;
/* Determine how much file is left. */
cp = ftell(infile);
fseek(infile, 0, SEEK_END);
ep = ftell(infile);
fseek(infile, cp, SEEK_SET);

size = ep-cp;
Data = (uchar *)malloc(size);
if (Data == NULL) {
php_error(E_ERROR,"could not allocate data for entire image");
}

got = fread(Data, 1, size, infile);
if (got != size) {
php_error(E_ERROR,"could not read the rest of the image");
}

Sections[*SectionsRead].Data = Data;
Sections[*SectionsRead].Size = size;
Sections[*SectionsRead].Type = PSEUDO_IMAGE_MARKER;
(*SectionsRead)++;
/*
*HaveAll = 1;
*/
}
return TRUE;


I believe the line above should be changed to feed 0 as value of parameter ReadAll.

Thanks.
V


-- 
Edit Bug report at: http://bugs.php.net/?id=10166&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] PHP 4.0 Bug #10165: install.txt doesn't mention copying DLLs to WINNT

2001-04-04 Thread jhurshman

From: [EMAIL PROTECTED]
Operating system: Windows 2000 Advanced Server
PHP version:  4.0.4pl1
PHP Bug Type: Documentation problem
Bug description:  install.txt doesn't mention copying DLLs to WINNT

I have PHP running as CGI on IIS5.0 (Windows 2000 Advanced Server). I followed exactly 
the instructions in the install.txt document.

When I tried to load certain extensions (any database extensions, specifically), 
php.exe would hang, with the complaint that "Warning : Unable to load dynamic library 
'./php_mssql70.dll' - The specified module could not be found."

In searching the bug reports here, I found the suggestion to copy the contents of the 
php/dll directory to winnt\system32. That fixed the problem.

The "install.txt" document should mention this.


-- 
Edit Bug report at: http://bugs.php.net/?id=10165&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: ; arg seperator

2001-04-04 Thread Rasmus Lerdorf

> There was a discussion about things to break in 4.1. magic_quotes_gpc would
> definitely be my favourite. I'd like to see it set to off for good and
> removed from php.ini.

I'd be completely against removing the concept of magic_quotes altogether.
We can discuss changing the default, but for someone writing simple sql
pages, it is extremely handy to have PHP deal with escaping stuff for you
so you don't have a bunch of addslashes() calls everywhere.

-Rasmus


-- 
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: ; arg seperator

2001-04-04 Thread Andi Gutmans

At 07:11 PM 4/4/2001 +0200, Edin Kadribasic wrote:
> > But commercial companies aside, the plethora of configuration options
>(like
> > magic_quotes_gpc) can and does make life harder for people writing code
> > libraries (like PEAR) that are meant to be dropped in anywhere, or for
>people
> > trying to write applications that have minimal setup required, or that
>people
> > can install on hosts where they don't have access to the php.ini
>parameters.
> > It's certainly something to keep in mind.
>
>There was a discussion about things to break in 4.1. magic_quotes_gpc would
>definitely be my favourite. I'd like to see it set to off for good and
>removed from php.ini.
>Is anybody keeping notes ? ;)

I think you just volunteered yourself :)

Andi


-- 
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] PHP 4.0 Bug #10164 Updated: a problem with PHP4TS.DLL

2001-04-04 Thread sniper

ID: 10164
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: *Web Server problem
Assigned To: 
Comments:

Does this happen with PHP 4.0.4pl1 too?

--Jani


Previous Comments:
---

[2001-04-04 13:07:13] [EMAIL PROTECTED]
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to 
complete your request.
Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time 
the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.





Apache/1.3.12 Server at neo-plane.mshome.net Port 80




It happened when i tried to test if it worked with : http://localhost/test.php3







---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10164&edit=2


-- 
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: ; arg seperator

2001-04-04 Thread Edin Kadribasic

> But commercial companies aside, the plethora of configuration options
(like
> magic_quotes_gpc) can and does make life harder for people writing code
> libraries (like PEAR) that are meant to be dropped in anywhere, or for
people
> trying to write applications that have minimal setup required, or that
people
> can install on hosts where they don't have access to the php.ini
parameters.
> It's certainly something to keep in mind.

There was a discussion about things to break in 4.1. magic_quotes_gpc would
definitely be my favourite. I'd like to see it set to off for good and
removed from php.ini.

Is anybody keeping notes ? ;)

Edin



-- 
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] PHP 4.0 Bug #10164: a problem with PHP4TS.DLL

2001-04-04 Thread cybersix

From: [EMAIL PROTECTED]
Operating system: windows ME
PHP version:  4.0.0
PHP Bug Type: *Web Server problem
Bug description:  a problem with PHP4TS.DLL

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to 
complete your request.
Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time 
the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.





Apache/1.3.12 Server at neo-plane.mshome.net Port 80




It happened when i tried to test if it worked with : http://localhost/test.php3








-- 
Edit Bug report at: http://bugs.php.net/?id=10164&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] file IO abstraction layer

2001-04-04 Thread Wez Furlong

Stig [+ Andi & others]

I've made a start, and concerning sockets, I wanted to ask a question.

main/network.c has php_hostconnect, which is used only by the http/ftp fopen wrappers, 
and does not yet implement the timeout (AFAICS).

ext/standard/fsock.c has php_fsockopen, which seems to a more complete implementation, 
but uses zvals and does resource registration, and doesn't handle IPV6 as well as 
php_hostconnect (if at all).

I take it the plan is to make php_hostconnect the definitive function for connecting 
to a host, but it not yet complete?

I'm aiming for a definitive function that will return a php_file * representing a 
socket - most of my skeleton is complete, it's just the opening of sockets that I 
wasn't 100% sure about.

Can I get away with merging php_fsockopen into php_hostconnect?  It's just the 
non-blocking stuff missing right?

Also, since these changes are pretty hairy, they will need a bit of "testing-in" - I 
dont want to check them into CVS and have it break everything, but at the same time I 
could do with some developers out there trying it out and giving me some feedback.  I 
could do a cvs diff periodically, but that makes things hard - I guess the best thing 
would be to create a branch?

Any pointers?

--Wez.

PS: for those that missed it last time, the general idea is that instead of all the 
madness with FP_FGETS and issock, sock and fp vars flying around, we aim for an 
abstraction where the calling code doesn't have to know if it is using a file or a 
socket (or anything else), unless it really wants to know.



--
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] PHP 4.0 Bug #10163: rollback_transactions at pgsql doesn't work with postgres 6.5.3

2001-04-04 Thread doe

From: [EMAIL PROTECTED]
Operating system: Redhat 6.2
PHP version:  4.0 Latest CVS (04/04/2001)
PHP Bug Type: PostgreSQL related
Bug description:  rollback_transactions at pgsql doesn't work with postgres 6.5.3

i ran into a problem that neither the newest cvs nor the php4.0.5RCs compile on my 
system.
there were no problems till 4.0.4pl1



make[3]: Entering directory `/usr/src/redhat/SOURCES/php-4.0.5RC5/ext/pgsql'
/bin/sh /usr/src/redhat/SOURCES/php-4.0.5RC5/libtool --silent --mode=compile gcc  -I. 
-I/usr/src/redhat/SOURCES/php-4.0.5RC5/ext/pgsql 
-I/usr/src/redhat/SOURCES/php-4.0.5RC5/main -I/usr/src/redhat/SOURCES/php-4.0.5RC5 
-I/usr/include/apache -I/usr/src/redhat/SOURCES/php-4.0.5RC5/Zend -I/usr/local/include 
-I/usr/src/redhat/SOURCES/php-4.0.5RC5/ext/mysql/libmysql 
-I/usr/src/redhat/SOURCES/php-4.0.5RC5/ext/xml/expat/xmltok 
-I/usr/src/redhat/SOURCES/php-4.0.5RC5/ext/xml/expat/xmlparse 
-I/usr/src/redhat/SOURCES/php-4.0.5RC5/TSRM -I/usr/include/pgsql -DLINUX=2 -DEAPI 
-DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2  -c pgsql.c
pgsql.c: In function `_rollback_transactions':
pgsql.c:165: void value not ignored as it ought to be
make[3]: *** [pgsql.lo] Error 1
make[3]: Leaving directory `/usr/src/redhat/SOURCES/php-4.0.5RC5/ext/pgsql'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/redhat/SOURCES/php-4.0.5RC5/ext/pgsql'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/redhat/SOURCES/php-4.0.5RC5/ext'
make: *** [all-recursive] Error 1

#

found in cvs that rollback_transactions is new after php4.0.4 and there is the 
problem: maybe the new
postgres libs need the transactions but my version doesn't like this. (version 6.5.3)
the function is about 7 weeks old ...

i'm sorry, but i'm not such a good programmer to solve the problem on my own.

greetings,
Stefan Döhla



-- 
Edit Bug report at: http://bugs.php.net/?id=10163&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] Unix timestamp maximum

2001-04-04 Thread Stanislav Malyshev

AG>> By the time we close in on 2038 and UNIX is still around
AG>> (*smile*) then most UNIX systems will most probably have moved
AG>> to 64bit timestamps, thus requiring in the best place just a
AG>> recompilation of your PHP binary and in the worse case if you
AG>> saved binary file stamps to a file, some kind of conversion
AG>> script. It's not as bad as the Y2K bug (which wasn't too bad:)

Well, seeing that most Unix concepts are alive from 60-70th till today,
they'll probably be there in 2038. And I'm not sure all systems will be
upgraded by then. But I would probably be retired already by then, so why
should I care? ;)

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



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




[PHP-DEV] CVS Account Request

2001-04-04 Thread CVS Account Request

Full name: Hadar Porat
Email: [EMAIL PROTECTED]
ID: hadar_p
Purpose: Hebrew PHP Manual

-- 
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] PHP 4.0 Bug #10161 Updated: base64_decode doesn't work correctly

2001-04-04 Thread kenji

ID: 10161
User Update by: [EMAIL PROTECTED]
Status: Closed
Bug Type: *URL Functions
Description: base64_decode doesn't work correctly

couldn't reproduce it anymore :)

Previous Comments:
---

[2001-04-04 12:07:29] [EMAIL PROTECTED]
couldn't reproduce it anymore :)

---

[2001-04-04 12:01:54] [EMAIL PROTECTED]
Why did you change this to open without giving any feedback?

--Jani


---

[2001-04-04 12:01:48] [EMAIL PROTECTED]
Why did you change this to open without giving any feedback?

--Jani


---

[2001-04-04 11:37:19] [EMAIL PROTECTED]
This works for me just fine:



It prints out "OTYw" and "960".

960 as ninesixzero.

This is with latest CVS. You can try the latest snapshot
from http://snaps.php.net/ to verify.

--Jani


---

[2001-04-04 11:14:22] [EMAIL PROTECTED]
Although base64_encode("960") produces the string "OTYw", 
base64_decode("OTYw") doesn't produce "960".

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=10161


-- 
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] PHP 4.0 Bug #10161 Updated: base64_decode doesn't work correctly

2001-04-04 Thread kenji

ID: 10161
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: *URL Functions
Description: base64_decode doesn't work correctly

couldn't reproduce it anymore :)

Previous Comments:
---

[2001-04-04 12:01:54] [EMAIL PROTECTED]
Why did you change this to open without giving any feedback?

--Jani


---

[2001-04-04 12:01:48] [EMAIL PROTECTED]
Why did you change this to open without giving any feedback?

--Jani


---

[2001-04-04 11:37:19] [EMAIL PROTECTED]
This works for me just fine:



It prints out "OTYw" and "960".

960 as ninesixzero.

This is with latest CVS. You can try the latest snapshot
from http://snaps.php.net/ to verify.

--Jani


---

[2001-04-04 11:14:22] [EMAIL PROTECTED]
Although base64_encode("960") produces the string "OTYw", 
base64_decode("OTYw") doesn't produce "960".

---


Full Bug description available at: http://bugs.php.net/?id=10161


-- 
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] PHP 4.0 Bug #10162 Updated: different behaviour of && and and operator

2001-04-04 Thread sniper

ID: 10162
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Unknown/Other Function
Assigned To: 
Comments:

Please check this manual page:

http://www.php.net/manual/en/language.operators.precedence.php

Not a bug.

--Jani


Previous Comments:
---

[2001-04-04 11:59:37] [EMAIL PROTECTED]
in the case shown below both operators generate different values, once TRUE twice 
FALSE

source code

= $b);
  
  return $valid;
  }

function isValid_and_($a)
  {
  $valid = true;
  $b = 1;
  
  $valid = $valid && (strlen($a) >= $b);
  
  return $valid;
  }

$a = "";

if (isValid_and($a))
  echo "and - true";
else
  echo "and - false";

if (isValid_and_($a))
  echo "&& - true";
else
  echo "&& - false";
?>


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10162&edit=2


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




[PHP-DEV] CVS Account Request

2001-04-04 Thread CVS Account Request

Full name: Joe Stump
Email: [EMAIL PROTECTED]
ID: miester
Purpose: Andrei Zmievski suggested I help work on gtk.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] PHP 4.0 Bug #10161 Updated: base64_decode doesn't work correctly

2001-04-04 Thread sniper

ID: 10161
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: *URL Functions
Assigned To: 
Comments:

Why did you change this to open without giving any feedback?

--Jani


Previous Comments:
---

[2001-04-04 12:01:48] [EMAIL PROTECTED]
Why did you change this to open without giving any feedback?

--Jani


---

[2001-04-04 11:37:19] [EMAIL PROTECTED]
This works for me just fine:



It prints out "OTYw" and "960".

960 as ninesixzero.

This is with latest CVS. You can try the latest snapshot
from http://snaps.php.net/ to verify.

--Jani


---

[2001-04-04 11:14:22] [EMAIL PROTECTED]
Although base64_encode("960") produces the string "OTYw", 
base64_decode("OTYw") doesn't produce "960".

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10161&edit=2


-- 
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] PHP 4.0 Bug #10161 Updated: base64_decode doesn't work correctly

2001-04-04 Thread sniper

ID: 10161
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: *URL Functions
Assigned To: 
Comments:

Why did you change this to open without giving any feedback?

--Jani


Previous Comments:
---

[2001-04-04 11:37:19] [EMAIL PROTECTED]
This works for me just fine:



It prints out "OTYw" and "960".

960 as ninesixzero.

This is with latest CVS. You can try the latest snapshot
from http://snaps.php.net/ to verify.

--Jani


---

[2001-04-04 11:14:22] [EMAIL PROTECTED]
Although base64_encode("960") produces the string "OTYw", 
base64_decode("OTYw") doesn't produce "960".

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10161&edit=2


-- 
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] PHP 4.0 Bug #10162: different behaviour of && and and operator

2001-04-04 Thread gerald . kallas

From: [EMAIL PROTECTED]
Operating system: Windows 2000 Professional
PHP version:  4.0.4
PHP Bug Type: Unknown/Other Function
Bug description:  different behaviour of && and and operator

in the case shown below both operators generate different values, once TRUE twice FALSE

source code

= $b);
  
  return $valid;
  }

function isValid_and_($a)
  {
  $valid = true;
  $b = 1;
  
  $valid = $valid && (strlen($a) >= $b);
  
  return $valid;
  }

$a = "";

if (isValid_and($a))
  echo "and - true";
else
  echo "and - false";

if (isValid_and_($a))
  echo "&& - true";
else
  echo "&& - false";
?>



-- 
Edit Bug report at: http://bugs.php.net/?id=10162&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] PHP 4.0 Bug #10161 Updated: base64_decode doesn't work correctly

2001-04-04 Thread kenji

ID: 10161
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: *URL Functions
Description: base64_decode doesn't work correctly



Previous Comments:
---

[2001-04-04 11:14:22] [EMAIL PROTECTED]
Although base64_encode("960") produces the string "OTYw", 
base64_decode("OTYw") doesn't produce "960".

---


Full Bug description available at: http://bugs.php.net/?id=10161


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

2001-04-04 Thread Cameron

i'v just started to get these in my error_log's

[Wed Apr  4 07:07:22 2001] [notice] Apache/1.3.19 (Unix)
ApacheJServ/1.1.2 mod_throttle/3.1.2 PHP/4.0.5-dev mod_ssl/2.8.2
OpenSSL/0.9.6 configured -- resuming normal operations
traceroute to 129.188.33.222 (129.188.33.222), 30 hops max, 40 byte
packets
[Wed Apr  4 15:46:29 2001] [notice] child pid 90680 exit signal
Segmentation fault (11)

in one of my scripts i do a

blahblah

blahblah

it looks as tho it is doing that when the execution time times out? not
exactly sure . . .

cvs snap from about 3hrs ago, freebsd 4.2-stable

Cameron Brunner


-- 
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: [PHP-QA] What to do about 4.0.5

2001-04-04 Thread Kirill Maximov



Andi Gutmans wrote:
> 
> OK guys,
> 
> I feel VERY uncomfortable releasing 4.0.5 with this arg_separators problem.
> Let's brainstorm and try to think of a nice, clean and constructive way of
> solving this problem. Let's try to ditch the "screw the user because he
> didn't read RFC foo.bar approach :)
> The issue is with the arg_separator of incoming URL's. If we think of a
> nice solution we should probably make it look&feel similar to the solution
> we will have with URL's which are created.
> 
> Ideas? Thoughts?

  I suppose that there should be a parameter in php.ini (defaults to off in 4.0.5) that
  considers ; as a separator. 

  And in 4.1 this parameter should be changed to 'on'.

  Best regards,
  KIR

-- 
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] What to do about 4.0.5

2001-04-04 Thread Andi Gutmans

At 05:40 PM 4/4/2001 +0200, Jani Taskinen wrote:
>On Wed, 4 Apr 2001, Andi Gutmans wrote:
>
> >I feel VERY uncomfortable releasing 4.0.5 with this arg_separators problem.
> >Let's brainstorm and try to think of a nice, clean and constructive way of
> >solving this problem. Let's try to ditch the "screw the user because he
> >didn't read RFC foo.bar approach :)
> >The issue is with the arg_separator of incoming URL's. If we think of a
> >nice solution we should probably make it look&feel similar to the solution
> >we will have with URL's which are created.
>
>We spoke with Zeev about this. We came to conclusion that
>there should be a php.ini directives like these:
>
>arg_separator.input=";&"
>arg_separator.output="&"
>
>Where defaults are:
>
>arg_separator.input="&"
>arg_separator.output="&"

Sounds like a good solution to me.
The places which used the old arg_separator seem to only be in main.c and 
url_scanner*.c
So we should update these and add support for the arg_separator.input.
I think that's really OK.

Andi


-- 
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] What to do about 4.0.5

2001-04-04 Thread Jani Taskinen

On Wed, 4 Apr 2001, Andi Gutmans wrote:

>I feel VERY uncomfortable releasing 4.0.5 with this arg_separators problem.
>Let's brainstorm and try to think of a nice, clean and constructive way of
>solving this problem. Let's try to ditch the "screw the user because he
>didn't read RFC foo.bar approach :)
>The issue is with the arg_separator of incoming URL's. If we think of a
>nice solution we should probably make it look&feel similar to the solution
>we will have with URL's which are created.

We spoke with Zeev about this. We came to conclusion that
there should be a php.ini directives like these:

arg_separator.input=";&"
arg_separator.output="&"

Where defaults are:

arg_separator.input="&"
arg_separator.output="&"

--Jani



-- 
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] PHP 4.0 Bug #10161 Updated: base64_decode doesn't work correctly

2001-04-04 Thread sniper

ID: 10161
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: *URL Functions
Assigned To: 
Comments:

This works for me just fine:



It prints out "OTYw" and "960".

960 as ninesixzero.

This is with latest CVS. You can try the latest snapshot
from http://snaps.php.net/ to verify.

--Jani


Previous Comments:
---

[2001-04-04 11:14:22] [EMAIL PROTECTED]
Although base64_encode("960") produces the string "OTYw", 
base64_decode("OTYw") doesn't produce "960".

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10161&edit=2


-- 
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] What to do about 4.0.5

2001-04-04 Thread Andi Gutmans

OK guys,

I feel VERY uncomfortable releasing 4.0.5 with this arg_separators problem. 
Let's brainstorm and try to think of a nice, clean and constructive way of 
solving this problem. Let's try to ditch the "screw the user because he 
didn't read RFC foo.bar approach :)
The issue is with the arg_separator of incoming URL's. If we think of a 
nice solution we should probably make it look&feel similar to the solution 
we will have with URL's which are created.

Ideas? Thoughts?

Andi


-- 
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] Unix timestamp maximum

2001-04-04 Thread Andi Gutmans

By the time we close in on 2038 and UNIX is still around (*smile*) then 
most UNIX systems will most probably have moved to 64bit timestamps, thus 
requiring in the best place just a recompilation of your PHP binary and in 
the worse case if you saved binary file stamps to a file, some kind of 
conversion script. It's not as bad as the Y2K bug (which wasn't too bad:)

Andi

At 05:06 PM 4/4/2001 +0200, Keith Waters wrote:
>From: [EMAIL PROTECTED]
>Operating system: RedHat Linux
>PHP version:  4.0.4pl1
>PHP Bug Type: Feature/Change Request
>Bug description:  Unix timestamp doesnt go over Tuesday 19 January 2038
>05:11
>
>As you know, most of PHP's date and time functions use the unix
>timestamp, which wont go past Tuesday 19 January 2038 05:11, numberically
>represented by 2147483648 (ie 30 bits)
>
>Surely PHP can get clever and work around this? (ie allow bigger values
>which will translate back and forth properly up to the year ?)
>Otherwise we will all find outselves with a Y2K-like date nightmare!
>
>eg:  currently:  echo mktime(0,0,0,1,1,2099);  outputs -1
>and putting any number past 2147483648 into date() wont give you
>anything past Tuesday 19 January 2038 05:11
>
>Thanks!
>regards,
>Keith
>
>
>
>
>--
>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] CVS Account Request

2001-04-04 Thread CVS Account Request

Full name: David Benson
Email: [EMAIL PROTECTED]
ID: dbenson
Purpose: Extending OCI8 module

-- 
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] PHP 4.0 Bug #10161: base64_decode doesn't work correctly

2001-04-04 Thread kenji

From: [EMAIL PROTECTED]
Operating system: Linux 2.2.12
PHP version:  4.0.4pl1
PHP Bug Type: *URL Functions
Bug description:  base64_decode doesn't work correctly

Although base64_encode("960") produces the string "OTYw", 
base64_decode("OTYw") doesn't produce "960".


-- 
Edit Bug report at: http://bugs.php.net/?id=10161&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] Unix timestamp maximum

2001-04-04 Thread Keith Waters

From: [EMAIL PROTECTED]
Operating system: RedHat Linux
PHP version:  4.0.4pl1
PHP Bug Type: Feature/Change Request
Bug description:  Unix timestamp doesnt go over Tuesday 19 January 2038
05:11

As you know, most of PHP's date and time functions use the unix
timestamp, which wont go past Tuesday 19 January 2038 05:11, numberically
represented by 2147483648 (ie 30 bits)

Surely PHP can get clever and work around this? (ie allow bigger values
which will translate back and forth properly up to the year ?)
Otherwise we will all find outselves with a Y2K-like date nightmare!

eg:  currently:  echo mktime(0,0,0,1,1,2099);  outputs -1
and putting any number past 2147483648 into date() wont give you
anything past Tuesday 19 January 2038 05:11

Thanks!
regards,
Keith




-- 
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] PHP 4.0 Bug #10159: bug with Caudium 1.0.2RC2

2001-04-04 Thread mazelier

From: [EMAIL PROTECTED]
Operating system: FreeBsd 4.1
PHP version:  4.0.4pl1
PHP Bug Type: Other web server
Bug description:  bug with Caudium 1.0.2RC2

The php support Caudium (roxen) server (the pike module)
seems to be very buggy !! For example , phpNuke website
based or phpmyadmin interface should not work !!
Simple php pages work as  Well.  There is certainly
a problem with include files, ...



-- 
Edit Bug report at: http://bugs.php.net/?id=10159&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: ; arg seperator

2001-04-04 Thread Chuck Hagenbuch

Quoting Joey Smith <[EMAIL PROTECTED]>:

>   I've never bought into this argument, because these companies
> can include a "config.php", or something like that, which uses
> ini_set() to set up the INI file however they need it...

But commercial companies aside, the plethora of configuration options (like 
magic_quotes_gpc) can and does make life harder for people writing code 
libraries (like PEAR) that are meant to be dropped in anywhere, or for people 
trying to write applications that have minimal setup required, or that people 
can install on hosts where they don't have access to the php.ini parameters. 
It's certainly something to keep in mind.

-chuck

--
Charles Hagenbuch, <[EMAIL PROTECTED]>
Number of U.S. nuclear bombs lost in accidents and never recovered: 11

-- 
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: [PHP-QA] RE: ; arg seperator

2001-04-04 Thread Zeev Suraski

At 23:04 3/4/2001, Joey Smith wrote:
> I've never bought into this argument, because these companies
>can include a "config.php", or something like that, which uses
>ini_set() to set up the INI file however they need it...

ini_set() is run after the input parsing is already done, so it won't help 
in this case.  Only .htaccess or equivalent.


-- 
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: [PHP-QA] Re: ; arg seperator

2001-04-04 Thread Zeev Suraski

At 22:52 3/4/2001, Hartmut Holzgraefe wrote:
>lets follow the "break it hard, break it early" rule here ...

It's kind of difficult to do that now, that this behavior has been around 
for the last 4 years :)  It'll never be early.

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] PHP 4.0 Bug #9903 Updated: Premature end of script

2001-04-04 Thread cynic

ID: 9903
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Apache related
Assigned To: 
Comments:



Previous Comments:
---

[2001-03-31 09:22:09] [EMAIL PROTECTED]
what are the relevant lines from your httpd.conf?

---

[2001-03-21 12:35:27] [EMAIL PROTECTED]
I installed PHP4.0.4 from the PHP4_win32 distribution on a win98 machine with DUN not 
connected to internet. Use Netscape and type: http://12.0.0.1/.  The apache test page 
comes up.  Edited the httpd.conf for PHP and typed: http://12.0.0.1/test.php.

An error about an internal server error was reported on the browser.  The apache 
error.log had an entry stating" Premature end of script headers in c:/program 
files/apache/cgi-bin/php/php.exe"

The php.ini file is the defalault from the PHP404.exe setup.  I did confirm the 
extensions_ line is pointing to my php directory.

I selected the interbase extension only, dm and one other were enabled by default so I 
left them.  I have MySQL installed on the machine but not running.

I would like to use the machine for local (not connected) development when on the 
road.
 

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9903&edit=2


-- 
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] PHP 4.0 Bug #10158 Updated: "r" format specifier in Date() causing problems

2001-04-04 Thread sniper

ID: 10158
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Date/time related
Assigned To: 
Comments:

Works for me with latest CVS just fine.
Try latest snapshot from http://snaps.php.net/ to verify
if this is fixed.

--Jani


Previous Comments:
---

[2001-04-04 09:30:50] [EMAIL PROTECTED]
echo date( "r h:ia" );

returns:

Tue, 3 Apr 2001 13:45:46 +0500 12:875903540pm

What's up with the minutes?  It seems the minutes are 
only screwed up with the "r" format specifier is used...

Chris

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10158&edit=2


-- 
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: [PHP-QA] Re: ; arg seperator

2001-04-04 Thread Zeev Suraski

I don't think it's a very good idea.  I think that crossposting in mailing 
list such as php-dev and php-qa makes perfect sense, because of the 
significant (yet far from 100%) overlap between the two lists.  You could 
just get your filters to filter out duplicate letters (there's a good 
procmail recipe for doing that automatically).

Zeev

At 13:46 4/4/2001, Hellekin O. Wolf wrote:
>At 00:54 04/04/2001 +0200, Hartmut Holzgraefe wrote:
>>[EMAIL PROTECTED] wrote:
>> > Please stop crossposting to the PHP-DEV and the PHP-QA mailing list. Most
>> > people interesting in this theme are reading both. And so it is really
>> > annoying to get everything twice.
>>
>>a bad idea IMHO as long as the topic is related to both lists as
>>this will break the thread in the archives for one of the lists
>>
>>--
>>Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de +49-711-99091-77
>*** np,
>
>---
>  FOR ARCHIVES :
>
>  Please follow-up this discussion on [EMAIL PROTECTED]
>---
>
>No cross-posting please.
>
>To subscribe to php-qa mailing-list :
>
> PHP Quality Assurance Mailing List 
> OR mailto:[EMAIL PROTECTED]
>
>
>--
>PHP Quality Assurance Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]

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


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




[PHP-DEV] PHP 4.0 Bug #10158: "r" format specifier in Date() causing problems

2001-04-04 Thread chris

From: [EMAIL PROTECTED]
Operating system: Solaris 5.6
PHP version:  4.0.4pl1
PHP Bug Type: Date/time related
Bug description:  "r" format specifier in Date() causing problems

echo date( "r h:ia" );

returns:

Tue, 3 Apr 2001 13:45:46 +0500 12:875903540pm

What's up with the minutes?  It seems the minutes are 
only screwed up with the "r" format specifier is used...

Chris


-- 
Edit Bug report at: http://bugs.php.net/?id=10158&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: ; arg seperator

2001-04-04 Thread Zeev Suraski

At 06:55 4/4/2001, Alexander Bokovoy wrote:
>If so, why this change didn't find its way into PHP_4_0_5 branch? It was
>done a week ago, at the time of ~ RC3 I think.

Because changes such as this aren't critical, make break things, and thus 
do not belong in RCs.

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] PHP 4.0 Bug #9903 Updated: Premature end of script

2001-04-04 Thread drgray

ID: 9903
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Apache related
Description: Premature end of script

It looks as though the PHP test page was trying to query the MySQL database and report 
it's status.  I did not have MySQL or any other database running.

PHP for non-DB scripts runs great and I will re-run test.php with MySQL running later 
today.

Previous Comments:
---

[2001-03-31 09:22:09] [EMAIL PROTECTED]
what are the relevant lines from your httpd.conf?

---

[2001-03-21 12:35:27] [EMAIL PROTECTED]
I installed PHP4.0.4 from the PHP4_win32 distribution on a win98 machine with DUN not 
connected to internet. Use Netscape and type: http://12.0.0.1/.  The apache test page 
comes up.  Edited the httpd.conf for PHP and typed: http://12.0.0.1/test.php.

An error about an internal server error was reported on the browser.  The apache 
error.log had an entry stating" Premature end of script headers in c:/program 
files/apache/cgi-bin/php/php.exe"

The php.ini file is the defalault from the PHP404.exe setup.  I did confirm the 
extensions_ line is pointing to my php directory.

I selected the interbase extension only, dm and one other were enabled by default so I 
left them.  I have MySQL installed on the machine but not running.

I would like to use the machine for local (not connected) development when on the 
road.
 

---


Full Bug description available at: http://bugs.php.net/?id=9903


-- 
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] PHP 4.0 Bug #10157: fdf_next_field_name still not work.

2001-04-04 Thread stefan

From: [EMAIL PROTECTED]
Operating system: Linux Slackware 7.1
PHP version:  4.0 Latest CVS (02/04/2001)
PHP Bug Type: FDF related
Bug description:  fdf_next_field_name still not work.

fdf_next_field_name still won't return any strings what so ever.. (see bug #7549) 

??


-- 
Edit Bug report at: http://bugs.php.net/?id=10157&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] PHP 4.0 Bug #10026 Updated: For loop always execute

2001-04-04 Thread svein

ID: 10026
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: *General Issues
Description: For loop always execute

I'm sorry, but all other script i make work ok. Its just this one that cause the 
problem.

I dont know how to make another script for you as i cant reproduce the error in any 5 
line of code.

- Svein

Previous Comments:
---

[2001-04-04 08:28:35] [EMAIL PROTECTED]
I asked for 'self-containing' script. ie. one that doesn't
need anything outside but works as is. This example script
you added is useless and can not be used to reproduce anything. Please create a SHORT 
(max 5 lines) script that doesn't work.

--Jani


---

[2001-04-04 06:26:22] [EMAIL PROTECTED]
The parameter passed to the function i prev. post is the stricture returned from 
imag_fetchstructure...

- Svein

---

[2001-04-04 06:24:05] [EMAIL PROTECTED]
I post the function that cause the problem.
Its the for-loop int the wery bottom of the function that cause my problem. If you can 
see any wrong logic in the code please let me know :)

I have solved this problem in another way in my current code. 
The code below have worked for a long time, but stopped working and caused described 
problem after installing - i think php4.0.4 or 4.0.4pl1

Even if i surrond the for-loop with this :

echo "First : $c";
if ($c!=0) {
  echo "Second : $c";
  for (..) {
echo "Inside for-loop...";
...
  }
}

the first echo output 0 but the second echo output another value like 1 or 2.
The strange thing is that if the FIRST echo output 0 the SECOND echo doesnt execute 
**BUT** the for-loop execute!



  // Parse the parts of message and get info on each
  function parseparts($ref, $ofs='') {
global $part_no, $msg_part, $imap, $sorted_msgs, $msg_no, $bgcolor, $background, 
$folder;
global $sort_order;
 
$part_no++;

$msg_part[$part_no] = $ref;
$msg_part[$part_no]->index = $ofs;

$ac = count($ref->dparameters);
for ($i=0; $i<$ac; $i++)
if (eregi($ref->dparameters[$i]->attribute, 'filename')) {
$msg_part[$part_no]->filename = $ref->dparameters[$i]->value;
break;
};

$ac = count($ref->parameters);
for ($i=0; $i<$ac; $i++)
  if (eregi($ref->parameters[$i]->attribute, 'name')) {
  $msg_part[$part_no]->name = $ref->parameters[$i]->value;
  break;
};

if (!strcmp($msg_part[$part_no]->subtype, 'HTML')) { // Get background for HTML 
message
  $tmp = @imap_fetchbody($imap, $sorted_msgs[$msg_no-1], 
$msg_part[$part_no]->index);
  // Encode data
  switch($msg_part[$part_no]->encoding) {
case ENCBASE64  : $tmp = @imap_base64($tmp); break;
case ENCQUOTEDPRINTABLE : $tmp = @imap_qprint($tmp); break;
  };

  // Background color
  if (preg_match('//si', $tmp, $tmp2)) {
$bgcolor=$tmp2[1];
$bgcolor = 'BGCOLOR="'.preg_replace('/"/', '', $bgcolor).'"';
  } else
$bgcolor='BGCOLOR="#ff"';;
  // Remove any "

  // Background image
  if (preg_match('//si', $tmp, $tmp2)) 
$tmp=$tmp2[1];
  else
$tmp='';

  if (!empty($tmp)) {
$background = 
"background="getpart.phtml?1get_type=1&part_id=".rawurlencode(ereg_replace(""", '', 
$tmp)).""";
  } else $background = '';

};  

$c = count($ref->parts);
for ($p=0; $p<$c; $p++) {
  if (empty($ofs)) $of = ''.($p+1); else $of = $ofs.'.'.($p+1);
  parseparts($ref->parts[$p], $of);
};
  };
  // Get info on each parts

  parseparts($msg_struct);


---

[2001-04-01 13:34:29] [EMAIL PROTECTED]
As I can not reproduce this with latest CVS please try
the latest snapshot from http://snaps.php.net/

And if happens with it too, create one 
short but self-containing script which can be used
to reproduce this anywhere without modifications
and add it into this bug report.

--Jani


---

[2001-03-29 12:57:01] [EMAIL PROTECTED]
When i said ONCE - i didnt mean ONCE :)
It ALWAYS happen in the code referred...

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=10026


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

Re: [PHP-DEV] [PHP-QA] PHP-4.0.5-RC6

2001-04-04 Thread André Langhorst

> ... SKIP ...
> OO Bug Test (Bug #7515) (029.phpt)   ... failed
> ... SKIP ...

ignore it

andré

-- 
· André Langhorstt: +49 331 5811560 ·
· [EMAIL PROTECTED]  m: +49 173 9558736 ·
* PHP Quality Assurance  http://qa.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] PHP 4.0 Bug #10026 Updated: For loop always execute

2001-04-04 Thread sniper

ID: 10026
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: *General Issues
Assigned To: 
Comments:

I asked for 'self-containing' script. ie. one that doesn't
need anything outside but works as is. This example script
you added is useless and can not be used to reproduce anything. Please create a SHORT 
(max 5 lines) script that doesn't work.

--Jani


Previous Comments:
---

[2001-04-04 06:26:22] [EMAIL PROTECTED]
The parameter passed to the function i prev. post is the stricture returned from 
imag_fetchstructure...

- Svein

---

[2001-04-04 06:24:05] [EMAIL PROTECTED]
I post the function that cause the problem.
Its the for-loop int the wery bottom of the function that cause my problem. If you can 
see any wrong logic in the code please let me know :)

I have solved this problem in another way in my current code. 
The code below have worked for a long time, but stopped working and caused described 
problem after installing - i think php4.0.4 or 4.0.4pl1

Even if i surrond the for-loop with this :

echo "First : $c";
if ($c!=0) {
  echo "Second : $c";
  for (..) {
echo "Inside for-loop...";
...
  }
}

the first echo output 0 but the second echo output another value like 1 or 2.
The strange thing is that if the FIRST echo output 0 the SECOND echo doesnt execute 
**BUT** the for-loop execute!



  // Parse the parts of message and get info on each
  function parseparts($ref, $ofs='') {
global $part_no, $msg_part, $imap, $sorted_msgs, $msg_no, $bgcolor, $background, 
$folder;
global $sort_order;
 
$part_no++;

$msg_part[$part_no] = $ref;
$msg_part[$part_no]->index = $ofs;

$ac = count($ref->dparameters);
for ($i=0; $i<$ac; $i++)
if (eregi($ref->dparameters[$i]->attribute, 'filename')) {
$msg_part[$part_no]->filename = $ref->dparameters[$i]->value;
break;
};

$ac = count($ref->parameters);
for ($i=0; $i<$ac; $i++)
  if (eregi($ref->parameters[$i]->attribute, 'name')) {
  $msg_part[$part_no]->name = $ref->parameters[$i]->value;
  break;
};

if (!strcmp($msg_part[$part_no]->subtype, 'HTML')) { // Get background for HTML 
message
  $tmp = @imap_fetchbody($imap, $sorted_msgs[$msg_no-1], 
$msg_part[$part_no]->index);
  // Encode data
  switch($msg_part[$part_no]->encoding) {
case ENCBASE64  : $tmp = @imap_base64($tmp); break;
case ENCQUOTEDPRINTABLE : $tmp = @imap_qprint($tmp); break;
  };

  // Background color
  if (preg_match('//si', $tmp, $tmp2)) {
$bgcolor=$tmp2[1];
$bgcolor = 'BGCOLOR="'.preg_replace('/"/', '', $bgcolor).'"';
  } else
$bgcolor='BGCOLOR="#ff"';;
  // Remove any "

  // Background image
  if (preg_match('//si', $tmp, $tmp2)) 
$tmp=$tmp2[1];
  else
$tmp='';

  if (!empty($tmp)) {
$background = 
"background="getpart.phtml?1get_type=1&part_id=".rawurlencode(ereg_replace(""", '', 
$tmp)).""";
  } else $background = '';

};  

$c = count($ref->parts);
for ($p=0; $p<$c; $p++) {
  if (empty($ofs)) $of = ''.($p+1); else $of = $ofs.'.'.($p+1);
  parseparts($ref->parts[$p], $of);
};
  };
  // Get info on each parts

  parseparts($msg_struct);


---

[2001-04-01 13:34:29] [EMAIL PROTECTED]
As I can not reproduce this with latest CVS please try
the latest snapshot from http://snaps.php.net/

And if happens with it too, create one 
short but self-containing script which can be used
to reproduce this anywhere without modifications
and add it into this bug report.

--Jani


---

[2001-03-29 12:57:01] [EMAIL PROTECTED]
When i said ONCE - i didnt mean ONCE :)
It ALWAYS happen in the code referred...

---

[2001-03-29 12:55:32] [EMAIL PROTECTED]
Its not easy reproduceable - i have only seen this happens ONCE - in the specified 
function. Its NOT a simple for-loop - the for-loop executes INSIDE a recursively 
called function.

I've also tried this one :
---
$c = count($myarray);
if ($c>0) {
  echo "c is greater than 0";
  for (...) {
...code
  }
}
---
then IF c is 0 the echo statement doesnt execute BUT the for loop executes...

I cant figure out why...

If some of you want it i can mail you the file so you can see the things in 
perspective.

- Svein

---

The remainder of the comments for this report are to

[PHP-DEV] Re: ; arg seperator

2001-04-04 Thread Hellekin O. Wolf

At 00:54 04/04/2001 +0200, Hartmut Holzgraefe wrote:
>[EMAIL PROTECTED] wrote:
> > Please stop crossposting to the PHP-DEV and the PHP-QA mailing list. Most
> > people interesting in this theme are reading both. And so it is really
> > annoying to get everything twice.
>
>a bad idea IMHO as long as the topic is related to both lists as
>this will break the thread in the archives for one of the lists
>
>--
>Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77
*** np,

---
  FOR ARCHIVES :

  Please follow-up this discussion on [EMAIL PROTECTED]
---

No cross-posting please.

To subscribe to php-qa mailing-list :

 PHP Quality Assurance Mailing List 
 OR mailto:[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] PHP 4.0 Bug #10156 Updated: nl2br doesn't ad XHTML slash

2001-04-04 Thread derick

ID: 10156
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Function Specific
Assigned To: 
Comments:

It will be in 4.0.5, the docs are ahead of releases this time.

Previous Comments:
---

[2001-04-04 07:13:34] [EMAIL PROTECTED]
It seems that contrary to the docs, nl2br doesn't replace returns with , only 
with .

Give it a try with:
print htmlspecialchars(nl2br("line1 n line2 n line3"));

If you're looking for XHTML compliance, use:

function nl2br_xhtml($text) {
return str_replace("", "", nl2br($text));
}

rgds,

Matt

My config command:
'./configure' '--prefix=/usr' '--with-config-file-path=/etc' '--disable-debug' 
'--enable-pic' '--enable-shared' '--enable-inline-optimization' 
'--with-apxs=/usr/sbin/apxs' '--with-exec-dir=/usr/bin' '--with-regex=system' 
'--with-gettext' '--with-gd' '--with-jpeg-dir=/usr' '--with-png' '--with-zlib' 
'--with-db2' '--with-db3' '--with-gdbm' '--enable-debugger' '--enable-magic-quotes' 
'--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' 
'--enable-track-vars' '--enable-yp' '--enable-ftp' '--enable-wddx' '--without-mysql' 
'--without-oracle' '--without-oci8' '--with-xml'

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10156&edit=2


-- 
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: ; arg seperatorx

2001-04-04 Thread Sascha Schumann

> If so, why this change didn't find its way into PHP_4_0_5 branch? It was
> done a week ago, at the time of ~ RC3 I think.

No need for anger.  We can drop some simple backwards macros
into the head branch which output a warning, when called, but
work normally otherwise.

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


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




[PHP-DEV] CVS Account Request

2001-04-04 Thread CVS Account Request

Full name: Sean Preston
Email: [EMAIL PROTECTED]
ID: fireclaw
Purpose: documentation for PEAR

-- 
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] PHP 4.0 Bug #10156: nl2br doesn't ad XHTML slash

2001-04-04 Thread kynaston

From: [EMAIL PROTECTED]
Operating system: Red Hat 7.0 (x86)
PHP version:  4.0.4pl1
PHP Bug Type: *Function Specific
Bug description:  nl2br doesn't ad XHTML slash

It seems that contrary to the docs, nl2br doesn't replace returns with , only 
with .

Give it a try with:
print htmlspecialchars(nl2br("line1 \n line2 \n line3"));

If you're looking for XHTML compliance, use:

function nl2br_xhtml($text) {
return str_replace("", "", nl2br($text));
}

rgds,

Matt

My config command:
'./configure' '--prefix=/usr' '--with-config-file-path=/etc' '--disable-debug' 
'--enable-pic' '--enable-shared' '--enable-inline-optimization' 
'--with-apxs=/usr/sbin/apxs' '--with-exec-dir=/usr/bin' '--with-regex=system' 
'--with-gettext' '--with-gd' '--with-jpeg-dir=/usr' '--with-png' '--with-zlib' 
'--with-db2' '--with-db3' '--with-gdbm' '--enable-debugger' '--enable-magic-quotes' 
'--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' 
'--enable-track-vars' '--enable-yp' '--enable-ftp' '--enable-wddx' '--without-mysql' 
'--without-oracle' '--without-oci8' '--with-xml'


-- 
Edit Bug report at: http://bugs.php.net/?id=10156&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] PHP 4.0 Bug #10155: Insert or update query not functioning correctly

2001-04-04 Thread jules

From: [EMAIL PROTECTED]
Operating system: Windows NT 4.0 build 1381
PHP version:  4.0.4pl1
PHP Bug Type: ODBC related
Bug description:  Insert or update query not functioning correctly

The database is  Access 2000 with a few tables and relations set up in the 
relationships area.

Put simply the update, insert and, possibly, delete querys all appear to work 
perfectely with no errors reported, except that the database ends up being unchanged 
afterwards. The only way I have been able to fix this is to query the same table with 
a select before the end of the script, the changes are then implemented.

I have played with autocommit and commit with no effect so I figure it must be a bug 
in either PHP or the ODBC drivers.

Here is one of the scripts with  a totally unecessary select towards the end to make 
it work.



http://www.justbiz.co.uk
[EMAIL PROTECTED]
 + 44 (0)870 841 3040

Project:Space Windows
Routine:ModifySeries2.php
Created:23/03/01
Descrip:Modify series number, title and description, update database. 
Also inserts new records.

Revision:   a
Rev. Date   23/03/01
Descrip:Created.

Parameters - From ModifySeries.php form
*/
error_reporting(63);
require("Security.php");
require("OpenDatabase.php");

if($SeriesId == "-1") {
// Create append query
$Query = "insert into tbl_Series ";
$Query .= "(SeriesNumber, ShortSeriesTitle, Description) ";
$Query .= "values('$SeriesNumber', '$ShortSeriesTitle', '$Description')";
}
else {
// Create update query
$Query = "update tbl_Series ";
$Query .= "set SeriesNumber= '$SeriesNumber', ShortSeriesTitle= 
'$ShortSeriesTitle', ";
$Query .= "Description= '$Description' where (SeriesId = $SeriesId)";
}
$Result = odbc_do($Connect, $Query);


?>

Space Windows - Series modified




");
$Query = "select SeriesId, SeriesNumber, ShortSeriesTitle, Description from 
tbl_Series";
$Result = odbc_do($Connect, $Query);

while(odbc_fetch_row($Result)) {
print(odbc_result($Result,1));
print(odbc_result($Result,2)."");
} 
if(!$Result) print("Failed");
Print("Database Updated for Series ".$SeriesNumber."");
?> Return to Series Page 





-- 
Edit Bug report at: http://bugs.php.net/?id=10155&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] PHP 4.0 Bug #10154: Function ereg array results

2001-04-04 Thread crash

From: [EMAIL PROTECTED]
Operating system: Linux/NT
PHP version:  4.0.4pl1
PHP Bug Type: *Regular Expressions
Bug description:  Function ereg array results

I'm not sure, if it's really an error or "feature" :). I would like to get $regs[10] 
value, but the output is always empty.


$string = "1234567890";

ereg( "^(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)", $string, $regs);

echo "Whole string: " . $regs[ 0 ] . "
"; for ( $i = 1; $i <= 10; $i++ ) { echo "
" . $i . " -> " . $regs[$i]; } -- Edit Bug report at: http://bugs.php.net/?id=10154&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] Code documentation

2001-04-04 Thread Stanislav Malyshev

C>> I started noting about all the PLS_FETCH(), and ELS_FETCH() and
C>> #ifdef ZTS and all that stuff but i really have a hard time
C>> sometime debugging my patches cause i don't really know what that
C>> function specifically does. now that i have new patches to do, i
C>> wish i had a plain documentation.

Well, there's some docs but they do not cover internals too much. If you
have specific questions - ask them.
ZTS means if PHP/Zend is built in threading environment (like for IIS) or
not (like httpd). The difference is that in the former case memory space
can be shared between number of execution threads, so special care should
be taken.
*_FETCH() "fetches" (i.e., makes available in current block) the
set of per-thread globals for given module. These globals are defined in
zend_globals.h for Zend and module headers for all modules. Generally,
every global variable you modify should be per-thread global, unless you
explicitly want it to be shared between threads - and then you should
lock/mutex it, etc.
In the non-ZTS mode most _FETCH functions are defined to do nothing, since
using plain old globals is OK.
-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



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




[PHP-DEV] FREE LEADS FOR OUR GROUP!!

2001-04-04 Thread wealthclub2738933




ATTENTION:  ANY SERIOUS NETWORK MARKETER
TAKE A LOOK AT THE FOLLOWING OPPORTUNITY I CAME ACROSS!!
IF YOU PLUG INTO THEIR PROVEN SYSTEM, THEY GUARANTEE YOU SUCCESS, 
AND PROVIDE YOU WITH FREE LEADS TO BUILD YOUR GROUP!!


DO NOT LET THIS SLIP AWAY!!  CLICK BELOW AND FIND OUT AS I DID,
WHY THESE GUYS ARE THE LEADERS IN THE INDUSTRY!!



http://www.geocities.com/wealthclub8989




*
THIS EMAIL COMPLIES WITH ALL REGULATIONS.  TO BE REMOVED WITHIN 
24 Hours, SIMPLYEMAIL [EMAIL PROTECTED] FOR IMMEDIATE 
REMOVAL FROM ANY FUTURE EMAILS FROM OUR COMPANY.
*

-- 
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] efree/emalloc in sapi

2001-04-04 Thread Stanislav Malyshev

BB>> can someone tell me the exact places where emalloced memory
BB>> begins to be tracked and where the leaks are efreed?

Generally, the emalloc should be working all the way since
start_memory_manager was called  - which means, from engine startup. The
"request cleanup" (freeing all non-persistent memory blocks) happens on
shutdown_memory_manager, which is called from php_request_shutdown,
after calling request shutdown routines for all modules and extensions,
including SAPI request shutdown.

Giving second look on what I wrote, you code (from what I got from your
description) generally should be safe to use emalloc... Maybe you have
some other problem there?
-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115




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




[PHP-DEV] PHP 4.0 Bug #10026 Updated: For loop always execute

2001-04-04 Thread svein

ID: 10026
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: *General Issues
Description: For loop always execute

The parameter passed to the function i prev. post is the stricture returned from 
imag_fetchstructure...

- Svein

Previous Comments:
---

[2001-04-04 06:24:05] [EMAIL PROTECTED]
I post the function that cause the problem.
Its the for-loop int the wery bottom of the function that cause my problem. If you can 
see any wrong logic in the code please let me know :)

I have solved this problem in another way in my current code. 
The code below have worked for a long time, but stopped working and caused described 
problem after installing - i think php4.0.4 or 4.0.4pl1

Even if i surrond the for-loop with this :

echo "First : $c";
if ($c!=0) {
  echo "Second : $c";
  for (..) {
echo "Inside for-loop...";
...
  }
}

the first echo output 0 but the second echo output another value like 1 or 2.
The strange thing is that if the FIRST echo output 0 the SECOND echo doesnt execute 
**BUT** the for-loop execute!



  // Parse the parts of message and get info on each
  function parseparts($ref, $ofs='') {
global $part_no, $msg_part, $imap, $sorted_msgs, $msg_no, $bgcolor, $background, 
$folder;
global $sort_order;
 
$part_no++;

$msg_part[$part_no] = $ref;
$msg_part[$part_no]->index = $ofs;

$ac = count($ref->dparameters);
for ($i=0; $i<$ac; $i++)
if (eregi($ref->dparameters[$i]->attribute, 'filename')) {
$msg_part[$part_no]->filename = $ref->dparameters[$i]->value;
break;
};

$ac = count($ref->parameters);
for ($i=0; $i<$ac; $i++)
  if (eregi($ref->parameters[$i]->attribute, 'name')) {
  $msg_part[$part_no]->name = $ref->parameters[$i]->value;
  break;
};

if (!strcmp($msg_part[$part_no]->subtype, 'HTML')) { // Get background for HTML 
message
  $tmp = @imap_fetchbody($imap, $sorted_msgs[$msg_no-1], 
$msg_part[$part_no]->index);
  // Encode data
  switch($msg_part[$part_no]->encoding) {
case ENCBASE64  : $tmp = @imap_base64($tmp); break;
case ENCQUOTEDPRINTABLE : $tmp = @imap_qprint($tmp); break;
  };

  // Background color
  if (preg_match('//si', $tmp, $tmp2)) {
$bgcolor=$tmp2[1];
$bgcolor = 'BGCOLOR="'.preg_replace('/"/', '', $bgcolor).'"';
  } else
$bgcolor='BGCOLOR="#ff"';;
  // Remove any "

  // Background image
  if (preg_match('//si', $tmp, $tmp2)) 
$tmp=$tmp2[1];
  else
$tmp='';

  if (!empty($tmp)) {
$background = 
"background="getpart.phtml?1get_type=1&part_id=".rawurlencode(ereg_replace(""", '', 
$tmp)).""";
  } else $background = '';

};  

$c = count($ref->parts);
for ($p=0; $p<$c; $p++) {
  if (empty($ofs)) $of = ''.($p+1); else $of = $ofs.'.'.($p+1);
  parseparts($ref->parts[$p], $of);
};
  };
  // Get info on each parts

  parseparts($msg_struct);


---

[2001-04-01 13:34:29] [EMAIL PROTECTED]
As I can not reproduce this with latest CVS please try
the latest snapshot from http://snaps.php.net/

And if happens with it too, create one 
short but self-containing script which can be used
to reproduce this anywhere without modifications
and add it into this bug report.

--Jani


---

[2001-03-29 12:57:01] [EMAIL PROTECTED]
When i said ONCE - i didnt mean ONCE :)
It ALWAYS happen in the code referred...

---

[2001-03-29 12:55:32] [EMAIL PROTECTED]
Its not easy reproduceable - i have only seen this happens ONCE - in the specified 
function. Its NOT a simple for-loop - the for-loop executes INSIDE a recursively 
called function.

I've also tried this one :
---
$c = count($myarray);
if ($c>0) {
  echo "c is greater than 0";
  for (...) {
...code
  }
}
---
then IF c is 0 the echo statement doesnt execute BUT the for loop executes...

I cant figure out why...

If some of you want it i can mail you the file so you can see the things in 
perspective.

- Svein

---

[2001-03-29 11:55:23] [EMAIL PROTECTED]
I can't reproduce this (using code below):



Could you try this one?
And note: If the variable passed to count() is not an array,
it will return 1.

--Jani


---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at: h

[PHP-DEV] PHP 4.0 Bug #10026 Updated: For loop always execute

2001-04-04 Thread svein

ID: 10026
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: *General Issues
Description: For loop always execute

I post the function that cause the problem.
Its the for-loop int the wery bottom of the function that cause my problem. If you can 
see any wrong logic in the code please let me know :)

I have solved this problem in another way in my current code. 
The code below have worked for a long time, but stopped working and caused described 
problem after installing - i think php4.0.4 or 4.0.4pl1

Even if i surrond the for-loop with this :

echo "First : $c";
if ($c!=0) {
  echo "Second : $c";
  for (..) {
echo "Inside for-loop...";
...
  }
}

the first echo output 0 but the second echo output another value like 1 or 2.
The strange thing is that if the FIRST echo output 0 the SECOND echo doesnt execute 
**BUT** the for-loop execute!



  // Parse the parts of message and get info on each
  function parseparts($ref, $ofs='') {
global $part_no, $msg_part, $imap, $sorted_msgs, $msg_no, $bgcolor, $background, 
$folder;
global $sort_order;
 
$part_no++;

$msg_part[$part_no] = $ref;
$msg_part[$part_no]->index = $ofs;

$ac = count($ref->dparameters);
for ($i=0; $i<$ac; $i++)
if (eregi($ref->dparameters[$i]->attribute, 'filename')) {
$msg_part[$part_no]->filename = $ref->dparameters[$i]->value;
break;
};

$ac = count($ref->parameters);
for ($i=0; $i<$ac; $i++)
  if (eregi($ref->parameters[$i]->attribute, 'name')) {
  $msg_part[$part_no]->name = $ref->parameters[$i]->value;
  break;
};

if (!strcmp($msg_part[$part_no]->subtype, 'HTML')) { // Get background for HTML 
message
  $tmp = @imap_fetchbody($imap, $sorted_msgs[$msg_no-1], 
$msg_part[$part_no]->index);
  // Encode data
  switch($msg_part[$part_no]->encoding) {
case ENCBASE64  : $tmp = @imap_base64($tmp); break;
case ENCQUOTEDPRINTABLE : $tmp = @imap_qprint($tmp); break;
  };

  // Background color
  if (preg_match('//si', $tmp, $tmp2)) {
$bgcolor=$tmp2[1];
$bgcolor = 'BGCOLOR="'.preg_replace('/\"/', '', $bgcolor).'"';
  } else
$bgcolor='BGCOLOR="#ff"';;
  // Remove any "

  // Background image
  if (preg_match('//si', $tmp, $tmp2)) 
$tmp=$tmp2[1];
  else
$tmp='';

  if (!empty($tmp)) {
$background = 
"background=\"getpart.phtml?1get_type=1&part_id=".rawurlencode(ereg_replace("\"", '', 
$tmp))."\"";
  } else $background = '';

};  

$c = count($ref->parts);
for ($p=0; $p<$c; $p++) {
  if (empty($ofs)) $of = ''.($p+1); else $of = $ofs.'.'.($p+1);
  parseparts($ref->parts[$p], $of);
};
  };
  // Get info on each parts

  parseparts($msg_struct);


Previous Comments:
---

[2001-04-01 13:34:29] [EMAIL PROTECTED]
As I can not reproduce this with latest CVS please try
the latest snapshot from http://snaps.php.net/

And if happens with it too, create one 
short but self-containing script which can be used
to reproduce this anywhere without modifications
and add it into this bug report.

--Jani


---

[2001-03-29 12:57:01] [EMAIL PROTECTED]
When i said ONCE - i didnt mean ONCE :)
It ALWAYS happen in the code referred...

---

[2001-03-29 12:55:32] [EMAIL PROTECTED]
Its not easy reproduceable - i have only seen this happens ONCE - in the specified 
function. Its NOT a simple for-loop - the for-loop executes INSIDE a recursively 
called function.

I've also tried this one :
---
$c = count($myarray);
if ($c>0) {
  echo "c is greater than 0";
  for (...) {
...code
  }
}
---
then IF c is 0 the echo statement doesnt execute BUT the for loop executes...

I cant figure out why...

If some of you want it i can mail you the file so you can see the things in 
perspective.

- Svein

---

[2001-03-29 11:55:23] [EMAIL PROTECTED]
I can't reproduce this (using code below):



Could you try this one?
And note: If the variable passed to count() is not an array,
it will return 1.

--Jani


---

[2001-03-27 11:09:08] [EMAIL PROTECTED]
The code submitted is inside a function that is called recursively and its not exact 
copy of the code.

I've also tried to change the for loop to a while loop with the same result.

---

The remainder of the comments for this report are too long.  To view the re

Re: [PHP-DEV] Re: ; arg seperator

2001-04-04 Thread Jani Taskinen

On Wed, 4 Apr 2001, Alexander Bokovoy wrote:

>> Why do you see it as a problem? They should be doing their own
>> releases after our releases. ie. They should say that this version
>> works with PHP 4.0.5. People should know that when they get
>> the bleeding edge..it might not work at all.. There have been also
>> other changes (e.g. in Zend) which might break those extensions.
>> So I don't really see this renaming as a big problem.

>I'm not against renaming, I'm warning that CVS and release version
>will use different macros so extensions will be in trouble till next
>release based on HEAD branch.

And again: The people releasing external extensions should make a releases
for certain versions of PHP/Zend as it still is a moving target. IMNSHO.

[..]
>If so, why this change didn't find its way into PHP_4_0_5 branch? It was
>done a week ago, at the time of ~ RC3 I think.

So you think we should break the configure now when the release date
is so close? Umm..I really don't understand how THAT would be a good thing
to do. I think it's better to give the developers of those extensions
enough time to make the necessary changes into their code before a PHP
with changed configure is released.

Or are you saying that we should break everything in 4.0.5-BOOM ? :)
(could we have some nice 'codenames' for the releases? Please.. :)

--Jani


-- 
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] PHP 4.0 Bug #10147 Updated: DrWatson make a dump when stopping apache service

2001-04-04 Thread sniper

ID: 10147
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Reproduceable crash
Assigned To: 
Comments:

See last note on #9785 which says that it's fixed in Apache
CVS. So the fix didn't make it into 1.3.19 but will be in 1.3.20. So you just have to 
get Apache CVS version or wait
for next release.

--Jani



Previous Comments:
---

[2001-04-03 20:59:47] [EMAIL PROTECTED]
Despite previous bug reports that say this is an Apache bug that has been fixed, I 
still get this problem with Apache 1.3.19

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10147&edit=2


-- 
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] PHP 4.0 Bug #10152 Updated: Success Warning with readfile("http://...");

2001-04-04 Thread sniper

ID: 10152
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: *Directory/Filesystem functions
Assigned To: 
Comments:

I tried your example script but that host must be some
internal one? Anyway I think this is fixed in latest CVS.
Please try a snapshot from http://snaps.php.net/

--Jani


Previous Comments:
---

[2001-04-04 04:51:03] [EMAIL PROTECTED]
[1. Script Code]
http://opachost.ub.uni-marburg.de/cgi-bin/nph-wwwp3?DB=BES2.SYS8&LANG=
DU&EXT=OFF&CMD=f+kls+6+16");
?>

[2. configure-line]
./configure --with-mysql --with-apxs=/usr/local/apache/bin/apxs

[3. Output]
Warning:
readfile("http://opachost.ub.uni-marburg.de/cgi-bin/nph-wwwp3?DB=BES2.SYS8&LANG=DU&EXT=OFF&CMD=f+kls+6+16")

 - Erfolg in /herder1/httpd/html/php/sys_idx0.php on line 2

As you can see, instead of redirecting the output of "readfile" to STDOUT,
the script produces a "success warning". As far as I can see, there are
no real errors in the script. Do you have an idea of how to make the
redirection work?

Thank you very much!

Yours,

Stefan Aumann



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10152&edit=2


-- 
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] PHP 4.0 Bug #10150 Updated: Error when compiling Apache 1.3.14+SSL with static PHP4.0.4

2001-04-04 Thread sniper

ID: 10150
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Compile Failure
Assigned To: 
Comments:

Could you please try the latest CVS snapshot from http://snaps.php.net/
as there have been some fixes regarding this.
(and just use the configure line without any LIBS defined)

--Jani


Previous Comments:
---

[2001-04-04 01:47:26] [EMAIL PROTECTED]
When compiling apache 1.3.14 (with apache-ssl patches applied) and php 4.0.4 (Static) 
I get the following results:


<...snip...>
gcc  -DLINUX=2 -DTARGET="httpsd" -I/data/apache/php-4.0.4 
-I/data/apache/php-4.0.4/main -I/data/apache/php-4.0.4/main 
-I/data/apache/php-4.0.4/Zend -I/data/apache/php-4.0.4/Zend 
-I/data/apache/php-4.0.4/TSRM -I/data/apache/php-4.0.4/TSRM -I/data/apache/php-4.0.4 
-DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED -DAPACHE_SSL `./apaci`
  -o httpsd buildmark.o modules.o modules/standard/libstandard.a 
modules/ssl/libssl.a modules/php4/libphp4.a main/libmain.a ./os/unix/libos.a 
ap/libap.a  lib/expat-lite/libexpat.a -lnss_dns -rdynamic -Lmodules/php4 
-L../modules/php4 -L../../modules/php4 -lmodphp4  -lpam -lc-client  -ldl -lresolv -lm 
-ldl -lcrypt -lnsl  -lresolv   -lm -L/usr/local/ssl/lib -lssl -lcrypto
modules/php4/libphp4.a(dns.lo): In function `php_if_checkdnsrr':
/data/apache/php-4.0.4/ext/standard/dns.c:200: undefined reference to `__res_search'
<...snip...>

I saw a similar problem reported (bug# 4739) but as you can see above, I attempted to 
run configure with the 'EXTRA_LIBS="-lnss_dns" and still no luck. (Actually the 
configure script reported that EXTRA_LIBS was deprecated and should be replaced with 
simply LIBS so thats what I did.)


Any suggestions?

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10150&edit=2


-- 
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] PHP 4.0 Bug #10126 Updated: ASP can't working

2001-04-04 Thread phildriscoll

ID: 10126
Updated by: phildriscoll
Reported By: [EMAIL PROTECTED]
Status: Suspended
Bug Type: IIS related
Assigned To: 
Comments:

Actually, I suspect it's just the usual ISAPI thing - the PHP ISAPI module has brought 
IIS to it's knees and hence ASP has stopped working.

Previous Comments:
---

[2001-04-04 05:51:22] [EMAIL PROTECTED]
Suspended until someone finds out why this happens.
(could it be the asp tags in php.ini?)

--Jani


---

[2001-04-03 23:45:04] [EMAIL PROTECTED]
ok it can be work!now.

---

[2001-04-03 03:47:39] [EMAIL PROTECTED]
Please reinstall PHP as a CGI rather than as an ISAPI filter/module and let us know if 
your ASP starts working ok again.

As stated in the installation notes, the ISAPI module is currently not ready for 
production use - and this it the kind of problem it currently causes.

---

[2001-04-02 22:16:32] [EMAIL PROTECTED]
user for win2000+php+iis+asp,if install the php4.0.4pl1-Win32  the asp can't work.if 
uninstall php4.0.4pl1.the asp can working. 

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10126&edit=2


-- 
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] PHP 4.0 Bug #10126 Updated: ASP can't working

2001-04-04 Thread sniper

ID: 10126
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Suspended
Bug Type: IIS related
Assigned To: 
Comments:

Suspended until someone finds out why this happens.
(could it be the asp tags in php.ini?)

--Jani


Previous Comments:
---

[2001-04-03 23:45:04] [EMAIL PROTECTED]
ok it can be work!now.

---

[2001-04-03 03:47:39] [EMAIL PROTECTED]
Please reinstall PHP as a CGI rather than as an ISAPI filter/module and let us know if 
your ASP starts working ok again.

As stated in the installation notes, the ISAPI module is currently not ready for 
production use - and this it the kind of problem it currently causes.

---

[2001-04-02 22:16:32] [EMAIL PROTECTED]
user for win2000+php+iis+asp,if install the php4.0.4pl1-Win32  the asp can't work.if 
uninstall php4.0.4pl1.the asp can working. 

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10126&edit=2


-- 
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] PHP 4.0 Bug #10153: Resource lost on the way..

2001-04-04 Thread romolo

From: [EMAIL PROTECTED]
Operating system: linux
PHP version:  4.0 Latest CVS (04/04/2001)
PHP Bug Type: PostgreSQL related
Bug description:  Resource lost on the way..

Executing this script generate the error:
Warning: 1 is not a valid PostgreSQL link resource in test.php on line 24
The main problem is that adding a little bit of code to php source to printout the 
refcount of the resource just after the pg_connect get executed and zend_list_addref 
get called 
and just before the pg_exec get really executed i obtain the output at the end of the 
script, please not how refcount magically decrease between the pg_connect and the 
pg_exec.

The script...
";

$db=pg_connect("dbname=test");
$res1=pg_exec($db,"SELECT * from tbltest");
echo "2 ".$db."";
pg_close($db);

$db=pg_connect("dbname=test");
$res1=pg_exec($db,"SELECT * from tbltest");
echo "3 ".$db."";
pg_close($db);

$db=pg_connect("dbname=test");
$res1=pg_exec($db,"SELECT * from tbltest");
echo "4 ".$db."";
pg_close($db);

pg_close($db1);

?>

The output:

Warning: Refcount 2 in /usr/local/httpd/htdocs/test.php on line 6
1 Resource id #1
Warning: Refcount 3 in /usr/local/httpd/htdocs/test.php on line 9
Warning: Refcount 3 in /usr/local/httpd/htdocs/test.php on line 10
2 Resource id #1
Warning: Refcount 3 in /usr/local/httpd/htdocs/test.php on line 14
Warning: Refcount 3 in /usr/local/httpd/htdocs/test.php on line 15
3 Resource id #1
Warning: Refcount 3 in /usr/local/httpd/htdocs/test.php on line 19
Warning: Refcount 2 in /usr/local/httpd/htdocs/test.php on line 20
4 Resource id #1
Warning: 1 is not a valid PostgreSQL link resource in
   /usr/local/httpd/htdocs/test.php on line 24



-- 
Edit Bug report at: http://bugs.php.net/?id=10153&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]




  1   2   >