Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:101161 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 33695 invoked from network); 27 Nov 2017 15:34:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Nov 2017 15:34:52 -0000 Authentication-Results: pb1.pair.com smtp.mail=ml@anderiasch.de; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ml@anderiasch.de; 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:46328] helo=ares.art-core.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B3/F7-26862-8903C1A5 for ; Mon, 27 Nov 2017 10:34:49 -0500 Received: from [192.168.178.20] (p4FC4A9F3.dip0.t-ipconnect.de [79.196.169.243]) by ares.art-core.org (mail.art-core.org) with ESMTPSA id B174910380018; Mon, 27 Nov 2017 15:34:45 +0000 (UTC) To: PHP internals Cc: Dan Ackroyd , Sara Golemon References: <73a4b3a5-5a48-fdab-8d7a-08cc596661ff@anderiasch.de> <587c708c-48b9-b18e-098f-26ac0a113cc8@anderiasch.de> Message-ID: <142a4a73-ee43-efea-d1f9-69ad981178f9@anderiasch.de> Date: Mon, 27 Nov 2017 16:34:43 +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 27.11.2017 12:15, Dan Ackroyd wrote: > On 26 November 2017 at 16:28, Florian Anderiasch wrote: > >> if this simply doesn't work on some OSes for >> no good reason.. that's a pretty leaky abstraction. > > Cool. Does that mean that we can drop support for 32bit builds if > leaky abstractions are an important thing? If someone commits something that only works on 64bit and wasn't tested a single time on a 32 bit machine - yes. >> Looks good in theory, but without a lot of thought, how likely is this >> to break/work on "supported" operating systems? > > It's likely to work on platforms that have the C functions > implemented. Which is the level of guarantee that PHP aims for; "If > the platform implements a feature, PHP will expose it, but won't > always go out of its way to work around missing features". Yes, I wrote that it's likely. Maybe I just didn't make myself clear enough that I see a *slight* difference between something that's relatively nicely encapsulated in the language itself versus something that not only depends on some C headers, but maybe the whole network stack of the OS. >> just because there's one year of time and "we have no CI for that" is >> not a good excuse in my book. > > If this is important to you, please step up and do something about it. > > If it is only of just enough importance to you that you send an email > to this list, asking other people to do a shedload of work to satisfy > your vague feelings, then as Sara said, committing it now gives people > a whole year to find issues with it, and then we can take action > against known issues, rather than worrying about unknown unknowns. I didn't ask anybody to to any work. I saw this as a call for comments, and Sara kind of addressed my *concerns* where I said I *think* this *might* break. Also I'm really sorry that I disappointed you by not managing to finish testing on OpenBSD (which I actually started just before seeing this mail) and I already sent some results for FreeBSD yesterday, which showed a tiny issue. Insert friendly suggestion to not throw stones when lingering near breakable structures. Greetings, Florian