Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:79928 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48648 invoked from network); 24 Dec 2014 23:53:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Dec 2014 23:53:08 -0000 Authentication-Results: pb1.pair.com smtp.mail=morrison.levi@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=morrison.levi@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.46 as permitted sender) X-PHP-List-Original-Sender: morrison.levi@gmail.com X-Host-Fingerprint: 209.85.218.46 mail-oi0-f46.google.com Received: from [209.85.218.46] ([209.85.218.46:56602] helo=mail-oi0-f46.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 32/60-39162-3E15B945 for ; Wed, 24 Dec 2014 18:53:08 -0500 Received: by mail-oi0-f46.google.com with SMTP id h136so18883028oig.5 for ; Wed, 24 Dec 2014 15:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=6odgbF5bec4LWEtEr3vhBC5tBRTsUEHDWVPkrPHRxxg=; b=SRAKfFyP/ByZrzPIPHJHg6SS4NXo6qsRp+sGRFB9PfZX9OLTiqbTaCEA+/B28aC4YB yMy52Q6Jr1zQmytx+NrqIKEfWAyUA8PnmQTuN3m2q/Kemso9JknQxiqzHpwXmrFO8f3G f2lgR7qemfMrRJw7g+6FeZBl8I7nujuDRDrSCbVcnb2DeRz0O6RMVohWwPybH/QmHpfV l8C9pEerdXNiIhs1B1fPJlSQ0r9mll/nVKfILijnRS8fmbVd8mBq3+5GZiolbDqlOvR7 s4E2rQycsUiWYlQGmPRGijDUCDDax1GdCoudenTr1UgqMiMgq2t1BssVIsFf0BCbILtQ 5VfA== MIME-Version: 1.0 X-Received: by 10.182.130.232 with SMTP id oh8mr21113622obb.49.1419465184857; Wed, 24 Dec 2014 15:53:04 -0800 (PST) Sender: morrison.levi@gmail.com Received: by 10.76.89.237 with HTTP; Wed, 24 Dec 2014 15:53:04 -0800 (PST) In-Reply-To: <1419463624.28792.6.camel@kuechenschabe> 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> Date: Wed, 24 Dec 2014 16:53:04 -0700 X-Google-Sender-Auth: rj6Ies-Jx8hQGs6ORHMcQMFqbzs Message-ID: To: =?UTF-8?Q?Johannes_Schl=C3=BCter?= Cc: Andrea Faulds , Pierre Joye , PHP internals , Laruence Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] About SUCCESS/FAILURE From: levim@php.net (Levi Morrison) 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 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 check 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 FAILURE needs to be negative and want to know why this is the case.