Re: [dpdk-dev] [PATCH v1 2/3] net/hyperv: implement core functionality

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue, 19 Dec 2017 11:15:38 +0100
Adrien Mazarguil <adrien.mazarguil@6wind.com> wrote:

> On Tue, Dec 19, 2017 at 09:53:27AM +0000, Bruce Richardson wrote:
> > On Mon, Dec 18, 2017 at 09:23:41PM +0100, Adrien Mazarguil wrote:  
> > > On Mon, Dec 18, 2017 at 10:34:12AM -0800, Stephen Hemminger wrote:  
> > > > On Mon, 18 Dec 2017 17:46:23 +0100
> > > > Adrien Mazarguil <adrien.mazarguil@6wind.com> wrote:
> > > >   
> > <snip>  
> > > > > +static int
> > > > > +hyperv_iface_is_netvsc(const struct if_nameindex *iface)
> > > > > +{
> > > > > +	static const char temp[] = "/sys/class/net/%s/device/class_id";
> > > > > +	char path[snprintf(NULL, 0, temp, iface->if_name) + 1];  
> > > > 
> > > > Doing this snprintf is gross. Either use PATH_MAX or asprintf  
> > > 
> > > I don't think allocating more stack space than necessary or on the heap with
> > > a possible allocation failure to deal with is any better, sorry.
> > > 
> > > Prove this snprintf() call can fail and you'll have a point.
> > >   
> > While I get your point, I'd tend to go with Stephen's view on this that
> > it's looking a bit "gross". What's the problem with allocating a bit
> > more stack space for it?  
> 
> Well, apart from making a stand, none really. Too "unusual" perhaps, but I
> don't think "gross" is a valid argument to reject a perfectly valid piece of
> code that doesn't rely on obscure knowledge nor weird side effects.
> 
> I'll update this in v2 to make it look more acceptable in any case.
> 

In this particular case, you can easily show that the maximum length of
the string would be less than the format plus maximum length of interface
name.

Why not:
	char path[sizeof(temp) + IFNAMSIZ];
which keeps the flexibility but also can be evaluated at compile time.


Upleveling. You need to understand that open source software is a collabrative
effort. And like doing improvisational theatre, the best answer to any
feedback is yes unless there is a technical reason otherwise.