Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query andpossible integer overflow?

[Matt Flaherty]

Thanks guys for your feedback. With regard to PEAR, I've had to patch
PEAR::DB::mysql to solve another problem I've had with the
prepared_queries field growing steadily. I'm sure this is also a problem
with the either DB subclasses. I'll post my patch to pear-dev as I don't
have a CVS account yet.

-Matt



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query and possible integer overflow?

[Zak Greant]

D'oh - read too little, too fast. :)

On Tue, Mar 25, 2003 at 05:55:42PM -0800, Zeev Suraski wrote:
> I believe he meant the query id's that the engine uses, and not the auto 
> increment id's.  Wez's response was accurate, we'll overflow at some 
> point.  This is basically because PHP was designed with short requests in 
> mind.  We could probably fix it relatively easily for ZE2.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query and possible integer overflow?

[Zeev Suraski]

I believe he meant the query id's that the engine uses, and not the auto 
increment id's.  Wez's response was accurate, we'll overflow at some 
point.  This is basically because PHP was designed with short requests in 
mind.  We could probably fix it relatively easily for ZE2.

Zeev

At 13:15 25/03/2003, Zak Greant wrote:
On Tue, Mar 25, 2003 at 01:50:17PM +, Matt Flaherty wrote:
> Hi,
>
> I have a question for the authors of the mysql extension. I'm sure you
> gentlemen are very busy, but I'd appreciate your insight if you can
> spare a moment. I'm developing a stand-alone php application running in
> an infinite loop from the command line interface. A mysql database is
> polled continually for new rows to deal with. The same query is executed
> several times in one second. I've noticed that whether or not a query
> resource is freed the next query identifier returned from mysql_query()
> is ++ the last one. I'm sure this is by design and governed by the mysql
> driver. Naturally I'm concerned about integer overflow when the the
> application has been running uninterrupted for a very long time. I don't
> think I can wait around while a test script runs to see what happens
> after 4,294,967,295 is exceeded though! Can anyone tell me with
> certainty or hazard a guess what might happen here? I thank you very
> much for your time.
  The query that generates an auto_increment value larger than the largest
  value allowed for the column will fail with error 1062 (Duplicate
  entry 'xxx' for key 1)
> Matt
>
> ps - I'm doing this through PEAR::DB::mysql
  I am not exactly sure how PEAR::DB will propagate this error through
  its error handling interface.
  An easy way to test this is to create a temporary table that has a
  TINYINT as its auto_incrementing primary key, fill the table up and
  then watch to see what breaks.
  Cheers!
  --zak
--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query and possible integer overflow?

[Zak Greant]

On Tue, Mar 25, 2003 at 01:50:17PM +, Matt Flaherty wrote:
> Hi,
> 
> I have a question for the authors of the mysql extension. I'm sure you
> gentlemen are very busy, but I'd appreciate your insight if you can
> spare a moment. I'm developing a stand-alone php application running in
> an infinite loop from the command line interface. A mysql database is
> polled continually for new rows to deal with. The same query is executed
> several times in one second. I've noticed that whether or not a query
> resource is freed the next query identifier returned from mysql_query()
> is ++ the last one. I'm sure this is by design and governed by the mysql
> driver. Naturally I'm concerned about integer overflow when the the
> application has been running uninterrupted for a very long time. I don't
> think I can wait around while a test script runs to see what happens
> after 4,294,967,295 is exceeded though! Can anyone tell me with
> certainty or hazard a guess what might happen here? I thank you very
> much for your time.

  The query that generates an auto_increment value larger than the largest
  value allowed for the column will fail with error 1062 (Duplicate
  entry 'xxx' for key 1)

> Matt
> 
> ps - I'm doing this through PEAR::DB::mysql

  I am not exactly sure how PEAR::DB will propagate this error through
  its error handling interface.

  An easy way to test this is to create a temporary table that has a
  TINYINT as its auto_incrementing primary key, fill the table up and
  then watch to see what breaks.
  
  Cheers!
  --zak

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query andpossible integer overflow?

[Matt Flaherty]

Thanks Wez,

If all that happens is the query will fail, I can live with that. It's a
simple SELECT query called over and over again. If the integer wraps
around negative, I'm guessing that would probably have undesirable
effects. If not, then I can let it run forever. What I don't want is
something like a segfault. I'm considering making the application
restart itself periodically to clear out the cobwebs.

-Matt

On Tue, 2003-03-25 at 14:12, Wez Furlong wrote:
> Hi Matt,
> 
> Yes, there is a risk of overflow.
> >From my understanding, the id is signed, so you will hit overflow at 2G
> rather than 4G resources.
> This applies to any/all PHP/ZE resources.
> 
> I'm not sure what happens when it overflows; it seems like the query
> would fail.
> 
> You could design your application so that it re-runs itself when the
> query fails (pcntl_exec(), or one of the other execution functions).
> 
> --Wez.
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query andpossible integer overflow?

[Wez Furlong]

Hi Matt,

Yes, there is a risk of overflow.
>From my understanding, the id is signed, so you will hit overflow at 2G
rather than 4G resources.
This applies to any/all PHP/ZE resources.

I'm not sure what happens when it overflows; it seems like the query
would fail.

You could design your application so that it re-runs itself when the
query fails (pcntl_exec(), or one of the other execution functions).

--Wez.

On Tue, 25 Mar 2003, Matt Flaherty wrote:

> Hi,
>
> I have a question for the authors of the mysql extension. I'm sure you
> gentlemen are very busy, but I'd appreciate your insight if you can
> spare a moment. I'm developing a stand-alone php application running in
> an infinite loop from the command line interface. A mysql database is
> polled continually for new rows to deal with. The same query is executed
> several times in one second. I've noticed that whether or not a query
> resource is freed the next query identifier returned from mysql_query()
> is ++ the last one. I'm sure this is by design and governed by the mysql
> driver. Naturally I'm concerned about integer overflow when the the
> application has been running uninterrupted for a very long time. I don't
> think I can wait around while a test script runs to see what happens
> after 4,294,967,295 is exceeded though! Can anyone tell me with
> certainty or hazard a guess what might happen here? I thank you very
> much for your time.
>
> Matt
>
> ps - I'm doing this through PEAR::DB::mysql
> --
> Matt Flaherty <[EMAIL PROTECTED]>
> Boltblue International Ltd.
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Question for Zeev, Zak or Georg - mysql_query and possible integeroverflow?

[Matt Flaherty]

Hi,

I have a question for the authors of the mysql extension. I'm sure you
gentlemen are very busy, but I'd appreciate your insight if you can
spare a moment. I'm developing a stand-alone php application running in
an infinite loop from the command line interface. A mysql database is
polled continually for new rows to deal with. The same query is executed
several times in one second. I've noticed that whether or not a query
resource is freed the next query identifier returned from mysql_query()
is ++ the last one. I'm sure this is by design and governed by the mysql
driver. Naturally I'm concerned about integer overflow when the the
application has been running uninterrupted for a very long time. I don't
think I can wait around while a test script runs to see what happens
after 4,294,967,295 is exceeded though! Can anyone tell me with
certainty or hazard a guess what might happen here? I thank you very
much for your time.

Matt

ps - I'm doing this through PEAR::DB::mysql
-- 
Matt Flaherty <[EMAIL PROTECTED]>
Boltblue International Ltd.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Question on startup

[Marcus Börger]

Can anybody answer this: Why do we have a sapi_deactivate(TSRMLS_C);
call in php_module_startup()?
marcus

--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question about zend_compile

[George Schlossnagle]

Look at apc.  It tracks per-file function and class tables.

http://apc.communityconnect.com/  (v2.0)
pear/PECL/apc (v1.x)
Both versions do the thing you wish for.

--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Question about zend_compile

[John Coggeshall]

I'm playing around with the compiler/executor and I was wondering if
someone could answer a question.. 

Is there any reasonable way to essentially push/pop the function table?
What I'd like to do is get a function_table hash for only a single file
(pesudo code below):

PUSH_FUNCTION_TABLE(CG(function_table))
Op_array = zend_compile_file(fh, ZEND_REQUIRE);

/* retrieve information from the function_table 
about the functions in the fh handle only*/

POP_FUNCTION_TABLE(CG(function_table))

Specifically, I'd like to get the zend_function structures for the
user-defined functions declared inside of myfile.php... Basically my
problem is I have a userspace get_func_info($filename) function which
works great when retrieving information from the function table after
zend_compile_file(), but I end up having more functions than I wanted
since every user-defined function regardless of file (including the file
I'm in) is in the hash... i.e.

Myscript.php


It seems to me that this is exactly the sort of thing I would want to
use namespaces for, is there a elequent way to create a new namespace
from within my C function temporarily between when my function is called
and returns?

Suggestions? 

John



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question on bug list

[Sander Roobol]

On Sun, Feb 02, 2003 at 01:17:41PM -0800, Sara Golemon wrote:
> > Jesus suggested the same thing, I'm trying out a few different approaches
> to
> > see what looks best, I'll post again when I have something usable.
> >
> http://frankenbox.alphaweb.net/test/export.phps
> 

Looks good and useful. +1.

Sander

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question on bug list

[Sara Golemon]

> > Wouldn't it be nice/more useful to generate RDF/RSS on a per-bug basis?
> > Then you could just add the feed url to your favourite RSS client.
> >
> > If you make it do that, then I will take a look and commit, provided
> > that there are no objections to this.
> >
> Jesus suggested the same thing, I'm trying out a few different approaches
to
> see what looks best, I'll post again when I have something usable.
>
http://frankenbox.alphaweb.net/test/export.phps

In normal mode (called as http://bugs.php.net/export.php?id=12345 ) it would
output an RSS 1.0 valid bug listing similar to the following output:

http://frankenbox.alphaweb.net/test/export.rss

It also allows for a more detailed extract (called as
http://bugs.php.net/export.php?id=12345&format=xml ) which includes all the
information related to the bug (except password, I accidently included that
field in my first sample)  Output sample:

http://frankenbox.alphaweb.net/test/export.xml

-Pollita


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question on bug list

[Sara Golemon]

> Wouldn't it be nice/more useful to generate RDF/RSS on a per-bug basis?
> Then you could just add the feed url to your favourite RSS client.
>
> If you make it do that, then I will take a look and commit, provided
> that there are no objections to this.
>
Jesus suggested the same thing, I'm trying out a few different approaches to
see what looks best, I'll post again when I have something usable.

-Pollita



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question on bug list

[Wez Furlong]

Hey,

Wouldn't it be nice/more useful to generate RDF/RSS on a per-bug basis?
Then you could just add the feed url to your favourite RSS client.

If you make it do that, then I will take a look and commit, provided
that there are no objections to this.

--Wez.

On Fri, 31 Jan 2003, Sara Golemon wrote:

> > I have a "daily page" I go to every morning which contains all my news
> > feeds, some comic strips, movie listings, etc If there were a
> > programmatic query interface to bugs.php.net I could select bug #s to
> track,
> > and be able to bring up histories of them from my daily page.
> >
> To that end... here's a simple script (based heavily on
> php-bugs-web/bug.php) to do just that:
>
> http://frankenbox.alphaweb.net/test/export.phps
>
> Meant to be called as:
>
> http://bugs.php.net/export.php?id=1234
>
>
> If it's deemed worthy could someone add it to php-bugs-web?  I don't have
> the karma.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question on bug list

[Sara Golemon]

> > >I had two questions: One to assign to all NEW messages and one
> > >feature request to assign to selective bugs...I wanted to avoid reading
> > >all messages on any bug. Thats overkill...
> >
> > Get a mail client that can handle threading..
>
> PHP-Bugs doesn't have "In-Reply-To" and "References", does it?
>
Actually, it does... Here's a sample:

In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question on bug list

[Daniel Lorch]

hi,

> >I had two questions: One to assign to all NEW messages and one
> >feature request to assign to selective bugs...I wanted to avoid reading
> >all messages on any bug. Thats overkill...
> 
> Get a mail client that can handle threading..

PHP-Bugs doesn't have "In-Reply-To" and "References", does it?

-daniel

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question on bug list

[Sara Golemon]

> I have a "daily page" I go to every morning which contains all my news
> feeds, some comic strips, movie listings, etc If there were a
> programmatic query interface to bugs.php.net I could select bug #s to
track,
> and be able to bring up histories of them from my daily page.
>
To that end... here's a simple script (based heavily on
php-bugs-web/bug.php) to do just that:

http://frankenbox.alphaweb.net/test/export.phps

Meant to be called as:

http://bugs.php.net/export.php?id=1234


If it's deemed worthy could someone add it to php-bugs-web?  I don't have
the karma.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question on bug list

[Sara Golemon]

> > Wouldn't it be nice if one could attach himself to a bug and receive an
email
> > on every new message to that bug?
> >
I have a "daily page" I go to every morning which contains all my news
feeds, some comic strips, movie listings, etc If there were a
programmatic query interface to bugs.php.net I could select bug #s to track,
and be able to bring up histories of them from my daily page.

Something along the lines of:

http://bugs.php.net/export.php?bugid=12345

which would output:


  12345
  [EMAIL PROTECTED]
  Jan 30, 2003 12:45 pm PST -0800
  Bogus
  
[EMAIL PROTECTED]
Jan 31, 2003 8:13 am PST -0800
bogus
Your comment does not imply a bug in PHP itselfblah blah
blah...
  
  
[EMAIL PROTECTED]
Jan 30, 2003 12:45 pm PST -0800
NEW
I havn't read the manual
  



Obviously not all the information one would look for, basicly the output of
'bug.php' but in XML format for easy parsing.

Anyway, if I went to the trouble of writting this page, would it be
accepted?  Or at least entertained?  Does such an animal already exist?

-Pollita


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question on bug list

[Moriyoshi Koizumi]

[EMAIL PROTECTED] (Marcus Börger) wrote:

> Wouldn't it be nice if one could attach himself to a bug and receive an email
> on every new message to that bug?
> 
> And then how am i informed about new bugs? Is there a mailing list for that?
> Currently i read the bug-summary-list..

I was thinking of a similar bug db feature too, though my idea seems 
rather user-oriented.

IMO it would be nice if a commenter could make a choice to receive 
notifications by every new comment. I suppose that would be useful if 
you wanted feedbacks from multiple users.

In a QA member's point of view, I don't see that much need for "my 
favourite bugs" because my MUA is just doing enough.

Moriyoshi



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question on bug list

[Marcus Börger]

At 11:37 31.01.2003, Jani Taskinen wrote:

On Fri, 31 Jan 2003, Marcus Börger wrote:

>I had two questions: One to assign to all NEW messages and one
>feature request to assign to selective bugs...I wanted to avoid reading
>all messages on any bug. Thats overkill...

Get a mail client that can handle threading..




Yes and no - my idea was to make the handling a bit more comfortable.


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question on bug list

[Jani Taskinen]

On Fri, 31 Jan 2003, Marcus Börger wrote:

>I had two questions: One to assign to all NEW messages and one
>feature request to assign to selective bugs...I wanted to avoid reading
>all messages on any bug. Thats overkill...

Get a mail client that can handle threading..

--Jani
   


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question on bug list

[Marcus Börger]

At 10:24 31.01.2003, Thomas Seifert wrote:



On Fri, 31 Jan 2003 02:49:01 + [EMAIL PROTECTED] (Daniel Lorch) wrote:

> hi,
>
> > > Wouldn't it be nice if one could attach himself to a bug and 
receive an
> > > email
> > > on every new message to that bug?
> > >
> > > And then how am i informed about new bugs? Is there a mailing list for
> > > that?
> > > Currently i read the bug-summary-list..
> > >
> >
> > [EMAIL PROTECTED]
>
> Empty mail to <[EMAIL PROTECTED]> should do it.


This will send you EVERY message about any bug.
What Marcus meant was to subscribe to ONE bug I think.

I had two questions: One to assign to all NEW messages and one
feature request to assign to selective bugs...I wanted to avoid reading
all messages on any bug. Thats overkill...

marcus


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question on bug list

[Thomas Seifert]

On Fri, 31 Jan 2003 02:49:01 + [EMAIL PROTECTED] (Daniel Lorch) wrote:

> hi,
> 
> > > Wouldn't it be nice if one could attach himself to a bug and receive an 
> > > email
> > > on every new message to that bug?
> > > 
> > > And then how am i informed about new bugs? Is there a mailing list for 
> > > that?
> > > Currently i read the bug-summary-list..
> > > 
> > 
> > [EMAIL PROTECTED]
> 
> Empty mail to <[EMAIL PROTECTED]> should do it.


This will send you EVERY message about any bug.
What Marcus meant was to subscribe to ONE bug I think.



Thomas

-- 
Thomas Seifert

mailto:[EMAIL PROTECTED]
http://www.MyPhorum.de 

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question on bug list

[Daniel Lorch]

hi,

> > Wouldn't it be nice if one could attach himself to a bug and receive an 
> > email
> > on every new message to that bug?
> > 
> > And then how am i informed about new bugs? Is there a mailing list for 
> > that?
> > Currently i read the bug-summary-list..
> > 
> 
> [EMAIL PROTECTED]

Empty mail to <[EMAIL PROTECTED]> should do it.

-daniek

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question on bug list

[Tal Peer]

Marcus Börger wrote:

Wouldn't it be nice if one could attach himself to a bug and receive an 
email
on every new message to that bug?

And then how am i informed about new bugs? Is there a mailing list for 
that?
Currently i read the bug-summary-list..


[EMAIL PROTECTED]


marcus






--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Question on bug list

[Marcus Börger]

Wouldn't it be nice if one could attach himself to a bug and receive an email
on every new message to that bug?

And then how am i informed about new bugs? Is there a mailing list for that?
Currently i read the bug-summary-list..

marcus


--
--->>> mailto:[EMAIL PROTECTED] <<<--
"We are animals among animals, all children of matter,
save that we are the more disarmed. But since, unlike animals,
we know that we must die, let us prepare for that moment
by enjoying the life that has been given us by chance and for chance."
   Umberto Eco, The island of the day before
->>> http://marcus-boerger.de <<<-


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question on SSL.

[Wei Weng]

Sorry about it if I had written to the wrong mailing list.

Since it was a php internal question, I thought php-dev would be a better place
since people here have better understandings of how php works.

Thanks

Wei


- Original Message -
From: "Derick Rethans" <[EMAIL PROTECTED]>
To: "Wei Weng" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, January 27, 2003 1:02 PM
Subject: Re: [PHP-DEV] Question on SSL.


> Hello,
>
> please forward user questions to the [EMAIL PROTECTED]
> mailinglist, this list is for development _OF_ PHP, not development
> _with_ PHP.
>
> Derick
>
> On Mon, 27 Jan 2003, Wei Weng wrote:
>
> > This question is a bit Apache specific.
> >
> > How does PHP detect whether it is on a SSL connection (with respect to an
Apache
> > server)?
> >
> > Thanks
> >
> >
> > Wei
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> --
>
> -
>  Derick Rethans http://derickrethans.nl/
>  PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
> -
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question on SSL.

[Derick Rethans]

Hello,

please forward user questions to the [EMAIL PROTECTED]
mailinglist, this list is for development _OF_ PHP, not development
_with_ PHP.

Derick

On Mon, 27 Jan 2003, Wei Weng wrote:

> This question is a bit Apache specific.
> 
> How does PHP detect whether it is on a SSL connection (with respect to an Apache
> server)?
> 
> Thanks
> 
> 
> Wei
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Question on SSL.

[Wei Weng]

This question is a bit Apache specific.

How does PHP detect whether it is on a SSL connection (with respect to an Apache
server)?

Thanks


Wei


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Question about Classes

[Juerg Zgraggen]

hi

i made a class in PHP. id like to define public and private function for
that class like in C++. is this possible? the public and private inside the
class does not work... why?

thanx, jürg zgraggen

/* My Class*/
 class bz_ClassX
 {
  var $nNumber;
  var $strDescription;
  var $strModul;

// public:??? does not work
  function bz_ClassX()
  {
   $this->bz_reset();
  }
  function bz_print()
  {
   echo "Return-Object";
   echo "";
   echo "Modul:" . $this->strModul . "";
   echo "Method:" . $this->strMethod . "";
   echo "Number:" . $this->nNumber . "";
   echo "Description:" . $this->strDescription .
"";
   echo "";
  }
  function bz_clear()
  {
   $this->bz_reset();
  }

// private:??? does not work
  function bz_reset()
  {
   $this->strModul = "Unknown";
   $this->strMethod = "Unknown";
   $this->nNumber = 0;
   $this->strDescription = "Unknown";
  }
 }





-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Question regarding zend_hash_*_functions and bug 17490

[Douglas Hawkins]

I already posted this, but received no responses.  For that reason, I 
am posting it again.


I have been investigating the cause of bug 17490 which appears to have 
been a problem with the serializer.  I am working with the PHP 4.2.3 source.
http://bugs.php.net/bug.php?id=17490

The cause of the problem appears to be that zend_hash_num_elements was 
returning a number smaller than the actual number of elements being iterated across 
using the zend_hash_*_ex functions.

This caused the serializer to store a number of elements smaller than 
the actual number of elements written.  This in turn leads to the unserializer failing 
later.

I would like to know if there is some reason why 
zend_hash_num_elements would be expected to return a value smaller than the number of 
actual elements iterated across using the zend_hash_*_ex functions.  This problem is 
rare, but was happening sporadically.

Below is the section of code that is displaying this behavior.   If 
you see any obvious errors please let me know.

Thank you in advance,
Douglas Q. Hawkins


static inline void php_var_serialize_hash_all(
   smart_str *buf,
   zval **struc,
   HashTable *var_hash TSRMLS_DC )
{
   int numElements;
   int cur;
   int actualCount;
   
   smart_str tmp = {0};
   
   numElements = zend_hash_num_elements( HASH_OF( *struc ) );

/* There is a problem with the value returned by 
zend_hash_num_elements
   not returning a value equivalent to the number elements 
actually
   iterated across using zend_hash_*_ex functions */

/* Solution iterate filling a temporary buffer and remembering 
the count -
   then copy the temporary buffer into the actual buffer */

if ( numElements > 0 )
{
char *key;
zval **data;
ulong index;
uint key_len;
HashPosition pos;   

for (
   /* initialize */
   zend_hash_internal_pointer_reset_ex(
  HASH_OF( *struc ),
  &pos ),
   actualCount = 0;
  
   /* test */;

   /* advance */
   zend_hash_move_forward_ex(
HASH_OF( *struc ),
&pos ),
   ++actualCount )
{   
   cur = zend_hash_get_current_key_ex(
  HASH_OF( *struc ),
  &key,
  &key_len, 
   &index,
   0,
   &pos );


if ( cur == HASH_KEY_NON_EXISTANT ) break;

switch ( cur )
{
  case HASH_KEY_IS_LONG:
php_var_serialize_long( &tmp, 
index );
break; 
 

case HASH_KEY_IS_STRING:
php_var_serialize_string( 
&tmp, key, key_len - 1 );
break;
}

/* we should still add element even if it's 
not OK,
   since we already wrote the length of the 
array before */
if ( ( zend_hash_get_current_data_ex( 
 HASH_OF( *struc ),
 ( void ** ) &data,

[PHP-DEV] Question regarding zend_hash_* functions

[Douglas Hawkins]

I have been investigating the cause of bug 17490 which appears to have been a problem 
with the serializer.  I am working with the PHP 4.2.3 source.
http://bugs.php.net/bug.php?id=17490

The cause of the problem appears to be that zend_hash_num_elements was returning a 
number smaller than the actual number of elements being iterated across using the 
zend_hash_*_ex functions.

This caused the serializer to store a number of elements smaller than the actual 
number of elements written.  This in turn leads to the unserializer failing later.

I would like to know if there is some reason why zend_hash_num_elements would be 
expected to return a value smaller than the number of actual elements iterated across 
using the zend_hash_*_ex functions.  This problem is rare, but was happening 
sporadically.

Below is the section of code that is displaying this behavior.   If you see any 
obvious errors please let me know.

Thank you in advance,
Douglas Q. Hawkins


static inline void php_var_serialize_hash_all(
   smart_str *buf,
   zval **struc,
   HashTable *var_hash TSRMLS_DC )
{
   int numElements;
   int cur;
   int actualCount;
   
   smart_str tmp = {0};
   
   numElements = zend_hash_num_elements( HASH_OF( *struc ) );

/* There is a problem with the value returned by zend_hash_num_elements
   not returning a value equivalent to the number elements actually
   iterated across using zend_hash_*_ex functions */

/* Solution iterate filling a temporary buffer and remembering the count -
   then copy the temporary buffer into the actual buffer */

if ( numElements > 0 )
{
char *key;
zval **data;
ulong index;
uint key_len;
HashPosition pos;   

for (
   /* initialize */
   zend_hash_internal_pointer_reset_ex(
  HASH_OF( *struc ),
  &pos ),
   actualCount = 0;
  
   /* test */;

   /* advance */
   zend_hash_move_forward_ex(
HASH_OF( *struc ),
&pos ),
   ++actualCount )
{   
   cur = zend_hash_get_current_key_ex(
  HASH_OF( *struc ),
  &key,
  &key_len, 
   &index,
   0,
   &pos );


if ( cur == HASH_KEY_NON_EXISTANT ) break;

switch ( cur )
{
  case HASH_KEY_IS_LONG:
php_var_serialize_long( &tmp, index );
break;  

case HASH_KEY_IS_STRING:
php_var_serialize_string( &tmp, key, key_len - 
1 );
break;
}

/* we should still add element even if it's not OK,
   since we already wrote the length of the array before */
if ( ( zend_hash_get_current_data_ex( 
 HASH_OF( *struc ),
 ( void ** ) &data,
 &pos ) != SUCCESS ) ||
  ( ! data ) ||
   ( data == struc ) )
  {
php_var_serialize_null( &tmp );
  } 
else
{
   php_var_serialize_intern(
  &tmp,
  data,
  var_hash TSRMLS_CC );
}
}
}
else
  {
 actualCount = 0;
  }

smart_str_append_long( buf, actualCount );
smart_str_appendc( buf, TYPE_VALUE_DELIMITER_CHAR );
smart_str_appendc( buf, OPEN_HASH_CHAR );   
smart_str_appendl( buf, tmp.c, tmp.len );
smart_str_appendc( buf, CLOSE_HASH_CHAR );
}




--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question, might be stupid...

[DJ Anubis]

Le Jeudi 26 Septembre 2002 04:12, Ken a écrit :
> I have a HTML form that has a session variable called $cost. Now I want to
> set the value to this table data input field. Anyone know how this is
> accomplished?
>
> 
>
> Thanks in advance!

This list is only intended for core PHP development.
You should ask this in php-general. Or, even better, browse the 
http://www.phpcomplete.com/ site where you'll find very good tutorials.

DJ Anubis


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Question, might be stupid...

[Ken]

I have a HTML form that has a session variable called $cost. Now I want to
set the value to this table data input field. Anyone know how this is
accomplished?



Thanks in advance!





-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] question type

[Vergoz Michael \(SYSDOOR\)]

WHAT ?!
I never refering to typedef anyway !!
_s64 are nothing in common with typedef !

_s64 is a double words :

linux/types.h:113:typedef   __s64   int64_t;

descript@fabienne:/usr/include$ grep -rn s64 * | wc -l
 85
descript@fabienne:/usr/include$


Well, i think that you have to learn C hmmm...

--
Sorry for my nerviousity today.

Vergoz Michael

- Original Message -
From: "Hartmut Holzgraefe" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Vergoz Michael (SYSDOOR)" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Thursday, September 19, 2002 3:06 PM
Subject: Re: [PHP-DEV] question type


> > Vergoz Michael (SYSDOOR) wrote:
> >> does PHP support _s64 type ?
>
> there is no such thing as a _s64 type in C,
> what you are refering to is a typedef to
> a native C type of that size ...
>
> [EMAIL PROTECTED] wrote:
> > No, PHP has only:
> >
> > null
> > bool (true or false)
> > string
> > integer (signed, 32 bits)
> > array
> > object
>
> well, actualy it also has "float"
> where PHP float maps to C double
> abd PHP integer maps to C long
>
> the actual bit sizes depend on whatever the C compiler
> used for compiling PHP uses as long and double
>
> 32bits signed for long and 64bits IEEE Format for
> double are the usual values, but long may also
> be 64bits signed on true 64bit CPUs
>
>
> --
> Six Offene Systeme GmbH http://www.six.de/
> i.A. Hartmut Holzgraefe
> Email: [EMAIL PROTECTED]
> Tel.:  +49-711-99091-77
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] question type

[Hartmut Holzgraefe]

 > Vergoz Michael (SYSDOOR) wrote:
>> does PHP support _s64 type ?

there is no such thing as a _s64 type in C,
what you are refering to is a typedef to
a native C type of that size ...

[EMAIL PROTECTED] wrote:
> No, PHP has only:
> 
> null
> bool (true or false)
> string
> integer (signed, 32 bits)
> array
> object

well, actualy it also has "float"
where PHP float maps to C double
abd PHP integer maps to C long

the actual bit sizes depend on whatever the C compiler
used for compiling PHP uses as long and double

32bits signed for long and 64bits IEEE Format for
double are the usual values, but long may also
be 64bits signed on true 64bit CPUs


-- 
Six Offene Systeme GmbH http://www.six.de/
i.A. Hartmut Holzgraefe
Email: [EMAIL PROTECTED]
Tel.:  +49-711-99091-77


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] question type

[derick]

On Thu, 19 Sep 2002, Vergoz Michael (SYSDOOR) wrote:

> hi list,
> 
> does PHP support _s64 type ?

No, PHP has only:

null
bool (true or false)
string
integer (signed, 32 bits)
array
object

Derick

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
-[ [EMAIL PROTECTED]: Databases are for Assholes ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] question type

[Vergoz Michael \(SYSDOOR\)]

hi list,

does PHP support _s64 type ?

michael

[PHP-DEV] Question about print_r

[Garland foster]

Hi all,

Does anyone know any problem related to print_r($foo) if $foo is a resource,
I'm developing a module where a function returns a resource, that is then
used by other functions, if I use a print_r($resource) in the middle things
change. I'm starting to think that print_r changes the resource in some
way, do you know if this might be right?

Garland.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.362 / Virus Database: 199 - Release Date: 5/16/02

RE: [PHP-DEV] question

[Joseph Tate]

a) Yes, if and only if memory has been allocated and you have to deallocate
it.  Otherwise a memory leak occurs.

b) No if a is not the case.

> -Original Message-
> From: Vergoz Michael (SYSDOOR) [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, March 24, 2002 6:00 PM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] question
>
>
> look this code :
>
> char  buffer[MAXPATHLEN];
> char *p;
>
> if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "") == FAILURE)
> return;
>
> if((p = VCWD_GETCWD(buffer, MAXPATHLEN)) == NULL) {
> POSIX_G(last_error) = errno;
> RETURN_FALSE;
> }
>
> RETURN_STRING(buffer, 1);
>
> in this code the char pointer 'p' is really needed ?
>
> michael
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] question

[Vergoz Michael (SYSDOOR)]

look this code :

char  buffer[MAXPATHLEN];
char *p;

if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "") == FAILURE)
return;

if((p = VCWD_GETCWD(buffer, MAXPATHLEN)) == NULL) {
POSIX_G(last_error) = errno;
RETURN_FALSE;
}

RETURN_STRING(buffer, 1);

in this code the char pointer 'p' is really needed ?

michael


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question concerning zend_mem_header

[Zeev Suraski]

At 02:08 PM 3/23/2002, Stefan Esser wrote:
>Hi,
>
>currently all memory allocated with emalloc has a
>zend_mem_header infront of it. This header contains
>the backward and forward pointer and the size of this
>block. My question is: is there any need for this
>linked list on a production system? I commented the
>ADD_POINTER_TO_LIST and REMOVE_POINTER_FROM_LIST
>macros out and havent seen any impact (but infact I
>only run phpinfo() and some basic scripts). From the
>rest of the code the linked list doesn't look used
>at all. If this linked list is only for finding
>memory leaks etc., we should remove it from the
>release. (I did wrap the macro definition with
>#if ZEND_DEBUG)

It's not debug code, it's production code.  It must not be removed in 
production releases.  They're necessary to prevent memory leaks, which come 
standard in the Web environment unless you do something to avoid them.

>The reasons for removing are: wasted cpu time and
>the danger that comes with those macros. As an example
>the bufferoverflow in PHP3 was only exploitable on
>most systems because of these 2 macros. With them
>removed the overflow would have been exploitable only
>on Solaris/Linux and maybe Windows.

Well, that's really not a valid reason for removing them.  The fact these 
macros happened to make a bug somewhere else exploitable doesn't make them 
any less necessary.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question concerning zend_mem_header

[Stefan Esser]

On Sat, Mar 23, 2002 at 01:23:41PM +0200, Andi Gutmans wrote:
> The list is used in order to cleanup any per-request memory leaks (Also in 
> release mode). It's very much needed.

Ahhh i see. So it would not be needed if there aren't any memory
leaks anymore. Okay now I understand the use of it. Maybe i will
create an inofficial "Zend hardening patch" for *BSD users.


Stefan Esser

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question concerning zend_mem_header

[Andi Gutmans]

The list is used in order to cleanup any per-request memory leaks (Also in 
release mode). It's very much needed.

Andi

At 13:08 23/03/2002 +0100, Stefan Esser wrote:
>Hi,
>
>currently all memory allocated with emalloc has a
>zend_mem_header infront of it. This header contains
>the backward and forward pointer and the size of this
>block. My question is: is there any need for this
>linked list on a production system? I commented the
>ADD_POINTER_TO_LIST and REMOVE_POINTER_FROM_LIST
>macros out and havent seen any impact (but infact I
>only run phpinfo() and some basic scripts). From the
>rest of the code the linked list doesn't look used
>at all. If this linked list is only for finding
>memory leaks etc., we should remove it from the
>release. (I did wrap the macro definition with
>#if ZEND_DEBUG)
>
>The reasons for removing are: wasted cpu time and
>the danger that comes with those macros. As an example
>the bufferoverflow in PHP3 was only exploitable on
>most systems because of these 2 macros. With them
>removed the overflow would have been exploitable only
>on Solaris/Linux and maybe Windows.
>
>Stefan Esser
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Question concerning zend_mem_header

[Stefan Esser]

Hi,

currently all memory allocated with emalloc has a 
zend_mem_header infront of it. This header contains
the backward and forward pointer and the size of this
block. My question is: is there any need for this
linked list on a production system? I commented the
ADD_POINTER_TO_LIST and REMOVE_POINTER_FROM_LIST
macros out and havent seen any impact (but infact I
only run phpinfo() and some basic scripts). From the
rest of the code the linked list doesn't look used
at all. If this linked list is only for finding
memory leaks etc., we should remove it from the
release. (I did wrap the macro definition with 
#if ZEND_DEBUG)

The reasons for removing are: wasted cpu time and
the danger that comes with those macros. As an example
the bufferoverflow in PHP3 was only exploitable on 
most systems because of these 2 macros. With them 
removed the overflow would have been exploitable only
on Solaris/Linux and maybe Windows. 

Stefan Esser


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Vlad Krupin]

Zeev Suraski wrote:
[snip]

> What I *really* fail to understand is the gain we get by modifying 
> exit()'s behavior, as opposed to adding a new function or adding a new 
> $silent argument.  Giving a WFF to several people?  Consistency with 
> other languages that have nothing to do with the Web environment 
> (which is why we got so little complaints about this over *5* years)?

If something has been broken for 5 years, and nobody complained, that 
doesn't mean it does not have to get fixed. Maybe people just haven't 
cared enough until now.

Making several exit()-like functions, one for each bugfix to what should 
really be the only exit() function is IMHO not very good. Making exit() 
accept two parameters... well, it's probably not quite as bad, but... 
well, this will be the first exit() with two arguments I know of...

Vlad


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Lars Torben Wilson]

[EMAIL PROTECTED] writes:
> On Thu, 20 Dec 2001, Zeev Suraski wrote:
> 
> > This patch is fine with me, but as it would still print out the error
> > message, I think it's not fine with some other people...
> 
> This solves nothing IMO. The problem is that exit (5) displays '5', and
> that must be fixed.
> 
> Derick

This does solve a problem, just not that one. :) I did actually
address that one as well in my message, with the suggestion of an
optional second parameter to suppress the output. Something like:

  void exit($status[, $suppress_output = false])

Existing scripts would behave as they always have but coders would
have the option to not have any output generated. My personal
suggestion would be to do this, actually:

  void exit($status[, $suppress_output = true])

  void die($status[, $suppress_output = false])

...but that first one would reintroduce the BC problem. :)

Anyway, the whole output/not output thing isn't that important to me
personally; I was more concerned about the inconsistency in the
argument usage. At least with that patch it would be
language-consistent, even if one doesn't like the output.
 
> >
> > At 16:29 20/12/2001, Lars Torben Wilson wrote:
> > >Zeev Suraski writes:
> > > > At 15:18 20/12/2001, Yasuo Ohgaki wrote:
> > > > >Nobody should complain about BC changes if changes are notified
> > > > >early enough and there is alternative way to do the same thing.
> > > > >IMHO. (This has been done for some features such as track vars ;)
> > > >
> > > > That's a very impractical statement in my opinion...  Breaking
> > > > compatibility hurts (almost) regardless of when you announce you're going
> > > > to break it.  Users would still have to go over their code and fix it.
> > > >
> > > > What I *really* fail to understand is the gain we get by modifying
> > > exit()'s
> > > > behavior, as opposed to adding a new function or adding a new $silent
> > > > argument.  Giving a WFF to several people?  Consistency with other
> > > > languages that have nothing to do with the Web environment (which is
> > > why we
> > > > got so little complaints about this over *5* years)?
> > >
> > >What would the problem be with the attached patch (against PHP
> > >4.1.0rc3)? This patch meets the following criteria:
> > >
> > >  o Backward compatibility is maintained, since strings passed to
> > >exit() will still be output. BC will only break in those instances
> > >where something depends on the fact that PHP will not set the exit
> > >code when exiting with a string--very unlikely. This should keep
> > >the BC people happy and not introduce any new surprises.
> > >  o No new functions need to be created, and no new arguments need to
> > >be added to exit(). This should keep the No New Functions or
> > >Arguments For Small Functionalities people happy.
> > >  o exit() will now behave like other PHP functions wrt its argument
> > >type. Whereas a PHP programmer expects the calls
> > >somefunc('2') and somefunc(2) to behave identically, exit() breaks
> > >this mould. This patch rectifies that, so that exit('2') and
> > >exit(2) will now behave the same. Again, the only time BC is broken
> > >is in cases where something depends on i.e. exit('2') outputting
> > >'0'--which is likely to be *very* rare since it doesn't make any
> > >sense.
> > >
> > >Of course, the criterium which this patch does not fulfil is that of
> > >killing the output from exit(), which would break BC. However, it
> > >would still be possible to add an option second argument to exit()
> > >which would suppress this output, but be off by default.
> > >
> > > > I see this as very similar to the case sensitivity issue, even though this
> > > > is obviously on a much smaller scale.  It's possibly a bad decision that
> > > > was made 5 years ago, but it was made all the same.  Since it does *not*
> > > > have far-reaching negative implications, it shouldn't be changed.
> > > >
> > > > Zeev
> > >
> > >The current behaviour may not be earthshatteringly bad, but it does
> > >break language consistency and so introduces a higher memory load on
> > >the user (gotta remember that everything works the same 'cept
> > >exit()). It also tends to keep some people (OK, at least me) from
> > >doing much non-web scripting in PHP since it's a fairly fundamental
> > >bit of functionality which is something of a bother to work
> > >around. Not a major bother, but enough.
> > >
> > >My point is this: we don't break, lose, or complicate anything with
> > >this patch, and it makes the language more consistent and generally
> > >usable.
> > >
> > >Just my $0.02 for the night.
> > >
> > >
> > >Torben
> > >
> > >--- zend_execute.bakWed Dec 19 16:19:44 2001
> > >+++ zend_execute.c  Wed Dec 19 16:37:29 2001
> > >@@ -2379,11 +2379,16 @@
> > > case ZEND_EXIT:
> > > if (opline->op1.op_type != IS_UNUSED) {
> > >  

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Yasuo Ohgaki]

Zeev Suraski wrote:

> At 15:18 20/12/2001, Yasuo Ohgaki wrote:
> 
>> Nobody should complain about BC changes if changes are notified
>> early enough and there is alternative way to do the same thing.
>> IMHO. (This has been done for some features such as track vars ;)
> 
> 
> That's a very impractical statement in my opinion...  Breaking 
> compatibility hurts (almost) regardless of when you announce you're 
> going to break it.  Users would still have to go over their code and fix 
> it.


I agree with your opinion also. I think compatibility is one of the most
important aspect of successful software/hardware.
(All of us know how Microsoft and Intel is successful :)

> 
> What I *really* fail to understand is the gain we get by modifying 
> exit()'s behavior, as opposed to adding a new function or adding a new 
> $silent argument.  Giving a WFF to several people?  Consistency with 
> other languages that have nothing to do with the Web environment (which 
> is why we got so little complaints about this over *5* years)?


That's too bad If I (probably, Markus, Derick and Jani also)
was using PHP at that time, I would strongly object that...


> I see this as very similar to the case sensitivity issue, even though 
> this is obviously on a much smaller scale.  It's possibly a bad decision 
> that was made 5 years ago, but it was made all the same.  Since it does 
> *not* have far-reaching negative implications, it shouldn't be changed.
> 
> Zeev
> 


I understand your opinion. I'm not strongly againt to have other

function for retuning exit status. It is just like  to me.
(Better to have one for consistency, but it's not strictly required.
It will not be a reason for many bug reports also :)

BTW, did you notice my proposal for error level and error message
handling? It will break a *LOT* of scripts, but it will give us
a *LOT* of benefits/consistency.

Parhaps, we should discuss how/when/what breaking compatibility(BC)
features should be added/deleted/modified, instead of little spec
like exit()? I have sevral proposals that require BC. I suppose
many people have them, just like you would like to have case
sensitivity for functions :)

PS: I *strongly* agree with you to have case sensitivity for
function names.

-- 
Yasuo Ohgaki


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[derick]

On Thu, 20 Dec 2001, Zeev Suraski wrote:

> This patch is fine with me, but as it would still print out the error
> message, I think it's not fine with some other people...

This solves nothing IMO. The problem is that exit (5) displays '5', and
that must be fixed.

Derick

>
> At 16:29 20/12/2001, Lars Torben Wilson wrote:
> >Zeev Suraski writes:
> > > At 15:18 20/12/2001, Yasuo Ohgaki wrote:
> > > >Nobody should complain about BC changes if changes are notified
> > > >early enough and there is alternative way to do the same thing.
> > > >IMHO. (This has been done for some features such as track vars ;)
> > >
> > > That's a very impractical statement in my opinion...  Breaking
> > > compatibility hurts (almost) regardless of when you announce you're going
> > > to break it.  Users would still have to go over their code and fix it.
> > >
> > > What I *really* fail to understand is the gain we get by modifying
> > exit()'s
> > > behavior, as opposed to adding a new function or adding a new $silent
> > > argument.  Giving a WFF to several people?  Consistency with other
> > > languages that have nothing to do with the Web environment (which is
> > why we
> > > got so little complaints about this over *5* years)?
> >
> >What would the problem be with the attached patch (against PHP
> >4.1.0rc3)? This patch meets the following criteria:
> >
> >  o Backward compatibility is maintained, since strings passed to
> >exit() will still be output. BC will only break in those instances
> >where something depends on the fact that PHP will not set the exit
> >code when exiting with a string--very unlikely. This should keep
> >the BC people happy and not introduce any new surprises.
> >  o No new functions need to be created, and no new arguments need to
> >be added to exit(). This should keep the No New Functions or
> >Arguments For Small Functionalities people happy.
> >  o exit() will now behave like other PHP functions wrt its argument
> >type. Whereas a PHP programmer expects the calls
> >somefunc('2') and somefunc(2) to behave identically, exit() breaks
> >this mould. This patch rectifies that, so that exit('2') and
> >exit(2) will now behave the same. Again, the only time BC is broken
> >is in cases where something depends on i.e. exit('2') outputting
> >'0'--which is likely to be *very* rare since it doesn't make any
> >sense.
> >
> >Of course, the criterium which this patch does not fulfil is that of
> >killing the output from exit(), which would break BC. However, it
> >would still be possible to add an option second argument to exit()
> >which would suppress this output, but be off by default.
> >
> > > I see this as very similar to the case sensitivity issue, even though this
> > > is obviously on a much smaller scale.  It's possibly a bad decision that
> > > was made 5 years ago, but it was made all the same.  Since it does *not*
> > > have far-reaching negative implications, it shouldn't be changed.
> > >
> > > Zeev
> >
> >The current behaviour may not be earthshatteringly bad, but it does
> >break language consistency and so introduces a higher memory load on
> >the user (gotta remember that everything works the same 'cept
> >exit()). It also tends to keep some people (OK, at least me) from
> >doing much non-web scripting in PHP since it's a fairly fundamental
> >bit of functionality which is something of a bother to work
> >around. Not a major bother, but enough.
> >
> >My point is this: we don't break, lose, or complicate anything with
> >this patch, and it makes the language more consistent and generally
> >usable.
> >
> >Just my $0.02 for the night.
> >
> >
> >Torben
> >
> >--- zend_execute.bakWed Dec 19 16:19:44 2001
> >+++ zend_execute.c  Wed Dec 19 16:37:29 2001
> >@@ -2379,11 +2379,16 @@
> > case ZEND_EXIT:
> > if (opline->op1.op_type != IS_UNUSED) {
> > zval *ptr;
> >+   zval exit_code;
> >
> > ptr = get_zval_ptr(&opline->op1,
> > Ts, &EG(free_op1), BP_VAR_R);
> >-   if (Z_TYPE_P(ptr) == IS_LONG) {
> >-   EG(exit_status) =
> >Z_LVAL_P(ptr);
> >-   }
> >+
> >+   exit_code = *ptr;
> >+   zval_copy_ctor(&exit_code);
> >+   convert_to_long(&exit_code);
> >+
> >+   EG(exit_status) =
> >Z_LVAL_P(&exit_code);
> >+
> > zend_print_variable(ptr);
> > FREE_OP(&opline->op1, EG(free_op1));
> > }
> >
> >
> >
> >--
> >  Torben Wilson <[EMAIL PROTECTED]>
> >  http://www.thebuttlesschaps.com
> >  http://www.hybrid17.com
>

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Lars Torben Wilson]

Zeev Suraski writes:
> This patch is fine with me, but as it would still print out the error 
> message, I think it's not fine with some other people...

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


'night
 
> At 16:29 20/12/2001, Lars Torben Wilson wrote:
> >Zeev Suraski writes:
> > > At 15:18 20/12/2001, Yasuo Ohgaki wrote:
> > > >Nobody should complain about BC changes if changes are notified
> > > >early enough and there is alternative way to do the same thing.
> > > >IMHO. (This has been done for some features such as track vars ;)
> > >
> > > That's a very impractical statement in my opinion...  Breaking
> > > compatibility hurts (almost) regardless of when you announce you're going
> > > to break it.  Users would still have to go over their code and fix it.
> > >
> > > What I *really* fail to understand is the gain we get by modifying 
> > exit()'s
> > > behavior, as opposed to adding a new function or adding a new $silent
> > > argument.  Giving a WFF to several people?  Consistency with other
> > > languages that have nothing to do with the Web environment (which is 
> > why we
> > > got so little complaints about this over *5* years)?
> >
> >What would the problem be with the attached patch (against PHP
> >4.1.0rc3)? This patch meets the following criteria:
> >
> >  o Backward compatibility is maintained, since strings passed to
> >exit() will still be output. BC will only break in those instances
> >where something depends on the fact that PHP will not set the exit
> >code when exiting with a string--very unlikely. This should keep
> >the BC people happy and not introduce any new surprises.
> >  o No new functions need to be created, and no new arguments need to
> >be added to exit(). This should keep the No New Functions or
> >Arguments For Small Functionalities people happy.
> >  o exit() will now behave like other PHP functions wrt its argument
> >type. Whereas a PHP programmer expects the calls
> >somefunc('2') and somefunc(2) to behave identically, exit() breaks
> >this mould. This patch rectifies that, so that exit('2') and
> >exit(2) will now behave the same. Again, the only time BC is broken
> >is in cases where something depends on i.e. exit('2') outputting
> >'0'--which is likely to be *very* rare since it doesn't make any
> >sense.
> >
> >Of course, the criterium which this patch does not fulfil is that of
> >killing the output from exit(), which would break BC. However, it
> >would still be possible to add an option second argument to exit()
> >which would suppress this output, but be off by default.
> >
> > > I see this as very similar to the case sensitivity issue, even though this
> > > is obviously on a much smaller scale.  It's possibly a bad decision that
> > > was made 5 years ago, but it was made all the same.  Since it does *not*
> > > have far-reaching negative implications, it shouldn't be changed.
> > >
> > > Zeev
> >
> >The current behaviour may not be earthshatteringly bad, but it does
> >break language consistency and so introduces a higher memory load on
> >the user (gotta remember that everything works the same 'cept
> >exit()). It also tends to keep some people (OK, at least me) from
> >doing much non-web scripting in PHP since it's a fairly fundamental
> >bit of functionality which is something of a bother to work
> >around. Not a major bother, but enough.
> >
> >My point is this: we don't break, lose, or complicate anything with
> >this patch, and it makes the language more consistent and generally
> >usable.
> >
> >Just my $0.02 for the night.
> >
> >
> >Torben
> >
> >--- zend_execute.bakWed Dec 19 16:19:44 2001
> >+++ zend_execute.c  Wed Dec 19 16:37:29 2001
> >@@ -2379,11 +2379,16 @@
> > case ZEND_EXIT:
> > if (opline->op1.op_type != IS_UNUSED) {
> > zval *ptr;
> >+   zval exit_code;
> >
> > ptr = get_zval_ptr(&opline->op1, 
> > Ts, &EG(free_op1), BP_VAR_R);
> >-   if (Z_TYPE_P(ptr) == IS_LONG) {
> >-   EG(exit_status) = 
> >Z_LVAL_P(ptr);
> >-   }
> >+
> >+   exit_code = *ptr;
> >+   zval_copy_ctor(&exit_code);
> >+   convert_to_long(&exit_code);
> >+
> >+   EG(exit_status) = 
> >Z_LVAL_P(&exit_code);
> >+
> > zend_print_variable(ptr);
> > FREE_OP(&opline->op1, EG(free_op1));
> > }
> >
> >
> >
> >--
> >  Torben Wilson <[EMAIL PROTECTED]>
> >  http://www.thebuttlesschaps.com
> >  http://www.hybrid17.com
>

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Zeev Suraski]

This patch is fine with me, but as it would still print out the error 
message, I think it's not fine with some other people...

At 16:29 20/12/2001, Lars Torben Wilson wrote:
>Zeev Suraski writes:
> > At 15:18 20/12/2001, Yasuo Ohgaki wrote:
> > >Nobody should complain about BC changes if changes are notified
> > >early enough and there is alternative way to do the same thing.
> > >IMHO. (This has been done for some features such as track vars ;)
> >
> > That's a very impractical statement in my opinion...  Breaking
> > compatibility hurts (almost) regardless of when you announce you're going
> > to break it.  Users would still have to go over their code and fix it.
> >
> > What I *really* fail to understand is the gain we get by modifying 
> exit()'s
> > behavior, as opposed to adding a new function or adding a new $silent
> > argument.  Giving a WFF to several people?  Consistency with other
> > languages that have nothing to do with the Web environment (which is 
> why we
> > got so little complaints about this over *5* years)?
>
>What would the problem be with the attached patch (against PHP
>4.1.0rc3)? This patch meets the following criteria:
>
>  o Backward compatibility is maintained, since strings passed to
>exit() will still be output. BC will only break in those instances
>where something depends on the fact that PHP will not set the exit
>code when exiting with a string--very unlikely. This should keep
>the BC people happy and not introduce any new surprises.
>  o No new functions need to be created, and no new arguments need to
>be added to exit(). This should keep the No New Functions or
>Arguments For Small Functionalities people happy.
>  o exit() will now behave like other PHP functions wrt its argument
>type. Whereas a PHP programmer expects the calls
>somefunc('2') and somefunc(2) to behave identically, exit() breaks
>this mould. This patch rectifies that, so that exit('2') and
>exit(2) will now behave the same. Again, the only time BC is broken
>is in cases where something depends on i.e. exit('2') outputting
>'0'--which is likely to be *very* rare since it doesn't make any
>sense.
>
>Of course, the criterium which this patch does not fulfil is that of
>killing the output from exit(), which would break BC. However, it
>would still be possible to add an option second argument to exit()
>which would suppress this output, but be off by default.
>
> > I see this as very similar to the case sensitivity issue, even though this
> > is obviously on a much smaller scale.  It's possibly a bad decision that
> > was made 5 years ago, but it was made all the same.  Since it does *not*
> > have far-reaching negative implications, it shouldn't be changed.
> >
> > Zeev
>
>The current behaviour may not be earthshatteringly bad, but it does
>break language consistency and so introduces a higher memory load on
>the user (gotta remember that everything works the same 'cept
>exit()). It also tends to keep some people (OK, at least me) from
>doing much non-web scripting in PHP since it's a fairly fundamental
>bit of functionality which is something of a bother to work
>around. Not a major bother, but enough.
>
>My point is this: we don't break, lose, or complicate anything with
>this patch, and it makes the language more consistent and generally
>usable.
>
>Just my $0.02 for the night.
>
>
>Torben
>
>--- zend_execute.bakWed Dec 19 16:19:44 2001
>+++ zend_execute.c  Wed Dec 19 16:37:29 2001
>@@ -2379,11 +2379,16 @@
> case ZEND_EXIT:
> if (opline->op1.op_type != IS_UNUSED) {
> zval *ptr;
>+   zval exit_code;
>
> ptr = get_zval_ptr(&opline->op1, 
> Ts, &EG(free_op1), BP_VAR_R);
>-   if (Z_TYPE_P(ptr) == IS_LONG) {
>-   EG(exit_status) = 
>Z_LVAL_P(ptr);
>-   }
>+
>+   exit_code = *ptr;
>+   zval_copy_ctor(&exit_code);
>+   convert_to_long(&exit_code);
>+
>+   EG(exit_status) = 
>Z_LVAL_P(&exit_code);
>+
> zend_print_variable(ptr);
> FREE_OP(&opline->op1, EG(free_op1));
> }
>
>
>
>--
>  Torben Wilson <[EMAIL PROTECTED]>
>  http://www.thebuttlesschaps.com
>  http://www.hybrid17.com
>  http://www.inflatableeye.com
>  +1.604.709.0506


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Lars Torben Wilson]

Zeev Suraski writes:
> At 15:18 20/12/2001, Yasuo Ohgaki wrote:
> >Nobody should complain about BC changes if changes are notified
> >early enough and there is alternative way to do the same thing.
> >IMHO. (This has been done for some features such as track vars ;)
> 
> That's a very impractical statement in my opinion...  Breaking 
> compatibility hurts (almost) regardless of when you announce you're going 
> to break it.  Users would still have to go over their code and fix it.
> 
> What I *really* fail to understand is the gain we get by modifying exit()'s 
> behavior, as opposed to adding a new function or adding a new $silent 
> argument.  Giving a WFF to several people?  Consistency with other 
> languages that have nothing to do with the Web environment (which is why we 
> got so little complaints about this over *5* years)?

What would the problem be with the attached patch (against PHP
4.1.0rc3)? This patch meets the following criteria:

 o Backward compatibility is maintained, since strings passed to
   exit() will still be output. BC will only break in those instances
   where something depends on the fact that PHP will not set the exit
   code when exiting with a string--very unlikely. This should keep
   the BC people happy and not introduce any new surprises.
 o No new functions need to be created, and no new arguments need to
   be added to exit(). This should keep the No New Functions or
   Arguments For Small Functionalities people happy.
 o exit() will now behave like other PHP functions wrt its argument
   type. Whereas a PHP programmer expects the calls
   somefunc('2') and somefunc(2) to behave identically, exit() breaks
   this mould. This patch rectifies that, so that exit('2') and
   exit(2) will now behave the same. Again, the only time BC is broken
   is in cases where something depends on i.e. exit('2') outputting
   '0'--which is likely to be *very* rare since it doesn't make any
   sense.
 
Of course, the criterium which this patch does not fulfil is that of
killing the output from exit(), which would break BC. However, it
would still be possible to add an option second argument to exit()
which would suppress this output, but be off by default.

> I see this as very similar to the case sensitivity issue, even though this 
> is obviously on a much smaller scale.  It's possibly a bad decision that 
> was made 5 years ago, but it was made all the same.  Since it does *not* 
> have far-reaching negative implications, it shouldn't be changed.
> 
> Zeev

The current behaviour may not be earthshatteringly bad, but it does
break language consistency and so introduces a higher memory load on
the user (gotta remember that everything works the same 'cept
exit()). It also tends to keep some people (OK, at least me) from
doing much non-web scripting in PHP since it's a fairly fundamental
bit of functionality which is something of a bother to work
around. Not a major bother, but enough.

My point is this: we don't break, lose, or complicate anything with
this patch, and it makes the language more consistent and generally
usable. 

Just my $0.02 for the night.


Torben

--- zend_execute.bakWed Dec 19 16:19:44 2001
+++ zend_execute.c  Wed Dec 19 16:37:29 2001
@@ -2379,11 +2379,16 @@
case ZEND_EXIT:
if (opline->op1.op_type != IS_UNUSED) {
zval *ptr;
+   zval exit_code;
 
ptr = get_zval_ptr(&opline->op1, Ts, 
&EG(free_op1), BP_VAR_R);
-   if (Z_TYPE_P(ptr) == IS_LONG) {
-   EG(exit_status) = Z_LVAL_P(ptr);
-   }
+
+   exit_code = *ptr;
+   zval_copy_ctor(&exit_code);
+   convert_to_long(&exit_code);
+
+   EG(exit_status) = Z_LVAL_P(&exit_code);
+
zend_print_variable(ptr);
FREE_OP(&opline->op1, EG(free_op1));
}



-- 
 Torben Wilson <[EMAIL PROTECTED]>
 http://www.thebuttlesschaps.com
 http://www.hybrid17.com
 http://www.inflatableeye.com
 +1.604.709.0506


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Zeev Suraski]

At 15:18 20/12/2001, Yasuo Ohgaki wrote:
>Nobody should complain about BC changes if changes are notified
>early enough and there is alternative way to do the same thing.
>IMHO. (This has been done for some features such as track vars ;)

That's a very impractical statement in my opinion...  Breaking 
compatibility hurts (almost) regardless of when you announce you're going 
to break it.  Users would still have to go over their code and fix it.

What I *really* fail to understand is the gain we get by modifying exit()'s 
behavior, as opposed to adding a new function or adding a new $silent 
argument.  Giving a WFF to several people?  Consistency with other 
languages that have nothing to do with the Web environment (which is why we 
got so little complaints about this over *5* years)?

I see this as very similar to the case sensitivity issue, even though this 
is obviously on a much smaller scale.  It's possibly a bad decision that 
was made 5 years ago, but it was made all the same.  Since it does *not* 
have far-reaching negative implications, it shouldn't be changed.

Zeev


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[derick]

On Thu, 20 Dec 2001, benjamin yates wrote:

>
>
> > No offense Benjamin, but you don't understand the conversation.  This is
> > about running PHP apps in consoles, mail pre-processors and as cron jobs
> > where exit status is needed.  The only way to get an exit status is with
> > exit.
>
>  wow i just tried it... i never realized that return wasn't setting the exit
> code.  ok then - i guess i'm all for system_exit() or similar, but why
> wouldn't we want return to set it like it's C counterpart?

Actually, most ppl want to do that.

Derick


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[benjamin yates]

> No offense Benjamin, but you don't understand the conversation.  This is
> about running PHP apps in consoles, mail pre-processors and as cron jobs
> where exit status is needed.  The only way to get an exit status is with
> exit.

 wow i just tried it... i never realized that return wasn't setting the exit
code.  ok then - i guess i'm all for system_exit() or similar, but why
wouldn't we want return to set it like it's C counterpart?

  -benjamin

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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Yasuo Ohgaki]

Markus Fischer wrote:

> Actually, a good idea to keep BC. Its now just a matter if
> its really worth to keep BC for exit.


I agree with Markus.

However, since there are people who want strong compatibility.
I think we can wait exit() to return status code, a litle more.

As I posted already, it would be good idea to notify users for BC
changes expected a few version later. Since die() is the same
as exit(),  transition would be very easy. There are many BC
issues version to version anyway. It's called bug :)

Nobody should complain about BC changes if changes are notified
early enough and there is alternative way to do the same thing.
IMHO. (This has been done for some features such as track vars ;)

I suppose we can change exit() for 4.3.0, or even for
4.2.0, since we have different branch for 4.1.x and 4.2.0.
There will be 4.1.1 and/or even 4.1.2, 4.1.3. 4.2.0 may
not be released any time soon. :)

-- 
Yasuo Ohgaki


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Markus Fischer]

Actually, a good idea to keep BC. Its now just a matter if
its really worth to keep BC for exit.

On Wed, Dec 19, 2001 at 08:28:19PM +, [EMAIL PROTECTED] wrote : 
> 
> Just a thought...
> 
> ---
> void exit ( [mixed message[, int return_value]])
> 
> 
> Note: This is not a real function, but a language construct. 
> 
> The exit() function terminates execution of the script. Message
> must be a string or an int.  If a non-null message is given it is
> printed just before exiting. If return_value is given the exit status
> of the program is set to this value.  To set an exit status without
> printing anything, pass "" as message.
> 
> 
> exit();   end program, print nothing, return 0
> 
> exit( "message"   );  end program, print message, return 0
> 
> exit( 5 );end program, print 5,   return 0
> 
> exit( "messge", 5 );end program, print message, return 5
> 
> exit( 6, 5 ); end program, print 6,   return 5
> 
> exit( "", 5 );end program, print nothing, return 5
> 
> NOTE: The last example does not print _anything_.  No 's no \n's...
> nothing.  
> 
> ---
> 
> That should preserve BC and let those of us who are using php for shell
> scripting to have a reasonably simple way to return program status with
> or without printing message.
> 
> 
> 
> Rick
> 
> 
> Rick Widmer
> Internet Marketing Specialists
> http://www.developersdesk.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]

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

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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Rasmus Lerdorf]

This is what I suggested ages ago.  I think this is the correct solution 
for this one.  I don't see mass-breakage, or perhaps even any, caused by 
this change.  The case-insensitivity stuff is completely another matter 
though.  I see very little benefit in 1) breaking thousands of existing 
scripts and 2) encouraging people to avoid namespace clashes just by 
changing case.  Someone said they wanted to use If() for example.  Imaging 
debugging code like that?  No thanks.

-Rasmus

On Thu, 20 Dec 2001, Jani Taskinen wrote:

> 
> I have said this all the time..as well as many others.
> Try convince Zeev to fix his one script that breaks.
> 
> --Jani
> 
> 
> On Thu, 20 Dec 2001, Markus Fischer wrote:
> 
> >Why not just check the type of the parameter? No conversion
> >needed at all. If its a long -> exit/no show it. If anything
> >else (well, thats to argue, but not the point) exit and show.
> >It would be that easy. And, in that case, I don't care about
> >the number of broken scripts. Prove there are more then you
> >got fingers on your hand. And even those, you can fix under a
> >second.
> >
> >On Wed, Dec 19, 2001 at 03:33:15PM -0800, Lars Torben Wilson wrote :
> >> Vlad Krupin writes:
> >> > Please, understand me correctly - I have nothing against exit() working
> >> > in the same manner regardless of the type of the argument. I would love
> >> > to see that. The problem is that (1) it already accepts a string, and
> >> > has been working that way for a long time, so this can't go away, and
> >> > (2) there is no other way (AFAIK) to set exit codes, and some people
> >> > need that. Those are somewhat contradicting requirements, so we might
> >> > have to compromise.
> >> >
> >> > I do have a problem with the compromise you proposed though, if I
> >> > understood you correctly. You suggest using something like
> >> >
> >> > > exit("1boo")
> >> >
> >> > And having exit() parse the first digit out. That's BAD. What if
> >>
> >> It's not parsing anything. It's just converting to int using the well
> >> documented rules of string to integer conversion which have existed in
> >> the language for years. The language is pretty much impossible to use
> >> without running into implicit type conversions--it's designed for
> >> it. That's why the current behaviour of exit() breaks consistency.
> >> Please, check out the Type Juggling section of the manual. This
> >> shouldq not a special case, but it currently is treated as one. It
> >> should behave the way the rest of the language behaves.
> >>
> >> > someone already uses exit("123, 456 servers are unavailable"); or
> >> > something similar. How should we parse something like that? Chances
> >>
> >> Again, we don't. We let the language deal with it like it does every
> >> other string->integer conversion.
> >>
> >> > of that are slim, but just as good as Zeev's argument where he says
> >> > that there are scripts out there that rely on the current
> >> > implementation of exit(), e.g. one of his own. Jamming two values
> >> > into a storage space designed for a single value (a string) is bad
> >> > :(
> >>
> >> In the case you gave, the only difference the user would notice
> >> would be that the exit status of the script would be 123 instead of
> >> 0. It would still print out the '123, 456 servers are unavailable'.
> >>
> >> > Vlad
> >> >
> >> >
> >> >
> >> > Lars Torben Wilson wrote:
> >> >
> >> > >Vlad Krupin writes:
> >> > >
> >> > >>Lars Torben Wilson wrote:
> >> > >>
> >> > >>>Perhaps I have not explained my position. I don't care whether it
> >> > >>>outputs the exit status as a string--as long as it sets the error code
> >> > >>>appropriately *as well*. By appropriately, I mean that 'exit("boo");'
> >> > >>>would a) print 'boo' and b) return with exit status 0, but
> >> > >>>'exit("1boo")'; would a) print '1boo' and b) return with exit status
> >> > >>>1. This would be consistent with PHP's type conversion rules, and
> >> > >>>would also tend to behave in the way that the programmer expects it
> >> > >>>to.
> >> > >>>
> >> > >>Yikes. This is way worse than overloading. In school they called that
> >> > >>data-coupling, I think. In real life this is called a hack.
> >> > >>
> >> > >>Sorry, but a -1 on this.
> >> > >>
> >> > >>Vlad
> >> > >>
> >> > >
> >> > >No, it's called loose typing. See
> >> > >
> >> > 
>>http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
> >> > >
> >> > >We have a language here which considers the integer value of "5" to
> >> > >be 5, and an exit() construct which ignores that.
> >> > >
> >> > >For instance:
> >> > >
> >> > >  shanna% php -q
> >> > >  
> >> > >  5
> >> > >
> >> > >  shanna% echo $?
> >> > >  0
> >> > >
> >> > >  shanna% php -q
> >> > >  
> >> > >  5
> >> > >
> >> > >  shanna% echo $?
> >> > >  5
> >> > >
> >> > >How much sense does this make? None, as far as I can see.
> >> > >
> >> > >What I'm proposing is to make the behaviour of exit() _not_ depen

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[php4]

Just a thought...

---
void exit ( [mixed message[, int return_value]])


Note: This is not a real function, but a language construct. 

The exit() function terminates execution of the script. Message
must be a string or an int.  If a non-null message is given it is
printed just before exiting. If return_value is given the exit status
of the program is set to this value.  To set an exit status without
printing anything, pass "" as message.


exit(); end program, print nothing, return 0

exit( "message" );  end program, print message, return 0

exit( 5 );  end program, print 5,   return 0

exit( "messge", 5 );end program, print message, return 5

exit( 6, 5 );   end program, print 6,   return 5

exit( "", 5 );  end program, print nothing, return 5

NOTE: The last example does not print _anything_.  No 's no \n's...
nothing.  

---

That should preserve BC and let those of us who are using php for shell
scripting to have a reasonably simple way to return program status with
or without printing message.



Rick


Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.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] Question: Should exit() print out the integer exit-status?

[Lars Torben Wilson]

Markus Fischer writes:
> Implictely is more error prone.

How so? Can you give an example?

> On Wed, Dec 19, 2001 at 04:12:02PM -0800, Lars Torben Wilson wrote : 
> > Markus Fischer writes:
> > > Why not just check the type of the parameter? No conversion
> > > needed at all. If its a long -> exit/no show it. If anything
> > > else (well, thats to argue, but not the point) exit and show.
> > > It would be that easy. And, in that case, I don't care about
> > > the number of broken scripts. Prove there are more then you
> > > got fingers on your hand. And even those, you can fix under a
> > > second.
> > 
> > Because then exit('5') and exit(5) would still have different
> > behaviours, which is the current situation and which is the root of
> > the problem. If the implicit conversions are done, we end up with:
> > 
> > exit('5')   : prints '5' and sets exit code to 5
> > exit(5) : prints '5' and sets exit code to 5
> > exit('Some message'): prints 'Some message' and sets exit code to 0
> > 
> > ...etc. Existing scripts which use exit() to output a message would
> > still output the same message they currently do, so we maintain
> > backward compatibility. The only difference would be that exit() would
> > work the same way other php functions do--for instance, we expect the
> > same output from 'echo chr(65);' and 'echo chr("65");', right? Why
> > should exit be any different?
> > 
> > > On Wed, Dec 19, 2001 at 03:33:15PM -0800, Lars Torben Wilson wrote : 
> > > > Vlad Krupin writes:
> > > > > Please, understand me correctly - I have nothing against exit() working 
> > > > > in the same manner regardless of the type of the argument. I would love 
> > > > > to see that. The problem is that (1) it already accepts a string, and 
> > > > > has been working that way for a long time, so this can't go away, and 
> > > > > (2) there is no other way (AFAIK) to set exit codes, and some people 
> > > > > need that. Those are somewhat contradicting requirements, so we might 
> > > > > have to compromise.
> > > > > 
> > > > > I do have a problem with the compromise you proposed though, if I 
> > > > > understood you correctly. You suggest using something like
> > > > > 
> > > > > > exit("1boo")
> > > > >
> > > > > And having exit() parse the first digit out. That's BAD. What if
> > > > 
> > > > It's not parsing anything. It's just converting to int using the well
> > > > documented rules of string to integer conversion which have existed in
> > > > the language for years. The language is pretty much impossible to use
> > > > without running into implicit type conversions--it's designed for
> > > > it. That's why the current behaviour of exit() breaks consistency.
> > > > Please, check out the Type Juggling section of the manual. This
> > > > shouldq not a special case, but it currently is treated as one. It
> > > > should behave the way the rest of the language behaves. 
> > > > 
> > > > > someone already uses exit("123, 456 servers are unavailable"); or
> > > > > something similar. How should we parse something like that? Chances
> > > > 
> > > > Again, we don't. We let the language deal with it like it does every
> > > > other string->integer conversion.
> > > > 
> > > > > of that are slim, but just as good as Zeev's argument where he says
> > > > > that there are scripts out there that rely on the current
> > > > > implementation of exit(), e.g. one of his own. Jamming two values
> > > > > into a storage space designed for a single value (a string) is bad
> > > > > :(
> > > > 
> > > > In the case you gave, the only difference the user would notice
> > > > would be that the exit status of the script would be 123 instead of
> > > > 0. It would still print out the '123, 456 servers are unavailable'.
> > > > 
> > > > > Vlad
> > > > > 
> > > > > 
> > > > > 
> > > > > Lars Torben Wilson wrote:
> > > > > 
> > > > > >Vlad Krupin writes:
> > > > > >
> > > > > >>Lars Torben Wilson wrote:
> > > > > >>
> > > > > >>>Perhaps I have not explained my position. I don't care whether it
> > > > > >>>outputs the exit status as a string--as long as it sets the error code
> > > > > >>>appropriately *as well*. By appropriately, I mean that 'exit("boo");'
> > > > > >>>would a) print 'boo' and b) return with exit status 0, but
> > > > > >>>'exit("1boo")'; would a) print '1boo' and b) return with exit status
> > > > > >>>1. This would be consistent with PHP's type conversion rules, and
> > > > > >>>would also tend to behave in the way that the programmer expects it
> > > > > >>>to.
> > > > > >>>
> > > > > >>Yikes. This is way worse than overloading. In school they called that 
> > > > > >>data-coupling, I think. In real life this is called a hack.
> > > > > >>
> > > > > >>Sorry, but a -1 on this.
> > > > > >>
> > > > > >>Vlad
> > > > > >>
> > > > > >
> > > > > >No, it's called loose typing. See
> > > > > >
> > > > > 
>>http://www.php.net/manual/en/language.types.string.php#language.types.st

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Markus Fischer]

Implictely is more error prone.

On Wed, Dec 19, 2001 at 04:12:02PM -0800, Lars Torben Wilson wrote : 
> Markus Fischer writes:
> > Why not just check the type of the parameter? No conversion
> > needed at all. If its a long -> exit/no show it. If anything
> > else (well, thats to argue, but not the point) exit and show.
> > It would be that easy. And, in that case, I don't care about
> > the number of broken scripts. Prove there are more then you
> > got fingers on your hand. And even those, you can fix under a
> > second.
> 
> Because then exit('5') and exit(5) would still have different
> behaviours, which is the current situation and which is the root of
> the problem. If the implicit conversions are done, we end up with:
> 
> exit('5')   : prints '5' and sets exit code to 5
> exit(5) : prints '5' and sets exit code to 5
> exit('Some message'): prints 'Some message' and sets exit code to 0
> 
> ...etc. Existing scripts which use exit() to output a message would
> still output the same message they currently do, so we maintain
> backward compatibility. The only difference would be that exit() would
> work the same way other php functions do--for instance, we expect the
> same output from 'echo chr(65);' and 'echo chr("65");', right? Why
> should exit be any different?
> 
> > On Wed, Dec 19, 2001 at 03:33:15PM -0800, Lars Torben Wilson wrote : 
> > > Vlad Krupin writes:
> > > > Please, understand me correctly - I have nothing against exit() working 
> > > > in the same manner regardless of the type of the argument. I would love 
> > > > to see that. The problem is that (1) it already accepts a string, and 
> > > > has been working that way for a long time, so this can't go away, and 
> > > > (2) there is no other way (AFAIK) to set exit codes, and some people 
> > > > need that. Those are somewhat contradicting requirements, so we might 
> > > > have to compromise.
> > > > 
> > > > I do have a problem with the compromise you proposed though, if I 
> > > > understood you correctly. You suggest using something like
> > > > 
> > > > > exit("1boo")
> > > >
> > > > And having exit() parse the first digit out. That's BAD. What if
> > > 
> > > It's not parsing anything. It's just converting to int using the well
> > > documented rules of string to integer conversion which have existed in
> > > the language for years. The language is pretty much impossible to use
> > > without running into implicit type conversions--it's designed for
> > > it. That's why the current behaviour of exit() breaks consistency.
> > > Please, check out the Type Juggling section of the manual. This
> > > shouldq not a special case, but it currently is treated as one. It
> > > should behave the way the rest of the language behaves. 
> > > 
> > > > someone already uses exit("123, 456 servers are unavailable"); or
> > > > something similar. How should we parse something like that? Chances
> > > 
> > > Again, we don't. We let the language deal with it like it does every
> > > other string->integer conversion.
> > > 
> > > > of that are slim, but just as good as Zeev's argument where he says
> > > > that there are scripts out there that rely on the current
> > > > implementation of exit(), e.g. one of his own. Jamming two values
> > > > into a storage space designed for a single value (a string) is bad
> > > > :(
> > > 
> > > In the case you gave, the only difference the user would notice
> > > would be that the exit status of the script would be 123 instead of
> > > 0. It would still print out the '123, 456 servers are unavailable'.
> > > 
> > > > Vlad
> > > > 
> > > > 
> > > > 
> > > > Lars Torben Wilson wrote:
> > > > 
> > > > >Vlad Krupin writes:
> > > > >
> > > > >>Lars Torben Wilson wrote:
> > > > >>
> > > > >>>Perhaps I have not explained my position. I don't care whether it
> > > > >>>outputs the exit status as a string--as long as it sets the error code
> > > > >>>appropriately *as well*. By appropriately, I mean that 'exit("boo");'
> > > > >>>would a) print 'boo' and b) return with exit status 0, but
> > > > >>>'exit("1boo")'; would a) print '1boo' and b) return with exit status
> > > > >>>1. This would be consistent with PHP's type conversion rules, and
> > > > >>>would also tend to behave in the way that the programmer expects it
> > > > >>>to.
> > > > >>>
> > > > >>Yikes. This is way worse than overloading. In school they called that 
> > > > >>data-coupling, I think. In real life this is called a hack.
> > > > >>
> > > > >>Sorry, but a -1 on this.
> > > > >>
> > > > >>Vlad
> > > > >>
> > > > >
> > > > >No, it's called loose typing. See
> > > > >
> > > > 
>>http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
> > > > >
> > > > >We have a language here which considers the integer value of "5" to
> > > > >be 5, and an exit() construct which ignores that.
> > > > >
> > > > >For instance:
> > > > >
> > > > >  shanna% php -q
> > > > >  
> > > > > 

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Markus Fischer]

Yeah Jani I know. It was more targeted at Torben than the
whole audience ;)

On Thu, Dec 20, 2001 at 02:16:21AM +0200, Jani Taskinen wrote : 
> 
> I have said this all the time..as well as many others.
> Try convince Zeev to fix his one script that breaks.
> 
> --Jani
> 
> 
> On Thu, 20 Dec 2001, Markus Fischer wrote:
> 
> >Why not just check the type of the parameter? No conversion
> >needed at all. If its a long -> exit/no show it. If anything
> >else (well, thats to argue, but not the point) exit and show.
> >It would be that easy. And, in that case, I don't care about
> >the number of broken scripts. Prove there are more then you
> >got fingers on your hand. And even those, you can fix under a
> >second.
> >
> >On Wed, Dec 19, 2001 at 03:33:15PM -0800, Lars Torben Wilson wrote :
> >> Vlad Krupin writes:
> >> > Please, understand me correctly - I have nothing against exit() working
> >> > in the same manner regardless of the type of the argument. I would love
> >> > to see that. The problem is that (1) it already accepts a string, and
> >> > has been working that way for a long time, so this can't go away, and
> >> > (2) there is no other way (AFAIK) to set exit codes, and some people
> >> > need that. Those are somewhat contradicting requirements, so we might
> >> > have to compromise.
> >> >
> >> > I do have a problem with the compromise you proposed though, if I
> >> > understood you correctly. You suggest using something like
> >> >
> >> > > exit("1boo")
> >> >
> >> > And having exit() parse the first digit out. That's BAD. What if
> >>
> >> It's not parsing anything. It's just converting to int using the well
> >> documented rules of string to integer conversion which have existed in
> >> the language for years. The language is pretty much impossible to use
> >> without running into implicit type conversions--it's designed for
> >> it. That's why the current behaviour of exit() breaks consistency.
> >> Please, check out the Type Juggling section of the manual. This
> >> shouldq not a special case, but it currently is treated as one. It
> >> should behave the way the rest of the language behaves.
> >>
> >> > someone already uses exit("123, 456 servers are unavailable"); or
> >> > something similar. How should we parse something like that? Chances
> >>
> >> Again, we don't. We let the language deal with it like it does every
> >> other string->integer conversion.
> >>
> >> > of that are slim, but just as good as Zeev's argument where he says
> >> > that there are scripts out there that rely on the current
> >> > implementation of exit(), e.g. one of his own. Jamming two values
> >> > into a storage space designed for a single value (a string) is bad
> >> > :(
> >>
> >> In the case you gave, the only difference the user would notice
> >> would be that the exit status of the script would be 123 instead of
> >> 0. It would still print out the '123, 456 servers are unavailable'.
> >>
> >> > Vlad
> >> >
> >> >
> >> >
> >> > Lars Torben Wilson wrote:
> >> >
> >> > >Vlad Krupin writes:
> >> > >
> >> > >>Lars Torben Wilson wrote:
> >> > >>
> >> > >>>Perhaps I have not explained my position. I don't care whether it
> >> > >>>outputs the exit status as a string--as long as it sets the error code
> >> > >>>appropriately *as well*. By appropriately, I mean that 'exit("boo");'
> >> > >>>would a) print 'boo' and b) return with exit status 0, but
> >> > >>>'exit("1boo")'; would a) print '1boo' and b) return with exit status
> >> > >>>1. This would be consistent with PHP's type conversion rules, and
> >> > >>>would also tend to behave in the way that the programmer expects it
> >> > >>>to.
> >> > >>>
> >> > >>Yikes. This is way worse than overloading. In school they called that
> >> > >>data-coupling, I think. In real life this is called a hack.
> >> > >>
> >> > >>Sorry, but a -1 on this.
> >> > >>
> >> > >>Vlad
> >> > >>
> >> > >
> >> > >No, it's called loose typing. See
> >> > >
> >> > 
>>http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
> >> > >
> >> > >We have a language here which considers the integer value of "5" to
> >> > >be 5, and an exit() construct which ignores that.
> >> > >
> >> > >For instance:
> >> > >
> >> > >  shanna% php -q
> >> > >  
> >> > >  5
> >> > >
> >> > >  shanna% echo $?
> >> > >  0
> >> > >
> >> > >  shanna% php -q
> >> > >  
> >> > >  5
> >> > >
> >> > >  shanna% echo $?
> >> > >  5
> >> > >
> >> > >How much sense does this make? None, as far as I can see.
> >> > >
> >> > >What I'm proposing is to make the behaviour of exit() _not_ depend on
> >> > >the type of its argument. At present if the argument is an integer
> >> > >exit() prints it and sets the error status, but if it's any other
> >> > >type, exit() just prints it and doesn't set the exit status. This is
> >> > >more complex than my proposal: no matter what the argument is, print
> >> > >out its string value, and set the exit status to its integer valu

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Lars Torben Wilson]

Markus Fischer writes:
> Why not just check the type of the parameter? No conversion
> needed at all. If its a long -> exit/no show it. If anything
> else (well, thats to argue, but not the point) exit and show.
> It would be that easy. And, in that case, I don't care about
> the number of broken scripts. Prove there are more then you
> got fingers on your hand. And even those, you can fix under a
> second.

Because then exit('5') and exit(5) would still have different
behaviours, which is the current situation and which is the root of
the problem. If the implicit conversions are done, we end up with:

exit('5')   : prints '5' and sets exit code to 5
exit(5) : prints '5' and sets exit code to 5
exit('Some message'): prints 'Some message' and sets exit code to 0

...etc. Existing scripts which use exit() to output a message would
still output the same message they currently do, so we maintain
backward compatibility. The only difference would be that exit() would
work the same way other php functions do--for instance, we expect the
same output from 'echo chr(65);' and 'echo chr("65");', right? Why
should exit be any different?

> On Wed, Dec 19, 2001 at 03:33:15PM -0800, Lars Torben Wilson wrote : 
> > Vlad Krupin writes:
> > > Please, understand me correctly - I have nothing against exit() working 
> > > in the same manner regardless of the type of the argument. I would love 
> > > to see that. The problem is that (1) it already accepts a string, and 
> > > has been working that way for a long time, so this can't go away, and 
> > > (2) there is no other way (AFAIK) to set exit codes, and some people 
> > > need that. Those are somewhat contradicting requirements, so we might 
> > > have to compromise.
> > > 
> > > I do have a problem with the compromise you proposed though, if I 
> > > understood you correctly. You suggest using something like
> > > 
> > > > exit("1boo")
> > >
> > > And having exit() parse the first digit out. That's BAD. What if
> > 
> > It's not parsing anything. It's just converting to int using the well
> > documented rules of string to integer conversion which have existed in
> > the language for years. The language is pretty much impossible to use
> > without running into implicit type conversions--it's designed for
> > it. That's why the current behaviour of exit() breaks consistency.
> > Please, check out the Type Juggling section of the manual. This
> > shouldq not a special case, but it currently is treated as one. It
> > should behave the way the rest of the language behaves. 
> > 
> > > someone already uses exit("123, 456 servers are unavailable"); or
> > > something similar. How should we parse something like that? Chances
> > 
> > Again, we don't. We let the language deal with it like it does every
> > other string->integer conversion.
> > 
> > > of that are slim, but just as good as Zeev's argument where he says
> > > that there are scripts out there that rely on the current
> > > implementation of exit(), e.g. one of his own. Jamming two values
> > > into a storage space designed for a single value (a string) is bad
> > > :(
> > 
> > In the case you gave, the only difference the user would notice
> > would be that the exit status of the script would be 123 instead of
> > 0. It would still print out the '123, 456 servers are unavailable'.
> > 
> > > Vlad
> > > 
> > > 
> > > 
> > > Lars Torben Wilson wrote:
> > > 
> > > >Vlad Krupin writes:
> > > >
> > > >>Lars Torben Wilson wrote:
> > > >>
> > > >>>Perhaps I have not explained my position. I don't care whether it
> > > >>>outputs the exit status as a string--as long as it sets the error code
> > > >>>appropriately *as well*. By appropriately, I mean that 'exit("boo");'
> > > >>>would a) print 'boo' and b) return with exit status 0, but
> > > >>>'exit("1boo")'; would a) print '1boo' and b) return with exit status
> > > >>>1. This would be consistent with PHP's type conversion rules, and
> > > >>>would also tend to behave in the way that the programmer expects it
> > > >>>to.
> > > >>>
> > > >>Yikes. This is way worse than overloading. In school they called that 
> > > >>data-coupling, I think. In real life this is called a hack.
> > > >>
> > > >>Sorry, but a -1 on this.
> > > >>
> > > >>Vlad
> > > >>
> > > >
> > > >No, it's called loose typing. See
> > > >
> > > 
>>http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
> > > >
> > > >We have a language here which considers the integer value of "5" to
> > > >be 5, and an exit() construct which ignores that.
> > > >
> > > >For instance:
> > > >
> > > >  shanna% php -q
> > > >  
> > > >  5
> > > >
> > > >  shanna% echo $?
> > > >  0
> > > > 
> > > >  shanna% php -q
> > > >  
> > > >  5
> > > >
> > > >  shanna% echo $?
> > > >  5
> > > >
> > > >How much sense does this make? None, as far as I can see.
> > > >
> > > >What I'm proposing is to make the behaviour of exit() _not_ depend on
> > > >the typ

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Jani Taskinen]

I have said this all the time..as well as many others.
Try convince Zeev to fix his one script that breaks.

--Jani


On Thu, 20 Dec 2001, Markus Fischer wrote:

>Why not just check the type of the parameter? No conversion
>needed at all. If its a long -> exit/no show it. If anything
>else (well, thats to argue, but not the point) exit and show.
>It would be that easy. And, in that case, I don't care about
>the number of broken scripts. Prove there are more then you
>got fingers on your hand. And even those, you can fix under a
>second.
>
>On Wed, Dec 19, 2001 at 03:33:15PM -0800, Lars Torben Wilson wrote :
>> Vlad Krupin writes:
>> > Please, understand me correctly - I have nothing against exit() working
>> > in the same manner regardless of the type of the argument. I would love
>> > to see that. The problem is that (1) it already accepts a string, and
>> > has been working that way for a long time, so this can't go away, and
>> > (2) there is no other way (AFAIK) to set exit codes, and some people
>> > need that. Those are somewhat contradicting requirements, so we might
>> > have to compromise.
>> >
>> > I do have a problem with the compromise you proposed though, if I
>> > understood you correctly. You suggest using something like
>> >
>> > > exit("1boo")
>> >
>> > And having exit() parse the first digit out. That's BAD. What if
>>
>> It's not parsing anything. It's just converting to int using the well
>> documented rules of string to integer conversion which have existed in
>> the language for years. The language is pretty much impossible to use
>> without running into implicit type conversions--it's designed for
>> it. That's why the current behaviour of exit() breaks consistency.
>> Please, check out the Type Juggling section of the manual. This
>> shouldq not a special case, but it currently is treated as one. It
>> should behave the way the rest of the language behaves.
>>
>> > someone already uses exit("123, 456 servers are unavailable"); or
>> > something similar. How should we parse something like that? Chances
>>
>> Again, we don't. We let the language deal with it like it does every
>> other string->integer conversion.
>>
>> > of that are slim, but just as good as Zeev's argument where he says
>> > that there are scripts out there that rely on the current
>> > implementation of exit(), e.g. one of his own. Jamming two values
>> > into a storage space designed for a single value (a string) is bad
>> > :(
>>
>> In the case you gave, the only difference the user would notice
>> would be that the exit status of the script would be 123 instead of
>> 0. It would still print out the '123, 456 servers are unavailable'.
>>
>> > Vlad
>> >
>> >
>> >
>> > Lars Torben Wilson wrote:
>> >
>> > >Vlad Krupin writes:
>> > >
>> > >>Lars Torben Wilson wrote:
>> > >>
>> > >>>Perhaps I have not explained my position. I don't care whether it
>> > >>>outputs the exit status as a string--as long as it sets the error code
>> > >>>appropriately *as well*. By appropriately, I mean that 'exit("boo");'
>> > >>>would a) print 'boo' and b) return with exit status 0, but
>> > >>>'exit("1boo")'; would a) print '1boo' and b) return with exit status
>> > >>>1. This would be consistent with PHP's type conversion rules, and
>> > >>>would also tend to behave in the way that the programmer expects it
>> > >>>to.
>> > >>>
>> > >>Yikes. This is way worse than overloading. In school they called that
>> > >>data-coupling, I think. In real life this is called a hack.
>> > >>
>> > >>Sorry, but a -1 on this.
>> > >>
>> > >>Vlad
>> > >>
>> > >
>> > >No, it's called loose typing. See
>> > >
>> > 
>>http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
>> > >
>> > >We have a language here which considers the integer value of "5" to
>> > >be 5, and an exit() construct which ignores that.
>> > >
>> > >For instance:
>> > >
>> > >  shanna% php -q
>> > >  
>> > >  5
>> > >
>> > >  shanna% echo $?
>> > >  0
>> > >
>> > >  shanna% php -q
>> > >  
>> > >  5
>> > >
>> > >  shanna% echo $?
>> > >  5
>> > >
>> > >How much sense does this make? None, as far as I can see.
>> > >
>> > >What I'm proposing is to make the behaviour of exit() _not_ depend on
>> > >the type of its argument. At present if the argument is an integer
>> > >exit() prints it and sets the error status, but if it's any other
>> > >type, exit() just prints it and doesn't set the exit status. This is
>> > >more complex than my proposal: no matter what the argument is, print
>> > >out its string value, and set the exit status to its integer value.
>> > >
>> > >AFAICT exit() is currently broken wrt how it handles the type of its
>> > >argument.
>> > >
>> > >
>> >
>> >
>> >
>>
>> --
>>  Torben Wilson <[EMAIL PROTECTED]>
>>  http://www.thebuttlesschaps.com
>>  http://www.hybrid17.com
>>  http://www.inflatableeye.com
>>  +1.604.709.0506
>>
>>
>> --
>> PHP Development Mailing List 
>> To unsubscribe, e-mai

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Markus Fischer]

Why not just check the type of the parameter? No conversion
needed at all. If its a long -> exit/no show it. If anything
else (well, thats to argue, but not the point) exit and show.
It would be that easy. And, in that case, I don't care about
the number of broken scripts. Prove there are more then you
got fingers on your hand. And even those, you can fix under a
second.

On Wed, Dec 19, 2001 at 03:33:15PM -0800, Lars Torben Wilson wrote : 
> Vlad Krupin writes:
> > Please, understand me correctly - I have nothing against exit() working 
> > in the same manner regardless of the type of the argument. I would love 
> > to see that. The problem is that (1) it already accepts a string, and 
> > has been working that way for a long time, so this can't go away, and 
> > (2) there is no other way (AFAIK) to set exit codes, and some people 
> > need that. Those are somewhat contradicting requirements, so we might 
> > have to compromise.
> > 
> > I do have a problem with the compromise you proposed though, if I 
> > understood you correctly. You suggest using something like
> > 
> > > exit("1boo")
> >
> > And having exit() parse the first digit out. That's BAD. What if
> 
> It's not parsing anything. It's just converting to int using the well
> documented rules of string to integer conversion which have existed in
> the language for years. The language is pretty much impossible to use
> without running into implicit type conversions--it's designed for
> it. That's why the current behaviour of exit() breaks consistency.
> Please, check out the Type Juggling section of the manual. This
> shouldq not a special case, but it currently is treated as one. It
> should behave the way the rest of the language behaves. 
> 
> > someone already uses exit("123, 456 servers are unavailable"); or
> > something similar. How should we parse something like that? Chances
> 
> Again, we don't. We let the language deal with it like it does every
> other string->integer conversion.
> 
> > of that are slim, but just as good as Zeev's argument where he says
> > that there are scripts out there that rely on the current
> > implementation of exit(), e.g. one of his own. Jamming two values
> > into a storage space designed for a single value (a string) is bad
> > :(
> 
> In the case you gave, the only difference the user would notice
> would be that the exit status of the script would be 123 instead of
> 0. It would still print out the '123, 456 servers are unavailable'.
> 
> > Vlad
> > 
> > 
> > 
> > Lars Torben Wilson wrote:
> > 
> > >Vlad Krupin writes:
> > >
> > >>Lars Torben Wilson wrote:
> > >>
> > >>>Perhaps I have not explained my position. I don't care whether it
> > >>>outputs the exit status as a string--as long as it sets the error code
> > >>>appropriately *as well*. By appropriately, I mean that 'exit("boo");'
> > >>>would a) print 'boo' and b) return with exit status 0, but
> > >>>'exit("1boo")'; would a) print '1boo' and b) return with exit status
> > >>>1. This would be consistent with PHP's type conversion rules, and
> > >>>would also tend to behave in the way that the programmer expects it
> > >>>to.
> > >>>
> > >>Yikes. This is way worse than overloading. In school they called that 
> > >>data-coupling, I think. In real life this is called a hack.
> > >>
> > >>Sorry, but a -1 on this.
> > >>
> > >>Vlad
> > >>
> > >
> > >No, it's called loose typing. See
> > >
> > 
>>http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
> > >
> > >We have a language here which considers the integer value of "5" to
> > >be 5, and an exit() construct which ignores that.
> > >
> > >For instance:
> > >
> > >  shanna% php -q
> > >  
> > >  5
> > >
> > >  shanna% echo $?
> > >  0
> > > 
> > >  shanna% php -q
> > >  
> > >  5
> > >
> > >  shanna% echo $?
> > >  5
> > >
> > >How much sense does this make? None, as far as I can see.
> > >
> > >What I'm proposing is to make the behaviour of exit() _not_ depend on
> > >the type of its argument. At present if the argument is an integer
> > >exit() prints it and sets the error status, but if it's any other
> > >type, exit() just prints it and doesn't set the exit status. This is
> > >more complex than my proposal: no matter what the argument is, print
> > >out its string value, and set the exit status to its integer value.
> > >
> > >AFAICT exit() is currently broken wrt how it handles the type of its
> > >argument. 
> > >
> > >
> > 
> > 
> > 
> 
> -- 
>  Torben Wilson <[EMAIL PROTECTED]>
>  http://www.thebuttlesschaps.com
>  http://www.hybrid17.com
>  http://www.inflatableeye.com
>  +1.604.709.0506
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]

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

-- 
PHP Development Mailing List 
To 

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Lars Torben Wilson]

Vlad Krupin writes:
> Please, understand me correctly - I have nothing against exit() working 
> in the same manner regardless of the type of the argument. I would love 
> to see that. The problem is that (1) it already accepts a string, and 
> has been working that way for a long time, so this can't go away, and 
> (2) there is no other way (AFAIK) to set exit codes, and some people 
> need that. Those are somewhat contradicting requirements, so we might 
> have to compromise.
> 
> I do have a problem with the compromise you proposed though, if I 
> understood you correctly. You suggest using something like
> 
> > exit("1boo")
>
> And having exit() parse the first digit out. That's BAD. What if

It's not parsing anything. It's just converting to int using the well
documented rules of string to integer conversion which have existed in
the language for years. The language is pretty much impossible to use
without running into implicit type conversions--it's designed for
it. That's why the current behaviour of exit() breaks consistency.
Please, check out the Type Juggling section of the manual. This
shouldq not a special case, but it currently is treated as one. It
should behave the way the rest of the language behaves. 

> someone already uses exit("123, 456 servers are unavailable"); or
> something similar. How should we parse something like that? Chances

Again, we don't. We let the language deal with it like it does every
other string->integer conversion.

> of that are slim, but just as good as Zeev's argument where he says
> that there are scripts out there that rely on the current
> implementation of exit(), e.g. one of his own. Jamming two values
> into a storage space designed for a single value (a string) is bad
> :(

In the case you gave, the only difference the user would notice
would be that the exit status of the script would be 123 instead of
0. It would still print out the '123, 456 servers are unavailable'.

> Vlad
> 
> 
> 
> Lars Torben Wilson wrote:
> 
> >Vlad Krupin writes:
> >
> >>Lars Torben Wilson wrote:
> >>
> >>>Perhaps I have not explained my position. I don't care whether it
> >>>outputs the exit status as a string--as long as it sets the error code
> >>>appropriately *as well*. By appropriately, I mean that 'exit("boo");'
> >>>would a) print 'boo' and b) return with exit status 0, but
> >>>'exit("1boo")'; would a) print '1boo' and b) return with exit status
> >>>1. This would be consistent with PHP's type conversion rules, and
> >>>would also tend to behave in the way that the programmer expects it
> >>>to.
> >>>
> >>Yikes. This is way worse than overloading. In school they called that 
> >>data-coupling, I think. In real life this is called a hack.
> >>
> >>Sorry, but a -1 on this.
> >>
> >>Vlad
> >>
> >
> >No, it's called loose typing. See
> >
> 
>>http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
> >
> >We have a language here which considers the integer value of "5" to
> >be 5, and an exit() construct which ignores that.
> >
> >For instance:
> >
> >  shanna% php -q
> >  
> >  5
> >
> >  shanna% echo $?
> >  0
> > 
> >  shanna% php -q
> >  
> >  5
> >
> >  shanna% echo $?
> >  5
> >
> >How much sense does this make? None, as far as I can see.
> >
> >What I'm proposing is to make the behaviour of exit() _not_ depend on
> >the type of its argument. At present if the argument is an integer
> >exit() prints it and sets the error status, but if it's any other
> >type, exit() just prints it and doesn't set the exit status. This is
> >more complex than my proposal: no matter what the argument is, print
> >out its string value, and set the exit status to its integer value.
> >
> >AFAICT exit() is currently broken wrt how it handles the type of its
> >argument. 
> >
> >
> 
> 
> 

-- 
 Torben Wilson <[EMAIL PROTECTED]>
 http://www.thebuttlesschaps.com
 http://www.hybrid17.com
 http://www.inflatableeye.com
 +1.604.709.0506


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Zeev Suraski]

sys_exit()/system_exit() sound nice to me, definitely nicer than all of my 
suggestions :)

At 23:13 19/12/2001, Jason Greene wrote:
>Zeev,
>
>I understand argument 1, and that's why I like the idea of overloading 
>integer output. I still wonder
>if there is a web page out there that calls exit(integer)
>
>Argument 2 is good, because PHP is focused toward the web, which I 
>understand that it should be.
>However, I believe the language syntax and style can make a good general 
>purpose scripting language
>as well. Things like this can keep PHP from increasing beyond the 10% cmd 
>line usage.
>
>If adding an additional function is all that you will settle for, then I 
>would suggest
>we use sys_exit() or system_exit() that way we resemble some of the 
>languages out there.
>(Java - System.exit(), Python - Sys.exit())
>
>-Jason
>
>
>- Original Message -
>From: "Zeev Suraski" <[EMAIL PROTECTED]>
>To: "Jason Greene" <[EMAIL PROTECTED]>
>Cc: "Lars Torben Wilson" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Vlad Krupin" 
><[EMAIL PROTECTED]>; "Jani Taskinen" <[EMAIL PROTECTED]>; "PHP
>Developers Mailing List" <[EMAIL PROTECTED]>
>Sent: Wednesday, December 19, 2001 2:26 PM
>Subject: Re: [PHP-DEV] Question: Should exit() print out the integer 
>exit-status?
>
>
> > Two reasons:
> > (1) It never behaved that way, and we're not in the language design phase,
> > but almost 4.5 years after it got started.
> > (2) The Web being PHP's primary environment where system exit codes have no
> > meaning at all, makes this argument useless in well over 90% (est) of 
> the cases
> >
> > If (1) wasn't true, we could consider it, and frankly, chances are it would
> > have ended up behaving like its C counterpart.  However, because there's no
> > overwhelming reason to change it other than a few people not liking a
> > longer name for their relatively-rare usage, breaking compatibility makes
> > no sense.
> >
> > Zeev
> >
> > At 17:57 19/12/2001, Jason Greene wrote:
> > >Zeev,
> > >
> > >Why don't we follow C/C++/Java/Perl/Python, and almost every other
> > >language on this one, and make exit behave like exit should.
> > >
> > >-Jason
> > >
> > >- Original Message -
> > >From: "Zeev Suraski" <[EMAIL PROTECTED]>
> > >To: "Lars Torben Wilson" <[EMAIL PROTECTED]>
> > >Cc: <[EMAIL PROTECTED]>; "Vlad Krupin" <[EMAIL PROTECTED]>; "Jani Taskinen"
> > ><[EMAIL PROTECTED]>; "PHP Developers Mailing List"
> > ><[EMAIL PROTECTED]>
> > >Sent: Wednesday, December 19, 2001 6:59 AM
> > >Subject: Re: [PHP-DEV] Question: Should exit() print out the integer
> > >exit-status?
> > >
> > >
> > > > exit_with_status(), silent_exit(), quiet_exit(), etc. etc.  Something
> > > > should fit :)
> > > >
> > > >
> > > > At 14:49 19/12/2001, Lars Torben Wilson wrote:
> > > > >Zeev Suraski writes:
> > > > > > At 14:04 19/12/2001, [EMAIL PROTECTED] wrote:
> > > > > > >Two ways to fix it then, either update the manual, or fix exit().
> > > I go for
> > > > > > >the last one then. Ppl who relied on the undocumented feature
> > > then, did
> > > > > > >simply the wrong thing.
> > > > > >
> > > > > > Only the documentation was wrong to begin with!  A 
> documentation bug
> > > > > should
> > > > > > not become a feature, especially when it never worked that way, so
> > > anybody
> > > > > > who actually used this function saw that it was behaving 
> differently.
> > > > > >
> > > > > > Zeev
> > > > >
> > > > >Well, from another point of view, both were wrong. :) The manual
> > > > >documented behaviour which didn't exist, so it was wrong. In another
> > > > >sense, the code behaved in a fashion which had a very high WTF factor,
> > > > >so it couild be called 'wrong' too.
> > > > >
> > > > >An easy way to set and check the exit status of a PHP script would
> > > > >make a lot of life a hell of a lot easier.
> > > > >
> > > > >
> > > > >--
> > > > >  Torben Wilson <[EMAIL PROTECTED]>
> > > > >  http://www.thebuttlesschaps.com
> > > > >  http://www.hybrid17.com
> > > > >  http://www.inflatableeye.com
> > > > >  +1.604.709.0506
> > > >
> > > >
> > > > --
> > > > PHP Development Mailing List <http://www.php.net/>
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > To contact the list administrators, e-mail: 
> [EMAIL PROTECTED]
> > > >
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Vlad Krupin]

Please, understand me correctly - I have nothing against exit() working 
in the same manner regardless of the type of the argument. I would love 
to see that. The problem is that (1) it already accepts a string, and 
has been working that way for a long time, so this can't go away, and 
(2) there is no other way (AFAIK) to set exit codes, and some people 
need that. Those are somewhat contradicting requirements, so we might 
have to compromise.

I do have a problem with the compromise you proposed though, if I 
understood you correctly. You suggest using something like

> exit("1boo")
And having exit() parse the first digit out. That's BAD. What if someone already uses 
exit("123, 456 servers are unavailable"); or something similar. How should we parse 
something like that? Chances of that are slim, but just as good as Zeev's argument 
where he says that there are scripts out there that rely on the current implementation 
of exit(), e.g. one of his own. Jamming two values into a storage space designed for a 
single value (a string) is bad :(

Vlad



Lars Torben Wilson wrote:

>Vlad Krupin writes:
>
>>Lars Torben Wilson wrote:
>>
>>>Perhaps I have not explained my position. I don't care whether it
>>>outputs the exit status as a string--as long as it sets the error code
>>>appropriately *as well*. By appropriately, I mean that 'exit("boo");'
>>>would a) print 'boo' and b) return with exit status 0, but
>>>'exit("1boo")'; would a) print '1boo' and b) return with exit status
>>>1. This would be consistent with PHP's type conversion rules, and
>>>would also tend to behave in the way that the programmer expects it
>>>to.
>>>
>>Yikes. This is way worse than overloading. In school they called that 
>>data-coupling, I think. In real life this is called a hack.
>>
>>Sorry, but a -1 on this.
>>
>>Vlad
>>
>
>No, it's called loose typing. See
>
>http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
>
>We have a language here which considers the integer value of "5" to
>be 5, and an exit() construct which ignores that.
>
>For instance:
>
>  shanna% php -q
>  
>  5
>
>  shanna% echo $?
>  0
> 
>  shanna% php -q
>  
>  5
>
>  shanna% echo $?
>  5
>
>How much sense does this make? None, as far as I can see.
>
>What I'm proposing is to make the behaviour of exit() _not_ depend on
>the type of its argument. At present if the argument is an integer
>exit() prints it and sets the error status, but if it's any other
>type, exit() just prints it and doesn't set the exit status. This is
>more complex than my proposal: no matter what the argument is, print
>out its string value, and set the exit status to its integer value.
>
>AFAICT exit() is currently broken wrt how it handles the type of its
>argument. 
>
>




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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Lars Torben Wilson]

Vlad Krupin writes:
> Lars Torben Wilson wrote:
> >Perhaps I have not explained my position. I don't care whether it
> >outputs the exit status as a string--as long as it sets the error code
> >appropriately *as well*. By appropriately, I mean that 'exit("boo");'
> >would a) print 'boo' and b) return with exit status 0, but
> >'exit("1boo")'; would a) print '1boo' and b) return with exit status
> >1. This would be consistent with PHP's type conversion rules, and
> >would also tend to behave in the way that the programmer expects it
> >to.
> >
> Yikes. This is way worse than overloading. In school they called that 
> data-coupling, I think. In real life this is called a hack.
> 
> Sorry, but a -1 on this.
> 
> Vlad

No, it's called loose typing. See

http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion

We have a language here which considers the integer value of "5" to
be 5, and an exit() construct which ignores that.

For instance:

  shanna% php -q
  
  5

  shanna% echo $?
  0
 
  shanna% php -q
  
  5

  shanna% echo $?
  5

How much sense does this make? None, as far as I can see.

What I'm proposing is to make the behaviour of exit() _not_ depend on
the type of its argument. At present if the argument is an integer
exit() prints it and sets the error status, but if it's any other
type, exit() just prints it and doesn't set the exit status. This is
more complex than my proposal: no matter what the argument is, print
out its string value, and set the exit status to its integer value.

AFAICT exit() is currently broken wrt how it handles the type of its
argument. 


-- 
 Torben Wilson <[EMAIL PROTECTED]>
 http://www.thebuttlesschaps.com
 http://www.hybrid17.com
 http://www.inflatableeye.com
 +1.604.709.0506


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Brian Moon]

No offense Benjamin, but you don't understand the conversation.  This is
about running PHP apps in consoles, mail pre-processors and as cron jobs
where exit status is needed.  The only way to get an exit status is with
exit.

Brian.

- Original Message -
From: "benjamin yates" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, December 19, 2001 3:00 PM
Subject: Re: [PHP-DEV] Question: Should exit() print out the integer
exit-status?


| >What are you talking about?
| >1) Setting the exit status of a process is common.
| >2) Try and right any kind of executer/parser that performs well without
| >goto's
|
|   1 - u can return a value just fine (and silently :) with return, and
| having multiple exit points i've always thought was bad design...
|
|   2 - i don't think anyone is going to write that kind of parser in php...
| but i see your point
|
|   -benjamin
|
| _
| Send and receive Hotmail on your mobile device: http://mobile.msn.com
|
|
| --
| PHP Development Mailing List <http://www.php.net/>
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
| To contact the list administrators, e-mail: [EMAIL PROTECTED]
|
|
|


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Jason Greene]

Zeev,

I understand argument 1, and that's why I like the idea of overloading integer output. 
I still wonder
if there is a web page out there that calls exit(integer)

Argument 2 is good, because PHP is focused toward the web, which I understand that it 
should be.
However, I believe the language syntax and style can make a good general purpose 
scripting language
as well. Things like this can keep PHP from increasing beyond the 10% cmd line usage.

If adding an additional function is all that you will settle for, then I would suggest
we use sys_exit() or system_exit() that way we resemble some of the languages out 
there.
(Java - System.exit(), Python - Sys.exit())

-Jason


- Original Message -
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Jason Greene" <[EMAIL PROTECTED]>
Cc: "Lars Torben Wilson" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Vlad Krupin" 
<[EMAIL PROTECTED]>; "Jani Taskinen" <[EMAIL PROTECTED]>; "PHP
Developers Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, December 19, 2001 2:26 PM
Subject: Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?


> Two reasons:
> (1) It never behaved that way, and we're not in the language design phase,
> but almost 4.5 years after it got started.
> (2) The Web being PHP's primary environment where system exit codes have no
> meaning at all, makes this argument useless in well over 90% (est) of the cases
>
> If (1) wasn't true, we could consider it, and frankly, chances are it would
> have ended up behaving like its C counterpart.  However, because there's no
> overwhelming reason to change it other than a few people not liking a
> longer name for their relatively-rare usage, breaking compatibility makes
> no sense.
>
> Zeev
>
> At 17:57 19/12/2001, Jason Greene wrote:
> >Zeev,
> >
> >Why don't we follow C/C++/Java/Perl/Python, and almost every other
> >language on this one, and make exit behave like exit should.
> >
> >-Jason
> >
> >- Original Message -
> >From: "Zeev Suraski" <[EMAIL PROTECTED]>
> >To: "Lars Torben Wilson" <[EMAIL PROTECTED]>
> >Cc: <[EMAIL PROTECTED]>; "Vlad Krupin" <[EMAIL PROTECTED]>; "Jani Taskinen"
> ><[EMAIL PROTECTED]>; "PHP Developers Mailing List"
> ><[EMAIL PROTECTED]>
> >Sent: Wednesday, December 19, 2001 6:59 AM
> >Subject: Re: [PHP-DEV] Question: Should exit() print out the integer
> >exit-status?
> >
> >
> > > exit_with_status(), silent_exit(), quiet_exit(), etc. etc.  Something
> > > should fit :)
> > >
> > >
> > > At 14:49 19/12/2001, Lars Torben Wilson wrote:
> > > >Zeev Suraski writes:
> > > > > At 14:04 19/12/2001, [EMAIL PROTECTED] wrote:
> > > > > >Two ways to fix it then, either update the manual, or fix exit().
> > I go for
> > > > > >the last one then. Ppl who relied on the undocumented feature
> > then, did
> > > > > >simply the wrong thing.
> > > > >
> > > > > Only the documentation was wrong to begin with!  A documentation bug
> > > > should
> > > > > not become a feature, especially when it never worked that way, so
> > anybody
> > > > > who actually used this function saw that it was behaving differently.
> > > > >
> > > > > Zeev
> > > >
> > > >Well, from another point of view, both were wrong. :) The manual
> > > >documented behaviour which didn't exist, so it was wrong. In another
> > > >sense, the code behaved in a fashion which had a very high WTF factor,
> > > >so it couild be called 'wrong' too.
> > > >
> > > >An easy way to set and check the exit status of a PHP script would
> > > >make a lot of life a hell of a lot easier.
> > > >
> > > >
> > > >--
> > > >  Torben Wilson <[EMAIL PROTECTED]>
> > > >  http://www.thebuttlesschaps.com
> > > >  http://www.hybrid17.com
> > > >  http://www.inflatableeye.com
> > > >  +1.604.709.0506
> > >
> > >
> > > --
> > > PHP Development Mailing List <http://www.php.net/>
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> > >
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[benjamin yates]

>What are you talking about?
>1) Setting the exit status of a process is common.
>2) Try and right any kind of executer/parser that performs well without 
>goto's

  1 - u can return a value just fine (and silently :) with return, and 
having multiple exit points i've always thought was bad design...

  2 - i don't think anyone is going to write that kind of parser in php... 
but i see your point

  -benjamin

_
Send and receive Hotmail on your mobile device: http://mobile.msn.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] Question: Should exit() print out the integer exit-status?

[Jason Greene]

What are you talking about?
1) Setting the exit status of a process is common.
2) Try and right any kind of executer/parser that performs well without goto's

-Jason
- Original Message -
From: "benjamin yates" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; 
<[EMAIL PROTECTED]>
Sent: Wednesday, December 19, 2001 2:45 PM
Subject: Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?


> >Two reasons:
>
> one more...
> (3) exit is as forbidden as goto so stop using it.
>
>   -benjamin
>
> _
> Join the world’s largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[benjamin yates]

>Two reasons:

one more...
(3) exit is as forbidden as goto so stop using it.

  -benjamin

_
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.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] Question: Should exit() print out the integer exit-status?

[Zeev Suraski]

Two reasons:
(1) It never behaved that way, and we're not in the language design phase, 
but almost 4.5 years after it got started.
(2) The Web being PHP's primary environment where system exit codes have no 
meaning at all, makes this argument useless in well over 90% (est) of the cases

If (1) wasn't true, we could consider it, and frankly, chances are it would 
have ended up behaving like its C counterpart.  However, because there's no 
overwhelming reason to change it other than a few people not liking a 
longer name for their relatively-rare usage, breaking compatibility makes 
no sense.

Zeev

At 17:57 19/12/2001, Jason Greene wrote:
>Zeev,
>
>Why don't we follow C/C++/Java/Perl/Python, and almost every other 
>language on this one, and make exit behave like exit should.
>
>-Jason
>
>- Original Message -
>From: "Zeev Suraski" <[EMAIL PROTECTED]>
>To: "Lars Torben Wilson" <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>; "Vlad Krupin" <[EMAIL PROTECTED]>; "Jani Taskinen" 
><[EMAIL PROTECTED]>; "PHP Developers Mailing List"
><[EMAIL PROTECTED]>
>Sent: Wednesday, December 19, 2001 6:59 AM
>Subject: Re: [PHP-DEV] Question: Should exit() print out the integer 
>exit-status?
>
>
> > exit_with_status(), silent_exit(), quiet_exit(), etc. etc.  Something
> > should fit :)
> >
> >
> > At 14:49 19/12/2001, Lars Torben Wilson wrote:
> > >Zeev Suraski writes:
> > > > At 14:04 19/12/2001, [EMAIL PROTECTED] wrote:
> > > > >Two ways to fix it then, either update the manual, or fix exit(). 
> I go for
> > > > >the last one then. Ppl who relied on the undocumented feature 
> then, did
> > > > >simply the wrong thing.
> > > >
> > > > Only the documentation was wrong to begin with!  A documentation bug
> > > should
> > > > not become a feature, especially when it never worked that way, so 
> anybody
> > > > who actually used this function saw that it was behaving differently.
> > > >
> > > > Zeev
> > >
> > >Well, from another point of view, both were wrong. :) The manual
> > >documented behaviour which didn't exist, so it was wrong. In another
> > >sense, the code behaved in a fashion which had a very high WTF factor,
> > >so it couild be called 'wrong' too.
> > >
> > >An easy way to set and check the exit status of a PHP script would
> > >make a lot of life a hell of a lot easier.
> > >
> > >
> > >--
> > >  Torben Wilson <[EMAIL PROTECTED]>
> > >  http://www.thebuttlesschaps.com
> > >  http://www.hybrid17.com
> > >  http://www.inflatableeye.com
> > >  +1.604.709.0506
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Vlad Krupin]

Lars Torben Wilson wrote:

>Zeev Suraski writes:
>
>>At 15:15 19/12/2001, Lars Torben Wilson wrote:
>>
>>>Zeev Suraski writes:
>>>
exit_with_status(), silent_exit(), quiet_exit(), etc. etc.  Something
should fit :)

>>>Yeah, you could do that. But then, why don't we have a
>>>'c_compatible_dirname()' now, instead of a proper dirname() patch
>>>which has been proven to break BC? Because the new version is Correct--at
>>>least according to programming tradition. (Sorry, Manuel.) A function
>>>named exit(), which accepts an argument, is just _expected_ to set the
>>>exit status (assuming the coder has coded in other languages before).
>>>
>>>A better solution IMHO would be to make exit() do the right thing and
>>>create a new function named something like 'exit_print()' which
>>>behaves the way the current exit() does.
>>>
>>>Besides, as Vlad pointed out it's a _hell_ of a lot easier to do
>>>the print-out thing in userland than it is to set the exit status. :)
>>>
>>It's not about whether or not it's easy or not - we're not at the stage of 
>>designing the language behavior from scratch now...
>>
>>There's a fundamental difference between dirname(), which is supposed to 
>>answer the question of 'what directory does this file sit in?' - and 
>>there's only one correct answer.  The old dirname() had a bug, period.
>>What a function named exit() does is entirely up to us.  Of course, it's 
>>expected to terminate execution by its very name, but it may do other 
>>things too, such as set the OS error code, print out an error message, etc.
>>
>
>Perhaps I have not explained my position. I don't care whether it
>outputs the exit status as a string--as long as it sets the error code
>appropriately *as well*. By appropriately, I mean that 'exit("boo");'
>would a) print 'boo' and b) return with exit status 0, but
>'exit("1boo")'; would a) print '1boo' and b) return with exit status
>1. This would be consistent with PHP's type conversion rules, and
>would also tend to behave in the way that the programmer expects it
>to.
>
Yikes. This is way worse than overloading. In school they called that 
data-coupling, I think. In real life this is called a hack.

Sorry, but a -1 on this.

Vlad



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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Vlad Krupin]

it's kinda lame to create a yet another function when exit() already 
exists. After a while you have die(), exit(), exit_with_status(),
silent_exit(), loud_exit(), etc. Maybe not *that* bad, but still exit is 
just as simple as... well, an exit. Unfortunately, it seems like there 
will be tons of ways to do a simple operation. Now, imagine you are just 
starting out with PHP - will you be looking for a whole array of exit() 
functions, or will you just try to use the one that seems to make sense, 
namely exit()?

It's not really just an exit() function issue - it is more a question of 
whether we will keep bloating php with more and more functions to save 
BC at any cost or we will draw a line somewhere. As it is right now, 
IMHO, exit with an error code is broken (I just can't see people needing 
that error code printed), and I really don't think that keeping BC 
intact to keep broken things working warrants creation of a new 
function, which mimicks the already existent function, except in a 
proper way.

As far as the bigger picture, we have no guidelines as to what warrants 
breaking BC, and if fixing a broken behaviour constitutes breaking BC. 
Every time this comes up (and it has come up quite a bit lately), there 
is a big discussion, and the decision inevitably ends up being "we'll 
just break it at the next major/minor version". This is a good step, but 
(1) a new major version does not warrant breaking everything, (2) things 
that are totally wrong should get fixed ASAP, because they are already 
broken, and (3) you can not bloat a language indefinitely just for the 
sake of BC, because it ends up being *very* backwards compatible, and at 
the same time *very* cumbersome and harder to learn for new users.

No, I don't have any suggestions as to what to do when those cases (like 
fixing exit()/ fixing docs/ bloating php) arise, but I do think that we 
can have some discussion about it and use it later as some sort of a 
precedent for these kinds of issues.

:) (I'm a friendly guy, don't kill me for expressing my opinions)

Vlad


Zeev Suraski wrote:

> exit_with_status(), silent_exit(), quiet_exit(), etc. etc.  Something 
> should fit :)
>
>
> At 14:49 19/12/2001, Lars Torben Wilson wrote:
>
>> Zeev Suraski writes:
>> > At 14:04 19/12/2001, [EMAIL PROTECTED] wrote:
>> > >Two ways to fix it then, either update the manual, or fix exit(). 
>> I go for
>> > >the last one then. Ppl who relied on the undocumented feature 
>> then, did
>> > >simply the wrong thing.
>> >
>> > Only the documentation was wrong to begin with!  A documentation 
>> bug should
>> > not become a feature, especially when it never worked that way, so 
>> anybody
>> > who actually used this function saw that it was behaving differently.
>> >
>> > Zeev
>>
>> Well, from another point of view, both were wrong. :) The manual
>> documented behaviour which didn't exist, so it was wrong. In another
>> sense, the code behaved in a fashion which had a very high WTF factor,
>> so it couild be called 'wrong' too.
>>
>> An easy way to set and check the exit status of a PHP script would
>> make a lot of life a hell of a lot easier.
>>
>>
>> -- 
>>  Torben Wilson <[EMAIL PROTECTED]>
>>  http://www.thebuttlesschaps.com
>>  http://www.hybrid17.com
>>  http://www.inflatableeye.com
>>  +1.604.709.0506
>
>




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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Jani Taskinen]

1. Because this is how things are done in PHP always..since PHP 3?
2. PHP != C/C++/Java/Perl/Python
3. Zeev says so
4. BC
.
.
.

It's totally useless to make any sense into the language as long
as functions are 'fixed' by adding new functions, new (optional)
arguments are added..etc. I do agree that BC is important.
But is it really wise in a long run?

So far only Zeev has found one script which would break. And
which also can be fixed very easily. This really doesn't prove
his point that fixing the behaviour to be correct would
'break thousands of scripts' and make people angry.

(It still is not clear why someone wants to _see_ the exit status
printed out when not explicitly said so..ie. when it's an integer?)

--Jani


On Wed, 19 Dec 2001, Jason Greene wrote:

>Zeev,
>
>Why don't we follow C/C++/Java/Perl/Python, and almost every other
>language on this one, and make exit behave like exit should.
>
>-Jason
>
>- Original Message -
>From: "Zeev Suraski" <[EMAIL PROTECTED]>
>To: "Lars Torben Wilson" <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>; "Vlad Krupin" <[EMAIL PROTECTED]>; "Jani Taskinen" <[EMAIL PROTECTED]>; 
>"PHP Developers Mailing List"
><[EMAIL PROTECTED]>
>Sent: Wednesday, December 19, 2001 6:59 AM
>Subject: Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?
>
>
>> exit_with_status(), silent_exit(), quiet_exit(), etc. etc.  Something
>> should fit :)
>>
>>
>> At 14:49 19/12/2001, Lars Torben Wilson wrote:
>> >Zeev Suraski writes:
>> > > At 14:04 19/12/2001, [EMAIL PROTECTED] wrote:
>> > > >Two ways to fix it then, either update the manual, or fix exit(). I go for
>> > > >the last one then. Ppl who relied on the undocumented feature then, did
>> > > >simply the wrong thing.
>> > >
>> > > Only the documentation was wrong to begin with!  A documentation bug
>> > should
>> > > not become a feature, especially when it never worked that way, so anybody
>> > > who actually used this function saw that it was behaving differently.
>> > >
>> > > Zeev
>> >
>> >Well, from another point of view, both were wrong. :) The manual
>> >documented behaviour which didn't exist, so it was wrong. In another
>> >sense, the code behaved in a fashion which had a very high WTF factor,
>> >so it couild be called 'wrong' too.
>> >
>> >An easy way to set and check the exit status of a PHP script would
>> >make a lot of life a hell of a lot easier.
>> >
>> >
>> >--
>> >  Torben Wilson <[EMAIL PROTECTED]>
>> >  http://www.thebuttlesschaps.com
>> >  http://www.hybrid17.com
>> >  http://www.inflatableeye.com
>> >  +1.604.709.0506
>>
>>
>> --
>> PHP Development Mailing List <http://www.php.net/>
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>>
>




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Jason Greene]

Zeev,

Why don't we follow C/C++/Java/Perl/Python, and almost every other language on this 
one, and make exit behave like exit should.

-Jason

- Original Message -
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Lars Torben Wilson" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Vlad Krupin" <[EMAIL PROTECTED]>; "Jani Taskinen" <[EMAIL PROTECTED]>; 
"PHP Developers Mailing List"
<[EMAIL PROTECTED]>
Sent: Wednesday, December 19, 2001 6:59 AM
Subject: Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?


> exit_with_status(), silent_exit(), quiet_exit(), etc. etc.  Something
> should fit :)
>
>
> At 14:49 19/12/2001, Lars Torben Wilson wrote:
> >Zeev Suraski writes:
> > > At 14:04 19/12/2001, [EMAIL PROTECTED] wrote:
> > > >Two ways to fix it then, either update the manual, or fix exit(). I go for
> > > >the last one then. Ppl who relied on the undocumented feature then, did
> > > >simply the wrong thing.
> > >
> > > Only the documentation was wrong to begin with!  A documentation bug
> > should
> > > not become a feature, especially when it never worked that way, so anybody
> > > who actually used this function saw that it was behaving differently.
> > >
> > > Zeev
> >
> >Well, from another point of view, both were wrong. :) The manual
> >documented behaviour which didn't exist, so it was wrong. In another
> >sense, the code behaved in a fashion which had a very high WTF factor,
> >so it couild be called 'wrong' too.
> >
> >An easy way to set and check the exit status of a PHP script would
> >make a lot of life a hell of a lot easier.
> >
> >
> >--
> >  Torben Wilson <[EMAIL PROTECTED]>
> >  http://www.thebuttlesschaps.com
> >  http://www.hybrid17.com
> >  http://www.inflatableeye.com
> >  +1.604.709.0506
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Lars Torben Wilson]

Zeev Suraski writes:
> >Perhaps I have not explained my position. I don't care whether it
> >outputs the exit status as a string--as long as it sets the error code
> >appropriately *as well*.
> 
> AFAIR, this is the way it works now...
> 
> Zeev

If that were the case I would expect the last 'echo $?' in this
example to output '5' instead of '0'. But I just sank another couple
of scotches so this could be screwed and I'm not gonna think about it
again till morning. :)

See you then,

Torben


Script started on Wed Dec 19 07:05:56 2001

~/work/php-4.1.0RC3
shanna% cat test-exist-status.php
#!/usr/local/bin/php -q


~/work/php-4.1.0RC3
shanna% ./test-exist-status.php 1
PHP 4.1.0RC3
$zero_foo: string: foo; integer: 0
$five_foo: string: 5foo; integer: 5
Exiting with constant 2...
2
~/work/php-4.1.0RC3
shanna% echo $?
2

~/work/php-4.1.0RC3
shanna% echo $?./test-exist-status.php 1
PHP 4.1.0RC3
$zero_foo: string: foo; integer: 0
$five_foo: string: 5foo; integer: 5
Exiting with $sero_foo == foo...
foo
~/work/php-4.1.0RC3
shanna% echo $?
0

~/work/php-4.1.0RC3
shanna% ./test-exist-status.php 5
PHP 4.1.0RC3
$zero_foo: string: foo; integer: 0
$five_foo: string: 5foo; integer: 5
Exiting with $five_foo == 5foo...
5foo
~/work/php-4.1.0RC3
shanna% echo $?
0

~/work/php-4.1.0RC3
shanna% exit

Script done on Wed Dec 19 07:06:16 2001




-- 
 Torben Wilson <[EMAIL PROTECTED]>
 http://www.thebuttlesschaps.com
 http://www.hybrid17.com
 http://www.inflatableeye.com
 +1.604.709.0506


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Zeev Suraski]

At 16:11 19/12/2001, Lars Torben Wilson wrote:
>Zeev Suraski writes:
> > At 15:15 19/12/2001, Lars Torben Wilson wrote:
> > >Zeev Suraski writes:
> > > > exit_with_status(), silent_exit(), quiet_exit(), etc. etc.  Something
> > > > should fit :)
> > >
> > >Yeah, you could do that. But then, why don't we have a
> > >'c_compatible_dirname()' now, instead of a proper dirname() patch
> > >which has been proven to break BC? Because the new version is Correct--at
> > >least according to programming tradition. (Sorry, Manuel.) A function
> > >named exit(), which accepts an argument, is just _expected_ to set the
> > >exit status (assuming the coder has coded in other languages before).
> > >
> > >A better solution IMHO would be to make exit() do the right thing and
> > >create a new function named something like 'exit_print()' which
> > >behaves the way the current exit() does.
> > >
> > >Besides, as Vlad pointed out it's a _hell_ of a lot easier to do
> > >the print-out thing in userland than it is to set the exit status. :)
> >
> > It's not about whether or not it's easy or not - we're not at the stage of
> > designing the language behavior from scratch now...
> >
> > There's a fundamental difference between dirname(), which is supposed to
> > answer the question of 'what directory does this file sit in?' - and
> > there's only one correct answer.  The old dirname() had a bug, period.
> > What a function named exit() does is entirely up to us.  Of course, it's
> > expected to terminate execution by its very name, but it may do other
> > things too, such as set the OS error code, print out an error message, etc.
>
>Perhaps I have not explained my position. I don't care whether it
>outputs the exit status as a string--as long as it sets the error code
>appropriately *as well*.

AFAIR, this is the way it works now...

Zeev


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Lars Torben Wilson]

Zeev Suraski writes:
> At 15:15 19/12/2001, Lars Torben Wilson wrote:
> >Zeev Suraski writes:
> > > exit_with_status(), silent_exit(), quiet_exit(), etc. etc.  Something
> > > should fit :)
> >
> >Yeah, you could do that. But then, why don't we have a
> >'c_compatible_dirname()' now, instead of a proper dirname() patch
> >which has been proven to break BC? Because the new version is Correct--at
> >least according to programming tradition. (Sorry, Manuel.) A function
> >named exit(), which accepts an argument, is just _expected_ to set the
> >exit status (assuming the coder has coded in other languages before).
> >
> >A better solution IMHO would be to make exit() do the right thing and
> >create a new function named something like 'exit_print()' which
> >behaves the way the current exit() does.
> >
> >Besides, as Vlad pointed out it's a _hell_ of a lot easier to do
> >the print-out thing in userland than it is to set the exit status. :)
> 
> It's not about whether or not it's easy or not - we're not at the stage of 
> designing the language behavior from scratch now...
> 
> There's a fundamental difference between dirname(), which is supposed to 
> answer the question of 'what directory does this file sit in?' - and 
> there's only one correct answer.  The old dirname() had a bug, period.
> What a function named exit() does is entirely up to us.  Of course, it's 
> expected to terminate execution by its very name, but it may do other 
> things too, such as set the OS error code, print out an error message, etc.

Perhaps I have not explained my position. I don't care whether it
outputs the exit status as a string--as long as it sets the error code
appropriately *as well*. By appropriately, I mean that 'exit("boo");'
would a) print 'boo' and b) return with exit status 0, but
'exit("1boo")'; would a) print '1boo' and b) return with exit status
1. This would be consistent with PHP's type conversion rules, and
would also tend to behave in the way that the programmer expects it
to.

> exit(), since its introduction to PHP, had two usages:
> - Terminate script execution
> - Terminate script execution with an error message
> 
> Changing it is out of the question, as:
> - Thousands of scripts rely on it
> - There's no 'right' or 'wrong' here, unlike dirname().  I personally find 
> the current behavior to be much more useful, as I don't use PHP to create 
> shell scripts, and I do use it to create Web apps.  exit(reason) makes good 
> sense to me.
>
> Changing it to be overloaded is a possibility, but a bad one IMHO, because:
> - Some scripts rely on it to behave as it always did (I have one such script)
> - It's inconsistent

I agree. That's why I think it should 

a) Print out whatever it is given as an argument, and
b) Set the exit status to whatever its argument evaluates to as an int.

This is not overriding, per se. It's just being language-consistent.
 
> Drawbacks to using a new name:
> - Slightly longer to type (negligible)
> - Not obvious to somebody with a background of other languages that support 
> exit(exit_code).  This may be an issue, but I don't think it outweighs the 
> advantages of staying with the current behavior.
>
> Zeev
> 

-- 
 Torben Wilson <[EMAIL PROTECTED]>
 http://www.thebuttlesschaps.com
 http://www.hybrid17.com
 http://www.inflatableeye.com
 +1.604.709.0506


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Zeev Suraski]

At 15:21 19/12/2001, Lars Torben Wilson wrote:
>Zeev Suraski writes:
> > Even if you repeat it may times, it still wouldn't be a bug.  When I wrote
> > exit() I intended exit() to print out its argument, regardless of its
> > type.  It's been behaving like this since PHP 3.0.0 alpha 1, because it 
> was
> > supposed to behave like that.
> > The doc team got it wrong, and misdocumented it.
>
>Only this May. Before that, the docs were correct. Logically, though,
>the fact that a member of the doc team replaced the correct docs with
>an erroneous description doesn't imply that the function behaved
>correctly to start with.

Considering it does what its author intended it to do, and that it's been 
doing that since 1997, yes, it does :)  If we argued about it in 1997 
things may have looked different, but this is almost 2002 now.

Zeev


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Zeev Suraski]

At 15:15 19/12/2001, Lars Torben Wilson wrote:
>Zeev Suraski writes:
> > exit_with_status(), silent_exit(), quiet_exit(), etc. etc.  Something
> > should fit :)
>
>Yeah, you could do that. But then, why don't we have a
>'c_compatible_dirname()' now, instead of a proper dirname() patch
>which has been proven to break BC? Because the new version is Correct--at
>least according to programming tradition. (Sorry, Manuel.) A function
>named exit(), which accepts an argument, is just _expected_ to set the
>exit status (assuming the coder has coded in other languages before).
>
>A better solution IMHO would be to make exit() do the right thing and
>create a new function named something like 'exit_print()' which
>behaves the way the current exit() does.
>
>Besides, as Vlad pointed out it's a _hell_ of a lot easier to do
>the print-out thing in userland than it is to set the exit status. :)

It's not about whether or not it's easy or not - we're not at the stage of 
designing the language behavior from scratch now...

There's a fundamental difference between dirname(), which is supposed to 
answer the question of 'what directory does this file sit in?' - and 
there's only one correct answer.  The old dirname() had a bug, period.
What a function named exit() does is entirely up to us.  Of course, it's 
expected to terminate execution by its very name, but it may do other 
things too, such as set the OS error code, print out an error message, etc.

exit(), since its introduction to PHP, had two usages:
- Terminate script execution
- Terminate script execution with an error message

Changing it is out of the question, as:
- Thousands of scripts rely on it
- There's no 'right' or 'wrong' here, unlike dirname().  I personally find 
the current behavior to be much more useful, as I don't use PHP to create 
shell scripts, and I do use it to create Web apps.  exit(reason) makes good 
sense to me.

Changing it to be overloaded is a possibility, but a bad one IMHO, because:
- Some scripts rely on it to behave as it always did (I have one such script)
- It's inconsistent

Drawbacks to using a new name:
- Slightly longer to type (negligible)
- Not obvious to somebody with a background of other languages that support 
exit(exit_code).  This may be an issue, but I don't think it outweighs the 
advantages of staying with the current behavior.

Zeev


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Lars Torben Wilson]

Zeev Suraski writes:
> Even if you repeat it may times, it still wouldn't be a bug.  When I wrote 
> exit() I intended exit() to print out its argument, regardless of its 
> type.  It's been behaving like this since PHP 3.0.0 alpha 1, because it was 
> supposed to behave like that.
> The doc team got it wrong, and misdocumented it.

Only this May. Before that, the docs were correct. Logically, though,
the fact that a member of the doc team replaced the correct docs with
an erroneous description doesn't imply that the function behaved
correctly to start with.

> Scripts who will break are scripts that terminate after printing out an 
> error code.  I have at least one such script, and I'm pretty sure that more 
> exist, especially in automated environments.
> 
> Zeev
> 
> At 15:08 19/12/2001, Jani Taskinen wrote:
> 
> >Fixing a bug by adding new function that behaves correctly is really
> >not the way to go. Could you please give me nice example what kind
> >of scripts break if the integer is not printed out?
> >
> >--Jani
> >
> >
> >
> >On Wed, 19 Dec 2001, Zeev Suraski wrote:
> >
> > >exit_with_status(), silent_exit(), quiet_exit(), etc. etc.  Something
> > >should fit :)
> > >
> > >
> > >At 14:49 19/12/2001, Lars Torben Wilson wrote:
> > >>Zeev Suraski writes:
> > >> > At 14:04 19/12/2001, [EMAIL PROTECTED] wrote:
> > >> > >Two ways to fix it then, either update the manual, or fix exit(). I 
> > go for
> > >> > >the last one then. Ppl who relied on the undocumented feature then, did
> > >> > >simply the wrong thing.
> > >> >
> > >> > Only the documentation was wrong to begin with!  A documentation bug
> > >> should
> > >> > not become a feature, especially when it never worked that way, so 
> > anybody
> > >> > who actually used this function saw that it was behaving differently.
> > >> >
> > >> > Zeev
> > >>
> > >>Well, from another point of view, both were wrong. :) The manual
> > >>documented behaviour which didn't exist, so it was wrong. In another
> > >>sense, the code behaved in a fashion which had a very high WTF factor,
> > >>so it couild be called 'wrong' too.
> > >>
> > >>An easy way to set and check the exit status of a PHP script would
> > >>make a lot of life a hell of a lot easier.
> > >>
> > >>
> > >>--
> > >>  Torben Wilson <[EMAIL PROTECTED]>
> > >>  http://www.thebuttlesschaps.com
> > >>  http://www.hybrid17.com
> > >>  http://www.inflatableeye.com
> > >>  +1.604.709.0506
> > >
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 

-- 
 Torben Wilson <[EMAIL PROTECTED]>
 http://www.thebuttlesschaps.com
 http://www.hybrid17.com
 http://www.inflatableeye.com
 +1.604.709.0506


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Lars Torben Wilson]

Zeev Suraski writes:
> exit_with_status(), silent_exit(), quiet_exit(), etc. etc.  Something 
> should fit :)

Yeah, you could do that. But then, why don't we have a
'c_compatible_dirname()' now, instead of a proper dirname() patch
which has been proven to break BC? Because the new version is Correct--at
least according to programming tradition. (Sorry, Manuel.) A function
named exit(), which accepts an argument, is just _expected_ to set the
exit status (assuming the coder has coded in other languages before).

A better solution IMHO would be to make exit() do the right thing and
create a new function named something like 'exit_print()' which
behaves the way the current exit() does.

Besides, as Vlad pointed out it's a _hell_ of a lot easier to do
the print-out thing in userland than it is to set the exit status. :)


Torben

> At 14:49 19/12/2001, Lars Torben Wilson wrote:
> >Zeev Suraski writes:
> > > At 14:04 19/12/2001, [EMAIL PROTECTED] wrote:
> > > >Two ways to fix it then, either update the manual, or fix exit(). I go for
> > > >the last one then. Ppl who relied on the undocumented feature then, did
> > > >simply the wrong thing.
> > >
> > > Only the documentation was wrong to begin with!  A documentation bug 
> > should
> > > not become a feature, especially when it never worked that way, so anybody
> > > who actually used this function saw that it was behaving differently.
> > >
> > > Zeev
> >
> >Well, from another point of view, both were wrong. :) The manual
> >documented behaviour which didn't exist, so it was wrong. In another
> >sense, the code behaved in a fashion which had a very high WTF factor,
> >so it couild be called 'wrong' too.
> >
> >An easy way to set and check the exit status of a PHP script would
> >make a lot of life a hell of a lot easier.
> >
> >
> >--
> >  Torben Wilson <[EMAIL PROTECTED]>
> >  http://www.thebuttlesschaps.com
> >  http://www.hybrid17.com
> >  http://www.inflatableeye.com
> >  +1.604.709.0506
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 

-- 
 Torben Wilson <[EMAIL PROTECTED]>
 http://www.thebuttlesschaps.com
 http://www.hybrid17.com
 http://www.inflatableeye.com
 +1.604.709.0506


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Zeev Suraski]

Even if you repeat it may times, it still wouldn't be a bug.  When I wrote 
exit() I intended exit() to print out its argument, regardless of its 
type.  It's been behaving like this since PHP 3.0.0 alpha 1, because it was 
supposed to behave like that.
The doc team got it wrong, and misdocumented it.
Scripts who will break are scripts that terminate after printing out an 
error code.  I have at least one such script, and I'm pretty sure that more 
exist, especially in automated environments.

Zeev

At 15:08 19/12/2001, Jani Taskinen wrote:

>Fixing a bug by adding new function that behaves correctly is really
>not the way to go. Could you please give me nice example what kind
>of scripts break if the integer is not printed out?
>
>--Jani
>
>
>
>On Wed, 19 Dec 2001, Zeev Suraski wrote:
>
> >exit_with_status(), silent_exit(), quiet_exit(), etc. etc.  Something
> >should fit :)
> >
> >
> >At 14:49 19/12/2001, Lars Torben Wilson wrote:
> >>Zeev Suraski writes:
> >> > At 14:04 19/12/2001, [EMAIL PROTECTED] wrote:
> >> > >Two ways to fix it then, either update the manual, or fix exit(). I 
> go for
> >> > >the last one then. Ppl who relied on the undocumented feature then, did
> >> > >simply the wrong thing.
> >> >
> >> > Only the documentation was wrong to begin with!  A documentation bug
> >> should
> >> > not become a feature, especially when it never worked that way, so 
> anybody
> >> > who actually used this function saw that it was behaving differently.
> >> >
> >> > Zeev
> >>
> >>Well, from another point of view, both were wrong. :) The manual
> >>documented behaviour which didn't exist, so it was wrong. In another
> >>sense, the code behaved in a fashion which had a very high WTF factor,
> >>so it couild be called 'wrong' too.
> >>
> >>An easy way to set and check the exit status of a PHP script would
> >>make a lot of life a hell of a lot easier.
> >>
> >>
> >>--
> >>  Torben Wilson <[EMAIL PROTECTED]>
> >>  http://www.thebuttlesschaps.com
> >>  http://www.hybrid17.com
> >>  http://www.inflatableeye.com
> >>  +1.604.709.0506
> >


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Jani Taskinen]

Fixing a bug by adding new function that behaves correctly is really
not the way to go. Could you please give me nice example what kind
of scripts break if the integer is not printed out?

--Jani



On Wed, 19 Dec 2001, Zeev Suraski wrote:

>exit_with_status(), silent_exit(), quiet_exit(), etc. etc.  Something
>should fit :)
>
>
>At 14:49 19/12/2001, Lars Torben Wilson wrote:
>>Zeev Suraski writes:
>> > At 14:04 19/12/2001, [EMAIL PROTECTED] wrote:
>> > >Two ways to fix it then, either update the manual, or fix exit(). I go for
>> > >the last one then. Ppl who relied on the undocumented feature then, did
>> > >simply the wrong thing.
>> >
>> > Only the documentation was wrong to begin with!  A documentation bug
>> should
>> > not become a feature, especially when it never worked that way, so anybody
>> > who actually used this function saw that it was behaving differently.
>> >
>> > Zeev
>>
>>Well, from another point of view, both were wrong. :) The manual
>>documented behaviour which didn't exist, so it was wrong. In another
>>sense, the code behaved in a fashion which had a very high WTF factor,
>>so it couild be called 'wrong' too.
>>
>>An easy way to set and check the exit status of a PHP script would
>>make a lot of life a hell of a lot easier.
>>
>>
>>--
>>  Torben Wilson <[EMAIL PROTECTED]>
>>  http://www.thebuttlesschaps.com
>>  http://www.hybrid17.com
>>  http://www.inflatableeye.com
>>  +1.604.709.0506
>


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Zeev Suraski]

exit_with_status(), silent_exit(), quiet_exit(), etc. etc.  Something 
should fit :)


At 14:49 19/12/2001, Lars Torben Wilson wrote:
>Zeev Suraski writes:
> > At 14:04 19/12/2001, [EMAIL PROTECTED] wrote:
> > >Two ways to fix it then, either update the manual, or fix exit(). I go for
> > >the last one then. Ppl who relied on the undocumented feature then, did
> > >simply the wrong thing.
> >
> > Only the documentation was wrong to begin with!  A documentation bug 
> should
> > not become a feature, especially when it never worked that way, so anybody
> > who actually used this function saw that it was behaving differently.
> >
> > Zeev
>
>Well, from another point of view, both were wrong. :) The manual
>documented behaviour which didn't exist, so it was wrong. In another
>sense, the code behaved in a fashion which had a very high WTF factor,
>so it couild be called 'wrong' too.
>
>An easy way to set and check the exit status of a PHP script would
>make a lot of life a hell of a lot easier.
>
>
>--
>  Torben Wilson <[EMAIL PROTECTED]>
>  http://www.thebuttlesschaps.com
>  http://www.hybrid17.com
>  http://www.inflatableeye.com
>  +1.604.709.0506


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Lars Torben Wilson]

Zeev Suraski writes:
> At 14:04 19/12/2001, [EMAIL PROTECTED] wrote:
> >Two ways to fix it then, either update the manual, or fix exit(). I go for
> >the last one then. Ppl who relied on the undocumented feature then, did
> >simply the wrong thing.
> 
> Only the documentation was wrong to begin with!  A documentation bug should 
> not become a feature, especially when it never worked that way, so anybody 
> who actually used this function saw that it was behaving differently.
> 
> Zeev

Well, from another point of view, both were wrong. :) The manual
documented behaviour which didn't exist, so it was wrong. In another
sense, the code behaved in a fashion which had a very high WTF factor,
so it couild be called 'wrong' too.

An easy way to set and check the exit status of a PHP script would
make a lot of life a hell of a lot easier.


-- 
 Torben Wilson <[EMAIL PROTECTED]>
 http://www.thebuttlesschaps.com
 http://www.hybrid17.com
 http://www.inflatableeye.com
 +1.604.709.0506


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Zeev Suraski]

At 14:04 19/12/2001, [EMAIL PROTECTED] wrote:
>Two ways to fix it then, either update the manual, or fix exit(). I go for
>the last one then. Ppl who relied on the undocumented feature then, did
>simply the wrong thing.

Only the documentation was wrong to begin with!  A documentation bug should 
not become a feature, especially when it never worked that way, so anybody 
who actually used this function saw that it was behaving differently.

Zeev


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[derick]

Hello,

On Wed, 19 Dec 2001, Lars Torben Wilson wrote:

> Vlad Krupin writes:
> > lot of reasons), and we don't have this functionality. Hence, at least
> > if parameter to exit() is an int, we should just return the error code,
> > *not* print it.
>
> +1

>From a techincal point of view I totally agree with this. But I also know
that it breaks some scripts, IMO, badly coded scripts, but still. I still
say +1 for this.

> > Jani Taskinen wrote:
> >
> > >>From manual:
> > >
> > >"The exit() function terminates execution of the script. It prints
> > >status just before exiting. If status is an integer, that value will be
> > >used as exit-status."
> > >
> > >This can be understood in many ways. If the status is integer,
> > >it is used as exit-status..but it's not clear that it's ALSO printed out
> > >which is simply buggy behaviour.

Two ways to fix it then, either update the manual, or fix exit(). I go for
the last one then. Ppl who relied on the undocumented feature then, did
simply the wrong thing.

Derick


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Lars Torben Wilson]

Vlad Krupin writes:
> Uh?
> You probably do not want to see the returned code printed anyway (unless 
> you are debugging and are lazy to get it in any other way). Chances are 
> that the codes returned by exit() won't make much sense to anyone but 
> the one who develops the code, and it's not too difficult to do:
> echo 1;
> exit(1);
> 
> There are ways to print out a message right before we exit. There aren't 
> too many ways to return an error code. I can think of a very good reason 
> why we might want the error code returned, but not prnted (in fact, a 
> lot of reasons), and we don't have this functionality. Hence, at least 
> if parameter to exit() is an int, we should just return the error code, 
> *not* print it.
> 
> I know, nobody has called a vote, but I thought I'd express my opinion 
> in the form of a vote anyway, since somebody asked:)
> 
> Vlad

+1

> Jani Taskinen wrote:
> 
> >background information:
> >
> >http://bugs.php.net/bug.php?edit=1&id=11008
> >http://bugs.php.net/bug.php?edit=1&id=14574
> >
> >exit() function is broken. Fixing the broken behaviour is the
> >only real solution, IMO.
> >
> >One solution:
> >
> >- When passed argument is string: print out this string
> >- When passed argument is integer: Don't print it, use it as exit-status
> >
> >This is what is the expected behaviour is and I really can't think
> >of any good examples where this would fail. Nobody ever gave any.
> >And to get the REAL users (not only Zeev's opinion) I'm sending
> >this also to php-general.
> >
> >>From manual:
> >
> >"The exit() function terminates execution of the script. It prints
> >status just before exiting. If status is an integer, that value will be
> >used as exit-status."
> >
> >This can be understood in many ways. If the status is integer,
> >it is used as exit-status..but it's not clear that it's ALSO printed out
> >which is simply buggy behaviour.
> >
> >Now, if general concencus amongs the users of PHP is that it should
> >also print out the exit-status when it's an integer then 'shell_exit()'
> >function should be added.
> >
> >--Jani
> >
> >
> >
> >
> 
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 

-- 
 Torben Wilson <[EMAIL PROTECTED]>
 http://www.thebuttlesschaps.com
 http://www.hybrid17.com
 http://www.inflatableeye.com
 +1.604.709.0506


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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[Vlad Krupin]

Uh?
You probably do not want to see the returned code printed anyway (unless 
you are debugging and are lazy to get it in any other way). Chances are 
that the codes returned by exit() won't make much sense to anyone but 
the one who develops the code, and it's not too difficult to do:
echo 1;
exit(1);

There are ways to print out a message right before we exit. There aren't 
too many ways to return an error code. I can think of a very good reason 
why we might want the error code returned, but not prnted (in fact, a 
lot of reasons), and we don't have this functionality. Hence, at least 
if parameter to exit() is an int, we should just return the error code, 
*not* print it.

I know, nobody has called a vote, but I thought I'd express my opinion 
in the form of a vote anyway, since somebody asked:)

Vlad


Jani Taskinen wrote:

>background information:
>
>http://bugs.php.net/bug.php?edit=1&id=11008
>http://bugs.php.net/bug.php?edit=1&id=14574
>
>exit() function is broken. Fixing the broken behaviour is the
>only real solution, IMO.
>
>One solution:
>
>- When passed argument is string: print out this string
>- When passed argument is integer: Don't print it, use it as exit-status
>
>This is what is the expected behaviour is and I really can't think
>of any good examples where this would fail. Nobody ever gave any.
>And to get the REAL users (not only Zeev's opinion) I'm sending
>this also to php-general.
>
>>From manual:
>
>"The exit() function terminates execution of the script. It prints
>status just before exiting. If status is an integer, that value will be
>used as exit-status."
>
>This can be understood in many ways. If the status is integer,
>it is used as exit-status..but it's not clear that it's ALSO printed out
>which is simply buggy behaviour.
>
>Now, if general concencus amongs the users of PHP is that it should
>also print out the exit-status when it's an integer then 'shell_exit()'
>function should be added.
>
>--Jani
>
>
>
>




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

[PHP-DEV] Question: Should exit() print out the integer exit-status?

[Jani Taskinen]

background information:

http://bugs.php.net/bug.php?edit=1&id=11008
http://bugs.php.net/bug.php?edit=1&id=14574

exit() function is broken. Fixing the broken behaviour is the
only real solution, IMO.

One solution:

- When passed argument is string: print out this string
- When passed argument is integer: Don't print it, use it as exit-status

This is what is the expected behaviour is and I really can't think
of any good examples where this would fail. Nobody ever gave any.
And to get the REAL users (not only Zeev's opinion) I'm sending
this also to php-general.

>From manual:

"The exit() function terminates execution of the script. It prints
status just before exiting. If status is an integer, that value will be
used as exit-status."

This can be understood in many ways. If the status is integer,
it is used as exit-status..but it's not clear that it's ALSO printed out
which is simply buggy behaviour.

Now, if general concencus amongs the users of PHP is that it should
also print out the exit-status when it's an integer then 'shell_exit()'
function should be added.

--Jani




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

[PHP-DEV] question re: Bug id #5428

[Adam Wisniewski]

Hi all,

Link "http://bugs.php.net/bug-dos-and-donts.php"; is mentioned @
"http://bugs.php.net/bug.php?id=5428";, any idea if this link is still
working or around anywhere, or would it even be helpful to me.

I'm getting "segmentation fault (11)" when executing Sablotron's
xslt_process() function.
apache-1.3.19 / php-4.0.6 / Sablot-0.70 / expat-1.95.2



Thanks for any help,


Adam Wisniewski
TouchBase Consulting
1583 Woodgate Trail
Oshawa, Ontario
l1g 8c8
[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] Question about php_fopen_and_set_opened_path...

[Andy Sautins]

Not 100% sure what my question is here, but I'm curious.

A little while back I was running PHP-4.0.6 on Solaris8 using apache and
wanted to get an idea of expect performance and configuration issues ( was
mostly curious about my apache configuration to make sure the .htaccess
calls were removed ).   I ran a perl script to hit the following script:



   I trussed an apache/php httpd process and was a little suprised by the
results.
There is a string of open/fstat/getdents64/close calls that are the majority
of the
system activity for the above simple example and I'm assuming is the
majority of
the I/O wait under load.

   I think I traced it down to a call to expand_filepath in
php_fopen_and_set_opened_path.
Not sure why this is done or what it is for.  Could someone please enlighten
me?  It is my
belief that if it could be minimized that it could significantly reduce
system load for simple
php scripts.

   Thanks.  Hope this makes sense.  What follows is the truss for a single
HTTP Get to
the above simple script:

umask(077) = 022
umask(022) = 077
setitimer(ITIMER_PROF, 0xFFBEF520, 0x) = 0
sigaction(SIGPROF, 0xFFBEF3F0, 0xFFBEF470) = 0
sigprocmask(SIG_UNBLOCK, 0xFFBEF510, 0x) = 0
pathconf(".", _PC_PATH_MAX) = 1024
stat64("./", 0xFFBEE408) = 0
stat64("/", 0xFFBEE370) = 0
open64("./../", O_RDONLY|O_NDELAY) = 5
fcntl(5, F_SETFD, 0x0001) = 0
fstat64(5, 0xFFBECD90) = 0
fstat64(5, 0xFFBEE408) = 0
close(5) = 0
chdir("/local/home/usr/local/apache/htdocs") = 0
open("/local/home/usr/local/apache/htdocs/f.php", O_RDONLY) = 5
pathconf(".", _PC_PATH_MAX) = 1024
stat64("./", 0xFFBED730) = 0
stat64("/", 0xFFBED698) = 0
open64("./../", O_RDONLY|O_NDELAY) = 6
fcntl(6, F_SETFD, 0x0001) = 0
fstat64(6, 0xFFBECCB8) = 0
fstat64(6, 0xFFBED730) = 0
getdents64(6, 0x0016A538, 1048) = 320
close(6) = 0
open64("./../../", O_RDONLY|O_NDELAY) = 6
fcntl(6, F_SETFD, 0x0001) = 0
fstat64(6, 0xFFBECCB8) = 0
fstat64(6, 0xFFBED730) = 0
getdents64(6, 0x0016A538, 1048) = 144
close(6) = 0
open64("./../../../", O_RDONLY|O_NDELAY) = 6
fcntl(6, F_SETFD, 0x0001) = 0
fstat64(6, 0xFFBECCB8) = 0
fstat64(6, 0xFFBED730) = 0
getdents64(6, 0x0016A538, 1048) = 648
close(6) = 0
open64("./../../../../", O_RDONLY|O_NDELAY) = 6
fcntl(6, F_SETFD, 0x0001) = 0
fstat64(6, 0xFFBECCB8) = 0
fstat64(6, 0xFFBED730) = 0
getdents64(6, 0x0016A538, 1048) = 208
close(6) = 0
open64("./../../../../../", O_RDONLY|O_NDELAY) = 6
fcntl(6, F_SETFD, 0x0001) = 0
fstat64(6, 0xFFBECCB8) = 0
fstat64(6, 0xFFBED730) = 0
getdents64(6, 0x0016A538, 1048) = 432
close(6) = 0
open64("./../../../../../../", O_RDONLY|O_NDELAY) = 6
fcntl(6, F_SETFD, 0x0001) = 0
fstat64(6, 0xFFBECCB8) = 0
fstat64(6, 0xFFBED730) = 0
open("/etc/mnttab", O_RDONLY) = 7
fstat64(7, 0xFFBEC678) = 0
ioctl(7, TCGETA, 0xFFBEC604) Err#22 EINVAL
read(7, " / d e v / d s k / c 0 t".., 512) = 455
ioctl(7, (('m'<<8)|1), 0xFF238BE0) = 0
ioctl(7, (('m'<<8)|2), 0x000BEA18) = 0
lstat64("/local", 0xFFBEC898) = 0
lstat64("/local/..", 0xFFBEC898) = 0
llseek(7, 0, SEEK_CUR) = 455
close(7) = 0
close(6) = 0
resolvepath("/local/home/usr/local/apache/htdocs/f.php",
"/local/home/usr/local/apache/htdocs/f.php", 1024) = 46
ioctl(5, TCGETA, 0xFFBEE224) Err#25 ENOTTY
fstat64(5, 0xFFBECAB8) = 0
ioctl(5, TCGETA, 0xFFBECA44) Err#25 ENOTTY
read(5, " < ? p r i n t " T e".., 8192) = 339
read(5, 0x001927B4, 8192) = 0
ioctl(5, TCGETA, 0xFFBECB1C) Err#25 ENOTTY
llseek(5, 0, SEEK_CUR) = 339
close(5) = 0
chdir("/") = 0
umask(022)



-- 
PHP Development Mailing 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] RE: [PHP-DEV] Question about PDF lib.

[By Proxy]

Try http://groups.yahoo.com/pdflib/

- Original Message -
From: "Criegern, Phillipp von (PDV)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 6:12 PM
Subject: [PHP] RE: [PHP-DEV] Question about PDF lib.


> I would suggest looking for a real *Support Forum* or
http://www.pdflib.com/
>
> >Do anyone know, how i define the "width", "height" etc. parameters in
> PDFlib
> >functions in PHP? Is it in cm, pixels, inch? Or?
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Question about PDF lib.

[Criegern, Phillipp von (PDV)]

I would suggest looking for a real *Support Forum* or http://www.pdflib.com/

>Do anyone know, how i define the "width", "height" etc. parameters in
PDFlib 
>functions in PHP? Is it in cm, pixels, inch? Or?

-- 
PHP Development Mailing 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] Question about PDF lib.

[Johan Holst Nielsen]

Hi

Do anyone know, how i define the "width", "height" etc. parameters in PDFlib 
functions in PHP? Is it in cm, pixels, inch? Or?

Anyone know?

I need to generate printingfiles, so I hope I can use cm or sometime like 
that :o)

Regards,

Johan

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