Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79945
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
Sender: mike.php.net@gmail.com
In-Reply-To: <CABBJUpd=+wUey1xLdC3+D-J9TspC+mARuWbTMDG4zALYA32KCA@mail.gmail.com>
References: <CABBJUpdWefmJAYK7rmwJ09kEVRvdLV8ruLJuLJMyM7W3Z8Z2Jw@mail.gmail.com>
	<946C1B1D-30B8-4029-A5A1-73D515A017D8@ajf.me>
	<1419428487.29904.6.camel@kuechenschabe>
	<CAEZPtU4_6uFjj1NWCjVhwcDSr2-94d+VW6JPoenXUFx=V=XS7Q@mail.gmail.com>
	<CAFMT4Nq-PdyJzfeZ8=FW6-CXZv6jDNYwhMTSRSKf6GaMuNwCVA@mail.gmail.com>
	<5E26F21C-EA41-43FF-8DDB-D0A985AB4197@ajf.me>
	<CAFMT4NoafZCLxsdaaUsBYp0t7xAWxdsjkFKUhXV_5-g34-TsRA@mail.gmail.com>
	<1419463624.28792.6.camel@kuechenschabe>
	<CAFMT4NqO8Z2AWsJxCJUWNvN6eAzT4foTojF4riGG4mZpUh4zWA@mail.gmail.com>
	<51160B8D-F662-458E-A0E0-1F37DC3A8869@ajf.me>
	<CAEZPtU7Jn_PHtAKbrYTXZm5GohA-qXq9M6+JnOt4OCUokRuuyA@mail.gmail.com>
	<CABBJUpd=+wUey1xLdC3+D-J9TspC+mARuWbTMDG4zALYA32KCA@mail.gmail.com>
Date: Thu, 25 Dec 2014 22:33:34 +0100
Message-ID: <CALJZF3iomGCVm-HytJAAoOttR7CeDvJ_bwQd2zk62yXv0aaoAw@mail.gmail.com>
To: Laruence <laruence@php.net>
Cc: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>, 
	Levi Morrison <levim@php.net>, Pierre Joye <pierre.php@gmail.com>, 
	PHP internals <internals@lists.php.net>, Andrea Faulds <ajf@ajf.me>
Content-Type: multipart/alternative; boundary=001a11c3bb3209efc8050b11297f
Subject: Re: [PHP-DEV] About SUCCESS/FAILURE
From: mike@php.net (Michael Wallner)

--001a11c3bb3209efc8050b11297f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

There's already ZEND_RESULT_CODE, or did I miss anything?
 On 25 Dec 2014 06:45, "Xinchen Hui" <laruence@php.net> wrote:

> Hey:
>
> On Thu, Dec 25, 2014 at 12:38 PM, Pierre Joye <pierre.php@gmail.com>
> wrote:
> > On Thu, Dec 25, 2014 at 3:06 PM, Andrea Faulds <ajf@ajf.me> wrote:
> >>
> >>> On 24 Dec 2014, at 23:53, Levi Morrison <levim@php.net> wrote:
> >>>
> >>> On Wed, Dec 24, 2014 at 4:27 PM, Johannes Schl=C3=BCter
> >>> <johannes@schlueters.de> wrote:
> >>>> On Wed, 2014-12-24 at 11:13 -0700, Levi Morrison wrote:
> >>>>
> >>>>> I'm asking for specific things. The reason is that some API's do a
> >>>>> non-zero error code; the fact that they are negative is a detail th=
at
> >>>>> we should not need to care about.
> >>>>
> >>>> My guess is that positive values more often might have a meaning ("5
> >>>> items changed", "address 0x1234") whereas negative values less often
> >>>> have a meaning. Also passing -1 as parameter is more often invalid.
> Thus
> >>>> passing -1 is making debug output look more suspicious.
> >>>>
> >>>>        (while there are  cases where -1 is valid, see recent famous
> pid
> >>>>        =3D fork(); /* ... */ kill(pid, SIGKILL); issue)
> >>>
> >>> I don't think this is the same use case as SUCCESS and FAILURE. Many
> >>> functions have an out parameter which is only valid when the returned
> >>> value is SUCCESS. This is not the same thing as an API which returns
> >>> an integer and just happen to embed error state in the negative range=
.
> >>> Notably, it doesn't make sense to do `strpos() =3D=3D SUCCESS` to che=
ck
> >>> success; these are different cases. My question is specifically
> >>> directed at the ones that use SUCCESS and FAILURE: which ones require
> >>> FAILURE to be negative instead of the normal UNIX-ism of non-zero?
> >>>
> >>> For the record I am in favor of an enum such as `zend_status` or some
> >>> other name which indicates whether an operation succeeded or not for
> >>> the reasons already cited in this thread. I just don't see why FAILUR=
E
> >>> needs to be negative and want to know why this is the case.
> >>
> >> Hi Levi,
> >>
> >> Again, I think the reason FAILURE is -1 is for consistency with other
> functions which use negative return values on error. Some functions retur=
n
> negative error codes, others just -1. Some functions return useful positi=
ve
> values, others just 0. But the idea is that all functions return a negati=
ve
> number on error, so you can use if (foo() < 0) to check for errors. That=
=E2=80=99s
> the point of making FAILURE be -1, AIUI. It makes it consistent with othe=
r
> things, like fork() or strpos().
> >
> > doing if (foo() < 0  is exactly what should not be done, for any
> > function returning a status. Only FAILURE and SUCCESS should be used.
> >
> > Which value FAILURE and SUCCESS have is not really relevant here but
> > to actually be consistent.
> >
> > For example
> >
> > ZEND_API int zend_hash_del(HashTable *ht, zend_string *key)
> >
> > should actually be
> >
> > ZEND_API status zend_hash_del(HashTable *ht, zend_string *key)
> >
> > and its usage should be:
> >
> > if (zend_hash_del(ht, key) =3D=3D FAILURE) {
> > ...
> > }
> >
> > Same for zend_parse_parameters and the likes.
> >
> > However functions like  zval_update_class_constant
> > (http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_API.c#1132 ) and all the
> > underlying functions, are confusing. Both the signature and the return
> > values should rely on FAILURE/SUCCESS.
> >
> > I think this is what Xinchen means too. Or at least this is what I
> > mean with unify the APIs.
> yes. and as a soft solution.
>
> we can change these functions which use success/failure return
> zend_status instead of int first.
>
> thanks
>
> >
> > Cheers,
> > --
> > Pierre
> >
> > @pierrejoye | http://www.libgd.org
>
>
>
> --
> Xinchen Hui
> @Laruence
> http://www.laruence.com/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11c3bb3209efc8050b11297f--