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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DC3EBC433F5 for ; Mon, 14 Feb 2022 10:39:18 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 16BD510E53E; Mon, 14 Feb 2022 10:39:18 +0000 (UTC) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0C08C10E53E for ; Mon, 14 Feb 2022 10:39:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644835156; x=1676371156; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=C9m2rcxcDwLvUl2QbsECG3i5+PvKcHA60fHQFVqzZzs=; b=J6b0XXkNyE1DjjO7JvGetUGZNxcvsaX5pUAQVOTqaPpgZGR8sIxtXtmC g2rBYR/2zlkTB1TXZPSwTnJIkKdo/b6TVUeInHsl3xh/iYv6UKtOIreVb 5RATuPx6qpOgnVuJ4d/yi/DXLsCPgsczBsy8ymjRPbs4UaGpHLrRSdpib ZJ6z4z63zaAxIZcmgoB7dP0NmgP9XjVRfiUL8OH8LWAMNwZhxXGXNPBJp AHpVrnj3nGPBs8R5MAxQWMWl9QezX2XgcPFLevyH63Z+XBm7tlYlrCMFW +ZrnR0wcL6J+WKGjU4wIwDtN519Ruy8Cn1FIUZED9jJUUrYunPnkJT6Te Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10257"; a="250009735" X-IronPort-AV: E=Sophos;i="5.88,367,1635231600"; d="scan'208";a="250009735" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2022 02:39:15 -0800 X-IronPort-AV: E=Sophos;i="5.88,367,1635231600"; d="scan'208";a="570085760" Received: from smile.fi.intel.com ([10.237.72.61]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2022 02:39:12 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1nJYkG-004Pw8-Jg; Mon, 14 Feb 2022 12:38:12 +0200 Date: Mon, 14 Feb 2022 12:38:12 +0200 From: Andy Shevchenko To: Thomas Zimmermann Subject: Re: [PATCH v4 1/6] drm/format-helper: Add drm_fb_xrgb8888_to_gray8_line() Message-ID: References: <20220211091927.2988283-1-javierm@redhat.com> <20220211091927.2988283-2-javierm@redhat.com> <4fa465d9-4fac-4199-9a04-d8e09d164308@redhat.com> <7560cd10-0a7c-3fda-da83-9008833e3901@suse.de> <87pmnt7gm3.fsf@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 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-fbdev@vger.kernel.org, David Airlie , Daniel Vetter , Javier Martinez Canillas , linux-kernel@vger.kernel.org, Noralf =?iso-8859-1?Q?Tr=F8nnes?= , Geert Uytterhoeven , dri-devel@lists.freedesktop.org, Sam Ravnborg , Maxime Ripard Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, Feb 14, 2022 at 10:03:53AM +0100, Thomas Zimmermann wrote: > Am 11.02.22 um 16:41 schrieb Andy Shevchenko: ... > > > IMO *always* prefer a for loop over while or do-while. > > > > > > The for (i = 0; i < N; i++) is such a strong paradigm in C. You > > > instantly know how many times you're going to loop, at a glance. Not so > > > with with the alternatives, which should be used sparingly. > > > > while () {} _is_ a paradigm, for-loop is syntax sugar on top of it. > > Naw, that's not true. In the section 3.5 "Loops - While and For" in "The C Programming Language" 2nd by K&R, the authors said: The for statement ... is equivalent to ... while..." They said that for is equivalent to while, and not otherwise. Also, syntax sugar by definition declares something that can be written as a single line of code, which usually is done using more (not always). > An idiomatic for loop, such as for (i = ...; i < N; > ++i), is such a strong pattern that it's way better than the corresponding > while loop. > > > And yes, the do-while suggested above is buggy, and you actually need to > > > stop and think to see why. > > > > It depends if pixels can be 0 or not and if it's not, then does it contain last > > or number. > > > > The do {} while (--pixels); might be buggy iff pixels may be 0. -- With Best Regards, Andy Shevchenko