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 C67D7432CE;
	Wed,  8 Nov 2023 04:25:06 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id B591B402D4;
	Wed,  8 Nov 2023 04:25:06 +0100 (CET)
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by mails.dpdk.org (Postfix) with ESMTP id 9A45B40279
 for <dev@dpdk.org>; Wed,  8 Nov 2023 04:25:05 +0100 (CET)
Received: by linux.microsoft.com (Postfix, from userid 1086)
 id E89C020B74C0; Tue,  7 Nov 2023 19:25:04 -0800 (PST)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com E89C020B74C0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
 s=default; t=1699413904;
 bh=J1S9eXueuoeoZKlpzxTUdaFu9PjHnBV09avGji09pKw=;
 h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
 b=NF+3jpBOl/UK1EgJY6a795pn8PQVbXy7vs5SLuEMVs2m4bfFjQoWBPyGxLoae7Rrv
 0QUlOPEYZ6gQmdz2+O9kTQeHRDAQlR2aM577BdmuiO2ZpREZPSkzxG0bf0pAIc20D0
 6e3/Aldomd0rJyyiJ+qpNqVF1BPS/QnJ6O6PHyyg=
Date: Tue, 7 Nov 2023 19:25:04 -0800
From: Tyler Retzlaff <roretzla@linux.microsoft.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org
Subject: Re: RFC acceptable handling of VLAs across toolchains
Message-ID: <20231108032504.GB19492@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
References: <20231107193220.GA15232@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
 <20231107183114.330c2d8e@hermes.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231107183114.330c2d8e@hermes.local>
User-Agent: Mutt/1.5.21 (2010-09-15)
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 Tue, Nov 07, 2023 at 06:31:14PM -0800, Stephen Hemminger wrote:
> On Tue, 7 Nov 2023 11:32:20 -0800
> Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:
> 
> > hi folks,
> > 
> > i'm seeking advice. we have use of VLAs which are now optional in
> > standard C. some toolchains provide a conformant implementation and msvc
> > does not (and never will).
> > 
> > we seem to have a few options, just curious about what people would
> > prefer.
> > 
> > * use alloca
> > 
> > * use dynamically allocated storage
> > 
> > * conditional compiled code where the msvc leg uses one of the previous
> >   two options
> > 
> > i'll leave it simple for now, i'd like to hear input rather than provide
> > a recommendation for now.
> >
> 
> VLAs are a bug magnet. Best to avoid them, most code doesn't need them.

just in case i didn't clarify properly early when i said they were
optional i meant they used to be non-optional. the intent of the RFC
here isn't that i want to add more but i'm looking for the best approach
to getting rid of the ones we already have.

> The one common use case is code that accepts a burst of packets.
> But such code could easily have an upper bound if necessary.
> 
> Please don't add more to the maze of #ifdef's 

thanks! i'll keep this in mind.