Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:79956 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 77373 invoked from network); 26 Dec 2014 06:05:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Dec 2014 06:05:40 -0000 Authentication-Results: pb1.pair.com smtp.mail=xinchen.h@zend.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=laruence@php.net; sender-id=unknown Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.215.42 as permitted sender) X-PHP-List-Original-Sender: xinchen.h@zend.com X-Host-Fingerprint: 209.85.215.42 mail-la0-f42.google.com Received: from [209.85.215.42] ([209.85.215.42:52046] helo=mail-la0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 17/B2-57071-DAAFC945 for ; Fri, 26 Dec 2014 01:05:36 -0500 Received: by mail-la0-f42.google.com with SMTP id gd6so8621269lab.1 for ; Thu, 25 Dec 2014 22:05:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=JpZNfQVMS1nsGC7pkY25jl1q53+QDIvudIsfDoZK2ws=; b=BEjZzHu+t3S9fpN33OxFSG39L+oIQB6utcWNm8OESKcwVXE6z4XvPGY2PhxY/dnUF1 0SQdz4R5HtyYuHv3l0XlAhKIPxrRXiCD4JN24fLlo8SKndeSxCwPOb14sjKKPCLXQ112 qacQnknQqf56EJejjIfc+IBWXvKO7WlKk8TMkpmnzq+yDVIZIglI8pKcrsiJFyllFJLD AhoEEeS2vNdKhISVNQRoXUvG1BBCFX1BCQ34RWe1mUul9Hyv8DNLjhwloe83fBZjFO1a fUGR9cVT1vQO4u/PY4hMl/KJcCK0cAcoW73jbSJXaSpQEVUmHS5uc71rhFFTq9fMLo02 7dBg== X-Gm-Message-State: ALoCoQnet+8fa4azwde/A19RvfIEdRKnVUtiDEiqgiKom6sq1e+KrrsDQRrR+i1fSX76bVkV8JkTP8add0bRzY4fbUj0C4EZT8tUHliIDlsNAFBzAKHBN6tm5Z2UgiHZWXvjyvqw2CI7DbRPlPIbmWBL4xXR+MWonQ== X-Received: by 10.152.205.75 with SMTP id le11mr36550004lac.20.1419573930465; Thu, 25 Dec 2014 22:05:30 -0800 (PST) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com. [209.85.215.48]) by mx.google.com with ESMTPSA id kt7sm7727970lac.4.2014.12.25.22.05.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Dec 2014 22:05:28 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id gf13so8277359lab.7 for ; Thu, 25 Dec 2014 22:05:28 -0800 (PST) X-Received: by 10.152.1.201 with SMTP id 9mr42008081lao.36.1419573928514; Thu, 25 Dec 2014 22:05:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.64.176 with HTTP; Thu, 25 Dec 2014 22:05:08 -0800 (PST) In-Reply-To: References: <946C1B1D-30B8-4029-A5A1-73D515A017D8@ajf.me> <1419428487.29904.6.camel@kuechenschabe> <5E26F21C-EA41-43FF-8DDB-D0A985AB4197@ajf.me> <1419463624.28792.6.camel@kuechenschabe> <51160B8D-F662-458E-A0E0-1F37DC3A8869@ajf.me> Date: Fri, 26 Dec 2014 14:05:08 +0800 Message-ID: To: Michael Wallner Cc: =?UTF-8?Q?Johannes_Schl=C3=BCter?= , Levi Morrison , Pierre Joye , PHP internals , Andrea Faulds Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] About SUCCESS/FAILURE From: laruence@php.net (Xinchen Hui) Hey: On Fri, Dec 26, 2014 at 5:33 AM, Michael Wallner wrote: > There's already ZEND_RESULT_CODE, or did I miss anything? yes, we were talking about use ZEND_RESULT_CODE as return type hinting for those functions use SUCCSS/FAILURE .. furthermore, maybe we could use it as all ZEND_API's return type hinting thanks > > On 25 Dec 2014 06:45, "Xinchen Hui" wrote: >> >> Hey: >> >> On Thu, Dec 25, 2014 at 12:38 PM, Pierre Joye >> wrote: >> > On Thu, Dec 25, 2014 at 3:06 PM, Andrea Faulds wrote: >> >> >> >>> On 24 Dec 2014, at 23:53, Levi Morrison wrote: >> >>> >> >>> On Wed, Dec 24, 2014 at 4:27 PM, Johannes Schl=C3=BCter >> >>> 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 >> >>>>> that >> >>>>> 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 ofte= n >> >>>> 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 returne= d >> >>> 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 rang= e. >> >>> Notably, it doesn't make sense to do `strpos() =3D=3D SUCCESS` to ch= eck >> >>> success; these are different cases. My question is specifically >> >>> directed at the ones that use SUCCESS and FAILURE: which ones requir= e >> >>> 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 som= e >> >>> other name which indicates whether an operation succeeded or not for >> >>> the reasons already cited in this thread. I just don't see why FAILU= RE >> >>> 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 r= eturn >> >> negative error codes, others just -1. Some functions return useful po= sitive >> >> values, others just 0. But the idea is that all functions return a ne= gative >> >> number on error, so you can use if (foo() < 0) to check for errors. T= hat=E2=80=99s >> >> the point of making FAILURE be -1, AIUI. It makes it consistent with = other >> >> 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 >> > --=20 Xinchen Hui @Laruence http://www.laruence.com/