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.bak Wed 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 <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]
