[dpdk-dev] [PATCH 2/2] eal/windows: fix build by supporting trace

[Dmitry Kozlyuk]

On 2020-04-26 17:53 GMT+0530 Jerin Jacob wrote:
> On Sun, Apr 26, 2020 at 5:32 PM Dmitry Kozlyuk <dmitry.kozliuk at gmail.com> wrote:
> >
> > On 2020-04-26 17:02 GMT+0530 Jerin Jacob wrote:  
> > > > +/**
> > > > + * Get absolute path to the directory where permanent data can be stored.
> > > > + *
> > > > + * @return
> > > > + *  Statically allocated string on success, NULL on failure.
> > > > + */
> > > > +const char *
> > > > +eal_permanent_data_path(void);  
> > >
> > > Do windows have PATH_MAX kind of macro? I think, it is better API
> > > consumer allocates
> > > the memory of size PATH_MAX and implementation fills it, instead of,
> > > the static scheme.  
> >
> > This API falls in line with rte_eal_get_runtime_dir() and other
> > eal_filesystem.h functions, that use static scheme. Logically, its result
> > never changes. It is race-free and is only called during initialization. What
> > you propose can be done, but are there any benefits?  
> 
> I thought who will free that memory? It looks like libc creating a static memory
> for this item. so, your current eal_permanent_data_path() declarations
> looks good to
> me.

Actually, your concern is valid (see man quotes below). Windows implementation
has no such issue because of its own static buffer. I'd use static scheme
in EAL interface for convenience, but change Unix implementation to copy
string returned by libc into a static buffer.

man 3 getenv:
	The string pointed to by the return value of getenv() may be
	statically allocated, and can be modified by a subsequent call to
	getenv(), putenv(3), setenv(3), or unsetenv(3).

man 3 getpwuid:
	The return value may point to a static area, and may be overwritten
	by subsequent calls to getpwent(3), getpwnam(), or getpwuid().

-- 
Dmitry Kozlyuk