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 4AE90C433EF for ; Thu, 24 Mar 2022 09:22:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349203AbiCXJXg (ORCPT ); Thu, 24 Mar 2022 05:23:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232772AbiCXJXe (ORCPT ); Thu, 24 Mar 2022 05:23:34 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 519D19E9D7 for ; Thu, 24 Mar 2022 02:22:03 -0700 (PDT) X-IronPort-AV: E=McAfee;i="6200,9189,10295"; a="238269683" X-IronPort-AV: E=Sophos;i="5.90,206,1643702400"; d="scan'208";a="238269683" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2022 02:22:03 -0700 X-IronPort-AV: E=Sophos;i="5.90,206,1643702400"; d="scan'208";a="552800752" Received: from smile.fi.intel.com ([10.237.72.59]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2022 02:22:02 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1nXJeo-005ih8-8L; Thu, 24 Mar 2022 11:21:26 +0200 Date: Thu, 24 Mar 2022 11:21:25 +0200 From: Andy Shevchenko To: Miguel Ojeda Cc: Miguel Ojeda , linux-kernel Subject: Re: [PATCH v1 4/4] auxdisplay: lcd2s: Use array size explicitly in lcd2s_gotoxy() Message-ID: References: <20220308151119.48412-1-andriy.shevchenko@linux.intel.com> <20220308151119.48412-4-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 23, 2022 at 08:15:57PM +0100, Miguel Ojeda wrote: > On Sat, Mar 19, 2022 at 12:37 PM Andy Shevchenko > wrote: > > > > With [] and parameters not being bytes by type one needs an additional > > processing step to figure that out. When I see u8 ...[3] I immediately > > understand that there are 3 _bytes_. Moreover, [] is error prone when > > one may add something to the buffer with the expectation that it will > > work somehow (for example, with an old device you need 3, with new > > device revision you need 4 bytes and passing 4 bytes breaks the old > > device). Of course most of that quite likely won't happen. > > I agree it is better to be explicit -- I just found the commit message > very confusing, i.e. the type will always be `u8`, what is unclear is > the total length, not so much the type change. > > I think the best approach when one needs an array to stay a particular > size due to some external constraint (like hardware) would be to use a > `static_assert` with a comment mentioning where the requirement comes > from. Or at least a comment above the array. > > Either way, I applied this one too to -next a few days ago. Thanks! Thanks! -- With Best Regards, Andy Shevchenko