Re: [PHP-DEV] PHP 4.0 Bug #9136 Updated: simple script with infinitefunction calls causes seg fault

[Derick Rethans]

On Wed, 7 Feb 2001, Boian Bonev wrote:

> hi,
>
> indeed it is theoretically impossible to track this :)
>
> implement a recursive alrorithm for something e.g.:
>
> function foo($n) { // calc $n!
> if ($n<=1)
> return $n;
> else
> return foo($n-1)*$n;
> }
>
> now tell me if it is infinite or finite? ;-) this is a verification and
> cannot be solved runtime.
>
> the best thing that can be done is to set a stack limit (php function call
> level) to something reasonable and thus avoid the segfault.

This gives a problem itself, how many levels before the stack is full? Not
every function call has the same memory footprint, so you can't tell after
how many levels the stack is full.

Derick Rethans

-
  PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
 H.v. Tussenbroekstraat 1 - 6952 BL Dieren - The Netherlands
-


-- 
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@lists.php.net

[Ron Chmara]

Toby Butzon wrote:
> 
> Another possibility :) Would require a bit of shifting things around,
> which could be quite a bit of a disturbance.
> 
> I have a get-to-the-root-of-it-all sort of question: Is the problem that
> it's too hard to combat spam or that the people in charge of the lists
> don't have time to really get into it?

Yes.

:-)

I've been fighting SPAM for years, and it's hard to find a balance that
works. Example:
Subject: Make Million$$$
vs.
Subject: My Make Million$$$ PHP site has a mysql problem.

In between the two is a good balance, but I know that many conventional methods
of spam filtering will block out valid users, valid domains, and valid
email. Many PHP users are working in "grey" areas, do we kick them out?

What if some spammer realizes that email from a user named
"rasmus" always gets through? Or that by having a forged IP allows
broadcasting? Or that as long as they change the subject line, or
"subscribe" for the 10 seconds it takes to broadcast email, or, or...

It's the same SPAM fight everybody's been doing, and there is no perfect
answer.

-Bop

--
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not necessarily those of myself,
my employers, or any of the other little voices in my head.

-- 
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] wrong implementation of isset()?

[Ron Chmara]

André Langhorst wrote:
> > Perhaps, in order to maintain compatibility, we should re-document is_set,
> > create the documentation for is_null, and look into creating a new function
> > that will determine if something has "ever been inside the namespace", regardless
> > of its current value, or absence of value.
> we should just define (and document) this similar to Andrei (note, I do
> not use the word "the same" I use that word equal, what means different
> things):
> NULL  equals  absence_of_value  equals  absence_of_variable_in_namespace
> I can imagine no case where people would need to differentiate between
> NULL and never been in namespace

(Disclaimer: I think much of this is a bit silly, as it all can be
worked around, or people can avoid using NULL... but for the sake of
those who believe "NULL" should be a value)

Here's a possible case for this:
You have three forms. Each uses differently named variables.
All three post to the same page. One way a user might try to code
for this is:
if (isset($HTTP_POST_VARS[var_only_from_form_one]){ include ("foo");}
if (isset($HTTP_POST_VARS[var_only_from_form_two]){ include ("bar");}

Or using "has_ever-been_a_var" to do the same thing. Now, if one of those var's
has been assigned NULL somehow, their logic breaks, even though the var is
actually there, and has been set with something they consider a "value".

In a more interesting fashion, it adds a possible security feature,
where folks could actually error out their scripts if a user tried
to _introduce_ a faked variable, because it wasn't "supposed to be
there" under the current conditions, or at all. By walking the var arrays,
and checking against the expected vars, a user could send a security
warning if sombody was hacking a URL or faking a form the obvious
case I can think of is folks adding "debug=1" somehow.

-Ronabop

--
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not necessarily those of myself,
my employers, or any of the other little voices in my head.

-- 
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 #9142: Charset error

[wkittiph]

From: [EMAIL PROTECTED]
Operating system: Linux and Windows
PHP version:  4.0.4pl1
PHP Bug Type: MySQL related
Bug description:  Charset error

With PHP4.0.4pl1 error like this
Warning: MySQL Connection Failed: Can't initialize character set 18 (path: default)


But with PHP4.0.3pl1 everything clear no error

I use MySQL with default-character-set=tis620 


-- 
Edit Bug report at: http://bugs.php.net/?id=9142&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 #9140 Updated: mysql_fetch_array($query, MYSQL_ASSOC) returns assoc AND num indexes

[kbertone]

ID: 9140
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: MySQL related
Description: mysql_fetch_array($query, MYSQL_ASSOC) returns assoc AND num indexes

OK.  Thanks.  Got mysql_fetch_assoc() to work.  Now not sure that 
mysql_fetch_array($query, MYSQL_ASSOC) is really broken.  So I will try to close this 
ticket.

Previous Comments:
---

[2001-02-07 00:10:07] [EMAIL PROTECTED]
well then, what about mysql_fetch_assoc()?

---

[2001-02-07 00:08:01] [EMAIL PROTECTED]
Thanks for quick response.  No, can't upgrade (running on web hosting service).  

---

[2001-02-07 00:04:40] [EMAIL PROTECTED]
cannot reproduce it with yesterday CVS snapshot. can you upgrade? try 4.0.4 pl1 or 
http://snaps.php.net/

---

[2001-02-07 00:02:06] [EMAIL PROTECTED]
mysql_fetch_array($query, MYSQL_ASSOC) seems to return BOTH the numerical AND the 
associative indexes (should only return associative). Have tried 
mysql_fetch_assoc($query) and I get the same problem.  Running PHP 4.0.4 on both Unix 
and Windows and problem appears on both.  Am I crazy?

---


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


-- 
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 #9141: cannot call a COM function opening a word appli

[shashank . kadge]

From: [EMAIL PROTECTED]
Operating system: windows NT
PHP version:  4.0.3pl1
PHP Bug Type: COM related
Bug description:  cannot call a COM function opening a word appli

This is the COM function being called from PHP.


Public Function setFile(filename as String)
Set wproc = CreateObject("Word.Application")
wproc.Visible = False
wproc.Documents.Open (filename)
str1 = Mid(filename, 1, Len(filename) - 3) & "txt"
wproc.ActiveDocument.SaveAs str1, wdFormatText
wproc.Quit
End Function

The error message popped is Invoke failed exception in the line where function is 
called.


-- 
Edit Bug report at: http://bugs.php.net/?id=9141&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 #9140 Updated: mysql_fetch_array($query, MYSQL_ASSOC) returns assoc AND num indexes

[cynic]

ID: 9140
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: MySQL related
Assigned To: 
Comments:

well then, what about mysql_fetch_assoc()?

Previous Comments:
---

[2001-02-07 00:08:01] [EMAIL PROTECTED]
Thanks for quick response.  No, can't upgrade (running on web hosting service).  

---

[2001-02-07 00:04:40] [EMAIL PROTECTED]
cannot reproduce it with yesterday CVS snapshot. can you upgrade? try 4.0.4 pl1 or 
http://snaps.php.net/

---

[2001-02-07 00:02:06] [EMAIL PROTECTED]
mysql_fetch_array($query, MYSQL_ASSOC) seems to return BOTH the numerical AND the 
associative indexes (should only return associative). Have tried 
mysql_fetch_assoc($query) and I get the same problem.  Running PHP 4.0.4 on both Unix 
and Windows and problem appears on both.  Am I crazy?

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9140&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 #9140 Updated: mysql_fetch_array($query, MYSQL_ASSOC) returns assoc AND num indexes

[kbertone]

ID: 9140
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: MySQL related
Description: mysql_fetch_array($query, MYSQL_ASSOC) returns assoc AND num indexes

Thanks for quick response.  No, can't upgrade (running on web hosting service).  

Previous Comments:
---

[2001-02-07 00:04:40] [EMAIL PROTECTED]
cannot reproduce it with yesterday CVS snapshot. can you upgrade? try 4.0.4 pl1 or 
http://snaps.php.net/

---

[2001-02-07 00:02:06] [EMAIL PROTECTED]
mysql_fetch_array($query, MYSQL_ASSOC) seems to return BOTH the numerical AND the 
associative indexes (should only return associative). Have tried 
mysql_fetch_assoc($query) and I get the same problem.  Running PHP 4.0.4 on both Unix 
and Windows and problem appears on both.  Am I crazy?

---


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


-- 
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 #9140 Updated: mysql_fetch_array($query, MYSQL_ASSOC) returns assoc AND num indexes

[cynic]

ID: 9140
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: MySQL related
Assigned To: 
Comments:

cannot reproduce it with yesterday CVS snapshot. can you upgrade? try 4.0.4 pl1 or 
http://snaps.php.net/

Previous Comments:
---

[2001-02-07 00:02:06] [EMAIL PROTECTED]
mysql_fetch_array($query, MYSQL_ASSOC) seems to return BOTH the numerical AND the 
associative indexes (should only return associative). Have tried 
mysql_fetch_assoc($query) and I get the same problem.  Running PHP 4.0.4 on both Unix 
and Windows and problem appears on both.  Am I crazy?

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9140&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 #9140: mysql_fetch_array($query, MYSQL_ASSOC) returns assoc AND num indexes

[kbertone]

From: [EMAIL PROTECTED]
Operating system: Unix and Windows
PHP version:  4.0.4
PHP Bug Type: MySQL related
Bug description:  mysql_fetch_array($query, MYSQL_ASSOC) returns assoc AND num indexes

mysql_fetch_array($query, MYSQL_ASSOC) seems to return BOTH the numerical AND the 
associative indexes (should only return associative). Have tried 
mysql_fetch_assoc($query) and I get the same problem.  Running PHP 4.0.4 on both Unix 
and Windows and problem appears on both.  Am I crazy?


-- 
Edit Bug report at: http://bugs.php.net/?id=9140&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: Dear Friends & Future Millionaire:

[Rasmus Lerdorf]

This might be workable.  I fear Sascha's solution could be rather prone to
mistakes, and it would slow down list delivery for everyone.  Requiring
approval for non-list members is a hassle for them, but if enough people
are willing to be on the receiving end of these messages to be approved it
probably wouldn't be too bad.  We just need to figure out how to do this
with ezmlm.

-Rasmus

On Tue, 6 Feb 2001, Stephen van Egmond wrote:

> Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
> > What we are not interested in is stopping people who are not subscribed to
> > the lists directly from participating.  A lot of people read the lists via
> > nntp or through various web gateways.  You can rant all you want about the
> > spam, but until you come up with a workable way to not cut off these
> > people there isn't much point.
>
> Understandable.
>
> Listar (the one I'm familiar) will send posts that aren't classified as
> spam, but still from non-members, to moderators.  Depending on your
> mailer, one keypress ("bounce this to [EMAIL PROTECTED]")
> will approve the post and send it out. This can be tweaked to
> auto-approve future posts from that person.
>
> /Steve
>
>


-- 
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] The library yes/lib does not exist

[Boian Bonev]

hi,

i've seen the same really soon and could track it:


checking for DOM support... yes
checking for DOM in default path... found in /usr/local
checking for libxml version... >= 2.2.7
- ac_add_library_path /usr/local/lib

 -lxml -ldb -lgdbm -lcurl -lbz2 -lssl -lcrypto -lresolv -lm -ldl -lcrypt
 -lnsl -lresolv
checking for libz needed by libxml ... already zlib support
--- -lxml -ldb -lgdbm -lcurl -lbz2 -lssl -lcrypto -lresolv -lm -ldl -lcrypt 
-lnsl -lresolv -Lyes/lib -lz
checking whether to enable exif support... no



the --- is debug echo from ext/domxml/config.m4:

withval=$old_withval
  else
echo  $LIBS
echo "checking for libz needed by libxml ... already zlib support"
LIBS="$LIBS -L$withval/lib -lz"
echo --- $LIBS
  fi

  AC_DEFINE(HAVE_DOMXML,1,[ ])
  AC_ADD_LIBRARY(z)



b.

- Original Message -
From: "Sascha Schumann" <[EMAIL PROTECTED]>
To: "Derick Rethans" <[EMAIL PROTECTED]>
Cc: "PHP Developers Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, February 07, 2001 1:30 AM
Subject: Re: [PHP-DEV] The library yes/lib does not exist


> On Wed, 7 Feb 2001, Derick Rethans wrote:
>
> > On Wed, 7 Feb 2001, Sascha Schumann wrote:
> >
> > > Please post your full configure line.
>
> Ok, those are quite a lot entries.  Did you add one recently?
> When did you see that kind of error for the first time?  Did
> you change anything related to those third party libraries in
> your system?
>
> - Sascha
>
>
> --
> 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] Re: [PHP-PEAR] Re: [PHP-DEV] Re: Dear Friends & Future Millionaire:

[Toby Butzon]

Another possibility :) Would require a bit of shifting things around,
which could be quite a bit of a disturbance.

I have a get-to-the-root-of-it-all sort of question: Is the problem that
it's too hard to combat spam or that the people in charge of the lists
don't have time to really get into it? 

Don't get me wrong on this; I'm not trying to say anybody's slouching or
anything. I know from my personal experience though that things can just
get to be too much. Perhaps the task of fixing the problem could be
given to a few people as a group, let them discuss it, come up with a
good, workable plan, and present it to php-dev or some such and then let
them implement it if everybody likes the plan.

-toby

Stephen van Egmond wrote:
> 
> Toby Butzon ([EMAIL PROTECTED]) wrote:
> > Although I agree, I don't think it's ever going to happen. Somehow, the
> > head PHP folks don't seem to be too interested in combatting spam; I
> > brought up the discussion a few weeks ago and was met with strong
> > resistance.
> >
> > Maybe when the list gets to be 20% spam they'll listen. It _is_ steadily
> > getting to be more and more as time progresses.
> 
> I operate mailing lists using the listar package, available for debian
> and other Unices.
> 
> It can reject, out-of-the-box, mail based on
> * grepping headers for regular expressions
> * requiring people be in the user database
> 
> Users in the database usually have the "echpost" flag - meaning send
> them copies of posts.  But if you turn off echopost (e.g. for an
> account you want to post from but not receive posts to), you're
> completely set.
> 
> You're right that this has to be something that list gods care enough
> about to fix. Given the attitude toward bug mailings, you're probably right.
> 
> /Steve
> 
> --
> PHP Extension and Add-on Repository (PEAR) mailing list.
> Documentation can be found at http://pear.php.net/doc/pear.html
> To unsubscribe, e-mail: [EMAIL PROTECTED] from the
> mail address you subscribed with.

-- 
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: Dear Friends & Future Millionaire:

[Toby Butzon]

Sascha Schumann wrote:
> 
> On Tue, 6 Feb 2001, Toby Butzon wrote:
> 
> > Although I agree, I don't think it's ever going to happen. Somehow, the
> > head PHP folks don't seem to be too interested in combatting spam; I
> > brought up the discussion a few weeks ago and was met with strong
> > resistance.
> 
> You'd be surprised to learn how many anti-spam measures we

> - Sascha

Now there's an idea I like a great deal.

General list members may wish to stop reading here; what follows is an
explaination (mostly to Rasmus, but also possibly of general interest)
for what Rasmus sees as "rants" and not workable ways to combat spam.

You see, Rasmus, the problem is: I don't have any knowledge of how the
PHP list system operates. The idea here that Sascha has proposed is
something that I could've never proposed because I didn't even know
there was a php3 mailing list. Hell, for that matter, if we really
needed to (and php3 was still an active list), we could create a decoy
list specifically for that purpose. The point is, I offerred up what I
saw as a possible solution. I am not bitter because my idea wasn't
adopted; rather, I am frustrated because I put forth some initiative
only to be shot down.

The way I see it, this problem cannot be impossible. There's a known
behavior that we don't want; what we need is a way to prevent it. It
only seems logical to me that someone without the knowledge of how the
"black box" that the list server is to me wouldn't be able to offer up
much of a solution - only precursory suggestions. So how come instead of
being given a little more information about fixing the problem I was
given a "No, that won't work. Period."? Now it seems maybe Sascha has
found a solution for the problem. I'm glad - we might be making progress
again. I'm anxious to hear what others have to say.

On a more general note pertaining to my personal philosophy, I
completely subscribe to the principle of suggesting an alternative
instead of just complaining. You'd be surprised at how many things I've
wished were different sometimes, but I try to keep my mouth shut unless
I can also propose a fix. I proposed all I knew how to propose,
including making posting to the list a priveledge of subscribers only. I
also tried to help form the basis of workarounds that could be
implemented to keep newsgroup-based posting viable. In short, I'm only
trying to help, and I'm only trying to help in a constructive, helpful
manner.

I give my apologies if my suggestions aren't taken as such. However, I
will continue to offer my opinion & suggestions on this and other
matters with the hope that at some point I will not be looked upon as
just another whining, ranting complainer.

--toby

-- 
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: Dear Friends & Future Millionaire:

[Stephen van Egmond]

Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
> What we are not interested in is stopping people who are not subscribed to
> the lists directly from participating.  A lot of people read the lists via
> nntp or through various web gateways.  You can rant all you want about the
> spam, but until you come up with a workable way to not cut off these
> people there isn't much point.

Understandable.

Listar (the one I'm familiar) will send posts that aren't classified as
spam, but still from non-members, to moderators.  Depending on your
mailer, one keypress ("bounce this to [EMAIL PROTECTED]")
will approve the post and send it out. This can be tweaked to
auto-approve future posts from that person.

/Steve



-- 
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: Dear Friends & Future Millionaire:

[Stephen van Egmond]

Toby Butzon ([EMAIL PROTECTED]) wrote:
> Although I agree, I don't think it's ever going to happen. Somehow, the
> head PHP folks don't seem to be too interested in combatting spam; I
> brought up the discussion a few weeks ago and was met with strong
> resistance.
> 
> Maybe when the list gets to be 20% spam they'll listen. It _is_ steadily
> getting to be more and more as time progresses.

I operate mailing lists using the listar package, available for debian
and other Unices.

It can reject, out-of-the-box, mail based on
* grepping headers for regular expressions
* requiring people be in the user database

Users in the database usually have the "echpost" flag - meaning send
them copies of posts.  But if you turn off echopost (e.g. for an
account you want to post from but not receive posts to), you're
completely set.

You're right that this has to be something that list gods care enough
about to fix. Given the attitude toward bug mailings, you're probably right.

/Steve

-- 
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 #9139: Broken link from your website

[bhiggins]

From: [EMAIL PROTECTED]
Operating system: Your webserver
PHP version:  4.0.4pl1
PHP Bug Type: Unknown/Other Function
Bug description:  Broken link from your website

when visiting http://php.net/manual/en/install-windows95-nt.php, the 
http://www.umesd.k12.or.us/php/win32install.html link does not work FYI.


-- 
Edit Bug report at: http://bugs.php.net/?id=9139&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 #9044 Updated: Compiling with latest Openlink ODBC fails with PHP4

[antiphobo]

ID: 9044
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Compile Failure
Description: Compiling with latest Openlink ODBC fails with PHP4

Copied contents of /ext/odbc/ of PHP404sp1 and tried compiling this with PHP403sp1 ... 
Compile fine; but Driver Not Capable error continues.

Previous Comments:
---

[2001-02-03 14:49:56] [EMAIL PROTECTED]
Allegedly PHP404sp1 fixes this Openlink problem ... but see bug id 
http://bugs.php.net/?id=9088&edit=1 for why i couldnt get PHP404sp1 to work with 
apache :(

---

[2001-02-01 17:44:06] [EMAIL PROTECTED]
Compiling Openlink4 with PHP 403sp1 and Apache 1.3.12 using the custom iodbc.h file I 
have included WORKS "FINE":

as in 
 - it compiles without errors
 - has warning: `SQL_LEN_DATA_AT_EXEC' redefined
 - produces a fully PHP-functional apache webserver

I still cannot manage to properly communicate to talbles using Openlink4, however, I 
recieve:

SQL error: [OpenLink][ODBC][Driver]Syntax error or access, SQL state 37000 in 
SQLExecDirect for complex selects such as "SELECT TOP 10 RECORD_NR, StatusField, 
ExtendedStatusField, PICTURE, SURNAME, FIRSTNAME, FORM, DOB, DESTINATION, EXPIRY FROM 
(SELECT TOP 10 * FROM WELLGIRLS ORDER BY RECORD_NR ASC,RECORD_NR ASC) ORDER BY 
RECORD_NR DESC,RECORD_NR DESC"

and for simple selects "SELECT * FROM TABLENAME", i get 

Warning: SQL error: [OpenLink][ODBC][Driver]Driver not capable, SQL state S1C00 in 
SQLExecDirect in /home/sites/home/web/current/Admin/admin_odbcsetup.php on line 125

The battle continues ... 

- Siggy

---

[2001-02-01 16:16:49] [EMAIL PROTECTED]
Modified Openlink3.2 iodbc.h so that it could be used with openlink4:

contents of /usr/local/openlink/odbcsdk/include/iodbc.h now:
##

#ifndef _CONFIG_H
#define _CONFIG_H

# if!defined(WINDOWS) && !defined(WIN32_SYSTEM)
#  define   _UNIX_

#  include  
#  include  

#  define   MEM_ALLOC(size) (malloc((size_t)(size)))
#  define   MEM_FREE(ptr)   {if(ptr) free(ptr);}

#  define   STRCPY(t, s)(strcpy((char*)(t), (char*)(s)))
#  define   STRNCPY(t,s,n)  (strncpy((char*)(t), (char*)(s), (size_t)(n)))
#  define   STRCAT(t, s)(strcat((char*)(t), (char*)(s)))
#  define   STRNCAT(t,s,n)  (strncat((char*)(t), (char*)(s), (size_t)(n)))
#  define   STREQ(a, b) (strcmp((char*)(a), (char*)(b)) == 0)
#  define   STRLEN(str) ((str)? strlen((char*)(str)):0)

#  define   EXPORT
#  define   CALLBACK
#  define   FAR


# endif /* _UNIX_ */

# ifdefined(WINDOWS) || defined(WIN32_SYSTEM)

#  include  
#  include  

#  ifdef_MSVC_
#   define  MEM_ALLOC(size) (fmalloc((size_t)(size)))
#   define  MEM_FREE(ptr)   ((ptr)? ffree((PTR)(ptr)):0))
#   define  STRCPY(t, s)(fstrcpy((char FAR*)(t), (char FAR*)(s)))
#   define  STRNCPY(t,s,n)  (fstrncpy((char FAR*)(t), (char FAR*)(s), 
(size_t)(n)))
#   define  STRLEN(str) ((str)? fstrlen((char FAR*)(str)):0)
#   define  STREQ(a, b) (fstrcmp((char FAR*)(a), (char FAR*)(b) == 0)
#  endif

#  ifdef_BORLAND_
#   define  MEM_ALLOC(size) (farmalloc((unsigned long)(size))
#   define  MEM_FREE(ptr)   ((ptr)? farfree((void far*)(ptr)):0)
#   define  STRCPY(t, s)(_fstrcpy((char FAR*)(t), (char FAR*)(s)))
#   define  STRNCPY(t,s,n)  (_fstrncpy((char FAR*)(t), (char FAR*)(s), 
(size_t)(n)))
#   define  STRLEN(str) ((str)? _fstrlen((char FAR*)(str)):0)
#   define  STREQ(a, b) (_fstrcmp((char FAR*)(a), (char FAR*)(b) == 0)
#  endif

# endif /* WINDOWS */

# defineSYSERR  (-1)

# ifndefNULL
#   define  NULL((void FAR*)0UL)
# endif

#endif

##

Compiled OK(version 404sp1); './configure' '--with-openlink=/usr/local/openlink' 
'--with-mysql' '--with-apache=../apache_1.3.17' '--enable-track-vars' 

Caused This WARNING when make-ing: 

make[3]: Entering directory `/tmp/php-4.0.4pl1/ext/odbc'
gcc  -I. -I/tmp/php-4.0.4pl1/ext/odbc -I/tmp/php-4.0.4pl1/main -I/tmp/php-4.0.4pl1 
-I/tmp/apache_1.3.17/src/include -I/tmp/apache_1.3.17/src/os/unix 
-I/tmp/php-4.0.4pl1/Zend -I/tmp/php-4.0.4pl1/ext/mysql/libmysql 
-I/usr/local/openlink/odbcsdk/include -I/tmp/php-4.0.4pl1/ext/xml/expat/xmltok 
-I/tmp/php-4.0.4pl1/ext/xml/expat/xmlparse -I/tmp/php-4.0.4pl1/TSRM  
-DXML_BYTE_ORDER=12 -g -O2  -c php_odbc.c && touch php_odbc.lo
In file included from php_odbc.h:128,
 from php_odbc.c:31:
/usr/local/openlink/odbcsdk/include/udbcext.h:47: warning: `SQL_LEN_DATA_AT_EXEC' 
redefined
/usr/local/openlink/odbcsdk/include/sqlext.h:250: warning: this is the location of the 
p

Re: [PHP-DEV] PHP 4.0 Bug #9136 Updated: simple script with infinite function calls causes seg fault

[Boian Bonev]

hi,

indeed it is theoretically impossible to track this :)

implement a recursive alrorithm for something e.g.:

function foo($n) { // calc $n!
if ($n<=1)
return $n;
else
return foo($n-1)*$n;
}

now tell me if it is infinite or finite? ;-) this is a verification and
cannot be solved runtime.

the best thing that can be done is to set a stack limit (php function call
level) to something reasonable and thus avoid the segfault.

b.

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, February 07, 2001 12:31 AM
Subject: [PHP-DEV] PHP 4.0 Bug #9136 Updated: simple script with infinite
function calls causes seg fault


> ID: 9136
> Updated by: waldschrott
> Reported By: [EMAIL PROTECTED]
> Status: Closed
> Bug Type: Reproduceable crash
> Assigned To: waldschrott
> Comments:
>
> and guess this "bug" was present in any version before, what
> do you expect to happen here? you will never leave these
> function calls (as you know I guess), as far as your stack
> is full it is full
>
> remember php has to remember each and every function call it
> did...
>
> a()
>b()
>   a()
>  b()
>
>
> if you really need exactly this construct, I would suggest
> you to use a static variable to count the total function
> calls and find the critical values a specific system
> segfaults (with your original code), then you stick a
> for(;;) around it and implement a check (eg. in a()) against
> the static variable to leave the recursion if a value with
> enough distance to the critical value is reached, then you
> should be able to begin the recursion again
>
> any recursion can be displayed as a loop, do not use
> recursion if you want to recurse infinitely
>
> Previous Comments:
> --
-
>
> [2001-02-06 17:22:36] [EMAIL PROTECTED]
> PHP doesn't handle infinite recursion, and as earlier was discussed on the
php-dev list, it wont be implemented to guard for this, because of the high
performance impact.
>
> --
-
>
> [2001-02-06 17:18:03] [EMAIL PROTECTED]
> ---
> <%
>
> function a () {
> b();
> }
>
> function b () {
> a();
> }
>
> a();
>
> %>
>
> done
> -
>
> The simple script above causes a seg fault.  If you need more info on
configuration etc please mail me.  We made this simple example from a more
compilcated instance.  This bug was also present in 4.0.3pl1, we upgraded to
try and stop the seg fault...
>
> thanks!
>
> --
-
>
>
>
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at
http://bugs.php.net/?id=9136&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]

Re: [PHP-DEV] Re: safe_mode redesign

[Boian Bonev]

hi,

here is something i have posted some days ago:

or better if you have untrusted users who shall have php access, give
them
cgi php and use apache's exec wrapper to setuid to user's uid and chroot to
her home dir.

if their count is not too big run their own web servers under their uids and
again chrooted to their home dirs. this is the best solution i know of.

...

most of the shared hosting environments at least allow one user to access
another's files. not mentioning system access, etc.
a safe_mode will not help in these cases - like named buffer overruns a
safe_mode hole will be discovered weekly.

i am running both configs since apache1.2/php3.0.5 and except performance
issues i have seen no other drawbacks...

b.

- Original Message -
From: "Jason Greene" <[EMAIL PROTECTED]>
To: "Zeev Suraski" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, February 06, 2001 9:53 PM
Subject: [PHP-DEV] Re: safe_mode redesign


> Zeev,
>
> I understand your viewpoint, but I respectfully disagree. I believe that
there are multiple levels of security, and that the OS is
> just part of the picture. There always is some layer of application
security(especially for those apps that run id=0). If you are a
> hosting company ( which is becoming a very large business), then you
desire a way to provide your customers with a programming
> interface that does not infringe on other customers, or your systems
security. Without a safe_mode, 
> is still allowed.
>
> While the details get tricky, and sometime complex, the overall concept is
simple. Before any risky activity is performed, check the
> list of things to block. There are tons of applications out there that
perform these  kind of important checks. ProFTPD is a good
> example of one such application. It allows you to lock users into certain
areas, use specific uids etc.
>
> It seems that your biggest concern is giving users a false sense of
security. This feature is something that would not be used by
> the average user. The people who would mainly be using this would have an
ok knowledge of security, and if you have an ok knowledge,
> then you will know to Never Trust Anything
> There is always a possibility of security methods being penetrated,
everyone just has to be made aware that security is just
> something that rules out the majority of breach attempts. That is why you
need multiple levels
>
> I believe that performing something similar to a chroot in the lower level
file operations, would lock php itself into a protected
> area. PHP is very modular, and has an excellent lower level API., both of
which makes this a very possible thing.
>
> I have spent quite a bit of time customizing PHP to work well in a secure
environment, and I have seen other service providers doing
> the same thing. The problem is that ppl are still going to do this whether
its part of the codebase or not. If all of this work was
> combined, then it can be shared, repaired, and optimized by everyone.
>
> A safe programming chapter could be referred to in documentation as "An
experimental security option designed for ISP and hosting
> providers. This is by no means the finality of security, just a tool to
help
> in developing a secure environment"
>
>
> Thanks,
> Jason
>
> - Original Message --
> From: "Zeev Suraski" <[EMAIL PROTECTED]>
> To: "Jason Greene" <[EMAIL PROTECTED]>
> ACc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Sunday, February 04, 2001 6:43 AM
> Subject: Re: safe_mode redesign
>
>
> > Jason,
> >
> > The one main problem with safe_mode in general is that the idea is
> > problematic by definition.  Security outside the OS level is prone to
> > errors, and a false sense of security is much worse than knowing you're
> > insecure.
> >
> > In my opinion, safe mode should only feature features which can have an
> > infrastructure-level solution, and are not prone to errors.  There
aren't
> > too many of these.  The current safe mode implementation is extremely
prone
> > to errors because it tries to protect opened files, and the way its
built,
> > it's bound to be missing checks in many places...
> >
> > Zeev
> >
> > At 22:53 1/2/2001, Jason Greene wrote:
> > >Is anyone up for a discussion on the redesign of safe_mode? I would
like
> > >to start working on this sometime soon, and I have a lot of
> > >ideas, but I know this is going to be something of a large debate.
> > >
> > >Some of the  new features I think would benefit php include:
> > >
> > >* safe_mode_hide_env_vars - will allow extra protection on removing
> > >environmental vars from hosted users ( I actually have a patch
> > >for this but  I have been waiting on it to discuss the redesign)
> > >
> > >* User configurable policy - safe_mode could have configuration
directives
> > >to specify exactly what checks are desired
> > >
> > >* Virtual Chroot - the ability to perform a chroot to a virtual host
> > >directory structure, so that a hosted user can not access
> > >an

Re: [PHP-DEV] why doesn't list() handle associative arrays?

[Cynic]

yes, that's what I mean.

At 03:09 7.2. 2001, Lars Torben Wilson wrote the following:
-- 
>Cynic writes:
>> $a['x'] = 'one' ;
>> $a['y'] = 'two' ;
>> $a['z'] = 'three' ;
>> 
>> list( $x , $y , $z ) = $a ;
>> 
>> Warning:  Undefined offset:  2 in ...
>> Warning:  Undefined offset:  1 in ...
>> Warning:  Undefined offset:  0 in ...
>
>You mean that this:
>
>  $a['x'] = 'one';
>  $a['y'] = 'two';
>  $a['z'] = 'three';
>  list($x, $y, $z) = $a;
>
>...should work like this?
>
>  $x = current(each($a));
>  $y = current(each($a));
>  $z = current(each($a));
>
>Given that numeric indices doen't necessarily indicate element
>positions, I don't see why that your request wouldn't be reasonable.
--end of quote-- 




Cynic:

A member of a group of ancient Greek philosophers who taught
that virtue constitutes happiness and that self control is
the essential part of virtue.

[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: Dear Friends & Future Millionaire:

[Rasmus Lerdorf]

> Although I agree, I don't think it's ever going to happen. Somehow, the
> head PHP folks don't seem to be too interested in combatting spam; I
> brought up the discussion a few weeks ago and was met with strong
> resistance.
>
> Maybe when the list gets to be 20% spam they'll listen. It _is_ steadily
> getting to be more and more as time progresses.

What we are not interested in is stopping people who are not subscribed to
the lists directly from participating.  A lot of people read the lists via
nntp or through various web gateways.  You can rant all you want about the
spam, but until you come up with a workable way to not cut off these
people there isn't much point.

-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] why doesn't list() handle associative arrays?

[Lars Torben Wilson]

Cynic writes:
> $a['x'] = 'one' ;
> $a['y'] = 'two' ;
> $a['z'] = 'three' ;
> 
> list( $x , $y , $z ) = $a ;
> 
> Warning:  Undefined offset:  2 in ...
> Warning:  Undefined offset:  1 in ...
> Warning:  Undefined offset:  0 in ...

You mean that this:

  $a['x'] = 'one';
  $a['y'] = 'two';
  $a['z'] = 'three';
  list($x, $y, $z) = $a;

...should work like this?

  $x = current(each($a));
  $y = current(each($a));
  $z = current(each($a));

Given that numeric indices doen't necessarily indicate element
positions, I don't see why that your request wouldn't be reasonable.


-- 
++
|Torben Wilson <[EMAIL PROTECTED]>Adcore Finland|
|http://www.coastnet.com/~torbenhttp://www.adcore.com|
|Ph: 1.604.709.0506 [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] wrong implementation of isset()?

[Cynic]

with all respect to the people who develop the language, I 
think this is nonsense:

$rs = mysql_query( 'select x, y, z from foo where ...' ) ;
$x = mysql_fetch_array( $rs , MYSQL_NUM ) ;
var_dump( $x[2] ) ;
var_dump( isset( $x[2] ) ) ;

NULL # well, the column contains null values
bool(false) 

But since (almost) everybody else disagrees, I must be missing 
something obvious.

BTW, does $x = null really equal to unset( $x ) or does 
isset() just get fooled by its value?

At 01:55 7.2. 2001, André Langhorst wrote the following:
-- 
>>Perhaps, in order to maintain compatibility, we should re-document is_set,
>>create the documentation for is_null, and look into creating a new function
>>that will determine if something has "ever been inside the namespace", regardless
>>of its current value, or absence of value.
>
>we should just define (and document) this similar to Andrei (note, I do not use the 
>word "the same" I use that word equal, what means different things):
>
>NULL  equals  absence_of_value  equals  absence_of_variable_in_namespace
>
>I can imagine no case where people would need to differentiate between NULL and never 
>been in namespace, we should not allow this, otherwise we would introduce the 
>differentiation into a third state, non existent, what raises the wtf-factor and is 
>not required as far as I can think
>
>andré
>
>
>-- 
>· André Langhorst   · t: +49 571 3201801 ·
>· [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]
>
--end of quote-- 




Cynic:

A member of a group of ancient Greek philosophers who taught
that virtue constitutes happiness and that self control is
the essential part of virtue.

[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 #8921 Updated: Require() function : filename string not terminated correctly internally

[mahony]

ID: 8921
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Unknown/Other Function
Description: Require() function : filename string not terminated correctly internally

Work-around.
---
I've since found that the problem only manifests itself when variables are used as 
parameters to Require().
eg: 
$filename = "test.html";
require($filename);

If a string constant is used as a parameter the function performs correctly.
eg:
require("test.html");

Consequently I was able to solve my problem by using PHPs "evaluate variable within 
string" trick -
eg: 
$filename = "test.html";
require("$filename");


Previous Comments:
---

[2001-01-25 19:18:31] [EMAIL PROTECTED]
Hi,

I've found what appears to be a reproducable bug with random effects.

When I pass a seemingly perfect filename string to the Require() function it comes 
back (2 times out of 3) with extra characters at the end, causing the require function 
to fail to find the file. The characters are illustrated below, and many seem to be 
non-alphabetic. It looks like a C string buffer overflow problem (ie: the length of 
the string has been enlarged by a random amount between about 2 and 5 characters, and 
it's picking up additional characters directly out of memory).

This is the code that is executing :

if("" == $inc_filename) {
  print("You have to enter a filename first !");
}
else  // NON-Blank include filename
{
  print("Filename = ".$inc_filename);   // < Note : here the filename displays 
fine

  require( $inc_filename );   // < Note : here it is corrupted
}


These are the output lines I got  (note the crap at the end of the filename in the 
error message) :

 Filename = inc/britz/britzspg.inc
Fatal error: Failed opening required 'inc/britz/britzspg.incÿ¿ñ'  
(include_path='.:/usr/local/lib/php') in
/home/ekiwi/public_html/layout.php on line 199


  Filename = inc/britz/britzspg.inc
 Fatal error: Failed opening required 'inc/britz/britzspg.inc)y'
 (include_path='.:/usr/local/lib/php') in
/home/ekiwi/public_html/layout.php
 on line 199

 THEN IT WAS OK TWICE, followed by

 Filename = inc/britz/britzspg.inc
Fatal error: Failed opening required 'inc/britz/britzspg.inc'A'
 (include_path='.:/usr/local/lib/php') in
/home/ekiwi/public_html/layout.php
 on line 199

 Filename = inc/britz/britzspg.inc
Fatal error: Failed opening required 'inc/britz/britzspg.inc)±'
 (include_path='.:/usr/local/lib/php') in
/home/ekiwi/public_html/layout.php
 on line 199

To see this in action see : 
http://chips.cwa.co.nz:8080/display.php?FEATURE_ID=13

Be aware that it works perfectly about a third of the time, so keep pressing the 
refresh button on your browser until it throws the error. 


We're running Linux kernal 2.2.18

Our PHP config details are available at :
http://chips.cwa.co.nz/~ian/php.status.php



Hope this helps,

Simon Mahony,
Technical Director,
CWA New Media,
New Zealand.




---


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


-- 
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] why doesn't list() handle associative arrays?

[Cynic]

$a['x'] = 'one' ;
$a['y'] = 'two' ;
$a['z'] = 'three' ;

list( $x , $y , $z ) = $a ;

Warning:  Undefined offset:  2 in ...
Warning:  Undefined offset:  1 in ...
Warning:  Undefined offset:  0 in ...




Cynic:

A member of a group of ancient Greek philosophers who taught
that virtue constitutes happiness and that self control is
the essential part of virtue.

[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] wrong implementation of isset()?

[John Donagher]

On Wed, 7 Feb 2001, [ISO-8859-1] André Langhorst wrote:

> we should just define (and document) this similar to Andrei (note, I do 
> not use the word "the same" I use that word equal, what means different 
> things):
> 
> NULL  equals  absence_of_value  equals  absence_of_variable_in_namespace
> 
> I can imagine no case where people would need to differentiate between 
> NULL and never been in namespace, we should not allow this, otherwise we 
> would introduce the differentiation into a third state, non existent, 
> what raises the wtf-factor and is not required as far as I can think
> 
> andré
> 

I agree. I've watched a lot of seasoned programmers learning PHP and the
behaviour of various functions operating on NULL, 0, and '' has always had an
extremely high wtf-factor (I really like that term). Most of the former
discrepancies have been fixed, though.

Try as I might, I can't think of a good case where you'd want to check for NULL
and existance in the namespace.  

-- 

John Donagher
Application Engineer
Intacct Corp. - Powerful Accounting on the Web
408-395-0989
720 University Ave.
Los Gatos CA 95032
www.intacct.com

Public key available off http://www.keyserver.net
Key fingerprint = 4024 DF50 56EE 19A3 258A  D628 22DE AD56 EEBE 8DDD


--
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] wrong implementation of isset()?

[André Langhorst]

> Perhaps, in order to maintain compatibility, we should re-document is_set,
> create the documentation for is_null, and look into creating a new function
> that will determine if something has "ever been inside the namespace", regardless
> of its current value, or absence of value.

we should just define (and document) this similar to Andrei (note, I do 
not use the word "the same" I use that word equal, what means different 
things):

NULL  equals  absence_of_value  equals  absence_of_variable_in_namespace

I can imagine no case where people would need to differentiate between 
NULL and never been in namespace, we should not allow this, otherwise we 
would introduce the differentiation into a third state, non existent, 
what raises the wtf-factor and is not required as far as I can think

andré


-- 
· André Langhorst   · t: +49 571 3201801 ·
· [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]

Re: [PHP-DEV] Re: Dear Friends & Future Millionaire:

[Sascha Schumann]

On Tue, 6 Feb 2001, Toby Butzon wrote:

> Although I agree, I don't think it's ever going to happen. Somehow, the
> head PHP folks don't seem to be too interested in combatting spam; I
> brought up the discussion a few weeks ago and was met with strong
> resistance.

You'd be surprised to learn how many anti-spam measures we
already have in place.  Those measures effectively dropped
99.9% of spam in the past; but spammers have adopted new
methods, so we need to change as well.

I noticed that the still existing, but inactive php3 list is
always spammed in a row with active lists.  Assuming that no
legitimate email is delivered to that list, we can treat all
emails as spam and hence automatically blacklist further spam
based on certain criteria.  We can create a separate list
where a notification about that event is sent to, so that the
actions are trackable.

Existing lists would introduce a certain delay between
receiving an email and forwarding it to list members.  The
delay would increase the chance that the spam has already
been delivered to the php3 blacklist, when we perform the
pre-forwarding check for existing lists.

So, if we pursue this plan, we should continue advertising
the php3 list in prominent places where email address
harvesters will find it (list archives might do a good job at
that already).

- Sascha


-- 
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 #8361 Updated: Chinese char changed & ADODB.command,recordset can not be used

[phanto]

ID: 8361
Updated by: phanto
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: COM related
Assigned To: phanto
Comments:

fixed in cvs

you have to wait till they recompile it

Previous Comments:
---

[2001-02-04 08:25:47] [EMAIL PROTECTED]
thanks! I use WindowsMe(chinese).

I don't know which platform they used to compile php.

please let me know if you finished. thanks!

steeven

---

[2001-02-04 06:34:15] [EMAIL PROTECTED]
which operating system do you use ?

if you're using windows nt/98/95 and the sources where compiled on win2k this could be 
the reason. i fix this in the evening.

harald

---

[2001-02-04 00:33:49] [EMAIL PROTECTED]
I donwload 4.05dev from www.mm4.de, and run the following code:
Provider = "sqloledb";
$dbc->Open('DSN=starmate;Database=magway;UID=sa;PWD=');
$q="select title from css";


?>
Here is the result:

Warning: Error in php_char_to_OLECHAR() in d:apachehtdocsmagwayphorumtest.php on line 
4

Warning: Invalid ProgID: Àà×Ö·û´®ÎÞЧ[invalid class string(by me)] in 
d:apachehtdocsmagwayphorumtest.php on line 4

Fatal error: Call to undefined function: open() in d:apachehtdocsmagwayphorumtest.php 
on line 6


Please tell me what you need to know for more.

---

[2001-02-02 13:07:28] [EMAIL PROTECTED]
could someone with a chinese charset try this please.

---

[2001-01-29 17:17:27] [EMAIL PROTECTED]
this should be fixed in cvs

please try a snapshot from http://snaps.php.net and give me feedback.

---

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


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8361&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: Dear Friends & Future Millionaire:

[Toby Butzon]

Although I agree, I don't think it's ever going to happen. Somehow, the
head PHP folks don't seem to be too interested in combatting spam; I
brought up the discussion a few weeks ago and was met with strong
resistance.

Maybe when the list gets to be 20% spam they'll listen. It _is_ steadily
getting to be more and more as time progresses.

-toby

André Langhorst wrote:
> 
> Couldn't some just go and kill those spammers?
> 
> Is it possible to set rules (similar to those my mozilla takes) for the
> list?
> class a candidate would be 'SEEN'+'NATIONAL'+'TV' and the like
> 
> andré
> 
>  Original Message 
> Subject: [PHP-PEAR] Dear Friends & Future Millionaire:
> Date: Tue, 6 Feb 2001 21:36:35 +0100
> From: Hi Tech Services <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 
> AS SEEN ON NATIONAL TV:
> Making over half million dollars every 4 to 5 months from your home for
> an investment of only $25 U.S. Dollars expense one time
> THANK'S TO THE COMPUTER AGE AND THE INTERNET !
> ==
> 
> --
> 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] wrong implementation of isset()?

[Ron Chmara]

"Mark J. Hershenson" wrote:
> >> Great analysis. What about answering the question? Stanislav Malyshev
> >> said some months ago this is 'strange', see the discussion around bug
> >> 6076. Tell us at least, why this actually isn't strange.
> > By default, any unset variable has value NULL - and isset(NULL) returns
> > false to indicate that. Similarly, assigning NULL to a variable unsets
> > it.
> > -Andrei
> > * The great thing about standards is that there are so many to choose from. *
> Well, sure, isset(NULL) should return false, it's not a variable set in the
> scope. A constant(?) yes, but not a variable.
> 
> But if you set a variable at some point in a script, would it not stand to
> reason that that name is in the global/local namespace, and therefore IS
> set?

Perhaps, in order to maintain compatibility, we should re-document is_set,
create the documentation for is_null, and look into creating a new function
that will determine if something has "ever been inside the namespace", regardless
of its current value, or absence of value.

Right now, the *documentation* for isset does imply that:
$a = NULL;
isset($a); //TRUE
when this is not the case. 

Specifically, the documentation says "Returns true if a variable exists"
rather than "Returns true if a variable exists, but has not been sunsequently
assigned a value (or non-value) of NULL, and has not been unset().

-Ronabop

--
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not neccesarrily those of myself,
my  employers, or any of the other little voices in my head.

-- 
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 #9138: setlocale changes over all thought process of Apache child.

[ngaugler]

From: [EMAIL PROTECTED]
Operating system: Sun OS 5.7
PHP version:  4.0.3pl1
PHP Bug Type: Apache related
Bug description:  setlocale changes over all thought process of Apache child.

Script:


Desc:
When PHP is compiled as an Apache module, and an individual script changes the locale 
via setlocale, PHP never resets it, and the Apache child continues to run in the new 
locale.  The problem with this is the log file gets printed in a new locale, and any 
new requests coming into that individual Apache child use the same setlocale as the 
original request.  This causes problems with other PHP based scripts, as well as 
analyzing programs trying to determine the numerous locales printed in the log file. 
(ie: Jan can be ene, Jan, etc..)  Please have setlocale replaced to what it was before 
the PHP script ran, as well as any other variables that can be thought to do this when 
this is brought to your attention.  Thanks!


-- 
Edit Bug report at: http://bugs.php.net/?id=9138&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 #9136: simple script with infinite function calls causes seg fault

[Zak Greant]

Sean wrote:
> I am not really sure what we are arguing at this point...

Errr... - twitch - well... blush... sigh.

Well, I am trying to prove that I lack the basic skill to read email
correctly.
I followed the thread a bit oddly and thought that you were the original
poster.

I love things like this that keep me humble... ;)

--zak



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

RE: [PHP-DEV] PHP 4.0 Bug #9136: simple script with infinite function calls causes seg fault

[Sean R. Bright]

That's a good reason :)

> -Original Message-
> From: Anil Madhavapeddy [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 06, 2001 6:36 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] PHP 4.0 Bug #9136: simple script with infinite
> function calls causes seg fault
> 
> 
> Sean R. Bright wrote:
> >
> > Because I don't consider it a problem that needs solving.  
> I am probably
> > overlooking some notoriously famous algorithm, but I can't 
> think of a
> valid
> > reason for such functionality to exist unless someone is 
> purposely trying
> to
> > bring a system to its knees.
> >
> 
> How about ... no PHP script should ever cause the webserver 
> to segfault?
> Segfaults are bad.
> 
> Anil
> 
> 

-- 
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: safe_mode redesign

[Zeev Suraski]

At 21:53 6/2/2001, Jason Greene wrote:
>Zeev,
>
>I understand your viewpoint, but I respectfully disagree. I believe that 
>there are multiple levels of security, and that the OS is
>just part of the picture. There always is some layer of application 
>security(especially for those apps that run id=0). If you are a
>hosting company ( which is becoming a very large business), then you 
>desire a way to provide your customers with a programming
>interface that does not infringe on other customers, or your systems 
>security. Without a safe_mode, 
>is still allowed.

My point is that with safe_mode, $x = file("/etc/passwd") can probably 
still be achieved, only perhaps not that easily.  The false sense of 
security that it gives you may (will) cause administrators to set their 
servers up in an insecure way.

>It seems that your biggest concern is giving users a false sense of 
>security. This feature is something that would not be used by
>the average user. The people who would mainly be using this would have an 
>ok knowledge of security, and if you have an ok knowledge,
>then you will know to Never Trust Anything
>There is always a possibility of security methods being penetrated, 
>everyone just has to be made aware that security is just
>something that rules out the majority of breach attempts. That is why you 
>need multiple levels
>
>I believe that performing something similar to a chroot in the lower level 
>file operations, would lock php itself into a protected
>area. PHP is very modular, and has an excellent lower level API., both of 
>which makes this a very possible thing.

Well, I respectfully disagree :)   One thing we haven't done, is telling 
people one clear statement - 'Safe mode is NOT secure'.  It's a functional 
feature, not a security feature.  It hasn't been audited, and God knows how 
many bugs and loopholes lurk in the dark (my guess - many).
I don't mind seeing an impressive safe mode being implemented, as long as 
it's presented as a functional feature, with the appropriate disclaimers 
telling people that this does *NOT* replace security measure that they 
would otherwise use.

Also, be advised that many functions don't use the APIs, but use system 
calls directly.

Zeev


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

RE: [PHP-DEV] PHP 4.0 Bug #9136: simple script with infinite function calls causes seg fault

[Sean R. Bright]

I never said that recursion or the ability for a function to call another
function was a feature/bug.  I agree that they are necessary to the
language.  My point is simply that I don't think PHP needs to be "fixed" so
that this user's mistake is somehow valid.

Take this example (in C):
/***/
#include 

int a(void);
int b(void);

int main(int argc, char **argv) {
a();
return;
}

int a(void) {
b();
}

int b(void) {
a();
}
/***/

If compiled and run this results in a segfault under linux2.2.18 (glibc2).
gcc doesn't warn me that this is invalid.

I am not really sure what we are arguing at this point...

Sean

> -Original Message-
> From: Zak Greant [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 06, 2001 6:22 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] PHP 4.0 Bug #9136: simple script with infinite
> function calls causes seg fault
>
>
> Sean wrote:
> > Dear Zak:
> >
> > Because I don't consider it a problem that needs solving.
> I am probably
> > overlooking some notoriously famous algorithm, but I can't
> think of a
> valid
> > reason for such functionality to exist unless someone is
> purposely trying
> to
> > bring a system to its knees.
>
> I don't think that this is feature (or a bug FTM) - this is
> just how things
> were implemented - a side effect of needing both recursion
> and allowing
> functions to call other functions.
>
> --zak
>
>


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

Re: [PHP-DEV] The library yes/lib does not exist

[Sascha Schumann]

On Wed, 7 Feb 2001, Derick Rethans wrote:

> On Wed, 7 Feb 2001, Sascha Schumann wrote:
>
> > Please post your full configure line.

Ok, those are quite a lot entries.  Did you add one recently?
When did you see that kind of error for the first time?  Did
you change anything related to those third party libraries in
your system?

- Sascha


-- 
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 #9136: simple script with infinite function calls causes seg fault

[Anil Madhavapeddy]

Sean R. Bright wrote:
>
> Because I don't consider it a problem that needs solving.  I am probably
> overlooking some notoriously famous algorithm, but I can't think of a
valid
> reason for such functionality to exist unless someone is purposely trying
to
> bring a system to its knees.
>

How about ... no PHP script should ever cause the webserver to segfault?
Segfaults are bad.

Anil


-- 
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] The library yes/lib does not exist

[Derick Rethans]

On Wed, 7 Feb 2001, Sascha Schumann wrote:

> Please post your full configure line.

--with-gd \
--with-ttf --with-mysql --with-pdflib --with-config-file-path=/etc/httpd \
--enable-track-vars --enable-magiq-quotes --enable-memory-limit \
--with-sablot --enable-ftp --with-pspell --enable-bcmath \
--with-ctype --with-gmp --with-ldap \
--enable-shmop --with-sockets --enable-sysvsem \
--with-dom \
--enable-sysvshm --enable-wddx --with-xml --with-zlib

Derick Rethans

-
  PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
 H.v. Tussenbroekstraat 1 - 6952 BL Dieren - The Netherlands
-


-- 
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 #9136: simple script with infinite function calls causes seg fault

[Zak Greant]

Sean wrote:
> Dear Zak:
>
> Because I don't consider it a problem that needs solving.  I am probably
> overlooking some notoriously famous algorithm, but I can't think of a
valid
> reason for such functionality to exist unless someone is purposely trying
to
> bring a system to its knees.

I don't think that this is feature (or a bug FTM) - this is just how things
were implemented - a side effect of needing both recursion and allowing
functions to call other functions.

--zak


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

Re: [PHP-DEV] The library yes/lib does not exist

[Sascha Schumann]

On Tue, 6 Feb 2001, Derick Rethans wrote:

> Hey,
>
> rather strange error in the ./configure script. I think it's from
> --with-dom. However, everything works fine.

That is probably caused by a construct like

PHP_ARG_WITH(foo, ..)
..
AC_ADD_LIBPATH($PHP_FOO/lib)

I.e. when using --with-foo, PHP_FOO is set to yes and the
config.m4 does not handle that case.  I've reviewed the
domxml extension's config.m4 and it seems to work properly.
Please post your full configure line.

- Sascha


-- 
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 #9136 Updated: simple script with infinite function calls causes seg fault

[nathan]

ID: 9136
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Feature/Change Request
Description: simple script with infinite function calls causes seg fault

I agree that recursion like this is not a good thing, it was an accidental bug in a 
very complex PHP module we were writing.  The problem is that it's an incredibly 
difficult bug to find when PHP just seg faults and you get a No Data error from 
Netscape.  When you are coding a very complex module as we were, the problem is not 
immediately obvious as in this example.

I would expect buggy PHP code like this to give me a stack overflow error report or 
execution time exceeded error or something.  I just sat there for about 5 minutes 
going WHAT!?!?! when I made a set of changes and suddenly PHP started seg faulting all 
over the place.

I agree that an ini setting to check the stack level against a maximum sounds like a 
good idea.  I think it would be good to have on by default (not just safe mode) given 
that many PHP developers are new programmers who can easily make recursion mistakes 
(not to mention more experienced php coders like me who still easily make recursion 
mistakes ;).  Just set the value to something large enough to catch these recursion 
bugs without effecting the running of most normal recursive applications.  True 
maniacs can turn it off by setting to -1 or something.  I prefer to be protected from 
myself until I'm ready to grow out of the protection... 

Previous Comments:
---

[2001-02-06 17:41:12] [EMAIL PROTECTED]
maybe we should move this to feature request for safe mode?
it would be fine to give the server owner the possibility to
autokill scripts which would kill the server in a few
microseconds, shouldn't it be implementable without loosing
performance, check the level the stack is filled up against
a values in php.ini maybe...

---

[2001-02-06 17:31:02] [EMAIL PROTECTED]
and guess this "bug" was present in any version before, what
do you expect to happen here? you will never leave these
function calls (as you know I guess), as far as your stack
is full it is full

remember php has to remember each and every function call it
did...

a()
   b()
  a()
 b()
   

if you really need exactly this construct, I would suggest
you to use a static variable to count the total function
calls and find the critical values a specific system
segfaults (with your original code), then you stick a
for(;;) around it and implement a check (eg. in a()) against
the static variable to leave the recursion if a value with
enough distance to the critical value is reached, then you
should be able to begin the recursion again

any recursion can be displayed as a loop, do not use
recursion if you want to recurse infinitely

---

[2001-02-06 17:22:36] [EMAIL PROTECTED]
PHP doesn't handle infinite recursion, and as earlier was discussed on the php-dev 
list, it wont be implemented to guard for this, because of the high performance impact.

---

[2001-02-06 17:18:03] [EMAIL PROTECTED]
---
<%

function a () {
b();
}

function b () {
a();
}

a();

%> 

done
-

The simple script above causes a seg fault.  If you need more info on configuration 
etc please mail me.  We made this simple example from a more compilcated instance.  
This bug was also present in 4.0.3pl1, we upgraded to try and stop the seg fault...

thanks!

---


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


-- 
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 #9136: simple script with infinite function calls causes seg fault

[Sean R. Bright]

Dear Zak:

Because I don't consider it a problem that needs solving.  I am probably
overlooking some notoriously famous algorithm, but I can't think of a valid
reason for such functionality to exist unless someone is purposely trying to
bring a system to its knees.

Sean

> -Original Message-
> From: Zak Greant [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 06, 2001 5:40 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] PHP 4.0 Bug #9136: simple script with infinite
> function calls causes seg fault
>
>
> Dear Sean,
>
> Your resume indicates that you have a wealth of skills that
> can be applied
> to this problem. It would also seem that you understand the
> open source
> ethic.  Why would you not look at solving the problem yourself?
>
> --zak
>
>
>
> - Original Message -
> From: "Sean R. Bright" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, February 06, 2001 3:17 PM
> Subject: RE: [PHP-DEV] PHP 4.0 Bug #9136: simple script with infinite
> function calls causes seg fault
>
>
> > 
> > Yes, I found this feature of PHP quite useful when I wanted
> to crash the
> > server.  There are many places on the web that you can
> download these
> very
> > useful applications that call functions infinitely.  The
> applications for
> > this type of code are innumerable.
> > 
> >
> > Sean
> > --
> > ===
> > Sean Bright
> > [EMAIL PROTECTED] / [EMAIL PROTECTED] / http://www.seanbright.com/
> > ===
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, February 06, 2001 5:18 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: [PHP-DEV] PHP 4.0 Bug #9136: simple script with infinite
> > > function calls causes seg fault
> > >
> > >
> > > From: [EMAIL PROTECTED]
> > > Operating system: red hat 7.0
> > > PHP version:  4.0.4pl1
> > > PHP Bug Type: Reproduceable crash
> > > Bug description:  simple script with infinite function calls
> > > causes seg fault
> > >
> > > ---
> > > <%
> > >
> > > function a () {
> > > b();
> > > }
> > >
> > > function b () {
> > > a();
> > > }
> > >
> > > a();
> > >
> > > %>
> > >
> > > done
> > > -
> > >
> > > The simple script above causes a seg fault.  If you need more
> > > info on configuration etc please mail me.  We made this
> > > simple example from a more compilcated instance.  This bug
> > > was also present in 4.0.3pl1, we upgraded to try and stop the
> > > seg fault...
> > >
> > > thanks!
> > >
> > >
> > > --
> > > Edit Bug report at: http://bugs.php.net/?id=9136&edit=1
> > >
> > >
> > >
> > > --
> > > PHP Development Mailing List 
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > To contact the list administrators, e-mail:
> > > [EMAIL PROTECTED]
> > >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail:
> [EMAIL PROTECTED]
> >
> >
>
>
> --
> PHP 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] PHP 4.0 Bug #9136 Updated: simple script with infinite function calls causes seg fault

[André Langhorst]

> why didn't you make it a Feature Request then? But I suppose you tried,
> and wasn't be able to do that. Jani, is this a bug in the bugsystem?

I did! it was just put into a rhetorical question ;)

andré

-- 
· André Langhorst   · t: +49 571 3201801 ·
· [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]

Re: [PHP-DEV] PHP 4.0 Bug #9136 Updated: simple script with infinitefunction calls causes seg fault

[Derick Rethans]

On Wed, 7 Feb 2001, Cynic wrote:

> but he did:
> > Old-Bug Type: Reproduceable crash
> > Bug Type: Feature/Change Request

I need either more sleep or less alcohol :)

Derick Rethans

-
  PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
 H.v. Tussenbroekstraat 1 - 6952 BL Dieren - The Netherlands
-


-- 
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 #9136 Updated: simple script with infinitefunction calls causes seg fault

[Derick Rethans]

Hey,

why didn't you make it a Feature Request then? But I suppose you tried,
and wasn't be able to do that. Jani, is this a bug in the bugsystem?

BTW, I think this would be a nice idea for the new safe_mode, but I wonder
if it's possible to do with a config switch. Zeev?

Greetingz,
Derick

On 6 Feb 2001 [EMAIL PROTECTED] wrote:

> ID: 9136
> Updated by: waldschrott
> Reported By: [EMAIL PROTECTED]
> Old-Status: Closed
> Status: Feedback
> Old-Bug Type: Reproduceable crash
> Bug Type: Feature/Change Request
> Assigned To: waldschrott
> Comments:

Derick Rethans

-
  PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
 H.v. Tussenbroekstraat 1 - 6952 BL Dieren - The Netherlands
-


-- 
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 #9136 Updated: simple script with infinite function calls causes seg fault

[waldschrott]

ID: 9136
Updated by: waldschrott
Reported By: [EMAIL PROTECTED]
Old-Status: Closed
Status: Feedback
Old-Bug Type: Reproduceable crash
Bug Type: Feature/Change Request
Assigned To: waldschrott
Comments:

maybe we should move this to feature request for safe mode?
it would be fine to give the server owner the possibility to
autokill scripts which would kill the server in a few
microseconds, shouldn't it be implementable without loosing
performance, check the level the stack is filled up against
a values in php.ini maybe...

Previous Comments:
---

[2001-02-06 17:31:02] [EMAIL PROTECTED]
and guess this "bug" was present in any version before, what
do you expect to happen here? you will never leave these
function calls (as you know I guess), as far as your stack
is full it is full

remember php has to remember each and every function call it
did...

a()
   b()
  a()
 b()
   

if you really need exactly this construct, I would suggest
you to use a static variable to count the total function
calls and find the critical values a specific system
segfaults (with your original code), then you stick a
for(;;) around it and implement a check (eg. in a()) against
the static variable to leave the recursion if a value with
enough distance to the critical value is reached, then you
should be able to begin the recursion again

any recursion can be displayed as a loop, do not use
recursion if you want to recurse infinitely

---

[2001-02-06 17:22:36] [EMAIL PROTECTED]
PHP doesn't handle infinite recursion, and as earlier was discussed on the php-dev 
list, it wont be implemented to guard for this, because of the high performance impact.

---

[2001-02-06 17:18:03] [EMAIL PROTECTED]
---
<%

function a () {
b();
}

function b () {
a();
}

a();

%> 

done
-

The simple script above causes a seg fault.  If you need more info on configuration 
etc please mail me.  We made this simple example from a more compilcated instance.  
This bug was also present in 4.0.3pl1, we upgraded to try and stop the seg fault...

thanks!

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9136&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] The library yes/lib does not exist

[Derick Rethans]

Hey,

rather strange error in the ./configure script. I think it's from
--with-dom. However, everything works fine.

Derick


/bin/sh ../libtool --silent --mode=link gcc  -g -O2  -o libZend.la  -lpam
-ldl -lz -lxmltok -lxmlparse -lsablot -lpspell -lz -ljpeg -lpng -ltiff
-lpdf -lldap -llber -lgmp -lttf -lz -lpng -lgd -lz -lxml -lresolv -lm -ldl
-lcrypt -lnsl  -lresolv -Lyes/lib -lz  zend_language_parser.lo
zend_ini_parser.lo zend_alloc.lo zend_compile.lo zend_constants.lo
zend_dynamic_array.lo zend_execute.lo zend_execute_API.lo
zend_highlight.lo zend_llist.lo zend_opcode.lo zend_operators.lo
zend_ptr_stack.lo zend_stack.lo zend_variables.lo zend.lo zend_API.lo
zend_extensions.lo zend_hash.lo zend_list.lo zend_indent.lo
zend_builtin_functions.lo zend_sprintf.lo zend_ini.lo libZend_c.la
../libtool: yes/lib: No such file or directory
libtool: link: warning: cannot determine absolute directory name of
`yes/lib'
libtool: link: passing it literally to the linker, although it

Derick Rethans

-
  PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
 H.v. Tussenbroekstraat 1 - 6952 BL Dieren - The Netherlands
-


-- 
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 #9136: simple script with infinite function calls causes seg fault

[Zak Greant]

Dear Sean,

Your resume indicates that you have a wealth of skills that can be applied
to this problem. It would also seem that you understand the open source
ethic.  Why would you not look at solving the problem yourself?

--zak



- Original Message -
From: "Sean R. Bright" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, February 06, 2001 3:17 PM
Subject: RE: [PHP-DEV] PHP 4.0 Bug #9136: simple script with infinite
function calls causes seg fault


> 
> Yes, I found this feature of PHP quite useful when I wanted to crash the
> server.  There are many places on the web that you can download these
very
> useful applications that call functions infinitely.  The applications for
> this type of code are innumerable.
> 
>
> Sean
> --
> ===
> Sean Bright
> [EMAIL PROTECTED] / [EMAIL PROTECTED] / http://www.seanbright.com/
> ===
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, February 06, 2001 5:18 PM
> > To: [EMAIL PROTECTED]
> > Subject: [PHP-DEV] PHP 4.0 Bug #9136: simple script with infinite
> > function calls causes seg fault
> >
> >
> > From: [EMAIL PROTECTED]
> > Operating system: red hat 7.0
> > PHP version:  4.0.4pl1
> > PHP Bug Type: Reproduceable crash
> > Bug description:  simple script with infinite function calls
> > causes seg fault
> >
> > ---
> > <%
> >
> > function a () {
> > b();
> > }
> >
> > function b () {
> > a();
> > }
> >
> > a();
> >
> > %>
> >
> > done
> > -
> >
> > The simple script above causes a seg fault.  If you need more
> > info on configuration etc please mail me.  We made this
> > simple example from a more compilcated instance.  This bug
> > was also present in 4.0.3pl1, we upgraded to try and stop the
> > seg fault...
> >
> > thanks!
> >
> >
> > --
> > Edit Bug report at: http://bugs.php.net/?id=9136&edit=1
> >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail:
> > [EMAIL PROTECTED]
> >
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


-- 
PHP 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 #9137 Updated: eval adds function to global space rather than class method

[waldschrott]

ID: 9137
Updated by: waldschrott
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Class/Object related
Assigned To: waldschrott
Comments:

and this is correct, eval uses its own scope, the only
possibilty I see at the moment to solve your specific
problem is to eval() the entire class maybe in combination
with inheritance

Previous Comments:
---

[2001-02-06 17:32:47] [EMAIL PROTECTED]
I am trying to generate class methods on the fly.

I created a string which was php code for a function. I wished this funciton to be a 
class method. I call eval on the string, and it produces no errors. When I wish to 
call that method of the object, the script fails indicating a call to an undefined 
funciton. However, I can call that function in the page space, rather than as a class 
method. But, the function is useless unless it is a method.

The following is part of the code that is executed in the constructor:

$str = "";
foreach($this->getMappedAttributes() as $attribute)
{
  $str .= "$"."this->_".$attribute['attribute']." = "";";
  $str .= "function get".$attribute['attribute']."() {";
  $str .= "return $"."this->_".$attribute['attribute'].";}";
}
eval($str);


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9137&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 #9137: eval adds function to global space rather than class method

[aj]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.4pl1
PHP Bug Type: Class/Object related
Bug description:  eval adds function to global space rather than class method

I am trying to generate class methods on the fly.

I created a string which was php code for a function. I wished this funciton to be a 
class method. I call eval on the string, and it produces no errors. When I wish to 
call that method of the object, the script fails indicating a call to an undefined 
funciton. However, I can call that function in the page space, rather than as a class 
method. But, the function is useless unless it is a method.

The following is part of the code that is executed in the constructor:

$str = "";
foreach($this->getMappedAttributes() as $attribute)
{
  $str .= "$"."this->_".$attribute['attribute']." = \"\";";
  $str .= "function get".$attribute['attribute']."() {";
  $str .= "return $"."this->_".$attribute['attribute'].";}";
}
eval($str);



-- 
Edit Bug report at: http://bugs.php.net/?id=9137&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 #9136 Updated: simple script with infinite function calls causes seg fault

[waldschrott]

ID: 9136
Updated by: waldschrott
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Reproduceable crash
Assigned To: waldschrott
Comments:

and guess this "bug" was present in any version before, what
do you expect to happen here? you will never leave these
function calls (as you know I guess), as far as your stack
is full it is full

remember php has to remember each and every function call it
did...

a()
   b()
  a()
 b()
   

if you really need exactly this construct, I would suggest
you to use a static variable to count the total function
calls and find the critical values a specific system
segfaults (with your original code), then you stick a
for(;;) around it and implement a check (eg. in a()) against
the static variable to leave the recursion if a value with
enough distance to the critical value is reached, then you
should be able to begin the recursion again

any recursion can be displayed as a loop, do not use
recursion if you want to recurse infinitely

Previous Comments:
---

[2001-02-06 17:22:36] [EMAIL PROTECTED]
PHP doesn't handle infinite recursion, and as earlier was discussed on the php-dev 
list, it wont be implemented to guard for this, because of the high performance impact.

---

[2001-02-06 17:18:03] [EMAIL PROTECTED]
---
<%

function a () {
b();
}

function b () {
a();
}

a();

%> 

done
-

The simple script above causes a seg fault.  If you need more info on configuration 
etc please mail me.  We made this simple example from a more compilcated instance.  
This bug was also present in 4.0.3pl1, we upgraded to try and stop the seg fault...

thanks!

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9136&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] PHP 4.0 Bug #9136: simple script with infinite function calls causes seg fault

[Sean R. Bright]

Yes, I found this feature of PHP quite useful when I wanted to crash the
server.  There are many places on the web that you can download these very
useful applications that call functions infinitely.  The applications for
this type of code are innumerable.


Sean
--
===
Sean Bright
[EMAIL PROTECTED] / [EMAIL PROTECTED] / http://www.seanbright.com/
===

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 06, 2001 5:18 PM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] PHP 4.0 Bug #9136: simple script with infinite
> function calls causes seg fault
>
>
> From: [EMAIL PROTECTED]
> Operating system: red hat 7.0
> PHP version:  4.0.4pl1
> PHP Bug Type: Reproduceable crash
> Bug description:  simple script with infinite function calls
> causes seg fault
>
> ---
> <%
>
> function a () {
> b();
> }
>
> function b () {
> a();
> }
>
> a();
>
> %>
>
> done
> -
>
> The simple script above causes a seg fault.  If you need more
> info on configuration etc please mail me.  We made this
> simple example from a more compilcated instance.  This bug
> was also present in 4.0.3pl1, we upgraded to try and stop the
> seg fault...
>
> thanks!
>
>
> --
> Edit Bug report at: http://bugs.php.net/?id=9136&edit=1
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail:
> [EMAIL PROTECTED]
>


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

[PHP-DEV] PHP 4.0 Bug #9136 Updated: simple script with infinite function calls causes seg fault

[derick]

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

PHP doesn't handle infinite recursion, and as earlier was discussed on the php-dev 
list, it wont be implemented to guard for this, because of the high performance impact.

Previous Comments:
---

[2001-02-06 17:18:03] [EMAIL PROTECTED]
---
<%

function a () {
b();
}

function b () {
a();
}

a();

%> 

done
-

The simple script above causes a seg fault.  If you need more info on configuration 
etc please mail me.  We made this simple example from a more compilcated instance.  
This bug was also present in 4.0.3pl1, we upgraded to try and stop the seg fault...

thanks!

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9136&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: Dear Friends & Future Millionaire:

[André Langhorst]

Couldn't some just go and kill those spammers?

Is it possible to set rules (similar to those my mozilla takes) for the 
list?
class a candidate would be 'SEEN'+'NATIONAL'+'TV' and the like

andré

 Original Message 
Subject: [PHP-PEAR] Dear Friends & Future Millionaire:
Date: Tue, 6 Feb 2001 21:36:35 +0100
From: Hi Tech Services <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>


AS SEEN ON NATIONAL TV:
Making over half million dollars every 4 to 5 months from your home for
an investment of only $25 U.S. Dollars expense one time
THANK'S TO THE COMPUTER AGE AND THE INTERNET !
==


-- 
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 #9136: simple script with infinite function calls causes seg fault

[nathan]

From: [EMAIL PROTECTED]
Operating system: red hat 7.0
PHP version:  4.0.4pl1
PHP Bug Type: Reproduceable crash
Bug description:  simple script with infinite function calls causes seg fault

---
<%

function a () {
b();
}

function b () {
a();
}

a();

%> 

done
-

The simple script above causes a seg fault.  If you need more info on configuration 
etc please mail me.  We made this simple example from a more compilcated instance.  
This bug was also present in 4.0.3pl1, we upgraded to try and stop the seg fault...

thanks!


-- 
Edit Bug report at: http://bugs.php.net/?id=9136&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 #9135: Could not establish connection

[mita]

From: [EMAIL PROTECTED]
Operating system: windows nt
PHP version:  4.0.4pl1
PHP Bug Type: MySQL related
Bug description:  Could not establish connection

I inserted a row in mysql database - user table with host = localhost:8080. I am 
running my apache server on port 8080.
The insertion was successful.

If I try to connect mysql using php script, I am getting a message -
connection to mysql server is lost.

Below is my php script:




Untitled













-- 
Edit Bug report at: http://bugs.php.net/?id=9135&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] wrong implementation of isset()?

[Chris Newbill]

null, adjective: having no value

IMHO, isset() should be left as is.  Either way if you are looking for a
null value you will have to use '== NULL' or is_null().

if (isset($a) && is_null($a))

if (isset($a))
if (is_null($a))

etc...

The only possible situation I can think(right now) of where this might be
useful is if you do not care that the value is null and null is a perfectly
legal value(or non-value).  In which case, all you are accomplishing is
breaking everyone else's script who does not allow null values because they
rely on isset() returning false and not letting these by.

Chris

-Original Message-
From: Martin Jansen [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 06, 2001 2:19 PM
To: Andrei Zmievski; Bjoern Hoehrmann
Cc: PHP Development Mailing List
Subject: Re: [PHP-DEV] wrong implementation of isset()?


On Tue, 6 Feb 2001 13:43:29 -0600, Andrei Zmievski wrote:
>On Tue, 06 Feb 2001, Bjoern Hoehrmann wrote:
>> >NULL == not set
>>
>> Great analysis. What about answering the question? Stanislav Malyshev
>> said some months ago this is 'strange', see the discussion around bug
>> 6076. Tell us at least, why this actually isn't strange.
>
>By default, any unset variable has value NULL - and isset(NULL) returns
>false to indicate that. Similarly, assigning NULL to a variable unsets
>it.

But if I declare the variable in my script (and in the namespace),
it's existing, no matter which value it has (String, Integer, NULL
or whatever). As a result of that, isset() should return true.

-Martin


--
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] wrong implementation of isset()?

[Martin Jansen]

On Tue, 6 Feb 2001 13:43:29 -0600, Andrei Zmievski wrote:
>On Tue, 06 Feb 2001, Bjoern Hoehrmann wrote:
>> >NULL == not set
>> 
>> Great analysis. What about answering the question? Stanislav Malyshev
>> said some months ago this is 'strange', see the discussion around bug
>> 6076. Tell us at least, why this actually isn't strange.
>
>By default, any unset variable has value NULL - and isset(NULL) returns
>false to indicate that. Similarly, assigning NULL to a variable unsets
>it.

But if I declare the variable in my script (and in the namespace),
it's existing, no matter which value it has (String, Integer, NULL
or whatever). As a result of that, isset() should return true.

-Martin


-- 
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] Dear Friends & Future Millionaire:

[Hi Tech Services]

AS SEEN ON NATIONAL TV: 
Making over half million dollars every 4 to 5 months from your home for 
an investment of only $25 U.S. Dollars expense one time 
THANK'S TO THE COMPUTER AGE AND THE INTERNET ! 
== 
BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! 
Before you say ''Bull'', please read the following. This is the letter you 
have been hearing about on the news lately. Due to the popularity of 
this letter on the Internet, a national weekly news program recently devoted 
an entire show to the investigation of this program described below, to see 
if it really can make people money. The show also investigated whether or 
not the program was legal. 
Their findings proved once and for all that there are ''absolutely NO Laws 
prohibiting the participation in the program and if people can -follow the 
simple instructions, they are bound to make some mega bucks with only 
$25 out of pocket cost''. DUE TO THE RECENT INCREASE OF 
POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, 
IT IS CURRENTLY WORKING BETTER THAN EVER. 
This is what one had to say: ''Thanks to this profitable opportunity. I 
was approached many times before but each time I passed on it. I am 
so gladI finally joined just to see what one could expect in return for the 
minimal effort and money required. To my astonishment, I received total $ 
610,470.00 in 21 weeks, with money still coming in." 
Pam Hedland, Fort Lee, New Jersey. 
=== 
Here is another testimonial: "This program has been around for a long 
time but I never believed in it. But one day when I received this again 
in the mail I decided to gamble my $25 on it. I followed the simple 
instructions and walaa . 3 weeks later the money started to come in. 
First month I only made $240.00 but the next 2 months after that I made 
a total of $290,000.00. So far, in the past 8 months by re-entering the 
program, I have made over $710,000.00 and I am playing it again. The 
key to success in this program is to follow the simple steps and NOT change 
anything.'' More testimonials later but first, 
= PRINT THIS NOW FOR YOUR FUTUREREFERENCE == 
$ 
If you would like to make at least $500,000 every 4 to 5 months easily and 
comfortably, please read the following...THEN READ IT AGAIN and AGAIN!!! 
$ 
FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL 
DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: 
=Order all 5 reports shown on the list below = 
For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT 
YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose 
name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN 
ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail 
problems. 
=== When you place your order, make sure you order each of the 5 reports. 
You will need all 5 reports so that you can save them on your computer 
and resell them. YOUR TOTAL COST $5 X 5=$25.00. 
Within a few days you will receive, vie e-mail, each of the 5 reports from 
these 5 different individuals. Save them on your computer so they will be 
accessible for you to send to the 1,000's of people who will order them 
from you. Also make a floppy of these reports and keep it on your desk in 
case something happen to your computer. 
IMPORTANT - DO NOT alter the names of the people who are listed next 
to each report, or their sequence on the list, in any way other than what is 
instructed below in step '' 1 through 6 '' or you will loose out on majority 
of your profits. Once you understand the way this works, you will also see 
how it does not work if you change it. Remember, this method has been 
tested, and if you alter, it will NOT work !!! People have tried to put their 
friends/relatives names on all five thinking they could get all the money. But 
it does not work this way. Believe us, we all have tried to be greedy and then 
nothing happened. So Do Not try to change anything other than what is 
instructed. Because if you do, it will not work for you. 
Remember, honesty reaps the reward!!! 
1 After you have ordered all 5 reports, take this advertisement and 
REMOVE the name & address of the person in REPORT # 5. This person 
has made it through the cycle and is no doubt counting their fortune. 
2 Move the name & address in REPORT # 4 down TO REPORT # 5. 
3 Move the name & address in REPORT # 3 down TO REPORT # 4. 
4 Move the name & address in REPORT # 2 down TO REPORT # 3. 
5 Move the name & address in REPORT # 1 down TO REPORT # 2 
6 Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE 
SURE you copy every name & address ACCURATELY! 
== 
 Take this entire letter, with the modified list of names, and save it on your 
computer. DO NOT MAKE ANY OTHE

[PHP-DEV] PHP 4.0 Bug #9031 Updated: ob_gzhandler memory leak and Headers already sent message!

[aboldt]

ID: 9031
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Output Control
Description: ob_gzhandler memory leak and Headers already sent message!

I've just found out what the problem is, and it's kind of weird:
With ob_gzhandler enabled (from php.ini or with ob_start("ob_gzhandler") in the .php) 
each readfile() makes the "Cannot add header information - headers already sent" error 
message appear.
This doesn't happen with output buffering enabled and no ob_gzhandler, it only happens 
with ob_gzhandler enabled.

Also tried to replace readfile with fpassthru(fopen()) but got the same result.

Hope this helps you fix the problem.

If you have any questions feel free to ask, I've been experimenting quite a lot.

Previous Comments:
---

[2001-02-02 09:23:24] [EMAIL PROTECTED]
Tried the php4-200102020545 snapshot and I still get the

httpd: PHP Warning:  Cannot add header information - headers already sent in Unknown 
on line 0

error message when enabling output_handler = ob_gzhandler.
This probably still causes a memory leak.

Found another interesting thing: when trying to see the headers of a ob_gzhandler 
compressed page with lynx, I get the following lynx error message:

Can't access startfile http://localhost/test.php

That's using lynx -head -source http://localhost/test.php. Seems lynx sees something 
which it doesn't like. With ob_gzhandler disabled, I get the normal http headers when 
invoking that lynx command.

---

[2001-02-01 20:03:32] [EMAIL PROTECTED]
This should be fixed in CVS now. Please try the latest CVS snapshot from 
http://snaps.php.net/ and reopen this bug report if problem still exists when
using it.

--Jani


---

[2001-01-31 09:15:17] [EMAIL PROTECTED]
When enabling output_handler = ob_gzhandler in php.ini, my Linux system starts to eat 
more and more memory in an unusual way, like there was a memory leak, like many people 
have reported.

But what is absolutely weird is that after enabling ob_gzhandler, I start to get this 
error messages in my log files:

Cannot add header information - headers already sent in Unknown on line 0

Which is weird, because one of the features of output buffering is to avoid that kind 
of problems. What's even more weird is that I don't get any "headers already sent" 
messages with output_handler = ob_gzhandler disabled!

---


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


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

[anonymous]

Full name: Chris Newbill
Email: [EMAIL PROTECTED]
ID: cnewbill
Purpose: Manual/Documentation Maintenance, Quality Assurance and PHP Community 
Assistance (talked with Zak Greant)

-- 
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] wrong implementation of isset()?

[Marten Gustafsson]

I have always (although I know this wasn?t the case prior to PHP 4) thought
that unset() removed the variable from memory. Clearly this can?t be the
case if it has a value of NULL.

But if this is the way things work then is_null() ought to be an alias of
isset().


-Marten.
Icq# 38863127



-Original Message-
From: Andrei Zmievski [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 06, 2001 8:43 PM
To: Bjoern Hoehrmann
Cc: Martin Jansen; PHP Development Mailing List
Subject: Re: [PHP-DEV] wrong implementation of isset()?


On Tue, 06 Feb 2001, Bjoern Hoehrmann wrote:
> >NULL == not set
>
> Great analysis. What about answering the question? Stanislav Malyshev
> said some months ago this is 'strange', see the discussion around bug
> 6076. Tell us at least, why this actually isn't strange.

By default, any unset variable has value NULL - and isset(NULL) returns
false to indicate that. Similarly, assigning NULL to a variable unsets
it.

-Andrei
* The great thing about standards is that there are so many to choose from.
*

--
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 #9127 Updated: submitting a boolean to an attribute seems to fail

[hans]

ID: 9127
User Update by: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Class/Object related
Description: submitting a boolean to an attribute seems to fail

Sorry, false alarm, you can close the bug

Previous Comments:
---

[2001-02-06 08:18:10] [EMAIL PROTECTED]
I've been working with a class and had some slight problems. One of the attributes is 
declared as a boolean (default = false) within the class and I can't seem to set it to 
true form within a function. It doesn't help setting the boolean to true as a default 
and changing it to false. This will have the same effect, no change.

A workaround is to declare the boolean global but I do not like it. Is this a bug or 
am I blond?

Regards,

Hans

---


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


-- 
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] wrong implementation of isset()?

[Mark J. Hershenson]

>> Great analysis. What about answering the question? Stanislav Malyshev
>> said some months ago this is 'strange', see the discussion around bug
>> 6076. Tell us at least, why this actually isn't strange.
> 
> By default, any unset variable has value NULL - and isset(NULL) returns
> false to indicate that. Similarly, assigning NULL to a variable unsets
> it.
> 
> -Andrei
> * The great thing about standards is that there are so many to choose from. *

Well, sure, isset(NULL) should return false, it's not a variable set in the
scope. A constant(?) yes, but not a variable.

But if you set a variable at some point in a script, would it not stand to
reason that that name is in the global/local namespace, and therefore IS
set?

It's somewhat conflicting when you reason:



Yields:


   [GLOBALS] => Array
 *RECURSION*
[a] => 1
[b] => 2
[c] => 
)

So, $c is set, since it is contained in $GLOBALS. Yet it's not, because it's
NULL.

I vote for isset() on a NULL value should be true if it's in the namespace.

  Mark J. Hershenson
  [EMAIL PROTECTED]
  http://www.green-ant.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 #9127 Updated: submitting a boolean to an attribute seems to fail

[zak]

ID: 9127
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Class/Object related
Assigned To: 
Comments:



Previous Comments:
---

[2001-02-06 08:18:10] [EMAIL PROTECTED]
I've been working with a class and had some slight problems. One of the attributes is 
declared as a boolean (default = false) within the class and I can't seem to set it to 
true form within a function. It doesn't help setting the boolean to true as a default 
and changing it to false. This will have the same effect, no change.

A workaround is to declare the boolean global but I do not like it. Is this a bug or 
am I blond?

Regards,

Hans

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9127&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] PHP 4.0 Bug #9134: configure: error: Invalid Apache directory - unable to find httpd.h under /usr/

[Chris Newbill]

Path simply means the directory in which the file resides.  Remove the
httpd.h from the --with-apache option and try again.

Chris

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 06, 2001 12:10 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] PHP 4.0 Bug #9134: configure: error: Invalid Apache
directory - unable to find httpd.h under /usr/


From: [EMAIL PROTECTED]
Operating system: Slackware Linux
PHP version:  4.0.4pl1
PHP Bug Type: *Install and Config
Bug description:  configure: error: Invalid Apache directory - unable to
find httpd.h under /usr/

It is the script that I write to ./configure the system:


./configure --with-apache=/usr/local/apache/include/httpd.h --enable-ftp --w
ith-mysql

And it is the result

configure: error: Invalid Apache directory - unable to find httpd.h under
/usr/local/apache/include/httpd.h

(The problem is that the path to httpd.h is correct, and the file is where I
say)

THANKS


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



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


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

RE: [PHP-DEV] PHP 4.0 Bug #9127: submitting a boolean to an attribute seems to fail

[Chris Newbill]

I talked to Hans, off the list, and it is something with his code.  Sample
code I sent him works just fine.

I have no karma or anything for the bug system, maybe I should ask for this.

Anyways, this is a bogus report.

Thanks,
Chris Newbill

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 06, 2001 6:18 AM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] PHP 4.0 Bug #9127: submitting a boolean to an
attribute seems to fail


From: [EMAIL PROTECTED]
Operating system: Linux kernel 2.4.0
PHP version:  4.0.4pl1
PHP Bug Type: Class/Object related
Bug description:  submitting a boolean to an attribute seems to fail

I've been working with a class and had some slight problems. One of the
attributes is declared as a boolean (default = false) within the class and I
can't seem to set it to true form within a function. It doesn't help setting
the boolean to true as a default and changing it to false. This will have
the same effect, no change.

A workaround is to declare the boolean global but I do not like it. Is this
a bug or am I blond?

Regards,

Hans


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



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


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

[PHP-DEV] Re: safe_mode redesign

[Jason Greene]

Zeev,

I understand your viewpoint, but I respectfully disagree. I believe that there are 
multiple levels of security, and that the OS is
just part of the picture. There always is some layer of application 
security(especially for those apps that run id=0). If you are a
hosting company ( which is becoming a very large business), then you desire a way to 
provide your customers with a programming
interface that does not infringe on other customers, or your systems security. Without 
a safe_mode, 
is still allowed.

While the details get tricky, and sometime complex, the overall concept is simple. 
Before any risky activity is performed, check the
list of things to block. There are tons of applications out there that perform these  
kind of important checks. ProFTPD is a good
example of one such application. It allows you to lock users into certain areas, use 
specific uids etc.

It seems that your biggest concern is giving users a false sense of security. This 
feature is something that would not be used by
the average user. The people who would mainly be using this would have an ok knowledge 
of security, and if you have an ok knowledge,
then you will know to Never Trust Anything
There is always a possibility of security methods being penetrated, everyone just has 
to be made aware that security is just
something that rules out the majority of breach attempts. That is why you need 
multiple levels

I believe that performing something similar to a chroot in the lower level file 
operations, would lock php itself into a protected
area. PHP is very modular, and has an excellent lower level API., both of which makes 
this a very possible thing.

I have spent quite a bit of time customizing PHP to work well in a secure environment, 
and I have seen other service providers doing
the same thing. The problem is that ppl are still going to do this whether its part of 
the codebase or not. If all of this work was
combined, then it can be shared, repaired, and optimized by everyone.

A safe programming chapter could be referred to in documentation as "An experimental 
security option designed for ISP and hosting
providers. This is by no means the finality of security, just a tool to help
in developing a secure environment"


Thanks,
Jason

- Original Message --
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Jason Greene" <[EMAIL PROTECTED]>
ACc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, February 04, 2001 6:43 AM
Subject: Re: safe_mode redesign


> Jason,
>
> The one main problem with safe_mode in general is that the idea is
> problematic by definition.  Security outside the OS level is prone to
> errors, and a false sense of security is much worse than knowing you're
> insecure.
>
> In my opinion, safe mode should only feature features which can have an
> infrastructure-level solution, and are not prone to errors.  There aren't
> too many of these.  The current safe mode implementation is extremely prone
> to errors because it tries to protect opened files, and the way its built,
> it's bound to be missing checks in many places...
>
> Zeev
>
> At 22:53 1/2/2001, Jason Greene wrote:
> >Is anyone up for a discussion on the redesign of safe_mode? I would like
> >to start working on this sometime soon, and I have a lot of
> >ideas, but I know this is going to be something of a large debate.
> >
> >Some of the  new features I think would benefit php include:
> >
> >* safe_mode_hide_env_vars - will allow extra protection on removing
> >environmental vars from hosted users ( I actually have a patch
> >for this but  I have been waiting on it to discuss the redesign)
> >
> >* User configurable policy - safe_mode could have configuration directives
> >to specify exactly what checks are desired
> >
> >* Virtual Chroot - the ability to perform a chroot to a virtual host
> >directory structure, so that a hosted user can not access
> >anything outside of their directory structure.
> >
> >* Shared Directories - The ability to specify a list of paths that are
> >shared amongst all hosted users. This would allow certain
> >extensions (gd, oracle, etc) the ability to access the needed datafiles
> >without failing a safe_mode check.
> >
> >Any comments, suggestions, other ideas?
> >
> >-Jason
>
> --
> Zeev Suraski <[EMAIL PROTECTED]>
> CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
>
>


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

Re: [PHP-DEV] wrong implementation of isset()?

[Andrei Zmievski]

On Tue, 06 Feb 2001, Bjoern Hoehrmann wrote:
> >NULL == not set
> 
> Great analysis. What about answering the question? Stanislav Malyshev
> said some months ago this is 'strange', see the discussion around bug
> 6076. Tell us at least, why this actually isn't strange.

By default, any unset variable has value NULL - and isset(NULL) returns
false to indicate that. Similarly, assigning NULL to a variable unsets
it.

-Andrei
* The great thing about standards is that there are so many to choose from. *

-- 
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] wrong implementation of isset()?

[Bjoern Hoehrmann]

* Andrei Zmievski wrote:
>> > $a = NULL;
>> if (isset($a)) { print "ok, du hast recht"; }
>> ?>
>> 
>> Shouldn't this script generate some output? IMO $a is set
>> and isset() should return true.

>NULL == not set

Great analysis. What about answering the question? Stanislav Malyshev
said some months ago this is 'strange', see the discussion around bug
6076. Tell us at least, why this actually isn't strange.
-- 
Björn Höhrmann ^ mailto:[EMAIL PROTECTED] ^ http://www.bjoernsworld.de
am Badedeich 7 ° Telefon: +49(0)4667/981028 ° http://bjoern.hoehrmann.de
25899 Dagebüll # PGP Pub. KeyID: 0xA4357E78 # http://learn.to/quote [!]e
~~ will code for food. ~~   

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

[anonymous]

Full name: Alexandre Correa
Email: [EMAIL PROTECTED]
ID: sabbathcop
Purpose: ?

-- 
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 #9134: configure: error: Invalid Apache directory - unable to find httpd.h under /usr/

[pablosof]

From: [EMAIL PROTECTED]
Operating system: Slackware Linux
PHP version:  4.0.4pl1
PHP Bug Type: *Install and Config
Bug description:  configure: error: Invalid Apache directory - unable to find httpd.h 
under /usr/

It is the script that I write to ./configure the system:

 ./configure --with-apache=/usr/local/apache/include/httpd.h --enable-ftp --with-mysql

And it is the result

configure: error: Invalid Apache directory - unable to find httpd.h under 
/usr/local/apache/include/httpd.h

(The problem is that the path to httpd.h is correct, and the file is where I say)

THANKS


-- 
Edit Bug report at: http://bugs.php.net/?id=9134&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 #9133: configure: error: Invalid Apache directory - unable to find httpd.h under /usr/

[pablosof]

From: [EMAIL PROTECTED]
Operating system: Slackware Linux
PHP version:  4.0.4pl1
PHP Bug Type: *Install and Config
Bug description:  configure: error: Invalid Apache directory - unable to find httpd.h 
under /usr/




-- 
Edit Bug report at: http://bugs.php.net/?id=9133&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] wrong implementation of isset()?

[Andrei Zmievski]

On Tue, 06 Feb 2001, Martin Jansen wrote:
> The following was reported today in the german language newsgroup
> news:de.comp.lang.php:
> 
>  $a = NULL;
> if (isset($a)) { print "ok, du hast recht"; }
> ?>
> 
> Shouldn't this script generate some output? IMO $a is set
> and isset() should return true.
> 
> The manual says:
> "isset -- Determine whether a variable is set"
> 
> So following the manual means that there _has_ to be
> output because $a is set in fact.
> 
> Or am I wrong?

NULL == not set

-Andrei

Some people try to achieve immortality through their work, others
through their children. I hope to achieve immortality by not dying.
-- Woody Allen

-- 
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] wrong implementation of isset()?

[Martin Jansen]

The following was reported today in the german language newsgroup
news:de.comp.lang.php:



Shouldn't this script generate some output? IMO $a is set
and isset() should return true.

The manual says:
"isset -- Determine whether a variable is set"

So following the manual means that there _has_ to be
output because $a is set in fact.

Or am I wrong?

-Martin
--
· Martin Jansen · mailto:[EMAIL PROTECTED]   ·
· Monschau, Germany · http://martin-jansen.de ·


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

[PHP-DEV] PHP 4.0 Bug #9132: 4.0.3pl1 takes too much memory (about 36 megs VSZ).

[stibor]

From: [EMAIL PROTECTED]
Operating system: linux i386 debian 2.2 potato
PHP version:  4.0.3pl1
PHP Bug Type: Performance problem
Bug description:  4.0.3pl1 takes too much memory (about 36 megs VSZ).

(And it does the same on debian-woody.)
ii  php4 4.0b3-6
  VSZ  RSS
 3632 1648
ii  php4 4.0.3pl1-0potato
36632 1964


-- 
Edit Bug report at: http://bugs.php.net/?id=9132&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 #9131: PHP_AUTH* empty with Caudium

[David Hedbor]

[EMAIL PROTECTED] writes:

> From: [EMAIL PROTECTED]
> Operating system: Linux
> PHP version:  4.0 Latest CVS (06/02/2001)
> PHP Bug Type: Other web server
> Bug description:  PHP_AUTH* empty with Caudium
> 
> from sapi/caudium.c :
>  /* FIXME: Check for auth stuff needs to be fixed... */
>   SG(request_info).auth_user = NULL;
>   SG(request_info).auth_password = NULL;

Yeah, I need to fix this. I had actually forgotten about it (oops).

-- 
[ Below is a random fortune, which is unrelated to the above message. ]
As in certain cults it is possible to kill a process if you know its true name.
-- Ken Thompson and Dennis M. Ritchie


-- 
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 #9131: PHP_AUTH* empty with Caudium

[david . gourdelier]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0 Latest CVS (06/02/2001)
PHP Bug Type: Other web server
Bug description:  PHP_AUTH* empty with Caudium

from sapi/caudium.c :
 /* FIXME: Check for auth stuff needs to be fixed... */
  SG(request_info).auth_user = NULL;
  SG(request_info).auth_password = NULL;



-- 
Edit Bug report at: http://bugs.php.net/?id=9131&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 #9116 Updated: PHP will stop returing anything in NES 4.1 SP1

[cboyce]

ID: 9116
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Description: PHP will stop returing anything in NES 4.1 SP1

FYI, in the magnus.conf file, the StackSize needs to be increased.


Previous Comments:
---

[2001-02-06 09:47:49] [EMAIL PROTECTED]
Output from truss:

Incurred fault #6, FLTBOUNDS  %pc = 0xFDD34B78
  siginfo: SIGSEGV SEGV_MAPERR addr=0xFD16C000
Received signal #11, SIGSEGV [caught]
  siginfo: SIGSEGV SEGV_MAPERR addr=0xFD16C000
*** process killed ***

---

[2001-02-05 12:34:05] [EMAIL PROTECTED]
Is there a certain number of Global variables, or number of functions you can load 
with the nsapi filter and NES?

I am using a function that uses many functions and many global variables.  PHP works 
fine through the rest of the application, but this one sections just dies, no errors 
or anything.  Apache works just fine with this application.

...

---


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


-- 
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: Fw: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed.

[Jason Greene]

Wow you're right. I stand corrected. You think I would have an understanding
of fork..one of the most basic unix system principals. 

Jason
- Original Message - 
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Jason Greene" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, February 06, 2001 4:10 AM
Subject: Re: Fw: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed.


> As Hartmut said, this argument is invalid in the Apache environment.  All 
> the static code in Apache is loaded to memory only once (in copy-on-write 
> pages, that will never be written to).  Using DSO's in Apache has no 
> advantages other than ease of administration (which is an important thing 
> by itself for many), and some disadvantages.
> 
> Zeev
> 
> At 08:17 6/2/2001, Jason Greene wrote:
> >Becuase DSO's are shared libs. Here is an excerpt about shared libs:
> >
> >
> >The shared library code is not present in the executable image on disk. 
> >Shared code is loaded into memory once in the shared library segment and 
> >shared by all
> >processes that reference it. The advantages of shared libraries are:
> >
> >   Less disk space is used because the shared library code is not 
> > included in the executable programs.
> >   Less memory is used because the shared library code is only loaded 
> > once.
> >   Load time may be reduced because the shared library code may 
> > already be in memory.
> >   Performance may be improved because fewer page faults will be 
> > generated when the shared library code is already in memory.
> >However, there is a
> >   performance cost in calls to shared library routines of one to 
> > eight instructions.
> >
> >Jason
> >
> >
> >
> >Zeev Suraski wrote:
> > >
> > > Why would using DSO reduce memory consumption?
> > > Using DSO makes things easier to administer and maintain, but it doesn't
> > > save any memory and it does pose a slight performance decrease...
> > >
> > > Zeev
> > >
> > > At 02:20 30/1/2001, Jason Greene wrote:
> > > >MaxRequestsPerChild is perfectly safe, and I always believe in setting it.
> > > >Keep in mind that if you compile all modules into apache statically, 
> > it takes
> > > >up far more base mem per process. If you use all DSO's, you can
> > > >significantly reduce memory usage. To find out what's in use on RH7
> > > >cat /proc//maps of an apache child.
> > > >You can also reduce the KeepAlive timeout value to help-out.
> > > >
> > > >Jason
> > > > >
> > > > >
> > > > >
> > > > > - Original Message -
> > > > > From: "Rasmus Lerdorf" <[EMAIL PROTECTED]>
> > > > > To: "Filip Sielimowicz" <[EMAIL PROTECTED]>
> > > > > Cc: <[EMAIL PROTECTED]>
> > > > > Sent: Monday, January 29, 2001 7:51 AM
> > > > > Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed.
> > > > >
> > > > >
> > > > > > On Mon, 29 Jan 2001, Filip Sielimowicz wrote:
> > > > > >
> > > > > > > > A quick fix would be to set your MaxRequestsPerChild to a lower
> > > > value.
> > > > > > >
> > > > > > > Have you ever tried to measure the time of killing and
> > > > > > > starting httpd process ? You can see that with a bare human eye.
> > > > > >
> > > > > > Sure.  But that isn't something that happens on an actual 
> > request, so an
> > > > > > end user isn't going to see that.
> > > > > >
> > > > > > -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 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]
> > >
> > > --
> > > 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]
> 
> --
> 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 #9116 Updated: PHP will stop returing anything in NES 4.1 SP1

[cboyce]

ID: 9116
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Description: PHP will stop returing anything in NES 4.1 SP1

Output from truss:

Incurred fault #6, FLTBOUNDS  %pc = 0xFDD34B78
  siginfo: SIGSEGV SEGV_MAPERR addr=0xFD16C000
Received signal #11, SIGSEGV [caught]
  siginfo: SIGSEGV SEGV_MAPERR addr=0xFD16C000
*** process killed ***

Previous Comments:
---

[2001-02-05 12:34:05] [EMAIL PROTECTED]
Is there a certain number of Global variables, or number of functions you can load 
with the nsapi filter and NES?

I am using a function that uses many functions and many global variables.  PHP works 
fine through the rest of the application, but this one sections just dies, no errors 
or anything.  Apache works just fine with this application.

...

---


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


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

Re: [PHP-DEV] Bug #9125: image file corrupted when upload

[phobo]

What is your code for opening the file?

Sounds to me like you're not opening the file as a 'binary file' in Linux.
Use 'b' as part of the fopen() statement. See http://php.net/fopen


Siggy



- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, February 07, 2001 1:48 AM
Subject: [PHP-DEV] Bug #9125: image file corrupted when upload


> From: [EMAIL PROTECTED]
> Operating system: Linux redhat 6.2 & SuSE 7.0 on intel platform
> PHP version:  3.0.17
> PHP Bug Type: Other
> Bug description:  image file corrupted when upload
>
> -php 3.0.18 under RedHat linux 6.2 , apache 1.3.14
> -php 3.0.16 and 4.0.3pl1 under SuSE linux 7.0 , apache 1.3.12
>
> I try to use upload files mechanism _in a correct manner_ with gif
> images files:
> - under Windows98 i have no problems, the files are upload correctly
> - under Linux with same version of php, the upload mechanism work but
> image file result corrupted
>
> then I try to open corrupted file and original file with hexeditor
> and surprise!
>
> I have found that the head of corrupted file begin like this:
>
>  43 6f 6e 74 65 6e 74 2d  54 79 70 65 3a 20 69 6d Content- Type: im
> 0010 61 67 65 2f 67 69 66 0d  0a 0d 0a 47 49 46 38 37 age/gif. ...GIF87
> 0020 61 98 01 4a 00 f7 00 00  00 00 00 ff ff ff 00 00 a..J.÷.. ...ÿÿÿ..
>
> a correct image file begin like this:
>
>  47 49 46 38 37 61 98 01  4a 00 f7 00 00 00 00 00 GIF87a.. J.÷.
> 0010 ff ff ff 00 00 00 00 00  00 00 00 00 00 00 00 00 ÿÿÿ. 
>
> I also tryed with jpeg , bmp , tif  and these files are uploaded
> correctly on SuSE 7.0 php 4.0.3pl1 .
> on RedHat 6.2 php 3.0.18 JPEG, files (and other??) some time are
> uploaded correctly but some time are corrupted with same bug:
>
>  43 6f 6e 74 65 6e 74 2d  54 79 70 65 3a 20 69 6d Content- Type: im
> 0010 61 67 65 2f 6a 70 65 67  0d 0a 0d 0a ff d8 ff e0 age/jpeg ÿØÿà
>
> the problem may be apache versions or some library versions ???
>
> with this bug I have a big problem for my work, for now I have try to
> write a little C program that correct files corrupted but I prefer a
> real solution!
>
>  help me!
>
> Samuele Catuzzi
> (from latina, italy)
>
>
>
>
> --
> 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 #9130: Connecting with sybase server makes php crash

[jpintoc]

From: [EMAIL PROTECTED]
Operating system: Win2000
PHP version:  4.0.4pl1
PHP Bug Type: Sybase-ct (ctlib) related
Bug description:  Connecting with sybase server makes php crash

There is a script that tries to connect to a sybase database, but when it uses 
sybase_connect(), i get an error window, whis says "unknown has generated errors and 
will be colsed by Windows. You must restart the program".

When ih click the OK button, the browser shows this messsage: 

"CGI ERROR. 

The specified CGI application my have an abnormal behavior if it doen not receive a 
complete set of HTTP headers. The returnde headres are: 

ERROR: could not get the task list"

I can see tha it happens in the sybase_connect() line of the script.

The environment:

Win2000, IIS 5, PHP 4.0.4pl1, Sybase 11.9.2




-- 
Edit Bug report at: http://bugs.php.net/?id=9130&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: PHP 4.0 Bug #9126 Updated: Compilation stop with

[Derick Rethans]

Hello

On Tue, 6 Feb 2001, PowerWeb root admin wrote:

> ./configure --prefix=/usr/local/pdflib-3.03 
>--with-tifflib=/usr/local/tiff-v3.5.6-beta --enable-shared 
>--with-pnglib=/usr/local/gnu --with-shared-pdflib

My bad, try --enable-shared-pdflib


Derick Rethans

-
  PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
 H.v. Tussenbroekstraat 1 - 6952 BL Dieren - The Netherlands
-


-- 
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 #9129 Updated: Compiling Errors

[wildwayz]

ID: 9129
User Update by: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Install and Config
Description: Compiling Errors

Also MySQL is version 3.21.33

Previous Comments:
---

[2001-02-06 08:44:54] [EMAIL PROTECTED]
I don't think this is a bug, php/apache compiles find on RedHat 5.2 for me. Try asking 
on the [EMAIL PROTECTED] mailinglist. If you are certain this is a bug, please 
reopen this bug report.

---

[2001-02-06 08:41:18] [EMAIL PROTECTED]
Hi, 

I am trying to upgrade from PHP3.0.7 to PHP4.0.4pl1 but I have had a nightmare.
Noone can tell me if PHP4.0.4 can be installed on RedHat 5.2 so I have that to contend 
with too.

Anyway

I am compiling with

./configure --with-mysql=/usr/local/mysql --with-config-file-path=/home/www/conf 
--with-apache=/usr/lib/perl5/site_perl/i386-linux/auto/Apache --enable-track-vars

and I get this...
Configuring SAPI modules
checking for AOLserver support... no
checking for Apache module support via DSO through APXS... no
checking for Apache module support... no
configure: error: Invalid Apache directory - unable to find httpd.h under 
/usr/lib/perl5/site_perl/i386-linux/auto/Apache

httpd.h is in the /usr/lib/perl5/site_perl/i386-linux/auto/Apache/include   folder

If I compile it without Apache, it is ok until I make it then I get

/usr/local/mysql/lib/libmysqlclient.a(mf_format.o): In function `fn_format':
mf_format.o(.text+0x201): undefined reference to `__lxstat64'
/usr/local/mysql/lib/libmysqlclient.a(my_fopen.o): In function `my_fopen':
my_fopen.o(.text+0x21): undefined reference to `fopen64'
make[1]: *** [php] Error 1
make[1]: Leaving directory `/home/webmaster/php-4.0.4pl1'
make: *** [all-recursive] Error 1


Any ideas?

Regards

James

---


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


-- 
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 #9129 Updated: Compiling Errors

[derick]

ID: 9129
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: *Install and Config
Assigned To: 
Comments:

I don't think this is a bug, php/apache compiles find on RedHat 5.2 for me. Try asking 
on the [EMAIL PROTECTED] mailinglist. If you are certain this is a bug, please 
reopen this bug report.

Previous Comments:
---

[2001-02-06 08:41:18] [EMAIL PROTECTED]
Hi, 

I am trying to upgrade from PHP3.0.7 to PHP4.0.4pl1 but I have had a nightmare.
Noone can tell me if PHP4.0.4 can be installed on RedHat 5.2 so I have that to contend 
with too.

Anyway

I am compiling with

./configure --with-mysql=/usr/local/mysql --with-config-file-path=/home/www/conf 
--with-apache=/usr/lib/perl5/site_perl/i386-linux/auto/Apache --enable-track-vars

and I get this...
Configuring SAPI modules
checking for AOLserver support... no
checking for Apache module support via DSO through APXS... no
checking for Apache module support... no
configure: error: Invalid Apache directory - unable to find httpd.h under 
/usr/lib/perl5/site_perl/i386-linux/auto/Apache

httpd.h is in the /usr/lib/perl5/site_perl/i386-linux/auto/Apache/include   folder

If I compile it without Apache, it is ok until I make it then I get

/usr/local/mysql/lib/libmysqlclient.a(mf_format.o): In function `fn_format':
mf_format.o(.text+0x201): undefined reference to `__lxstat64'
/usr/local/mysql/lib/libmysqlclient.a(my_fopen.o): In function `my_fopen':
my_fopen.o(.text+0x21): undefined reference to `fopen64'
make[1]: *** [php] Error 1
make[1]: Leaving directory `/home/webmaster/php-4.0.4pl1'
make: *** [all-recursive] Error 1


Any ideas?

Regards

James

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9129&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 #9129: Compiling Errors

[wildwayz]

From: [EMAIL PROTECTED]
Operating system: RedHat 5.2
PHP version:  4.0.4pl1
PHP Bug Type: *Install and Config
Bug description:  Compiling Errors

Hi, 

I am trying to upgrade from PHP3.0.7 to PHP4.0.4pl1 but I have had a nightmare.
Noone can tell me if PHP4.0.4 can be installed on RedHat 5.2 so I have that to contend 
with too.

Anyway

I am compiling with

./configure --with-mysql=/usr/local/mysql --with-config-file-path=/home/www/conf 
--with-apache=/usr/lib/perl5/site_perl/i386-linux/auto/Apache --enable-track-vars

and I get this...
Configuring SAPI modules
checking for AOLserver support... no
checking for Apache module support via DSO through APXS... no
checking for Apache module support... no
configure: error: Invalid Apache directory - unable to find httpd.h under 
/usr/lib/perl5/site_perl/i386-linux/auto/Apache

httpd.h is in the /usr/lib/perl5/site_perl/i386-linux/auto/Apache/include   folder

If I compile it without Apache, it is ok until I make it then I get

/usr/local/mysql/lib/libmysqlclient.a(mf_format.o): In function `fn_format':
mf_format.o(.text+0x201): undefined reference to `__lxstat64'
/usr/local/mysql/lib/libmysqlclient.a(my_fopen.o): In function `my_fopen':
my_fopen.o(.text+0x21): undefined reference to `fopen64'
make[1]: *** [php] Error 1
make[1]: Leaving directory `/home/webmaster/php-4.0.4pl1'
make: *** [all-recursive] Error 1


Any ideas?

Regards

James


-- 
Edit Bug report at: http://bugs.php.net/?id=9129&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 #9128: Memory Leak or Memory Problem.

[kaiser]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.4pl1
PHP Bug Type: Program Execution
Bug description:  Memory Leak or Memory Problem.

i coding a skin engine @ pixelcore.com and use template to parse it. I open this file 
with

$fp = fopen("http://",'r');
while

but if i forget to close this like and more that 20 users pars this skin i got some 
error messeages on screen.

Zend Stack crashed at xxx.c line 42 or so.

Regards Kaiser


-- 
Edit Bug report at: http://bugs.php.net/?id=9128&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: PHP 4.0 Bug #9126 Updated: Compilation stop withPDF_show_boxed in -lpdf... no

[Derick Rethans]

Hello,

what was your configure line for pdflib?

Derick

On Tue, 6 Feb 2001, PowerWeb root admin wrote:

> >
> > ID: 9126
> > Updated by: derick
> > Reported By: [EMAIL PROTECTED]
> > Old-Status: Open
> > Status: Closed
> > Bug Type: Compile Problem
> > Assigned To:
> > Comments:
> >
> > You need to compile pdflib --with-shared-pdflib for use with PHP. IF this still 
>causes problems, reopen this report.
>
> Well, does not help.
>
> It still creates only the files
> libpdf.a
> libpdf_java.a
> libpdf_java.la
> libpdf_java.so
> libpdf_java.so.0
> libpdf_java.so.0.1.1
>
> and PHP does not find them.
>
> Kind regards, Frank
>
> >
> > Previous Comments:
> > ---
> >
> > [2001-02-06 08:04:04] [EMAIL PROTECTED]
> > Including PDflib 3.0.3 into PHP4.0.4pl1 stops with
> >
> >   checking for PDF_show_boxed in -lpdf... no
> >   configure: error: pdflib extension requires pdflib 3.x.
> >
> > Somehow, PDFlib 3.0.3 created shared libs with the names
> > libpdf_java.so.0.1.1
> > wich are not recognized by PHPs configure
> >
> > Made a symbolic link resulting in a libpdf.so
> >
> > Works ...
> >
> > Kind regards, Frank Gadegast
> >
> > ---
> >
> >
> >
> > ATTENTION! Do NOT reply to this email!
> > To reply, use the web interface found at http://bugs.php.net/?id=9126&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]
>

Derick Rethans

-
  PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
 H.v. Tussenbroekstraat 1 - 6952 BL Dieren - The Netherlands
-


-- 
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 4.0 Bug #9126 Updated: Compilation stop with PDF_show_boxed in -lpdf... no

[PowerWeb root admin]

> 
> ID: 9126
> Updated by: derick
> Reported By: [EMAIL PROTECTED]
> Old-Status: Open
> Status: Closed
> Bug Type: Compile Problem
> Assigned To: 
> Comments:
> 
> You need to compile pdflib --with-shared-pdflib for use with PHP. IF this still 
>causes problems, reopen this report.

Well, does not help.

It still creates only the files
libpdf.a
libpdf_java.a
libpdf_java.la
libpdf_java.so
libpdf_java.so.0
libpdf_java.so.0.1.1

and PHP does not find them.

Kind regards, Frank

> 
> Previous Comments:
> ---
> 
> [2001-02-06 08:04:04] [EMAIL PROTECTED]
> Including PDflib 3.0.3 into PHP4.0.4pl1 stops with
> 
>   checking for PDF_show_boxed in -lpdf... no
>   configure: error: pdflib extension requires pdflib 3.x.
> 
> Somehow, PDFlib 3.0.3 created shared libs with the names
> libpdf_java.so.0.1.1
> wich are not recognized by PHPs configure
> 
> Made a symbolic link resulting in a libpdf.so
> 
> Works ...
> 
> Kind regards, Frank Gadegast
> 
> ---
> 
> 
> 
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at http://bugs.php.net/?id=9126&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 #9127: submitting a boolean to an attribute seems to fail

[hans]

From: [EMAIL PROTECTED]
Operating system: Linux kernel 2.4.0
PHP version:  4.0.4pl1
PHP Bug Type: Class/Object related
Bug description:  submitting a boolean to an attribute seems to fail

I've been working with a class and had some slight problems. One of the attributes is 
declared as a boolean (default = false) within the class and I can't seem to set it to 
true form within a function. It doesn't help setting the boolean to true as a default 
and changing it to false. This will have the same effect, no change.

A workaround is to declare the boolean global but I do not like it. Is this a bug or 
am I blond?

Regards,

Hans


-- 
Edit Bug report at: http://bugs.php.net/?id=9127&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 #9126 Updated: Compilation stop with PDF_show_boxed in -lpdf... no

[derick]

ID: 9126
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Compile Problem
Assigned To: 
Comments:

You need to compile pdflib --with-shared-pdflib for use with PHP. IF this still causes 
problems, reopen this report.

Previous Comments:
---

[2001-02-06 08:04:04] [EMAIL PROTECTED]
Including PDflib 3.0.3 into PHP4.0.4pl1 stops with

  checking for PDF_show_boxed in -lpdf... no
  configure: error: pdflib extension requires pdflib 3.x.

Somehow, PDFlib 3.0.3 created shared libs with the names
libpdf_java.so.0.1.1
wich are not recognized by PHPs configure

Made a symbolic link resulting in a libpdf.so

Works ...

Kind regards, Frank Gadegast

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9126&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 #9126: Compilation stop with PDF_show_boxed in -lpdf... no

[webmaster]

From: [EMAIL PROTECTED]
Operating system: Solaris/Linux
PHP version:  4.0.4pl1
PHP Bug Type: Compile Problem
Bug description:  Compilation stop with PDF_show_boxed in -lpdf... no

Including PDflib 3.0.3 into PHP4.0.4pl1 stops with

  checking for PDF_show_boxed in -lpdf... no
  configure: error: pdflib extension requires pdflib 3.x.

Somehow, PDFlib 3.0.3 created shared libs with the names
libpdf_java.so.0.1.1
wich are not recognized by PHPs configure

Made a symbolic link resulting in a libpdf.so

Works ...

Kind regards, Frank Gadegast


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



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

[PHP-DEV] Bug #9125: image file corrupted when upload

[samuele_catuzzi]

From: [EMAIL PROTECTED]
Operating system: Linux redhat 6.2 & SuSE 7.0 on intel platform
PHP version:  3.0.17
PHP Bug Type: Other
Bug description:  image file corrupted when upload

-php 3.0.18 under RedHat linux 6.2 , apache 1.3.14
-php 3.0.16 and 4.0.3pl1 under SuSE linux 7.0 , apache 1.3.12

I try to use upload files mechanism _in a correct manner_ with gif 
images files:
- under Windows98 i have no problems, the files are upload correctly
- under Linux with same version of php, the upload mechanism work but  
image file result corrupted

then I try to open corrupted file and original file with hexeditor
and surprise! 

I have found that the head of corrupted file begin like this:

 43 6f 6e 74 65 6e 74 2d  54 79 70 65 3a 20 69 6d Content- Type: im
0010 61 67 65 2f 67 69 66 0d  0a 0d 0a 47 49 46 38 37 age/gif. ...GIF87
0020 61 98 01 4a 00 f7 00 00  00 00 00 ff ff ff 00 00 a..J.÷.. ...ÿÿÿ..

a correct image file begin like this:

 47 49 46 38 37 61 98 01  4a 00 f7 00 00 00 00 00 GIF87a.. J.÷.
0010 ff ff ff 00 00 00 00 00  00 00 00 00 00 00 00 00 ÿÿÿ. 

I also tryed with jpeg , bmp , tif  and these files are uploaded 
correctly on SuSE 7.0 php 4.0.3pl1 .
on RedHat 6.2 php 3.0.18 JPEG, files (and other??) some time are 
uploaded correctly but some time are corrupted with same bug:

 43 6f 6e 74 65 6e 74 2d  54 79 70 65 3a 20 69 6d Content- Type: im
0010 61 67 65 2f 6a 70 65 67  0d 0a 0d 0a ff d8 ff e0 age/jpeg ÿØÿà

the problem may be apache versions or some library versions ???

with this bug I have a big problem for my work, for now I have try to 
write a little C program that correct files corrupted but I prefer a 
real solution!

 help me!

Samuele Catuzzi 
(from latina, italy)




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

[E-alliance - Bruno]

Hi,
How can i send a request form by fax? I'm trying to 
begin a business!
 
Thanks,
Bruno.
PS: Sorry, my english is not too 
good!

[PHP-DEV] PHP 4.0 Bug #8938 Updated: Segfaults

[cecot]

ID: 8938
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproduceable crash
Description: Segfaults

sorry for the double report, but when I restarted the apache some of the children died 
with segmentation fault

Previous Comments:
---

[2001-02-06 06:18:41] [EMAIL PROTECTED]
at about 2001-02-05 19:00 EET I got the CVS again and my observation is that there are 
no Segmentation faults for more than 15 hours, but there is still a lot of HTML code 
in my error.log file, if it helps

---

[2001-02-02 07:37:36] [EMAIL PROTECTED]
the bug is still there.

1. I get from CVS (today) not from snaps does it matter ??
2. in my debian distribution i have /usr/sbin/apache and /usr/sbin/apache.dbg, i made 
/usr/sbin writable by www-data (the apache user) both the apache and apache.dbg didn't 
make core file (the php from the CVS was compiled with --enable-debug=on).
3. I tried gdb /usr/sbin/apache and run -X. when I access any page with a browser 
nothing was seen in the browser neighter in gdb. the same with gdb 
/usr/sbin/apache.dbg (probaly i didn't give it enough time to start or I did something 
wrong, give some more inforamtion on how to do it)

---

[2001-02-01 20:06:54] [EMAIL PROTECTED]
Can you try again with today's snapshot? And to get a decent gdb backtrace
configure with --enable-debug and do following:

# gdb /opt/www/bin/httpd
(gdb) run -X

And then access the page which causes the crash and if it crashes:

(gdb) bt full

and then cut'n'paste the output and add it into this bug report.

--Jani


---

[2001-01-30 08:43:03] [EMAIL PROTECTED]
I got today the latest CVS and again gives segfaults but didn't manage to get core 
file :(


---

[2001-01-29 05:14:06] [EMAIL PROTECTED]
Does this happen with the latest CVS snapshot from
http://snaps.php.net/ ?? And if it does, please include
a gdb backtrace of the crash into this bug report.

--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: http://bugs.php.net/?id=8938


-- 
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 #8938 Updated: Segfaults

[cecot]

ID: 8938
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproduceable crash
Description: Segfaults

at about 2001-02-05 19:00 EET I got the CVS again and my observation is that there are 
no Segmentation faults for more than 15 hours, but there is still a lot of HTML code 
in my error.log file, if it helps

Previous Comments:
---

[2001-02-02 07:37:36] [EMAIL PROTECTED]
the bug is still there.

1. I get from CVS (today) not from snaps does it matter ??
2. in my debian distribution i have /usr/sbin/apache and /usr/sbin/apache.dbg, i made 
/usr/sbin writable by www-data (the apache user) both the apache and apache.dbg didn't 
make core file (the php from the CVS was compiled with --enable-debug=on).
3. I tried gdb /usr/sbin/apache and run -X. when I access any page with a browser 
nothing was seen in the browser neighter in gdb. the same with gdb 
/usr/sbin/apache.dbg (probaly i didn't give it enough time to start or I did something 
wrong, give some more inforamtion on how to do it)

---

[2001-02-01 20:06:54] [EMAIL PROTECTED]
Can you try again with today's snapshot? And to get a decent gdb backtrace
configure with --enable-debug and do following:

# gdb /opt/www/bin/httpd
(gdb) run -X

And then access the page which causes the crash and if it crashes:

(gdb) bt full

and then cut'n'paste the output and add it into this bug report.

--Jani


---

[2001-01-30 08:43:03] [EMAIL PROTECTED]
I got today the latest CVS and again gives segfaults but didn't manage to get core 
file :(


---

[2001-01-29 05:14:06] [EMAIL PROTECTED]
Does this happen with the latest CVS snapshot from
http://snaps.php.net/ ?? And if it does, please include
a gdb backtrace of the crash into this bug report.

--Jani

---

[2001-01-26 10:38:10] [EMAIL PROTECTED]
when I enable output_handler = ob_gzhandler in php.ini the system works but on some 
conditions I do not know which in error-log of the apache comes a lot of SegFaults and 
even more - the html content of some of the pages. There are also clients who complain 
that cannot open the pages ('no content' states Netscape)

on few other machines which are much heavy loaded and they can't stand output_handler 
= ob_gzhandler in php.ini that's why we use only on some scripts

if (strstr($HTTP_SERVER_VARS['HTTP_ACCEPT_ENCODING'], 
'gzip')){ob_start("gzencode");header("Content-Encoding: gzip");} 

and the same problem happens again

---

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


-- 
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] Resurrecting the Function Renaming Thread

[Phil Driscoll]

>Anyone else want to pipe in on this thread? I believe that the naming is
>still a significant issue. Just last week Jim - Jim fer diety's sake - made
>the is_set != isset mistake.

Sorry for late input on this one - just got back from holiday, but I'd just
like to say that I think it is important that we address this issue. I don't
care too much what mechanism we use to get there, but it would be really
good if at some point in the nearish future there is a clean, orthogonal
version of the language which can be called official or pure PHP, where
function names and the order of arguments obey sensible consistent rules. It
does not matter if PHP has to carry legacy baggage around with it for some
time, but it does matter that we should all be able to program without
having to remember special cases and taking a quick peek in the manual to
find things like the order of needles and haystacks, or whether or not an
underscore is required.

Also, a cleaned up language gives people fewer excuses for not adopting PHP.

Anyway, count me in for help with any work/discussion required.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org



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