Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3198892ybb; Mon, 6 Apr 2020 04:16:26 -0700 (PDT) X-Google-Smtp-Source: APiQypJpv5cVtUTWmVJIkCWGBDHqPSsw1DQXeNZOgmQTwOo5JzdELk9p4eKofU/EXQKSgDsMlEWK X-Received: by 2002:a9d:42f:: with SMTP id 44mr16929363otc.236.1586171785939; Mon, 06 Apr 2020 04:16:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586171785; cv=none; d=google.com; s=arc-20160816; b=IiG0OvnIAtdzxTWl1/0UANsQqEYqy8W7xBlJ3x9n47ZYkAp3nHxPWrZtexFDhtKykI 6iAZo8wM6WPZcQqx/UEaYGVWJ766vIo54ZMLoKpXhGgHALZrMdeZV0xxa8pInp0ZEZVf laHeTBiuBfoZV9l/QdglDFU38jvMX3YfjhsEnncWQFupPSV2K9fL4ca7qTyadtb/OWCg se3cDygOKhXUBn1qN2fiywGuGOM6zpU2e2eDMXS+QzSwSuI9Q6X7JWoQpfDPb7wSr4ZL yJ8RJIut/sF84FXlG6h1B6E+4HPQg9QjPJ+QRz7sUiVtiMwH8gZrGNQ/pvJeN3Dmghkr kBuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=QVjxrJ8QSz+DelTGjFdQ/F/1RkfZlL9u7ceZFM/P5eE=; b=ki1srzljOParUF2Y2b9r4KjQyEXB2US03tq8XvUiK48ZEmuthpaZZiExMFpGeATJGO AVWe/uJWYF5SqThpLol/JUlg4j/zgkKuP+WVnfv4XjWaDX3R+etrNn9EADATbpiyEpOE 3hihctrxThjoqcSNmHImBPOlwKwOKhshURzfO+IvRZvoW4OPCYAiruesEki7uevfh72v nH3Y3x0ebHW6nfwM3SWRiF23N7NJ+thrfkds7YxE0bYMoVl5IbRtc2G7dEQkesufiKIq K3PpjZzEbdv/UK6ZKzI7XgDNChKn/CeqFSRFVFDtPBa5S930otakTeTnRJTMCm6gzNGJ 48Rw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2020-01-29 header.b=EMJfk10G; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m1si7940050otn.91.2020.04.06.04.16.12; Mon, 06 Apr 2020 04:16:25 -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; dkim=pass header.i=@oracle.com header.s=corp-2020-01-29 header.b=EMJfk10G; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727187AbgDFLPl (ORCPT + 99 others); Mon, 6 Apr 2020 07:15:41 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:40970 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726873AbgDFLPl (ORCPT ); Mon, 6 Apr 2020 07:15:41 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 036BCt5u171444; Mon, 6 Apr 2020 11:15:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=corp-2020-01-29; bh=QVjxrJ8QSz+DelTGjFdQ/F/1RkfZlL9u7ceZFM/P5eE=; b=EMJfk10GM9MpU7Co0nc1cEz9LCFsf3eR9nuSc8gdbobAj97/byE2iB0ItD7qxR/mSzCB dwLYc2xB5yguezCQzpBJEFU3tu8quCpKGQcwrVmoW+gYPz7T8oh8tdzXipcNhR92nQf2 2ZfrPoGQ72jz0SPY6nwoyVAFJaE85E3ssdbU5d5ZvAxCoo/X6fC4/jWJNaa/S4TdCHZe TDp2zbp0KMevFd8Wk1OcV960UjUOe7JHF7nCCaSklX+3EE0j91WNT97VP/PKyPKB8YQm XNO1Ag6QAoxzq5gQsCmZwR3Xm1e2SqcIogaKiwDs3YD2bjgqPhr4bvf7e58BEyKKwEEL CA== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 306jvmx3uk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 06 Apr 2020 11:15:32 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 036BCaZl176512; Mon, 6 Apr 2020 11:13:32 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 3073spqqer-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 06 Apr 2020 11:13:32 +0000 Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 036BDUxr015538; Mon, 6 Apr 2020 11:13:31 GMT Received: from kadam (/41.57.98.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 06 Apr 2020 04:13:30 -0700 Date: Mon, 6 Apr 2020 14:13:23 +0300 From: Dan Carpenter To: Oscar Carter Cc: Forest Bond , Greg Kroah-Hartman , devel@driverdev.osuosl.org, Malcolm Priestley , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] staging: vt6656: Use ARRAY_SIZE instead of define RATE_54M Message-ID: <20200406111323.GD2001@kadam> References: <20200404141400.3772-1-oscar.carter@gmx.com> <20200404141400.3772-2-oscar.carter@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200404141400.3772-2-oscar.carter@gmx.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9582 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 spamscore=0 malwarescore=0 suspectscore=0 adultscore=0 bulkscore=0 mlxlogscore=792 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004060098 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9582 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 suspectscore=0 mlxlogscore=853 mlxscore=0 bulkscore=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 clxscore=1015 malwarescore=0 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004060098 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 04, 2020 at 04:13:58PM +0200, Oscar Carter wrote: > Use ARRAY_SIZE to replace the define RATE_54M so we will never have a > mismatch. In this way, avoid the possibility of a buffer overflow if > this define is changed in the future to a greater value. > Future proofing is not really a valid reason to change this. We have to assume that future programmers are not idiots. The only valid reason to do this is readability, but I'm not convinced the new version is more readable. regards, dan carpenter