diff mbox series

[XEN] libs/foreignmemory: Fix osdep_xenforeignmemory_map prototype

Message ID 20210601154147.55799-1-anthony.perard@citrix.com (mailing list archive)
State New
Headers show
Series [XEN] libs/foreignmemory: Fix osdep_xenforeignmemory_map prototype | expand

Commit Message

Anthony PERARD June 1, 2021, 3:41 p.m. UTC
Commit cf8c4d3d13b8 made some preparation to have one day
variable-length-array argument, but didn't declare the array in the
function prototype the same way as in the function definition. And now
GCC 11 complains about it.

Fixes: cf8c4d3d13b8 ("tools/libs/foreignmemory: pull array length argument to map forward")
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libs/foreignmemory/private.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Jan Beulich June 2, 2021, 8:25 a.m. UTC | #1
On 01.06.2021 17:41, Anthony PERARD wrote:
> Commit cf8c4d3d13b8 made some preparation to have one day
> variable-length-array argument, but didn't declare the array in the
> function prototype the same way as in the function definition. And now
> GCC 11 complains about it.
> 
> Fixes: cf8c4d3d13b8 ("tools/libs/foreignmemory: pull array length argument to map forward")
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

Ian - this (or whichever alternative might be chosen to address gcc11's
valid complaint) also will want backporting.

Jan
Julien Grall June 15, 2021, 1:31 p.m. UTC | #2
Hi Ian & Wei,

On 02/06/2021 10:25, Jan Beulich wrote:
> On 01.06.2021 17:41, Anthony PERARD wrote:
>> Commit cf8c4d3d13b8 made some preparation to have one day
>> variable-length-array argument, but didn't declare the array in the
>> function prototype the same way as in the function definition. And now
>> GCC 11 complains about it.
>>
>> Fixes: cf8c4d3d13b8 ("tools/libs/foreignmemory: pull array length argument to map forward")
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> 
> Ian - this (or whichever alternative might be chosen to address gcc11's
> valid complaint) also will want backporting.

I was about to commit this patch and noticed that there is still a 
missing an ack from the tools maintainers. @Ian, @Wei, can you provide one?

Cheers,
Julien Grall June 15, 2021, 5:12 p.m. UTC | #3
Hi,

On 15/06/2021 15:31, Julien Grall wrote:
> Hi Ian & Wei,
> 
> On 02/06/2021 10:25, Jan Beulich wrote:
>> On 01.06.2021 17:41, Anthony PERARD wrote:
>>> Commit cf8c4d3d13b8 made some preparation to have one day
>>> variable-length-array argument, but didn't declare the array in the
>>> function prototype the same way as in the function definition. And now
>>> GCC 11 complains about it.
>>>
>>> Fixes: cf8c4d3d13b8 ("tools/libs/foreignmemory: pull array length 
>>> argument to map forward")
>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>>
>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>>
>> Ian - this (or whichever alternative might be chosen to address gcc11's
>> valid complaint) also will want backporting.
> 
> I was about to commit this patch and noticed that there is still a 
> missing an ack from the tools maintainers. @Ian, @Wei, can you provide one?

 From an IRC discussion, Ian was happy to follow the rule:

"Commit something without the necessary acks if you're reasonably 
certain that the maintainer would have approved it"

This doesn't seem to be part of MAINTAINERS, but I will use it for this 
patch as Ian gave his assent.

This is committed now.

Cheers,
diff mbox series

Patch

diff --git a/tools/libs/foreignmemory/private.h b/tools/libs/foreignmemory/private.h
index 1ee3626dd278..5bb0cefb0987 100644
--- a/tools/libs/foreignmemory/private.h
+++ b/tools/libs/foreignmemory/private.h
@@ -32,7 +32,7 @@  int osdep_xenforeignmemory_close(xenforeignmemory_handle *fmem);
 void *osdep_xenforeignmemory_map(xenforeignmemory_handle *fmem,
                                  uint32_t dom, void *addr,
                                  int prot, int flags, size_t num,
-                                 const xen_pfn_t arr[num], int err[num]);
+                                 const xen_pfn_t arr[/*num*/], int err[/*num*/]);
 int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
                                  void *addr, size_t num);