Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119508 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 39407 invoked from network); 9 Feb 2023 15:30:13 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 9 Feb 2023 15:30:13 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3EB0E1804B1 for ; Thu, 9 Feb 2023 07:30:13 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (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 ; Thu, 9 Feb 2023 07:30:12 -0800 (PST) Received: by mail-wr1-f48.google.com with SMTP id h16so2125936wrz.12 for ; Thu, 09 Feb 2023 07:30:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=6QuT/5rqsR03pjDdH2ti6bHQs/Z7mwXuIuNY+9GNN/k=; b=mg8gI6SwK3i2wr1FxN1D6JFCp/DdRfaov11kNKhFdGHS1nD7ckbDoAMQZraBc3wSED B7DtSktcjsPiafyPeomzcgnbMGrdo9Tg2loZYfHjjByOVnDM+zEQdA/iHId3QCB3FazO lqGv6mi4kHkTKPvJsjzfguCAcleDEOcCKr5MXOgA/1WGhNgOjbdelTX7+/aiReJzdhAn C8a0+wmS0GHZjiVEMI0rOPwwRUKiz/FrBD2RMs2hsZBQ0s7Hl3S+bhc3oTX4XVJjczpi ijzVyuyGvaRczsaWXGjQ9yt3SAs75Tq1C/c30AlvgIvX92qx5zXofXyXCVoLh6rIlVqw deEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6QuT/5rqsR03pjDdH2ti6bHQs/Z7mwXuIuNY+9GNN/k=; b=aBtRubSRKjCz++nutVfFZucuNu1tWeaOgCj5og+Oppc6IH5T0qMB0lV/kPIwmOWf2f 5rz4wESvDh9GBN4mp9NrFhZuGDoLfPtX4WcS2d664yXNle0DZDAWM81u6wSXEGKq0pbc xkwQni12FecP9OG1V0/v4e405Vp9tpsHLvc9befgyWi8RR2fZHt1dvD2qIveLfsYC2JP 9I/pjTtMcEkUH4q/p5E7VRccewiE2XXMBnILFZXxEsIP9r2Q0PgXcP23TUy/V2A0Q0XW 0cFrdxQXUrgSkwGFztv3zx/7/tHOXkN/tXk1cUhqNf/Hsweid8JFZkwTDhWa1KZbTwpC mMBA== X-Gm-Message-State: AO0yUKW8wRJpwTgj0SZK8NnJfTr+i4baSxF55SffkiwhlmRxr1ux5Xuv SA9Runm06mu156mMWm7Qt7bSVAU4U+hfIz1zbGYJUgE9oDs= X-Google-Smtp-Source: AK7set/KHRc0dwn40mu7UtF83hY3+aaaeq0V47L05VMZqt9l4+NoIqG11P3FEiWWE7/0bV0jFduGVbAS0df5Ac+g6Ok= X-Received: by 2002:adf:f111:0:b0:2c3:ea83:d300 with SMTP id r17-20020adff111000000b002c3ea83d300mr455105wro.97.1675956611757; Thu, 09 Feb 2023 07:30:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 9 Feb 2023 15:29:59 +0000 Message-ID: To: internals@lists.php.net Content-Type: multipart/alternative; boundary="00000000000080bb9105f4460e50" Subject: Re: [PHP-DEV] How to deal with bugs in vendored libraries? From: rowan.collins@gmail.com (Rowan Tommins) --00000000000080bb9105f4460e50 Content-Type: text/plain; charset="UTF-8" On Thu, 9 Feb 2023 at 13:14, Max Kellermann wrote: > The issue still exists, and I'm here > for your advice on how to resolve this. I'm desperate. > Is this a critical security issue? If not, there's no need to be desperate; just take a breath, explain what you were trying to achieve, and be genuinely open to discussion and suggestions. In your head, I'm sure it's very clear what you're working on, and why it's the right thing to do; but clearly, it doesn't seem as obvious to everyone involved. > That's why I asked whether "secret" reverts without discussion are > considered good behavior. Maybe you believe maintainers should do > that - but that would be surprising for me. > This is where I'm suggesting you assume good faith: what looks like a "secret revert" probably feels like something entirely different to Derick. > > > Thirdly, it's not clear to me which of the following statements is true > of > > this change, and it might help the conversation to clarify more > precisely: > > a) The code you removed *violates* the C99 spec? > > This. The code in question declares typedefs that are reserved words > in the C99 spec section 7.26.8; not just reserved, they conflict with > actual typedefs from . > OK, that seems clear. As far as I can see, this is the first time on this thread or either of the PR threads that you've actually explained that violation. > b) The code you removed is *guaranteed to be pointless* under the C99 spec > > (but does not violate it)? > > No. It is not pointless. Those declarations occupy reserved words, > and that is not allowed. > OK, so follow-up question: what gives you confidence that the change is *safe*? Sometimes, technical violations of a spec are necessary for the practical realities of the situation. I think you've answered this question in the PR thread, but I'm trying to get the explanation all in one place, because you've mentioned different details at different times. Regards, -- Rowan Tommins [IMSoP] --00000000000080bb9105f4460e50--