From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4B9E8454AB; Thu, 20 Jun 2024 16:45:38 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3D9C3402D2; Thu, 20 Jun 2024 16:45:38 +0200 (CEST) Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) by mails.dpdk.org (Postfix) with ESMTP id 325BB402B1 for <dev@dpdk.org>; Thu, 20 Jun 2024 16:45:37 +0200 (CEST) Received: by mail-pg1-f178.google.com with SMTP id 41be03b00d2f7-6e7b121be30so743866a12.1 for <dev@dpdk.org>; Thu, 20 Jun 2024 07:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1718894736; x=1719499536; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=saHZD9CI/1FBLJCSe5qg8SRuvLIhgoK7tim9mM+5bsY=; b=hpG0DSkc9OXfiIdEmVk9Z5hgugjOmrKmG9xO1p4qHvvn+Lr9xIzsvbwBSqqaLSCSxI yR5m+ySvuNHKAIC4wA0IeO98QL8UW9vkHD/IFX+PuI5gqtGazcCT4CcvfMEoGPjS7z9S uRDycx2CuRUTG5JmGmXhmEOfmMZYm0OjjD8my39SA6tewaoQkYU8sxsEq4dGyHHMZEOH AmdOUYsyWGtkRZa9lrxztAFKQkZHdeJzRBshkfYXoOvKTJ4ocwsFYPUgqZk1qKAdF4+i 1MoyYRH1sP3P6XMhi5JHDhM5lJa0tLKQJ+PkqJizSywriAQ0hEIT5aj16mx3UV9xQ945 uZNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718894736; x=1719499536; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=saHZD9CI/1FBLJCSe5qg8SRuvLIhgoK7tim9mM+5bsY=; b=iNyy5Y3FPXJCdgZZFHHJkGW5bS5M59XnZw79EnKRSwpsb7V7m2da1v4MWQJf1edoWC +X0kIt8ZsBDVTHYxn1KRm4GIPF4Czz3ds1RpnFXIAUnTnogWnb3T2W8JyCfIRJrk+DD0 euF0ntDH5wii8SUZqsSdnqcyNGVJF0enVxXaDtQCh8XDkDYM7HM9WH81/vVkcU+w0nI2 aMbFIA8WtmALfidf4o6mt+8wNJgNhgT6CwDVdkA4zP60Im6SJaJnmPv+egUaftrQrcq6 mB14Pfkln1n731PhRaJqXOwUn6HzQKiP56Bhmg1ruraYyz/0RiB1EJrNzMFdGw4WTkN5 Ki3Q== X-Forwarded-Encrypted: i=1; AJvYcCWUwioB1Q8xZykYP0cIXrKf96qceUQ634TQkkenKt7E+hHyyaPCJD0buerwbfo4MTN6R0sPc8z7jSaPfLU= X-Gm-Message-State: AOJu0YwHu4spHWV3ZFjc8ATGKEQHBKONuzl8hiyEmP5eAX//SjFnGBZl KVO5fIcbV2RiZbEP/DRCQQL7Hxb0fiBqhjbK3peCP97/MfYqcULaMdBMGAhzOoI= X-Google-Smtp-Source: AGHT+IEJvV7pEIFofmOQTdNUER4e8KlpEV/SvfTwwLjrmjmhDiojgDWc1P4e0J0bGUALovEMb5/pRQ== X-Received: by 2002:a17:903:1211:b0:1f8:3c9e:3ba8 with SMTP id d9443c01a7336-1f9aa3b50b0mr63821325ad.10.1718894736284; Thu, 20 Jun 2024 07:45:36 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1f855f1a1ebsm138191565ad.238.2024.06.20.07.45.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jun 2024 07:45:36 -0700 (PDT) Date: Thu, 20 Jun 2024 07:45:34 -0700 From: Stephen Hemminger <stephen@networkplumber.org> To: Morten =?UTF-8?B?QnLDuHJ1cA==?= <mb@smartsharesystems.com> Cc: "Konstantin Ananyev" <konstantin.ananyev@huawei.com>, "Thomas Monjalon" <thomas@monjalon.net>, <dev@dpdk.org>, <ferruh.yigit@amd.com>, <bruce.richardson@intel.com>, <david.marchand@redhat.com> Subject: Re: Coding Style for local variables Message-ID: <20240620074534.76ffc29a@hermes.local> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F540@smartserver.smartshare.dk> References: <98CBD80474FA8B44BF855DF32C47DC35E9F512@smartserver.smartshare.dk> <722d00ff8ec9497a92b831cfd13475d5@huawei.com> <2579488.yFuDdFVEAc@thomas> <98CBD80474FA8B44BF855DF32C47DC35E9F53F@smartserver.smartshare.dk> <978413ec22cb4b76872bd85f3588e5f3@huawei.com> <98CBD80474FA8B44BF855DF32C47DC35E9F540@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org On Thu, 20 Jun 2024 11:02:21 +0200 Morten Br=C3=B8rup <mb@smartsharesystems.com> wrote: > > From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com] > > =20 > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > > > > > 10/06/2024 18:31, Konstantin Ananyev: =20 > > > > > Morten said: =20 > > > > > > The coding style guide says: > > > > > > > > > > > > "Variables should be declared at the start of a block of code r= ather =20 > > than =20 > > > > in the middle. The exception to this is when the variable is =20 > > > > > > const in which case the declaration must be at the point of fir= st =20 > > > > use/assignment. Declaring variable inside a for loop is OK." =20 > > > > > > > > > > > > Since DPDK switched to C11, variables can be declared where the= y are =20 > > used, =20 > > > > which reduces the risk of using effectively uninitialized =20 > > > > > > variables. "Effectively uninitialized" means initialized to 0 o= r NULL =20 > > > > where declared, to silence any compiler warnings about the use of = =20 > > > > > > uninitialized variables. > > > > > > > > > > > > Can we please agree to remove the recommendation/requirement to= =20 > > declare =20 > > > > variables at the start of a block of code? =20 > > > > > > > > > > I know that modern C standards allow to define variable in the mi= ddle. > > > > > But I am strongly opposed to allow that in DPDK coding style. > > > > > Such practice makes code much harder to read and understand (at l= east =20 > > for =20 > > > > me). > > > > > > > > Yes it is convenient to know that all variables are described > > > > in a known place, just after function parameters. > > > > > > > > There is also a consistency concern. > > > > > > > > Old contributors like to be in a comfort zone, > > > > and we don't want to lose old contributors. > > > > New contributors may be refrained by old rules, > > > > and we would like to get more new contributors. > > > > > > > > So that's a tricky decision. Either way looks ok to me. See no need for hard and fast rules in this area. But please no patches to change existing code.