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