#
1.10 |
|
01-Mar-2024 |
rillig |
tests/lint: remove redundant documentation
|
#
1.9 |
|
28-Mar-2023 |
rillig |
lint: warn about extern declarations outside headers
https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html
|
#
1.8 |
|
14-Jan-2023 |
rillig |
tests/lint: add more tests for array/enum mismatch
|
#
1.7 |
|
08-Jan-2023 |
rillig |
lint: recognize enum constant named 'max' as a count of values
Seen in external/bsd/mdocml/dist/mdoc.h(50).
|
#
1.6 |
|
08-Jan-2023 |
rillig |
tests/lint: add more tests for enum/array mismatch
|
Revision tags: netbsd-10-0-RC5 netbsd-10-0-RC4 netbsd-10-0-RC3 netbsd-10-0-RC2 netbsd-10-0-RC1 netbsd-10-base
|
#
1.5 |
|
11-Jun-2022 |
rillig |
lint: add quotes around a few more placeholders in messages
|
#
1.4 |
|
01-Nov-2021 |
rillig |
lint: do not warn about array size mismatch in array[(int)enum]
The cast to 'int' explicitly converts the type away from being an enum.
|
#
1.3 |
|
01-Nov-2021 |
rillig |
lint: in the check for array[enum], allow enum constant NUM
When an enum type defines a constant NUM_VALUES, this constant is usually not part of the enum values available to the application but rather a handy place for defining the number of other enum values. Don't warn about this case.
Seen in openpam_impl.h and several other places.
|
#
1.2 |
|
31-Oct-2021 |
rillig |
lint: fix invalid memory access in array[enum] check
Lint checks whether in an expression 'array[enum]', the array size matches the value of the maximum enum constant.
The previous tests for this check were missing the case where an enum name was explicitly cast to an integer type and then used as an array index. In this situation, the resulting type of the array index is a plain 'int' without any information about its previous 'enum' history.
An entirely different case is when the 'enum' is implicitly converted to an integer type, as in the test color_name_too_many. There, for the final type of the array index, rn->tn_type->t_is_enum is true, which means that rn->tn_type->t_enum is properly filled.
The bug was a simple typo, I had forgotten a tn_left indirection, which is necessary to get the type before the implicit conversion.
Found and reported by Christos, triggered by src/lib/libperfuse/ops.c 1.89 line 1226 expression 'VTTOIF(vap->va_type)'.
|
#
1.1 |
|
30-Oct-2021 |
rillig |
lint: warn if an enum name is used for mismatched array access
This helps to keep the enum definition and the straight-forward implementation of a to_string or name function in sync.
The test for message 241 had to be adjusted because of exactly this bug. That test defined a bit mask enum but accessed it like a value enum type.
|
#
1.9 |
|
28-Mar-2023 |
rillig |
lint: warn about extern declarations outside headers
https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html
|
#
1.8 |
|
14-Jan-2023 |
rillig |
tests/lint: add more tests for array/enum mismatch
|
#
1.7 |
|
08-Jan-2023 |
rillig |
lint: recognize enum constant named 'max' as a count of values
Seen in external/bsd/mdocml/dist/mdoc.h(50).
|
#
1.6 |
|
08-Jan-2023 |
rillig |
tests/lint: add more tests for enum/array mismatch
|
Revision tags: netbsd-10-base
|
#
1.5 |
|
11-Jun-2022 |
rillig |
lint: add quotes around a few more placeholders in messages
|
#
1.4 |
|
01-Nov-2021 |
rillig |
lint: do not warn about array size mismatch in array[(int)enum]
The cast to 'int' explicitly converts the type away from being an enum.
|
#
1.3 |
|
01-Nov-2021 |
rillig |
lint: in the check for array[enum], allow enum constant NUM
When an enum type defines a constant NUM_VALUES, this constant is usually not part of the enum values available to the application but rather a handy place for defining the number of other enum values. Don't warn about this case.
Seen in openpam_impl.h and several other places.
|
#
1.2 |
|
31-Oct-2021 |
rillig |
lint: fix invalid memory access in array[enum] check
Lint checks whether in an expression 'array[enum]', the array size matches the value of the maximum enum constant.
The previous tests for this check were missing the case where an enum name was explicitly cast to an integer type and then used as an array index. In this situation, the resulting type of the array index is a plain 'int' without any information about its previous 'enum' history.
An entirely different case is when the 'enum' is implicitly converted to an integer type, as in the test color_name_too_many. There, for the final type of the array index, rn->tn_type->t_is_enum is true, which means that rn->tn_type->t_enum is properly filled.
The bug was a simple typo, I had forgotten a tn_left indirection, which is necessary to get the type before the implicit conversion.
Found and reported by Christos, triggered by src/lib/libperfuse/ops.c 1.89 line 1226 expression 'VTTOIF(vap->va_type)'.
|
#
1.1 |
|
30-Oct-2021 |
rillig |
lint: warn if an enum name is used for mismatched array access
This helps to keep the enum definition and the straight-forward implementation of a to_string or name function in sync.
The test for message 241 had to be adjusted because of exactly this bug. That test defined a bit mask enum but accessed it like a value enum type.
|
#
1.8 |
|
14-Jan-2023 |
rillig |
tests/lint: add more tests for array/enum mismatch
|
#
1.7 |
|
08-Jan-2023 |
rillig |
lint: recognize enum constant named 'max' as a count of values
Seen in external/bsd/mdocml/dist/mdoc.h(50).
|
#
1.6 |
|
08-Jan-2023 |
rillig |
tests/lint: add more tests for enum/array mismatch
|
Revision tags: netbsd-10-base
|
#
1.5 |
|
11-Jun-2022 |
rillig |
lint: add quotes around a few more placeholders in messages
|
#
1.4 |
|
01-Nov-2021 |
rillig |
lint: do not warn about array size mismatch in array[(int)enum]
The cast to 'int' explicitly converts the type away from being an enum.
|
#
1.3 |
|
01-Nov-2021 |
rillig |
lint: in the check for array[enum], allow enum constant NUM
When an enum type defines a constant NUM_VALUES, this constant is usually not part of the enum values available to the application but rather a handy place for defining the number of other enum values. Don't warn about this case.
Seen in openpam_impl.h and several other places.
|
#
1.2 |
|
31-Oct-2021 |
rillig |
lint: fix invalid memory access in array[enum] check
Lint checks whether in an expression 'array[enum]', the array size matches the value of the maximum enum constant.
The previous tests for this check were missing the case where an enum name was explicitly cast to an integer type and then used as an array index. In this situation, the resulting type of the array index is a plain 'int' without any information about its previous 'enum' history.
An entirely different case is when the 'enum' is implicitly converted to an integer type, as in the test color_name_too_many. There, for the final type of the array index, rn->tn_type->t_is_enum is true, which means that rn->tn_type->t_enum is properly filled.
The bug was a simple typo, I had forgotten a tn_left indirection, which is necessary to get the type before the implicit conversion.
Found and reported by Christos, triggered by src/lib/libperfuse/ops.c 1.89 line 1226 expression 'VTTOIF(vap->va_type)'.
|
#
1.1 |
|
30-Oct-2021 |
rillig |
lint: warn if an enum name is used for mismatched array access
This helps to keep the enum definition and the straight-forward implementation of a to_string or name function in sync.
The test for message 241 had to be adjusted because of exactly this bug. That test defined a bit mask enum but accessed it like a value enum type.
|
#
1.7 |
|
08-Jan-2023 |
rillig |
lint: recognize enum constant named 'max' as a count of values
Seen in external/bsd/mdocml/dist/mdoc.h(50).
|
#
1.6 |
|
08-Jan-2023 |
rillig |
tests/lint: add more tests for enum/array mismatch
|
Revision tags: netbsd-10-base
|
#
1.5 |
|
11-Jun-2022 |
rillig |
lint: add quotes around a few more placeholders in messages
|
#
1.4 |
|
01-Nov-2021 |
rillig |
lint: do not warn about array size mismatch in array[(int)enum]
The cast to 'int' explicitly converts the type away from being an enum.
|
#
1.3 |
|
01-Nov-2021 |
rillig |
lint: in the check for array[enum], allow enum constant NUM
When an enum type defines a constant NUM_VALUES, this constant is usually not part of the enum values available to the application but rather a handy place for defining the number of other enum values. Don't warn about this case.
Seen in openpam_impl.h and several other places.
|
#
1.2 |
|
31-Oct-2021 |
rillig |
lint: fix invalid memory access in array[enum] check
Lint checks whether in an expression 'array[enum]', the array size matches the value of the maximum enum constant.
The previous tests for this check were missing the case where an enum name was explicitly cast to an integer type and then used as an array index. In this situation, the resulting type of the array index is a plain 'int' without any information about its previous 'enum' history.
An entirely different case is when the 'enum' is implicitly converted to an integer type, as in the test color_name_too_many. There, for the final type of the array index, rn->tn_type->t_is_enum is true, which means that rn->tn_type->t_enum is properly filled.
The bug was a simple typo, I had forgotten a tn_left indirection, which is necessary to get the type before the implicit conversion.
Found and reported by Christos, triggered by src/lib/libperfuse/ops.c 1.89 line 1226 expression 'VTTOIF(vap->va_type)'.
|
#
1.1 |
|
30-Oct-2021 |
rillig |
lint: warn if an enum name is used for mismatched array access
This helps to keep the enum definition and the straight-forward implementation of a to_string or name function in sync.
The test for message 241 had to be adjusted because of exactly this bug. That test defined a bit mask enum but accessed it like a value enum type.
|
#
1.5 |
|
11-Jun-2022 |
rillig |
lint: add quotes around a few more placeholders in messages
|
#
1.4 |
|
01-Nov-2021 |
rillig |
lint: do not warn about array size mismatch in array[(int)enum]
The cast to 'int' explicitly converts the type away from being an enum.
|
#
1.3 |
|
01-Nov-2021 |
rillig |
lint: in the check for array[enum], allow enum constant NUM
When an enum type defines a constant NUM_VALUES, this constant is usually not part of the enum values available to the application but rather a handy place for defining the number of other enum values. Don't warn about this case.
Seen in openpam_impl.h and several other places.
|
#
1.2 |
|
31-Oct-2021 |
rillig |
lint: fix invalid memory access in array[enum] check
Lint checks whether in an expression 'array[enum]', the array size matches the value of the maximum enum constant.
The previous tests for this check were missing the case where an enum name was explicitly cast to an integer type and then used as an array index. In this situation, the resulting type of the array index is a plain 'int' without any information about its previous 'enum' history.
An entirely different case is when the 'enum' is implicitly converted to an integer type, as in the test color_name_too_many. There, for the final type of the array index, rn->tn_type->t_is_enum is true, which means that rn->tn_type->t_enum is properly filled.
The bug was a simple typo, I had forgotten a tn_left indirection, which is necessary to get the type before the implicit conversion.
Found and reported by Christos, triggered by src/lib/libperfuse/ops.c 1.89 line 1226 expression 'VTTOIF(vap->va_type)'.
|
#
1.1 |
|
30-Oct-2021 |
rillig |
lint: warn if an enum name is used for mismatched array access
This helps to keep the enum definition and the straight-forward implementation of a to_string or name function in sync.
The test for message 241 had to be adjusted because of exactly this bug. That test defined a bit mask enum but accessed it like a value enum type.
|
#
1.4 |
|
01-Nov-2021 |
rillig |
lint: do not warn about array size mismatch in array[(int)enum]
The cast to 'int' explicitly converts the type away from being an enum.
|
#
1.3 |
|
01-Nov-2021 |
rillig |
lint: in the check for array[enum], allow enum constant NUM
When an enum type defines a constant NUM_VALUES, this constant is usually not part of the enum values available to the application but rather a handy place for defining the number of other enum values. Don't warn about this case.
Seen in openpam_impl.h and several other places.
|
#
1.2 |
|
31-Oct-2021 |
rillig |
lint: fix invalid memory access in array[enum] check
Lint checks whether in an expression 'array[enum]', the array size matches the value of the maximum enum constant.
The previous tests for this check were missing the case where an enum name was explicitly cast to an integer type and then used as an array index. In this situation, the resulting type of the array index is a plain 'int' without any information about its previous 'enum' history.
An entirely different case is when the 'enum' is implicitly converted to an integer type, as in the test color_name_too_many. There, for the final type of the array index, rn->tn_type->t_is_enum is true, which means that rn->tn_type->t_enum is properly filled.
The bug was a simple typo, I had forgotten a tn_left indirection, which is necessary to get the type before the implicit conversion.
Found and reported by Christos, triggered by src/lib/libperfuse/ops.c 1.89 line 1226 expression 'VTTOIF(vap->va_type)'.
|
#
1.1 |
|
30-Oct-2021 |
rillig |
lint: warn if an enum name is used for mismatched array access
This helps to keep the enum definition and the straight-forward implementation of a to_string or name function in sync.
The test for message 241 had to be adjusted because of exactly this bug. That test defined a bit mask enum but accessed it like a value enum type.
|
#
1.3 |
|
01-Nov-2021 |
rillig |
lint: in the check for array[enum], allow enum constant NUM
When an enum type defines a constant NUM_VALUES, this constant is usually not part of the enum values available to the application but rather a handy place for defining the number of other enum values. Don't warn about this case.
Seen in openpam_impl.h and several other places.
|
#
1.2 |
|
31-Oct-2021 |
rillig |
lint: fix invalid memory access in array[enum] check
Lint checks whether in an expression 'array[enum]', the array size matches the value of the maximum enum constant.
The previous tests for this check were missing the case where an enum name was explicitly cast to an integer type and then used as an array index. In this situation, the resulting type of the array index is a plain 'int' without any information about its previous 'enum' history.
An entirely different case is when the 'enum' is implicitly converted to an integer type, as in the test color_name_too_many. There, for the final type of the array index, rn->tn_type->t_is_enum is true, which means that rn->tn_type->t_enum is properly filled.
The bug was a simple typo, I had forgotten a tn_left indirection, which is necessary to get the type before the implicit conversion.
Found and reported by Christos, triggered by src/lib/libperfuse/ops.c 1.89 line 1226 expression 'VTTOIF(vap->va_type)'.
|
#
1.1 |
|
30-Oct-2021 |
rillig |
lint: warn if an enum name is used for mismatched array access
This helps to keep the enum definition and the straight-forward implementation of a to_string or name function in sync.
The test for message 241 had to be adjusted because of exactly this bug. That test defined a bit mask enum but accessed it like a value enum type.
|
#
1.1 |
|
30-Oct-2021 |
rillig |
lint: warn if an enum name is used for mismatched array access
This helps to keep the enum definition and the straight-forward implementation of a to_string or name function in sync.
The test for message 241 had to be adjusted because of exactly this bug. That test defined a bit mask enum but accessed it like a value enum type.
|