Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1415670imm; Tue, 2 Oct 2018 07:53:47 -0700 (PDT) X-Google-Smtp-Source: ACcGV62gQ15XM5jR/fbPrApRMtmTGkU04PsekOsgJ6DjVBNXjHu/6ITpffLN3/QIyJauZKHFvBat X-Received: by 2002:a63:b08:: with SMTP id 8-v6mr639213pgl.130.1538492027380; Tue, 02 Oct 2018 07:53:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538492027; cv=none; d=google.com; s=arc-20160816; b=BOFkIKgNM00M2USuUTKJ2oTx1Ke0TNvadYlWk6eOY+yI9Q7KPCLLPqQcnXt06xRh7m r27CnviY69GxsgkmZZPSybWSQG29XBZnpUGLwh5Q/dXgZtNo18QEMhz4QzXyUdcsfOY9 uzp/idPd1RrwCo84EQreZ8v0RP39N7+mofZvBp4w0JipeMePnze66wy1sTsi0HwzdSYy OvL0Oz7uZJafTH8M1fSDetE71irA/taA7dovXEwlCiP+MTbT24Tq0nM5AOWjLLVPekS7 Wk5ugh/f2BjpXfGuO2PPLPQfXc2LDOoHmt3XDVVLKUQzbXkusfEDCvznehDvpqLAoPxT 488w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:message-id:in-reply-to:subject:cc:to:from :date; bh=awRoLZ0eKYSYLGgRwkbkwyPG7SxnedG9nuYJmYVhIaM=; b=RZcxFFIOv05piZ0Dz6CCoULKl0hXagTLuq5bkN+d4giXURthUs1/eb79OqKHUFj8mY KH6z5HLseGUCgNVfEEqHSbF7Y967DysVGZIEcKf7ERlPR8RVMJeLsPAAQtO+sWXP7g8L 3tpTRbB1zccrDC0HOzycaJ+39YUSJSNBenhHJmvEv5ISRAPo4W3ZPIW4pCWgz8cG72jq AjNPOXDquGrpo6y04xnBJkGqbcp9UqbtFcNtrA31scgHMJM16QJEZ4iZ3cJbetCbTNBv +wisaMhF2jsyaCnnB0ydI9K0+Y5LwpWW1Ta+cxAJ4odWexDzsuzCMuROeBnhnHhF7+Mz 9iSw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m5-v6si17273632pfb.104.2018.10.02.07.53.31; Tue, 02 Oct 2018 07:53:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728585AbeJBVgq (ORCPT + 99 others); Tue, 2 Oct 2018 17:36:46 -0400 Received: from a3.inai.de ([88.198.85.195]:34280 "EHLO a3.inai.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726118AbeJBVgq (ORCPT ); Tue, 2 Oct 2018 17:36:46 -0400 Received: by a3.inai.de (Postfix, from userid 25121) id AE7233BACCDC; Tue, 2 Oct 2018 16:52:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by a3.inai.de (Postfix) with ESMTP id A27303BACCD0; Tue, 2 Oct 2018 16:52:56 +0200 (CEST) Date: Tue, 2 Oct 2018 16:52:56 +0200 (CEST) From: Jan Engelhardt To: David Howells cc: linux-api@vger.kernel.org, linux-kbuild@vger.kernel.org, Coly Li , Kent Overstreet , linux-bcache@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 04/11] UAPI: bcache: Fix use of embedded flexible array In-Reply-To: <153616290368.23468.7806230605345568524.stgit@warthog.procyon.org.uk> Message-ID: References: <153616290368.23468.7806230605345568524.stgit@warthog.procyon.org.uk> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 05 Sep 2018 16:55:03 +0100, David Howells wrote: > >The bkey struct defined by bcache is embedded in the jset struct. However, >this is illegal in C++ as there's a "flexible array" at the end of the struct. >Change this to be a 0-length struct instead. > >- __u64 ptr[]; >+ __u64 ptr[0]; As per the C++ standard, it is _also_ illegal to declare an array of size zero. """it [the array size expression] shall be a converted constant expression of type std::size_t and its value shall be greater than zero.""" —http://eel.is/c++draft/dcl.array That makes both "__u64 ptr[]" and "__u64 ptr[0]" *implementation-specific extensions*. 3rd party tooling (concerns both C and C++): Coverity Scan (IIRC) treats "__u64 ptr[0]" as an array of "definitely-zero" size. Writing to any element will outright flag an out-of-bounds violation. That is sensible, since only "ptr[]" was standardized. Conclusion: So please, do never use __u64 ptr[0].