From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C34B8C433F5 for ; Mon, 2 May 2022 13:13:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1385178AbiEBNQc (ORCPT ); Mon, 2 May 2022 09:16:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46204 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351348AbiEBNQb (ORCPT ); Mon, 2 May 2022 09:16:31 -0400 Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35894C0C; Mon, 2 May 2022 06:12:58 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id z144so13497137vsz.13; Mon, 02 May 2022 06:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=Q9PzyxjQuHY1spsfkApUPqmCQWtSz+AxNkiNIjpbrU8=; b=mJDEqDsVQSGSuhg63i6rSSlbP++q3ToYeRW7DKxkb1Mgg6ahghRFMAMYVO8Z248Wpv /zMAOvyhuFpiRAqn2VhRMA3uu9E2VH6ACglzHVwKn/4w8bGMp9mQx2Xcx1aHcJFCULwd /WzVHWm330mmycVGKOMDo98gNZZW3mekRi0x/PDJGRx9yPLvbhVlqTbbAjcKUl3QFBOx r5f57N5BwI9bpueFyyiPE8lmhgNPHdUr+4NejTLlWU9CozHtjS9GpXqjB0SCJG7l9tFN reM2aggIX8NxhU2uBmPxOp9y1Y09HDqTmQmXVatCdmw685GsgJmU9inIuFvA4fvUDJ4+ S/sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=Q9PzyxjQuHY1spsfkApUPqmCQWtSz+AxNkiNIjpbrU8=; b=VdLAWV52D5pn2k1CuyI1OZbZNcpOhc/XnOrelEDMdscMbG8L7ox9QW1ANuX38m3SxA qUWwAq1KsqKFxPo6SRmiU4tZuEs5OWeElZEykY1UofV0mOdYuTd7KZCpYq9aFcZ5T7X9 cLpCzu5L0S8KDLq9f+yZp62fa2cSL2cpe//6uhAW89DonLd6V/iFcKKe9SNU7uprLNIj iSXfnkkInNYMkkRyhRqKlMx3EFBG3ik4oTO0w/RaMYbRYw7Da227lfYLOu1fc85s4K3Q mBsHF3rNK3eUi8XQXTjno44ISuOYjXx5AzDUZgOlY2Of1rrzq2n5LZIo06VwN4j8h6vZ Yn7g== X-Gm-Message-State: AOAM531D+AaEh5TE2UYiOlLG9PhmKgW9WvB54Xje1xzfHINbv6LNGY/j F7ai/IkOOjBwoqexkneSV/Lj+C0Gx16BjRak/2RYXwdybpjQwTF7 X-Google-Smtp-Source: ABdhPJxbInO0MY7QS0qnVFBBJNpXUEKl/C28qXUrrFqVm+asE7qWtoiTdPab5crnAQKYbzgVZXYAV22vfuroIRfDXxo= X-Received: by 2002:a67:c107:0:b0:32d:3ac1:1e71 with SMTP id d7-20020a67c107000000b0032d3ac11e71mr1332770vsj.41.1651497177274; Mon, 02 May 2022 06:12:57 -0700 (PDT) MIME-Version: 1.0 References: <20220426131102.23966-1-andrea.merello@gmail.com> <20220426131102.23966-9-andrea.merello@gmail.com> In-Reply-To: Reply-To: andrea.merello@gmail.com From: Andrea Merello Date: Mon, 2 May 2022 15:12:45 +0200 Message-ID: Subject: Re: [v5 08/14] iio: imu: add Bosch Sensortec BNO055 core driver To: Andy Shevchenko Cc: Jonathan Cameron , Mauro Carvalho Chehab , linux-iio , Linux Kernel Mailing List , devicetree , Lars-Peter Clausen , Rob Herring , Matt Ranostay , Alexandru Ardelean , jmondi , Andrea Merello Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Il giorno lun 2 mag 2022 alle ore 12:12 Andy Shevchenko ha scritto: One inline comment. OK for the rest > > > > +#define BNO055_ATTR_VALS(...) \ > > > > + .vals = (int[]){ __VA_ARGS__}, \ > > > > + .len = ARRAY_SIZE(((int[]){__VA_ARGS__})) [...] > And my point about readability. The reader, and even the author after > some time, may have no clue in this forest of the macros and castings > what's going on. While I'm OK wrt your point in general, consider that it's just a three LOC macro, used only in a few structs just below. I wouldn't say it's so inricated; I've seen by far worse in the kernel :) > > but about avoiding as much as > > possible bugs caused by mismatched attr_vals, attr_aux and > > ARRAY_SIZE() arg. e.g: > > bno055_sysfs_attr_avail(priv, bno_foo_vals, ARRAY_SIZE(bno_bar_vals), > > bno_foobar_aux, vals, len) > > > > I used to make quite a lot of mess until I grouped all the stuff in > > one struct :/ > > If something you want to prevent at compile time, consider to utilize > static_assert() and / or BUILD_BUG_ON() depending on the place in the > code (the former is preferred). I would be happy to get rid of my macro and use those assertion things, but I can't see how exactly. Do you have any advice about how to take advantage of them for catching bugs like the one above in this specific case?