On Wed, Apr 3, 2024 at 8:52 AM Thomas Monjalon <thomas@monjalon.net> wrote:

> 02/04/2024 18:03, Ashish Sadanandan:
> > Hi everyone,
> > I've made the updates as suggested. Could someone please review the
> latest
> > patchset? Not sure if I followed the new patchset instructions correctly,
> > I've always had trouble with that part.
>
> I remember we were discussing about aligning all files.
> I was waiting for a patch applying the rule we discussed.
>
> I missed the part where people were volunteering me for additional work :)

The consensus seems to be that the extern "C" directives should only be in
public headers, not private ones. Can you please tell me if there's an easy
way to get a list of public headers?


> > On Sun, Mar 17, 2024 at 8:44 PM Ashish Sadanandan <
> > ashish.sadanandan@gmail.com> wrote:
> >
> > > The header was missing the extern "C" directive which causes name
> > > mangling of functions by C++ compilers, leading to linker errors
> > > complaining of undefined references to these functions.
> > >
> > > Also updated the coding style contribution guideline with a new
> > > "Language Linkage" section stating `extern "C"` block should be added
> to
> > > public headers.
> > >
> > > Fixes: 86c743cf9140 ("eal: define generic vector types")
> > > Cc: nelio.laranjeiro@6wind.com
> > > Cc: stable@dpdk.org
> > >
> > > Signed-off-by: Ashish Sadanandan <ashish.sadanandan@gmail.com>
> > > ---
> > >  .mailmap                                 |  2 +-
> > >  doc/guides/contributing/coding_style.rst | 21 +++++++++++++++++++++
> > >  lib/eal/include/generic/rte_vect.h       |  8 ++++++++
> > >  3 files changed, 30 insertions(+), 1 deletion(-)
> > >
> > > --- a/doc/guides/contributing/coding_style.rst
> > > +++ b/doc/guides/contributing/coding_style.rst
> > > +Language Linkage
> > > +~~~~~~~~~~~~~~~~
> > > +
> > > +Public headers should enclose all function and variable declarations
> and
> > > definitions in an ``extern "C"`` block to facilitate interoperability
> with
> > > C++.
> > > +
> > > +.. code-block:: c
> > > +
> > > +   #ifndef _FILE_H_
> > > +   #define _FILE_H_
> > > +
> > > +   #ifdef __cplusplus
> > > +   extern "C" {
> > > +   #endif
> > > +
> > > +   /* Code */
> > > +
> > > +   #ifdef __cplusplus
> > > +   }
> > > +   #endif
> > > +
> > > +   #endif /* _FILE_H_ */
>
> This is not describing where the includes should be placed.
>

Will address this along with the rest of the headers.

Regards,
Ashish.