[alsa-devel] [PATCH] Revert "ALSA: firewire-lib: change structure member with proper type"
This reverts commit 6b7e95d1336b9eb0d4c6db190ce756480496bd13. This commit is based on a concern about value of the given parameter. It's expected to be ORed value with some enumeration-constants, thus often it can not be one of the enumeration-constants. I understood that this is out of specification and causes implementation-dependent issues.
In C language specification, enumerated type can be interpreted as an integer type, in which all of enumeration-constants in corresponding enumerator-list can be stored. Implementations can select one of char, signed int and unsigned int as its type, and this selection is implementation-dependent.
In GCC, a signed integer is selected when at least one of enumeration-constants has negative value, else an unsigned integer is selected. This behaviour can be switched by -fshort-enums to short type. Anyway, the type can be decided after scanning all of enumeration-constants.
Totally, there's no rules to constrain the value of enumerated type to be one of enumeration-constants. In short, in enumerated type, decision of actual type for the type is the most important and enumeration-constants are just used for the decision, thus it's permitted to have an integer value in a range of enumeration-constants. In our case, actual type for the type is currently deterministic to be either char or unsigned int. Under GCC, it's unsigned int. --- sound/firewire/amdtp-stream.c | 2 +- sound/firewire/amdtp-stream.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/firewire/amdtp-stream.c b/sound/firewire/amdtp-stream.c index 8ce93cd..00060c4 100644 --- a/sound/firewire/amdtp-stream.c +++ b/sound/firewire/amdtp-stream.c @@ -69,7 +69,7 @@ static void pcm_period_tasklet(unsigned long data); * @protocol_size: the size to allocate newly for protocol */ int amdtp_stream_init(struct amdtp_stream *s, struct fw_unit *unit, - enum amdtp_stream_direction dir, int flags, + enum amdtp_stream_direction dir, enum cip_flags flags, unsigned int fmt, amdtp_stream_process_data_blocks_t process_data_blocks, unsigned int protocol_size) diff --git a/sound/firewire/amdtp-stream.h b/sound/firewire/amdtp-stream.h index 7be2142..c1bc7fa 100644 --- a/sound/firewire/amdtp-stream.h +++ b/sound/firewire/amdtp-stream.h @@ -93,7 +93,7 @@ typedef unsigned int (*amdtp_stream_process_data_blocks_t)( unsigned int *syt); struct amdtp_stream { struct fw_unit *unit; - int flags; + enum cip_flags flags; enum amdtp_stream_direction direction; struct mutex mutex;
@@ -137,7 +137,7 @@ struct amdtp_stream { };
int amdtp_stream_init(struct amdtp_stream *s, struct fw_unit *unit, - enum amdtp_stream_direction dir, int flags, + enum amdtp_stream_direction dir, enum cip_flags flags, unsigned int fmt, amdtp_stream_process_data_blocks_t process_data_blocks, unsigned int protocol_size);
On Thu, 05 Jan 2017 01:41:31 +0100, Takashi Sakamoto wrote:
This reverts commit 6b7e95d1336b9eb0d4c6db190ce756480496bd13. This commit is based on a concern about value of the given parameter. It's expected to be ORed value with some enumeration-constants, thus often it can not be one of the enumeration-constants. I understood that this is out of specification and causes implementation-dependent issues.
In C language specification, enumerated type can be interpreted as an integer type, in which all of enumeration-constants in corresponding enumerator-list can be stored. Implementations can select one of char, signed int and unsigned int as its type, and this selection is implementation-dependent.
In GCC, a signed integer is selected when at least one of enumeration-constants has negative value, else an unsigned integer is selected. This behaviour can be switched by -fshort-enums to short type. Anyway, the type can be decided after scanning all of enumeration-constants.
Totally, there's no rules to constrain the value of enumerated type to be one of enumeration-constants. In short, in enumerated type, decision of actual type for the type is the most important and enumeration-constants are just used for the decision, thus it's permitted to have an integer value in a range of enumeration-constants. In our case, actual type for the type is currently deterministic to be either char or unsigned int. Under GCC, it's unsigned int.
You sign-off is missing.
Takashi
On Jan 5 2017 15:34, Takashi Iwai wrote:
On Thu, 05 Jan 2017 01:41:31 +0100, Takashi Sakamoto wrote:
This reverts commit 6b7e95d1336b9eb0d4c6db190ce756480496bd13. This commit is based on a concern about value of the given parameter. It's expected to be ORed value with some enumeration-constants, thus often it can not be one of the enumeration-constants. I understood that this is out of specification and causes implementation-dependent issues.
In C language specification, enumerated type can be interpreted as an integer type, in which all of enumeration-constants in corresponding enumerator-list can be stored. Implementations can select one of char, signed int and unsigned int as its type, and this selection is implementation-dependent.
In GCC, a signed integer is selected when at least one of enumeration-constants has negative value, else an unsigned integer is selected. This behaviour can be switched by -fshort-enums to short type. Anyway, the type can be decided after scanning all of enumeration-constants.
Totally, there's no rules to constrain the value of enumerated type to be one of enumeration-constants. In short, in enumerated type, decision of actual type for the type is the most important and enumeration-constants are just used for the decision, thus it's permitted to have an integer value in a range of enumeration-constants. In our case, actual type for the type is currently deterministic to be either char or unsigned int. Under GCC, it's unsigned int.
You sign-off is missing.
Oops...
Signed-off-by: Takashi Sakamoto o-takashi@sakamocchi.jp
Should I re-post this with the sign-off?
Thanks
Takashi Sakamoto
On Thu, 05 Jan 2017 08:14:22 +0100, Takashi Sakamoto wrote:
On Jan 5 2017 15:34, Takashi Iwai wrote:
On Thu, 05 Jan 2017 01:41:31 +0100, Takashi Sakamoto wrote:
This reverts commit 6b7e95d1336b9eb0d4c6db190ce756480496bd13. This commit is based on a concern about value of the given parameter. It's expected to be ORed value with some enumeration-constants, thus often it can not be one of the enumeration-constants. I understood that this is out of specification and causes implementation-dependent issues.
In C language specification, enumerated type can be interpreted as an integer type, in which all of enumeration-constants in corresponding enumerator-list can be stored. Implementations can select one of char, signed int and unsigned int as its type, and this selection is implementation-dependent.
In GCC, a signed integer is selected when at least one of enumeration-constants has negative value, else an unsigned integer is selected. This behaviour can be switched by -fshort-enums to short type. Anyway, the type can be decided after scanning all of enumeration-constants.
Totally, there's no rules to constrain the value of enumerated type to be one of enumeration-constants. In short, in enumerated type, decision of actual type for the type is the most important and enumeration-constants are just used for the decision, thus it's permitted to have an integer value in a range of enumeration-constants. In our case, actual type for the type is currently deterministic to be either char or unsigned int. Under GCC, it's unsigned int.
You sign-off is missing.
Oops...
Signed-off-by: Takashi Sakamoto o-takashi@sakamocchi.jp
Should I re-post this with the sign-off?
No, I applied with a manual adjustment now. Thanks.
Takashi
participants (2)
-
Takashi Iwai
-
Takashi Sakamoto