2021-08-31 18:04:51

by Peter A. Bigot

[permalink] [raw]
Subject: [BlueZ PATCH] lib: fix variable-length array declarations in hci structures

Use of zero as the size for arrays as the last element of a structure
is a GNU C extension, which as of GCC 10 produces diagnostics when
values in the extended array are referenced. Switch to the C99
standard idiom for flexible array members, already in use in a few
other headers.

Signed-off-by: Peter A. Bigot <[email protected]>
---

No changes from previous submission except the BlueZ subject prefix
that I hope will get this into bluez.

lib/hci.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/lib/hci.h b/lib/hci.h
index 3382b87bf..a61568bce 100644
--- a/lib/hci.h
+++ b/lib/hci.h
@@ -729,7 +729,7 @@ typedef struct {
typedef struct {
uint8_t flt_type;
uint8_t cond_type;
- uint8_t condition[0];
+ uint8_t condition[];
} __attribute__ ((packed)) set_event_flt_cp;
#define SET_EVENT_FLT_CP_SIZE 2

@@ -2135,7 +2135,7 @@ typedef struct {
#define EVT_LE_META_EVENT 0x3E
typedef struct {
uint8_t subevent;
- uint8_t data[0];
+ uint8_t data[];
} __attribute__ ((packed)) evt_le_meta_event;
#define EVT_LE_META_EVENT_SIZE 1

@@ -2159,7 +2159,7 @@ typedef struct {
uint8_t bdaddr_type;
bdaddr_t bdaddr;
uint8_t length;
- uint8_t data[0];
+ uint8_t data[];
} __attribute__ ((packed)) le_advertising_info;
#define LE_ADVERTISING_INFO_SIZE 9

@@ -2246,7 +2246,7 @@ typedef struct {
typedef struct {
uint16_t total_num_blocks;
uint8_t num_handles;
- cmplt_handle handles[0];
+ cmplt_handle handles[];
} __attribute__ ((packed)) evt_num_completed_blocks;

#define EVT_AMP_STATUS_CHANGE 0x4D
@@ -2264,7 +2264,7 @@ typedef struct {
#define EVT_STACK_INTERNAL 0xFD
typedef struct {
uint16_t type;
- uint8_t data[0];
+ uint8_t data[];
} __attribute__ ((packed)) evt_stack_internal;
#define EVT_STACK_INTERNAL_SIZE 2

@@ -2407,19 +2407,19 @@ struct hci_dev_req {

struct hci_dev_list_req {
uint16_t dev_num;
- struct hci_dev_req dev_req[0]; /* hci_dev_req structures */
+ struct hci_dev_req dev_req[]; /* hci_dev_req structures */
};

struct hci_conn_list_req {
uint16_t dev_id;
uint16_t conn_num;
- struct hci_conn_info conn_info[0];
+ struct hci_conn_info conn_info[];
};

struct hci_conn_info_req {
bdaddr_t bdaddr;
uint8_t type;
- struct hci_conn_info conn_info[0];
+ struct hci_conn_info conn_info[];
};

struct hci_auth_info_req {
--
2.25.1


2021-08-31 18:07:31

by bluez.test.bot

[permalink] [raw]
Subject: RE: [BlueZ] lib: fix variable-length array declarations in hci structures

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=539937

---Test result---

Test Summary:
CheckPatch PASS 0.39 seconds
GitLint PASS 0.12 seconds
Prep - Setup ELL PASS 46.48 seconds
Build - Prep PASS 0.15 seconds
Build - Configure PASS 8.27 seconds
Build - Make PASS 207.41 seconds
Make Check PASS 9.24 seconds
Make Distcheck PASS 243.61 seconds
Build w/ext ELL - Configure PASS 8.39 seconds
Build w/ext ELL - Make PASS 192.18 seconds

Details
##############################
Test: CheckPatch - PASS
Desc: Run checkpatch.pl script with rule in .checkpatch.conf

##############################
Test: GitLint - PASS
Desc: Run gitlint with rule in .gitlint

##############################
Test: Prep - Setup ELL - PASS
Desc: Clone, build, and install ELL

##############################
Test: Build - Prep - PASS
Desc: Prepare environment for build

##############################
Test: Build - Configure - PASS
Desc: Configure the BlueZ source tree

##############################
Test: Build - Make - PASS
Desc: Build the BlueZ source tree

##############################
Test: Make Check - PASS
Desc: Run 'make check'

##############################
Test: Make Distcheck - PASS
Desc: Run distcheck to check the distribution

##############################
Test: Build w/ext ELL - Configure - PASS
Desc: Configure BlueZ source with '--enable-external-ell' configuration

##############################
Test: Build w/ext ELL - Make - PASS
Desc: Build BlueZ source with '--enable-external-ell' configuration



---
Regards,
Linux Bluetooth

2021-08-31 21:51:54

by Marcel Holtmann

[permalink] [raw]
Subject: Re: [BlueZ PATCH] lib: fix variable-length array declarations in hci structures

Hi Peter,

> Use of zero as the size for arrays as the last element of a structure
> is a GNU C extension, which as of GCC 10 produces diagnostics when
> values in the extended array are referenced. Switch to the C99
> standard idiom for flexible array members, already in use in a few
> other headers.
>
> Signed-off-by: Peter A. Bigot <[email protected]>
> ---
>
> No changes from previous submission except the BlueZ subject prefix
> that I hope will get this into bluez.
>
> lib/hci.h | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/lib/hci.h b/lib/hci.h
> index 3382b87bf..a61568bce 100644
> --- a/lib/hci.h
> +++ b/lib/hci.h
> @@ -729,7 +729,7 @@ typedef struct {
> typedef struct {
> uint8_t flt_type;
> uint8_t cond_type;
> - uint8_t condition[0];
> + uint8_t condition[];
> } __attribute__ ((packed)) set_event_flt_cp;
> #define SET_EVENT_FLT_CP_SIZE 2

does this break any API assumptions? Since as long as libbluetooth exists these headers are API.

Regards

Marcel

2021-08-31 21:54:07

by Peter A. Bigot

[permalink] [raw]
Subject: Re: [BlueZ PATCH] lib: fix variable-length array declarations in hci structures

On 8/31/21 2:23 PM, Marcel Holtmann wrote:
> Hi Peter,
>
>> Use of zero as the size for arrays as the last element of a structure
>> is a GNU C extension, which as of GCC 10 produces diagnostics when
>> values in the extended array are referenced. Switch to the C99
>> standard idiom for flexible array members, already in use in a few
>> other headers.
>>
>> Signed-off-by: Peter A. Bigot <[email protected]>
>> ---
>>
>> No changes from previous submission except the BlueZ subject prefix
>> that I hope will get this into bluez.
>>
>> lib/hci.h | 16 ++++++++--------
>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/lib/hci.h b/lib/hci.h
>> index 3382b87bf..a61568bce 100644
>> --- a/lib/hci.h
>> +++ b/lib/hci.h
>> @@ -729,7 +729,7 @@ typedef struct {
>> typedef struct {
>> uint8_t flt_type;
>> uint8_t cond_type;
>> - uint8_t condition[0];
>> + uint8_t condition[];
>> } __attribute__ ((packed)) set_event_flt_cp;
>> #define SET_EVENT_FLT_CP_SIZE 2
> does this break any API assumptions? Since as long as libbluetooth exists these headers are API.

The size of the structure remains the same; there should be no API
changes.  I've done this sort of change multiple times over the years
and nobody's reported any problems.

Peter

2021-09-08 17:24:43

by Luiz Augusto von Dentz

[permalink] [raw]
Subject: Re: [BlueZ PATCH] lib: fix variable-length array declarations in hci structures

Hi Marcel,

On Tue, Aug 31, 2021 at 2:54 PM Peter A. Bigot <[email protected]> wrote:
>
> On 8/31/21 2:23 PM, Marcel Holtmann wrote:
> > Hi Peter,
> >
> >> Use of zero as the size for arrays as the last element of a structure
> >> is a GNU C extension, which as of GCC 10 produces diagnostics when
> >> values in the extended array are referenced. Switch to the C99
> >> standard idiom for flexible array members, already in use in a few
> >> other headers.
> >>
> >> Signed-off-by: Peter A. Bigot <[email protected]>
> >> ---
> >>
> >> No changes from previous submission except the BlueZ subject prefix
> >> that I hope will get this into bluez.
> >>
> >> lib/hci.h | 16 ++++++++--------
> >> 1 file changed, 8 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/lib/hci.h b/lib/hci.h
> >> index 3382b87bf..a61568bce 100644
> >> --- a/lib/hci.h
> >> +++ b/lib/hci.h
> >> @@ -729,7 +729,7 @@ typedef struct {
> >> typedef struct {
> >> uint8_t flt_type;
> >> uint8_t cond_type;
> >> - uint8_t condition[0];
> >> + uint8_t condition[];
> >> } __attribute__ ((packed)) set_event_flt_cp;
> >> #define SET_EVENT_FLT_CP_SIZE 2
> > does this break any API assumptions? Since as long as libbluetooth exists these headers are API.
>
> The size of the structure remains the same; there should be no API
> changes. I've done this sort of change multiple times over the years
> and nobody's reported any problems.
>
> Peter

Looks like we also use [] in the kernel so I think it should be safe
to do this change on userspace as well.

--
Luiz Augusto von Dentz