This is really ugly for now but it show what need to be done
to support restricted enums (not how it must be done).
It need to incorporate changes to support correctly type attribues.
There is two problems with this for now:
1) scope of type attributes, for example in:
1a)
struct foo { ... } __aligned(8);
the attribute is purely ignored. And in
struct foo { ... } __aligned(8) var;
the attribute is attached to var, not to the struct.
1b)
struct __attribute foo { ... } ...
is parsed exactly like
__attribute struct foo { ... } ...
while their scope are in fact different (type vs. declaration).
2) enumerator values can have plenty of unexpected types.
For example in:
enum foo {
FOO = (char) 1,
BAR = (void*) 2,
BAZ = (int*) 3,
};
then typeof(FOO) is 'char', typeof(BAR) is 'void*' and
typeof(BAZ) is 'int*'. This was quite surprising to me and
not at all what GCC do.
To me:
- BAR & BAZ here above should be an error or
at least issues a warning.
- typeof(FOO) should be 'enum foo' (and same for
BAR & BAZ if not errors.
- of course, if the enum is declared as 'enum __bitwise foo'
then typeof(FOO) will be of the same type too
and thus will be of a restricted type only compatible
with other values of this enumeration type.
When using this series on the kernel (v4.15, defconfig) we got
a few new sparse warning:
1) a problem with (fs/aio.c)
struct kioctx {
...
struct __percpu kioctx_cpu *cpu;
...
};
should be:
__percpu struct kioctx_cpu *cpu;
2) a bunch of errors with pci_ers_result_t:
which is declared like:
typedef unsigned int __bitwise pci_ers_result_t;
enum pci_ers_result {
/* no result/none/not supported in device driver */
PCI_ERS_RESULT_NONE = (__force pci_ers_result_t) 1,
...
};
3) same with pci_channel...
typedef unsigned int __bitwise pci_channel_state_t;
enum pci_channel_state {
/* I/O channel is in normal state */
pci_channel_io_normal = (__force pci_channel_state_t) 1,
...
};
Of course 2) & 3) are, IMO, an horrible abuse of sparse type system
(and its current limitation and are exactly what Matthew want to avoid.
I can restore current behaviour of 1) but I think it should simply
use the correct syntax. In fact I think that declaring:
struct name { ... };
and then using 'struct __some_attribute__ name' should be an error.
----------------------------------------------------------------
This series is also available for evaluation in the Git repository at:
git://github.com/lucvoo/sparse-dev.git bitwise-enum-v0
----------------------------------------------------------------
Luc Van Oostenryck (3):
add testcase for restricted enum
extract apply_bitwise() from declaration_specifiers()
teach sparse about restricted enums
parse.c | 61 +++++++++++++++++++++++++++++++-------------
validation/enum-restricted.c | 21 +++++++++++++++
2 files changed, 64 insertions(+), 18 deletions(-)
create mode 100644 validation/enum-restricted.c
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
