DPDK patches and discussions
 help / color / mirror / Atom feed
From: Sunil Kumar Kori <skori@marvell.com>
To: Pawel Wodkowski <pawelwod@gmail.com>,
	Jerin Jacob Kollanukkaran <jerinj@marvell.com>
Cc: dev <dev@dpdk.org>, David Marchand <david.marchand@redhat.com>
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] tracepoint: fix compilation with C++
Date: Fri, 7 Aug 2020 05:54:45 +0000	[thread overview]
Message-ID: <CY4PR18MB1622ECD23411D0DCEFF800B3B4490@CY4PR18MB1622.namprd18.prod.outlook.com> (raw)
In-Reply-To: <47184d9f-88b5-7167-ab2b-ccb3b30c214a@gmail.com>

Answers inline.

Sunil Kumar Kori

>-----Original Message-----
>From: Pawel Wodkowski <pawelwod@gmail.com>
>Sent: Friday, August 7, 2020 12:14 AM
>To: Sunil Kumar Kori <skori@marvell.com>; Jerin Jacob Kollanukkaran
>Cc: dev <dev@dpdk.org>; David Marchand <david.marchand@redhat.com>
>Subject: Re: [EXT] Re: [dpdk-dev] [PATCH] tracepoint: fix compilation with C++
>On 06.08.2020 08:44, Sunil Kumar Kori wrote:
>> Hello Pawel,
>> See answers inline.
>> Regards
>> Sunil Kumar Kori
>>> -----Original Message-----
>>> From: David Marchand <david.marchand@redhat.com>
>>> Sent: Wednesday, August 5, 2020 1:30 PM
>>> To: Pawel Wodkowski <pawelwod@gmail.com>
>>> Cc: dev <dev@dpdk.org>; Jerin Jacob Kollanukkaran
>>> <jerinj@marvell.com>; Sunil Kumar Kori <skori@marvell.com>
>>> Subject: [EXT] Re: [dpdk-dev] [PATCH] tracepoint: fix compilation
>>> with C++
>>> External Email
>>> ---------------------------------------------------------------------
>>> -
>>> Hello Pawel,
>>> Thanks for contributing to DPDK.
>>> On Tue, Aug 4, 2020 at 7:52 PM Pawel Wodkowski
>>> wrote:
>>>> trace_mem is declared as 'void *' which triggers following error:
>>>> '...invalid conversion from ‘void*’ to ‘__rte_trace_header*’
>>>> [-fpermissive]...'
>>>> Fix this by changing void to struct __rte_trace_header
>> trace_mem is intentionally kept as void * so that it can not be accessed by
>application directly as it part of global header.
>But this structure is well defined in this file anyway. It can be casted to 'struct
>__rte_trace_header *' and used.
>Isn't the double underscore prefix good enough warning that it is internal
>But anyway, I'm not here to discuss the architecture of DPDK so lets go to the
>next point.
>> If I understood the problem correctly, it is because of using
>> trace_mem without typecasting and GCC does not report it as error due to
>implicit typecast and G++ reports it as error as it does not do implicit
>Actually it is because in C++ implicit cast from void pointer is not allowed. So
>when it is used like this
>      struct __rte_trace_header *trace = RTE_PER_LCORE(trace_mem);
>it triggers this type of error:
>include/rte_trace_point.h: In function ‘void*
>include/rte_per_lcore.h:44:46: error: invalid conversion from ‘void*’ to
>‘__rte_trace_header*’ [-fpermissive]
>  #define RTE_PER_LCORE(name) (per_lcore_##name)
>                                         ^
>nclude/rte_trace_point.h:303:37: note: in expansion of macro
>   struct __rte_trace_header *trace = RTE_PER_LCORE(trace_mem);
>                                                           ^
>One can add '-fpermisive' to allow this type of casting but it is only a
>workaround in C++ code. As you mentioned, other solution is typecast to
>__rte_trace_header but this is not needed in C and it have "__" prefix this why
>I decided to change 'void *' into 'struct __rte_trace_header *'.

But changing 'void *' to 'struct __rte_trace_header *' will change the interpretation of trace_mem from user perspective which is against the design.
I would request you to go for the proposed solution. Although  there is no need of this for GCC but if there is no harm. 

Also consider a use case where system is designed like  'structure is exposed to application as opaque pointer(void *) and typecasted by the underlying implementation before using it'.
Then changing opaque pointer to structure type is not expected.

>> If this is the case then, I think it is better to typecast the trace_mem where
>ever it is being used. Anyways that will be safe for both GCC and G++.
>> @Jerin Jacob Kollanukkaran Please suggest. If you have some thing mind.
>I'm fine any solution that make this code compile with C++. Please let me
>know what is the decision then I can make V2.
>> [snippet]
>> --

  reply	other threads:[~2020-08-07  5:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-04 17:51 [dpdk-dev] " Pawel Wodkowski
2020-08-05  8:00 ` David Marchand
2020-08-05  9:26   ` Pawel Wodkowski
2020-08-06  6:44   ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2020-08-06 18:44     ` Pawel Wodkowski
2020-08-07  5:54       ` Sunil Kumar Kori [this message]
2020-08-10 20:36 ` [dpdk-dev] [PATCH v2] " Pawel Wodkowski
2020-08-11  9:29   ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2020-08-11 13:34     ` Pawel Wodkowski
2020-08-12  6:51       ` Sunil Kumar Kori
2020-08-12  9:51   ` [dpdk-dev] [PATCH v3] trace: " skori
2020-09-11 20:33     ` Chautru, Nicolas
2020-09-17  8:16     ` David Marchand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CY4PR18MB1622ECD23411D0DCEFF800B3B4490@CY4PR18MB1622.namprd18.prod.outlook.com \
    --to=skori@marvell.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=pawelwod@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).