[v2] eal/windows: explicitly cast void * to type *

Message ID 1610739501-21508-1-git-send-email-roretzla@linux.microsoft.com (mailing list archive)
State Accepted, archived
Headers
Series [v2] eal/windows: explicitly cast void * to type * |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/iol-broadcom-Functional success Functional Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-mellanox-Functional success Functional Testing PASS
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS
ci/iol-abi-testing success Testing PASS
ci/iol-testing fail Testing issues

Commit Message

Tyler Retzlaff Jan. 15, 2021, 7:38 p.m. UTC
  Explicitly cast void * to type * so that eal headers may be compiled
as C or C++.

Fixes: e8428a9d89f1 ("eal/windows: add some basic functions and macros")
Cc: stable@dpdk.org

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/librte_eal/windows/include/rte_os.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

Comments

Thomas Monjalon Jan. 17, 2021, 5:19 p.m. UTC | #1
15/01/2021 20:38, Tyler Retzlaff:
> Explicitly cast void * to type * so that eal headers may be compiled
> as C or C++.
> 
> Fixes: e8428a9d89f1 ("eal/windows: add some basic functions and macros")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>

Applied with title "eal/windows: fix C++ compatibility", thanks.
  
Stephen Hemminger Jan. 17, 2021, 6:10 p.m. UTC | #2
On Fri, 15 Jan 2021 11:38:21 -0800
Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:

> Explicitly cast void * to type * so that eal headers may be compiled
> as C or C++.
> 
> Fixes: e8428a9d89f1 ("eal/windows: add some basic functions and macros")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
>  lib/librte_eal/windows/include/rte_os.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/librte_eal/windows/include/rte_os.h b/lib/librte_eal/windows/include/rte_os.h
> index ea3fe60e5..7ef38ff06 100644
> --- a/lib/librte_eal/windows/include/rte_os.h
> +++ b/lib/librte_eal/windows/include/rte_os.h
> @@ -86,7 +86,7 @@ asprintf(char **buffer, const char *format, ...)
>  		return -1;
>  	size++;
>  
> -	*buffer = malloc(size);
> +	*buffer = (char *)malloc(size);
>  	if (*buffer == NULL)
>  		return -1;
>  

Why is the compiler enforcing C++ rules on code that is inside "extern C {"?

Bigger question is why is this code inlined? It is not critical path
and should be a function.
  
Dmitry Kozlyuk Jan. 17, 2021, 7:51 p.m. UTC | #3
On Sun, 17 Jan 2021 10:10:39 -0800, Stephen Hemminger wrote: 
> > -	*buffer = malloc(size);
> > +	*buffer = (char *)malloc(size);
> >  	if (*buffer == NULL)
> >  		return -1;
> >    
> 
> Why is the compiler enforcing C++ rules on code that is inside "extern C {"?

Code inside extern "C" is not compiled as C; directive only affects linkage.

> Bigger question is why is this code inlined? It is not critical path
> and should be a function.

Absolutely.
There's more: windows/rte_os.h should not expose POSIX symbols at all, I'm
working on a patchset to clean it up and un-inline this code.
  

Patch

diff --git a/lib/librte_eal/windows/include/rte_os.h b/lib/librte_eal/windows/include/rte_os.h
index ea3fe60e5..7ef38ff06 100644
--- a/lib/librte_eal/windows/include/rte_os.h
+++ b/lib/librte_eal/windows/include/rte_os.h
@@ -86,7 +86,7 @@  asprintf(char **buffer, const char *format, ...)
 		return -1;
 	size++;
 
-	*buffer = malloc(size);
+	*buffer = (char *)malloc(size);
 	if (*buffer == NULL)
 		return -1;