lint: in strict bool mode, allow do-while-0

Even though 0 is not a boolean constant, allow this common idiom, to
help in those cases where the C preprocessor used by lint does not mark
tokens as coming from system headers (Clang).

tests/lint: clean up tests for strict bool mode

lint: since C99, a non-void function must return a value

lint: distinguish between arguments and parameters

lint: remove redundant '#' after 'argument' in diagnostics

lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

lint: add quotes around placeholders for the remaining messages

Reword some of the messages slightly, exchanging brevity for clarity.

Message 138 is kept as-is, as it is not yet covered by any tests.

Message 240 is kep as-is, as it is unreachable.

lint: add quotes around placeholders in 4 messages

tests/lint: demonstrate wrong syshdr check in strict bool mode

tests/lint: sync comment with reality

lint: in strict bool mode, check function arguments more strictly

When a system header defined the constant FALSE = 0, that constant could
be passed as a bool argument. On the other hand, the constant TRUE = 1
could not be passed in the same way. Remove this inconsistency.

tests/lint: extend tests for type mismatch in strict bool mode

Seen in games/gomoku when calling curses functions.

lint: fix wrong error in strict bool mode in condition with comma

For the result of the comma operator, it doesn't matter whether the
comma itself comes from a system header or not. Instead, it's the main
operator of the right operand.

Since 2021-11-16.

lint: clean up lex.c

Rename 'struct kwtab' to 'struct keyword' since a single keyword is not
a whole keyword table.

Sync comment for lex_name with reality: sbuf_t no longer contains the
hash value.

Remove redundant tests for EOF, as EOF is neither a space nor a digit
nor an xdigit.

No functional change.

tests/lint: remove false assumptions from comments

https://stackoverflow.com/q/65868752

tests/lint: one comment per expected diagnostic

This makes it possible to check for diagnostics that contain commas.

lint: improve introduction of test d_c99_bool_strict_syshdr

lint: explain why !finite(x) is not allowed in strict bool mode

lint: apply strict bool mode to lex.c

There are 2 remaining expressions:

In line 244, !(kw->kw_deco & deco) is a bitwise and. This is already
allowed for enums, it needs to be allowed for arbitrary integer
expressions as well. This covers the many places where plain integers
are used for bit fields, together with #define. This pattern is not as
typesafe as using enums, still it is common practice.

In line 769, the expression !finite(f) is a legitimate use of a function
that has return type int for traditional reasons. It's the same as for
ferror.

There are several other functions like unlink, open or strcmp that have
return type int as well, but with a different meaning. It is not yet
clear what the best way is to handle these different meanings. Having
to write finite(f) == 0 in strict bool mode doesn't look idiomatic, on
the other hand, !strcmp(s1, s2) is exactly the pattern that strict bool
mode wants to avoid.

lint: fix error message for relaxed bool operations in system headers

In strict mode, allowing 1 as bool constant expression is probably not
needed in practice since most comparisons are != 0 instead of == 0.

Furthermore, in the expression (flags & 0x0002) == true, comparing with
true is misleading since the '==' operator can never evaluate to true in
this case.

lint: fix two wrong error messages in strict bool mode

The strict bool mode gets complicated because for system headers the
rules need to be relaxed since they cannot be changed easily, often not at all.

Still, if lint validates a program in strict bool mode, that program
must run with equal behavior regarding boolean expressions even on a
pre-C99 platform.

lint: extend test for strict bool mode and system headers

lint: allow system headers to use int as bool, even in strict bool mode

lint: add more tests for system headers in strict bool mode

lint: since C99, a non-void function must return a value

lint: distinguish between arguments and parameters

lint: remove redundant '#' after 'argument' in diagnostics

lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

lint: add quotes around placeholders for the remaining messages

Reword some of the messages slightly, exchanging brevity for clarity.

Message 138 is kept as-is, as it is not yet covered by any tests.

Message 240 is kep as-is, as it is unreachable.

lint: add quotes around placeholders in 4 messages

tests/lint: demonstrate wrong syshdr check in strict bool mode

tests/lint: sync comment with reality

lint: in strict bool mode, check function arguments more strictly

When a system header defined the constant FALSE = 0, that constant could
be passed as a bool argument. On the other hand, the constant TRUE = 1
could not be passed in the same way. Remove this inconsistency.

tests/lint: extend tests for type mismatch in strict bool mode

Seen in games/gomoku when calling curses functions.

lint: fix wrong error in strict bool mode in condition with comma

For the result of the comma operator, it doesn't matter whether the
comma itself comes from a system header or not. Instead, it's the main
operator of the right operand.

Since 2021-11-16.

lint: clean up lex.c

Rename 'struct kwtab' to 'struct keyword' since a single keyword is not
a whole keyword table.

Sync comment for lex_name with reality: sbuf_t no longer contains the
hash value.

Remove redundant tests for EOF, as EOF is neither a space nor a digit
nor an xdigit.

No functional change.

tests/lint: remove false assumptions from comments

https://stackoverflow.com/q/65868752

tests/lint: one comment per expected diagnostic

This makes it possible to check for diagnostics that contain commas.

lint: improve introduction of test d_c99_bool_strict_syshdr

lint: explain why !finite(x) is not allowed in strict bool mode

lint: apply strict bool mode to lex.c

There are 2 remaining expressions:

In line 244, !(kw->kw_deco & deco) is a bitwise and. This is already
allowed for enums, it needs to be allowed for arbitrary integer
expressions as well. This covers the many places where plain integers
are used for bit fields, together with #define. This pattern is not as
typesafe as using enums, still it is common practice.

In line 769, the expression !finite(f) is a legitimate use of a function
that has return type int for traditional reasons. It's the same as for
ferror.

There are several other functions like unlink, open or strcmp that have
return type int as well, but with a different meaning. It is not yet
clear what the best way is to handle these different meanings. Having
to write finite(f) == 0 in strict bool mode doesn't look idiomatic, on
the other hand, !strcmp(s1, s2) is exactly the pattern that strict bool
mode wants to avoid.

lint: fix error message for relaxed bool operations in system headers

In strict mode, allowing 1 as bool constant expression is probably not
needed in practice since most comparisons are != 0 instead of == 0.

Furthermore, in the expression (flags & 0x0002) == true, comparing with
true is misleading since the '==' operator can never evaluate to true in
this case.

lint: fix two wrong error messages in strict bool mode

The strict bool mode gets complicated because for system headers the
rules need to be relaxed since they cannot be changed easily, often not at all.

Still, if lint validates a program in strict bool mode, that program
must run with equal behavior regarding boolean expressions even on a
pre-C99 platform.

lint: extend test for strict bool mode and system headers

lint: allow system headers to use int as bool, even in strict bool mode

lint: add more tests for system headers in strict bool mode

lint: distinguish between arguments and parameters

lint: remove redundant '#' after 'argument' in diagnostics

lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

lint: add quotes around placeholders for the remaining messages

Reword some of the messages slightly, exchanging brevity for clarity.

Message 138 is kept as-is, as it is not yet covered by any tests.

Message 240 is kep as-is, as it is unreachable.

lint: add quotes around placeholders in 4 messages

tests/lint: demonstrate wrong syshdr check in strict bool mode

tests/lint: sync comment with reality

lint: in strict bool mode, check function arguments more strictly

When a system header defined the constant FALSE = 0, that constant could
be passed as a bool argument. On the other hand, the constant TRUE = 1
could not be passed in the same way. Remove this inconsistency.

tests/lint: extend tests for type mismatch in strict bool mode

Seen in games/gomoku when calling curses functions.

lint: fix wrong error in strict bool mode in condition with comma

For the result of the comma operator, it doesn't matter whether the
comma itself comes from a system header or not. Instead, it's the main
operator of the right operand.

Since 2021-11-16.

lint: clean up lex.c

Rename 'struct kwtab' to 'struct keyword' since a single keyword is not
a whole keyword table.

Sync comment for lex_name with reality: sbuf_t no longer contains the
hash value.

Remove redundant tests for EOF, as EOF is neither a space nor a digit
nor an xdigit.

No functional change.

tests/lint: remove false assumptions from comments

https://stackoverflow.com/q/65868752

tests/lint: one comment per expected diagnostic

This makes it possible to check for diagnostics that contain commas.

lint: improve introduction of test d_c99_bool_strict_syshdr

lint: explain why !finite(x) is not allowed in strict bool mode

lint: apply strict bool mode to lex.c

There are 2 remaining expressions:

In line 244, !(kw->kw_deco & deco) is a bitwise and. This is already
allowed for enums, it needs to be allowed for arbitrary integer
expressions as well. This covers the many places where plain integers
are used for bit fields, together with #define. This pattern is not as
typesafe as using enums, still it is common practice.

In line 769, the expression !finite(f) is a legitimate use of a function
that has return type int for traditional reasons. It's the same as for
ferror.

There are several other functions like unlink, open or strcmp that have
return type int as well, but with a different meaning. It is not yet
clear what the best way is to handle these different meanings. Having
to write finite(f) == 0 in strict bool mode doesn't look idiomatic, on
the other hand, !strcmp(s1, s2) is exactly the pattern that strict bool
mode wants to avoid.

lint: fix error message for relaxed bool operations in system headers

In strict mode, allowing 1 as bool constant expression is probably not
needed in practice since most comparisons are != 0 instead of == 0.

Furthermore, in the expression (flags & 0x0002) == true, comparing with
true is misleading since the '==' operator can never evaluate to true in
this case.

lint: fix two wrong error messages in strict bool mode

The strict bool mode gets complicated because for system headers the
rules need to be relaxed since they cannot be changed easily, often not at all.

Still, if lint validates a program in strict bool mode, that program
must run with equal behavior regarding boolean expressions even on a
pre-C99 platform.

lint: extend test for strict bool mode and system headers

lint: allow system headers to use int as bool, even in strict bool mode

lint: add more tests for system headers in strict bool mode

lint: remove redundant '#' after 'argument' in diagnostics

lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

lint: add quotes around placeholders for the remaining messages

Reword some of the messages slightly, exchanging brevity for clarity.

Message 138 is kept as-is, as it is not yet covered by any tests.

Message 240 is kep as-is, as it is unreachable.

lint: add quotes around placeholders in 4 messages

tests/lint: demonstrate wrong syshdr check in strict bool mode

tests/lint: sync comment with reality

lint: in strict bool mode, check function arguments more strictly

When a system header defined the constant FALSE = 0, that constant could
be passed as a bool argument. On the other hand, the constant TRUE = 1
could not be passed in the same way. Remove this inconsistency.

tests/lint: extend tests for type mismatch in strict bool mode

Seen in games/gomoku when calling curses functions.

lint: fix wrong error in strict bool mode in condition with comma

For the result of the comma operator, it doesn't matter whether the
comma itself comes from a system header or not. Instead, it's the main
operator of the right operand.

Since 2021-11-16.

lint: clean up lex.c

Rename 'struct kwtab' to 'struct keyword' since a single keyword is not
a whole keyword table.

Sync comment for lex_name with reality: sbuf_t no longer contains the
hash value.

Remove redundant tests for EOF, as EOF is neither a space nor a digit
nor an xdigit.

No functional change.

tests/lint: remove false assumptions from comments

https://stackoverflow.com/q/65868752

tests/lint: one comment per expected diagnostic

This makes it possible to check for diagnostics that contain commas.

lint: improve introduction of test d_c99_bool_strict_syshdr

lint: explain why !finite(x) is not allowed in strict bool mode

lint: apply strict bool mode to lex.c

There are 2 remaining expressions:

In line 244, !(kw->kw_deco & deco) is a bitwise and. This is already
allowed for enums, it needs to be allowed for arbitrary integer
expressions as well. This covers the many places where plain integers
are used for bit fields, together with #define. This pattern is not as
typesafe as using enums, still it is common practice.

In line 769, the expression !finite(f) is a legitimate use of a function
that has return type int for traditional reasons. It's the same as for
ferror.

There are several other functions like unlink, open or strcmp that have
return type int as well, but with a different meaning. It is not yet
clear what the best way is to handle these different meanings. Having
to write finite(f) == 0 in strict bool mode doesn't look idiomatic, on
the other hand, !strcmp(s1, s2) is exactly the pattern that strict bool
mode wants to avoid.

lint: fix error message for relaxed bool operations in system headers

In strict mode, allowing 1 as bool constant expression is probably not
needed in practice since most comparisons are != 0 instead of == 0.

Furthermore, in the expression (flags & 0x0002) == true, comparing with
true is misleading since the '==' operator can never evaluate to true in
this case.

lint: fix two wrong error messages in strict bool mode

The strict bool mode gets complicated because for system headers the
rules need to be relaxed since they cannot be changed easily, often not at all.

Still, if lint validates a program in strict bool mode, that program
must run with equal behavior regarding boolean expressions even on a
pre-C99 platform.

lint: extend test for strict bool mode and system headers

lint: allow system headers to use int as bool, even in strict bool mode

lint: add more tests for system headers in strict bool mode

lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

lint: add quotes around placeholders for the remaining messages

Reword some of the messages slightly, exchanging brevity for clarity.

Message 138 is kept as-is, as it is not yet covered by any tests.

Message 240 is kep as-is, as it is unreachable.

lint: add quotes around placeholders in 4 messages

tests/lint: demonstrate wrong syshdr check in strict bool mode

tests/lint: sync comment with reality

lint: in strict bool mode, check function arguments more strictly

When a system header defined the constant FALSE = 0, that constant could
be passed as a bool argument. On the other hand, the constant TRUE = 1
could not be passed in the same way. Remove this inconsistency.

tests/lint: extend tests for type mismatch in strict bool mode

Seen in games/gomoku when calling curses functions.

lint: fix wrong error in strict bool mode in condition with comma

For the result of the comma operator, it doesn't matter whether the
comma itself comes from a system header or not. Instead, it's the main
operator of the right operand.

Since 2021-11-16.

lint: clean up lex.c

Rename 'struct kwtab' to 'struct keyword' since a single keyword is not
a whole keyword table.

Sync comment for lex_name with reality: sbuf_t no longer contains the
hash value.

Remove redundant tests for EOF, as EOF is neither a space nor a digit
nor an xdigit.

No functional change.

tests/lint: remove false assumptions from comments

https://stackoverflow.com/q/65868752

tests/lint: one comment per expected diagnostic

This makes it possible to check for diagnostics that contain commas.

lint: improve introduction of test d_c99_bool_strict_syshdr

lint: explain why !finite(x) is not allowed in strict bool mode

lint: apply strict bool mode to lex.c

There are 2 remaining expressions:

In line 244, !(kw->kw_deco & deco) is a bitwise and. This is already
allowed for enums, it needs to be allowed for arbitrary integer
expressions as well. This covers the many places where plain integers
are used for bit fields, together with #define. This pattern is not as
typesafe as using enums, still it is common practice.

In line 769, the expression !finite(f) is a legitimate use of a function
that has return type int for traditional reasons. It's the same as for
ferror.

There are several other functions like unlink, open or strcmp that have
return type int as well, but with a different meaning. It is not yet
clear what the best way is to handle these different meanings. Having
to write finite(f) == 0 in strict bool mode doesn't look idiomatic, on
the other hand, !strcmp(s1, s2) is exactly the pattern that strict bool
mode wants to avoid.

lint: fix error message for relaxed bool operations in system headers

In strict mode, allowing 1 as bool constant expression is probably not
needed in practice since most comparisons are != 0 instead of == 0.

Furthermore, in the expression (flags & 0x0002) == true, comparing with
true is misleading since the '==' operator can never evaluate to true in
this case.

lint: fix two wrong error messages in strict bool mode

The strict bool mode gets complicated because for system headers the
rules need to be relaxed since they cannot be changed easily, often not at all.

Still, if lint validates a program in strict bool mode, that program
must run with equal behavior regarding boolean expressions even on a
pre-C99 platform.

lint: extend test for strict bool mode and system headers

lint: allow system headers to use int as bool, even in strict bool mode

lint: add more tests for system headers in strict bool mode

lint: add quotes around placeholders for the remaining messages

Reword some of the messages slightly, exchanging brevity for clarity.

Message 138 is kept as-is, as it is not yet covered by any tests.

Message 240 is kep as-is, as it is unreachable.

lint: add quotes around placeholders in 4 messages

tests/lint: demonstrate wrong syshdr check in strict bool mode

tests/lint: sync comment with reality

lint: in strict bool mode, check function arguments more strictly

When a system header defined the constant FALSE = 0, that constant could
be passed as a bool argument. On the other hand, the constant TRUE = 1
could not be passed in the same way. Remove this inconsistency.

tests/lint: extend tests for type mismatch in strict bool mode

Seen in games/gomoku when calling curses functions.

lint: fix wrong error in strict bool mode in condition with comma

For the result of the comma operator, it doesn't matter whether the
comma itself comes from a system header or not. Instead, it's the main
operator of the right operand.

Since 2021-11-16.

lint: clean up lex.c

Rename 'struct kwtab' to 'struct keyword' since a single keyword is not
a whole keyword table.

Sync comment for lex_name with reality: sbuf_t no longer contains the
hash value.

Remove redundant tests for EOF, as EOF is neither a space nor a digit
nor an xdigit.

No functional change.

tests/lint: remove false assumptions from comments

https://stackoverflow.com/q/65868752

tests/lint: one comment per expected diagnostic

This makes it possible to check for diagnostics that contain commas.

lint: improve introduction of test d_c99_bool_strict_syshdr

lint: explain why !finite(x) is not allowed in strict bool mode

lint: apply strict bool mode to lex.c

There are 2 remaining expressions:

In line 244, !(kw->kw_deco & deco) is a bitwise and. This is already
allowed for enums, it needs to be allowed for arbitrary integer
expressions as well. This covers the many places where plain integers
are used for bit fields, together with #define. This pattern is not as
typesafe as using enums, still it is common practice.

In line 769, the expression !finite(f) is a legitimate use of a function
that has return type int for traditional reasons. It's the same as for
ferror.

There are several other functions like unlink, open or strcmp that have
return type int as well, but with a different meaning. It is not yet
clear what the best way is to handle these different meanings. Having
to write finite(f) == 0 in strict bool mode doesn't look idiomatic, on
the other hand, !strcmp(s1, s2) is exactly the pattern that strict bool
mode wants to avoid.

lint: fix error message for relaxed bool operations in system headers

In strict mode, allowing 1 as bool constant expression is probably not
needed in practice since most comparisons are != 0 instead of == 0.

Furthermore, in the expression (flags & 0x0002) == true, comparing with
true is misleading since the '==' operator can never evaluate to true in
this case.

lint: fix two wrong error messages in strict bool mode

The strict bool mode gets complicated because for system headers the
rules need to be relaxed since they cannot be changed easily, often not at all.

Still, if lint validates a program in strict bool mode, that program
must run with equal behavior regarding boolean expressions even on a
pre-C99 platform.

lint: extend test for strict bool mode and system headers

lint: allow system headers to use int as bool, even in strict bool mode

lint: add more tests for system headers in strict bool mode

lint: add quotes around placeholders in 4 messages

tests/lint: demonstrate wrong syshdr check in strict bool mode

tests/lint: sync comment with reality

lint: in strict bool mode, check function arguments more strictly

When a system header defined the constant FALSE = 0, that constant could
be passed as a bool argument. On the other hand, the constant TRUE = 1
could not be passed in the same way. Remove this inconsistency.

tests/lint: extend tests for type mismatch in strict bool mode

Seen in games/gomoku when calling curses functions.

lint: fix wrong error in strict bool mode in condition with comma

For the result of the comma operator, it doesn't matter whether the
comma itself comes from a system header or not. Instead, it's the main
operator of the right operand.

Since 2021-11-16.

lint: clean up lex.c

Rename 'struct kwtab' to 'struct keyword' since a single keyword is not
a whole keyword table.

Sync comment for lex_name with reality: sbuf_t no longer contains the
hash value.

Remove redundant tests for EOF, as EOF is neither a space nor a digit
nor an xdigit.

No functional change.

tests/lint: remove false assumptions from comments

https://stackoverflow.com/q/65868752

tests/lint: one comment per expected diagnostic

This makes it possible to check for diagnostics that contain commas.

lint: improve introduction of test d_c99_bool_strict_syshdr

lint: explain why !finite(x) is not allowed in strict bool mode

lint: apply strict bool mode to lex.c

There are 2 remaining expressions:

In line 244, !(kw->kw_deco & deco) is a bitwise and. This is already
allowed for enums, it needs to be allowed for arbitrary integer
expressions as well. This covers the many places where plain integers
are used for bit fields, together with #define. This pattern is not as
typesafe as using enums, still it is common practice.

In line 769, the expression !finite(f) is a legitimate use of a function
that has return type int for traditional reasons. It's the same as for
ferror.

There are several other functions like unlink, open or strcmp that have
return type int as well, but with a different meaning. It is not yet
clear what the best way is to handle these different meanings. Having
to write finite(f) == 0 in strict bool mode doesn't look idiomatic, on
the other hand, !strcmp(s1, s2) is exactly the pattern that strict bool
mode wants to avoid.

lint: fix error message for relaxed bool operations in system headers

In strict mode, allowing 1 as bool constant expression is probably not
needed in practice since most comparisons are != 0 instead of == 0.

Furthermore, in the expression (flags & 0x0002) == true, comparing with
true is misleading since the '==' operator can never evaluate to true in
this case.

lint: fix two wrong error messages in strict bool mode

The strict bool mode gets complicated because for system headers the
rules need to be relaxed since they cannot be changed easily, often not at all.

Still, if lint validates a program in strict bool mode, that program
must run with equal behavior regarding boolean expressions even on a
pre-C99 platform.

lint: extend test for strict bool mode and system headers

lint: allow system headers to use int as bool, even in strict bool mode

lint: add more tests for system headers in strict bool mode

tests/lint: demonstrate wrong syshdr check in strict bool mode

tests/lint: sync comment with reality

lint: in strict bool mode, check function arguments more strictly

When a system header defined the constant FALSE = 0, that constant could
be passed as a bool argument. On the other hand, the constant TRUE = 1
could not be passed in the same way. Remove this inconsistency.

tests/lint: extend tests for type mismatch in strict bool mode

Seen in games/gomoku when calling curses functions.

lint: fix wrong error in strict bool mode in condition with comma

For the result of the comma operator, it doesn't matter whether the
comma itself comes from a system header or not. Instead, it's the main
operator of the right operand.

Since 2021-11-16.

lint: clean up lex.c

Rename 'struct kwtab' to 'struct keyword' since a single keyword is not
a whole keyword table.

Sync comment for lex_name with reality: sbuf_t no longer contains the
hash value.

Remove redundant tests for EOF, as EOF is neither a space nor a digit
nor an xdigit.

No functional change.

tests/lint: remove false assumptions from comments

https://stackoverflow.com/q/65868752

tests/lint: one comment per expected diagnostic

This makes it possible to check for diagnostics that contain commas.

lint: improve introduction of test d_c99_bool_strict_syshdr

lint: explain why !finite(x) is not allowed in strict bool mode

lint: apply strict bool mode to lex.c

There are 2 remaining expressions:

In line 244, !(kw->kw_deco & deco) is a bitwise and. This is already
allowed for enums, it needs to be allowed for arbitrary integer
expressions as well. This covers the many places where plain integers
are used for bit fields, together with #define. This pattern is not as
typesafe as using enums, still it is common practice.

In line 769, the expression !finite(f) is a legitimate use of a function
that has return type int for traditional reasons. It's the same as for
ferror.

There are several other functions like unlink, open or strcmp that have
return type int as well, but with a different meaning. It is not yet
clear what the best way is to handle these different meanings. Having
to write finite(f) == 0 in strict bool mode doesn't look idiomatic, on
the other hand, !strcmp(s1, s2) is exactly the pattern that strict bool
mode wants to avoid.

lint: fix error message for relaxed bool operations in system headers

In strict mode, allowing 1 as bool constant expression is probably not
needed in practice since most comparisons are != 0 instead of == 0.

Furthermore, in the expression (flags & 0x0002) == true, comparing with
true is misleading since the '==' operator can never evaluate to true in
this case.

lint: fix two wrong error messages in strict bool mode

The strict bool mode gets complicated because for system headers the
rules need to be relaxed since they cannot be changed easily, often not at all.

Still, if lint validates a program in strict bool mode, that program
must run with equal behavior regarding boolean expressions even on a
pre-C99 platform.

lint: extend test for strict bool mode and system headers

lint: allow system headers to use int as bool, even in strict bool mode

lint: add more tests for system headers in strict bool mode

tests/lint: sync comment with reality

lint: in strict bool mode, check function arguments more strictly

When a system header defined the constant FALSE = 0, that constant could
be passed as a bool argument. On the other hand, the constant TRUE = 1
could not be passed in the same way. Remove this inconsistency.

tests/lint: extend tests for type mismatch in strict bool mode

Seen in games/gomoku when calling curses functions.

lint: fix wrong error in strict bool mode in condition with comma

For the result of the comma operator, it doesn't matter whether the
comma itself comes from a system header or not. Instead, it's the main
operator of the right operand.

Since 2021-11-16.

lint: clean up lex.c

Rename 'struct kwtab' to 'struct keyword' since a single keyword is not
a whole keyword table.

Sync comment for lex_name with reality: sbuf_t no longer contains the
hash value.

Remove redundant tests for EOF, as EOF is neither a space nor a digit
nor an xdigit.

No functional change.

tests/lint: remove false assumptions from comments

https://stackoverflow.com/q/65868752

tests/lint: one comment per expected diagnostic

This makes it possible to check for diagnostics that contain commas.

lint: improve introduction of test d_c99_bool_strict_syshdr

lint: explain why !finite(x) is not allowed in strict bool mode

lint: apply strict bool mode to lex.c

There are 2 remaining expressions:

In line 244, !(kw->kw_deco & deco) is a bitwise and. This is already
allowed for enums, it needs to be allowed for arbitrary integer
expressions as well. This covers the many places where plain integers
are used for bit fields, together with #define. This pattern is not as
typesafe as using enums, still it is common practice.

In line 769, the expression !finite(f) is a legitimate use of a function
that has return type int for traditional reasons. It's the same as for
ferror.

There are several other functions like unlink, open or strcmp that have
return type int as well, but with a different meaning. It is not yet
clear what the best way is to handle these different meanings. Having
to write finite(f) == 0 in strict bool mode doesn't look idiomatic, on
the other hand, !strcmp(s1, s2) is exactly the pattern that strict bool
mode wants to avoid.

lint: fix error message for relaxed bool operations in system headers

In strict mode, allowing 1 as bool constant expression is probably not
needed in practice since most comparisons are != 0 instead of == 0.

Furthermore, in the expression (flags & 0x0002) == true, comparing with
true is misleading since the '==' operator can never evaluate to true in
this case.

lint: fix two wrong error messages in strict bool mode

The strict bool mode gets complicated because for system headers the
rules need to be relaxed since they cannot be changed easily, often not at all.

Still, if lint validates a program in strict bool mode, that program
must run with equal behavior regarding boolean expressions even on a
pre-C99 platform.

lint: extend test for strict bool mode and system headers

lint: allow system headers to use int as bool, even in strict bool mode

lint: add more tests for system headers in strict bool mode

lint: fix wrong error in strict bool mode in condition with comma

For the result of the comma operator, it doesn't matter whether the
comma itself comes from a system header or not. Instead, it's the main
operator of the right operand.

Since 2021-11-16.

lint: clean up lex.c

Rename 'struct kwtab' to 'struct keyword' since a single keyword is not
a whole keyword table.

Sync comment for lex_name with reality: sbuf_t no longer contains the
hash value.

Remove redundant tests for EOF, as EOF is neither a space nor a digit
nor an xdigit.

No functional change.

tests/lint: remove false assumptions from comments

https://stackoverflow.com/q/65868752

tests/lint: one comment per expected diagnostic

This makes it possible to check for diagnostics that contain commas.

lint: improve introduction of test d_c99_bool_strict_syshdr

lint: explain why !finite(x) is not allowed in strict bool mode

lint: apply strict bool mode to lex.c

There are 2 remaining expressions:

In line 244, !(kw->kw_deco & deco) is a bitwise and. This is already
allowed for enums, it needs to be allowed for arbitrary integer
expressions as well. This covers the many places where plain integers
are used for bit fields, together with #define. This pattern is not as
typesafe as using enums, still it is common practice.

In line 769, the expression !finite(f) is a legitimate use of a function
that has return type int for traditional reasons. It's the same as for
ferror.

There are several other functions like unlink, open or strcmp that have
return type int as well, but with a different meaning. It is not yet
clear what the best way is to handle these different meanings. Having
to write finite(f) == 0 in strict bool mode doesn't look idiomatic, on
the other hand, !strcmp(s1, s2) is exactly the pattern that strict bool
mode wants to avoid.

lint: fix error message for relaxed bool operations in system headers

In strict mode, allowing 1 as bool constant expression is probably not
needed in practice since most comparisons are != 0 instead of == 0.

Furthermore, in the expression (flags & 0x0002) == true, comparing with
true is misleading since the '==' operator can never evaluate to true in
this case.

lint: fix two wrong error messages in strict bool mode

The strict bool mode gets complicated because for system headers the
rules need to be relaxed since they cannot be changed easily, often not at all.

Still, if lint validates a program in strict bool mode, that program
must run with equal behavior regarding boolean expressions even on a
pre-C99 platform.

lint: extend test for strict bool mode and system headers

lint: allow system headers to use int as bool, even in strict bool mode

lint: add more tests for system headers in strict bool mode

lint: fix wrong error in strict bool mode in condition with comma

For the result of the comma operator, it doesn't matter whether the
comma itself comes from a system header or not. Instead, it's the main
operator of the right operand.

Since 2021-11-16.

lint: clean up lex.c

Rename 'struct kwtab' to 'struct keyword' since a single keyword is not
a whole keyword table.

Sync comment for lex_name with reality: sbuf_t no longer contains the
hash value.

Remove redundant tests for EOF, as EOF is neither a space nor a digit
nor an xdigit.

No functional change.

tests/lint: remove false assumptions from comments

https://stackoverflow.com/q/65868752

tests/lint: one comment per expected diagnostic

This makes it possible to check for diagnostics that contain commas.

lint: improve introduction of test d_c99_bool_strict_syshdr

lint: explain why !finite(x) is not allowed in strict bool mode

lint: apply strict bool mode to lex.c

There are 2 remaining expressions:

In line 244, !(kw->kw_deco & deco) is a bitwise and. This is already
allowed for enums, it needs to be allowed for arbitrary integer
expressions as well. This covers the many places where plain integers
are used for bit fields, together with #define. This pattern is not as
typesafe as using enums, still it is common practice.

In line 769, the expression !finite(f) is a legitimate use of a function
that has return type int for traditional reasons. It's the same as for
ferror.

There are several other functions like unlink, open or strcmp that have
return type int as well, but with a different meaning. It is not yet
clear what the best way is to handle these different meanings. Having
to write finite(f) == 0 in strict bool mode doesn't look idiomatic, on
the other hand, !strcmp(s1, s2) is exactly the pattern that strict bool
mode wants to avoid.

lint: fix error message for relaxed bool operations in system headers

In strict mode, allowing 1 as bool constant expression is probably not
needed in practice since most comparisons are != 0 instead of == 0.

Furthermore, in the expression (flags & 0x0002) == true, comparing with
true is misleading since the '==' operator can never evaluate to true in
this case.

lint: fix two wrong error messages in strict bool mode

The strict bool mode gets complicated because for system headers the
rules need to be relaxed since they cannot be changed easily, often not at all.

Still, if lint validates a program in strict bool mode, that program
must run with equal behavior regarding boolean expressions even on a
pre-C99 platform.

lint: extend test for strict bool mode and system headers

lint: allow system headers to use int as bool, even in strict bool mode

lint: add more tests for system headers in strict bool mode

tests/lint: one comment per expected diagnostic

This makes it possible to check for diagnostics that contain commas.

lint: improve introduction of test d_c99_bool_strict_syshdr

lint: explain why !finite(x) is not allowed in strict bool mode

lint: apply strict bool mode to lex.c

There are 2 remaining expressions:

In line 244, !(kw->kw_deco & deco) is a bitwise and. This is already
allowed for enums, it needs to be allowed for arbitrary integer
expressions as well. This covers the many places where plain integers
are used for bit fields, together with #define. This pattern is not as
typesafe as using enums, still it is common practice.

In line 769, the expression !finite(f) is a legitimate use of a function
that has return type int for traditional reasons. It's the same as for
ferror.

There are several other functions like unlink, open or strcmp that have
return type int as well, but with a different meaning. It is not yet
clear what the best way is to handle these different meanings. Having
to write finite(f) == 0 in strict bool mode doesn't look idiomatic, on
the other hand, !strcmp(s1, s2) is exactly the pattern that strict bool
mode wants to avoid.

lint: fix error message for relaxed bool operations in system headers

In strict mode, allowing 1 as bool constant expression is probably not
needed in practice since most comparisons are != 0 instead of == 0.

Furthermore, in the expression (flags & 0x0002) == true, comparing with
true is misleading since the '==' operator can never evaluate to true in
this case.

lint: fix two wrong error messages in strict bool mode

The strict bool mode gets complicated because for system headers the
rules need to be relaxed since they cannot be changed easily, often not at all.

Still, if lint validates a program in strict bool mode, that program
must run with equal behavior regarding boolean expressions even on a
pre-C99 platform.

lint: extend test for strict bool mode and system headers

lint: allow system headers to use int as bool, even in strict bool mode

lint: add more tests for system headers in strict bool mode

lint: improve introduction of test d_c99_bool_strict_syshdr

lint: explain why !finite(x) is not allowed in strict bool mode

lint: apply strict bool mode to lex.c

There are 2 remaining expressions:

In line 244, !(kw->kw_deco & deco) is a bitwise and. This is already
allowed for enums, it needs to be allowed for arbitrary integer
expressions as well. This covers the many places where plain integers
are used for bit fields, together with #define. This pattern is not as
typesafe as using enums, still it is common practice.

In line 769, the expression !finite(f) is a legitimate use of a function
that has return type int for traditional reasons. It's the same as for
ferror.

There are several other functions like unlink, open or strcmp that have
return type int as well, but with a different meaning. It is not yet
clear what the best way is to handle these different meanings. Having
to write finite(f) == 0 in strict bool mode doesn't look idiomatic, on
the other hand, !strcmp(s1, s2) is exactly the pattern that strict bool
mode wants to avoid.

lint: fix error message for relaxed bool operations in system headers

In strict mode, allowing 1 as bool constant expression is probably not
needed in practice since most comparisons are != 0 instead of == 0.

Furthermore, in the expression (flags & 0x0002) == true, comparing with
true is misleading since the '==' operator can never evaluate to true in
this case.

lint: fix two wrong error messages in strict bool mode

The strict bool mode gets complicated because for system headers the
rules need to be relaxed since they cannot be changed easily, often not at all.

Still, if lint validates a program in strict bool mode, that program
must run with equal behavior regarding boolean expressions even on a
pre-C99 platform.

lint: extend test for strict bool mode and system headers

lint: allow system headers to use int as bool, even in strict bool mode

lint: add more tests for system headers in strict bool mode

lint: allow system headers to use int as bool, even in strict bool mode

lint: add more tests for system headers in strict bool mode