Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:101155 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 75560 invoked from network); 26 Nov 2017 16:28:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Nov 2017 16:28:32 -0000 Authentication-Results: pb1.pair.com header.from=ml@anderiasch.de; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ml@anderiasch.de; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain anderiasch.de designates 81.169.138.148 as permitted sender) X-PHP-List-Original-Sender: ml@anderiasch.de X-Host-Fingerprint: 81.169.138.148 ares.art-core.org Received: from [81.169.138.148] ([81.169.138.148:47316] helo=ares.art-core.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A1/23-26862-EABEA1A5 for ; Sun, 26 Nov 2017 11:28:31 -0500 Received: from [192.168.178.20] (p50802EE8.dip0.t-ipconnect.de [80.128.46.232]) by ares.art-core.org (mail.art-core.org) with ESMTPSA id 10A9910380002; Sun, 26 Nov 2017 16:28:28 +0000 (UTC) To: PHP internals Cc: Sara Golemon References: <73a4b3a5-5a48-fdab-8d7a-08cc596661ff@anderiasch.de> Message-ID: <587c708c-48b9-b18e-098f-26ac0a113cc8@anderiasch.de> Date: Sun, 26 Nov 2017 17:28:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] net_get_interfaces() From: ml@anderiasch.de (Florian Anderiasch) On 26.11.2017 17:10, Sara Golemon wrote: > On Sun, Nov 26, 2017 at 10:53 AM, Florian Anderiasch wrote: >> Looks good in theory, but without a lot of thought, how likely is this >> to break/work on "supported" operating systems? (Which ones are that, >> actually? http://php.net/manual/en/install.unix.php lists the BSDs and >> Solaris and HP/UX) >> >> I know, it explicitly mentions Windows and Linux - also probably someone >> tried it on OSX, and I don't think (Free|Open|Net)BSD will be a big >> problem here, but as I'm no expert on that - does that matter? Will it >> need "just a little work" or could the more exotic ones be more problematic? >> > Without a comprehensive CI matrix to run diffs like this against, > there's no way to be absolutely certain it'll work everywhere. > > That said, the config.m4 changes specifically test for the new APIs > being used. If they fail to compile in a standalone environment, the > new function isn't enabled for compilation in the main build. So, at > worst, we may find some OSs (AIX, Solaris, etc...) simply don't gain > the new functionality, but it shouldn't {knock on wood} cause any > builds to break. If it does, we have an entire year for interested > parties to catch it. Yeah, I know, and I'd agree on the "absolutely certain" part - but as this is not an extension, I have somewhat of an uneasy feeling to even merge this without some at least rudimentary testing on "all" OSes. I am confident it would probably work on most and can be fixed on the others - but I see that as a TODO during the PR phase. Speaking from a user PoV - if this simply doesn't work on some OSes for no good reason.. that's a pretty leaky abstraction. If it's in the PHP core, I'd assume it will work. Also I wouldn't count on it getting done, just because there's one year of time and "we have no CI for that" is not a good excuse in my book. Don't get me wrong, this sounds like a useful feature - but (and my wild guessing could be inaccurate) I think it's low-level enough that the differences might matter. Greetings, Florian