Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118716 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 67279 invoked from network); 30 Sep 2022 12:24:40 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 30 Sep 2022 12:24:40 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 67E8C18054B for ; Fri, 30 Sep 2022 05:24:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 30 Sep 2022 05:24:38 -0700 (PDT) Received: by mail-ej1-f42.google.com with SMTP id 13so8710891ejn.3 for ; Fri, 30 Sep 2022 05:24:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=+EotiI4sd6kYmJ/luPZCmRCu2+Sgn9nI/fgkgRvCNi8=; b=AE2lI01D3uSNZdfY/K+9wIz7HgJaKxPL0NYZkBMC1YxnCvlp1/GseigLtsiqmj2Ygg q0YgYeZXDyd0bfnMksf3jNpCTmW9Xg2jo0isPo0w8A3U4EXbeVug3IJqYb5GKGcaNX8s 5T6eNcuGpJ2RjUhmfegxtujH90AypFKp2aEdJpSkFE9TKdQLeQgHFhSfUQ3Uilz9enLV VNv5l5TGH+/U24HB2st3rXbMz+/hpiJT0WeTF6jU/Fg3uq4wVcxEEch6k3yJUlHwSqeT im65hhMD/JhHm/q10/f5ybndRqR9pvNgMJPFoXMHBX3pc2XSjFUTeQnFrn53KNWerHbI imJg== X-Gm-Message-State: ACrzQf1qjgqq9Q/XFlXP3RjihWbI4WZH9XRYm8WcV/evoJfKE1TelLWy LgMR4AxG/nyeyNgJrfTaQmwoJNkV9g6ow34mv6s= X-Google-Smtp-Source: AMsMyM53OdfP1N3WnBKPIWZfq+vL36UotzpKyOSg5NlK597d+QfaoSQCUUPDN+XyzEqxTcZMpQlBxg3GeizdCHzUgSQ= X-Received: by 2002:a17:906:5a45:b0:77a:406c:6867 with SMTP id my5-20020a1709065a4500b0077a406c6867mr6141262ejc.437.1664540677488; Fri, 30 Sep 2022 05:24:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 30 Sep 2022 13:24:26 +0100 Message-ID: To: Timmy Almroth Cc: PHP internals list Content-Type: multipart/alternative; boundary="000000000000cbc41105e9e4130d" Subject: Re: [PHP-DEV] RFC: StreamWrapper Support for glob() From: bukka@php.net (Jakub Zelenka) --000000000000cbc41105e9e4130d Content-Type: text/plain; charset="UTF-8" Hi, On Sun, Sep 18, 2022 at 11:02 PM Timmy Almroth wrote: > Hi @Dan, hi @Sara. Thanks for giving us your feedback on this. > > > I think that although the RFC discussion can go ahead without a patch, > > it would be better to have a patch before it went to vote, as there > > seem to be quite a few hidden details that might not be able to be > > made to work. > > I wanted that too. But it's hard to find someone willing to invest the time > and effort. And it's even harder when that time invested is not guaranteed > to lead to something. Therefore a PoC patch was produced that should give a > good understanding of what is intended. It was not my choice but I > understood the reasons. > > I had a quick look to that PoC and it's basically just a quick wrapper that depends on GLOB_ALTDIRFUNC. Unfortunately that's a non standard extension that might be missing on some platform (e.g. alpine won't probably work because from a quick look the musl libc doesn't seeem to implement it - https://git.musl-libc.org/cgit/musl/tree/include/glob.h ). The code obviously needs more work and we will need bunch of tests for this. Well obviously it's just a PoC but what I want to say is that implementation is really main thing here and should also help to provide more details in RFC. For example it's not currently clear that you would change underlaying glob implementation on some platforms - quite important thing to mention though. To be honest if there is a good implementation, I think it's quite unlikely that the RFC will fail. Regards Jakub --000000000000cbc41105e9e4130d--