The NetBSD Project

CVS log for src/tests/usr.bin/xlint/lint1/Attic/d_c99_bool_strict.exp

[BACK] Up to [cvs.NetBSD.org] / src / tests / usr.bin / xlint / lint1

Request diff between arbitrary revisions


Default branch: MAIN


Revision 1.34, Fri Jun 17 20:23:58 2022 UTC (7 months, 2 weeks ago) by rillig
Branch: MAIN
CVS Tags: HEAD
Changes since 1.33: +0 -0 lines
FILE REMOVED

tests/lint: remove .exp files, as they have become redundant

Now that each lint1 test lists all generated diagnostics as 'expect'
comments, the information from the .exp files is no longer needed.  The
only information that gets lost is the order of the diagnostics, which
is mostly relevant for paired messages like 'inconsistent definition' +
'previous definition was here'.

Revision 1.33 / (download) - annotate - [select for diffs], Sat Jan 15 14:22:03 2022 UTC (12 months, 3 weeks ago) by rillig
Branch: MAIN
Changes since 1.32: +172 -172 lines
Diff to previous 1.32 (colored)

tests/lint: expect complete messages in feature tests

Previously, the tests contained many comments like /* expect: 123 */,
which were useless to a casual reader since nobody is expected to learn
lint's message IDs by heart.  Replace these with the complete
diagnostics, to show what lint is complaining about.

The tests named msg_*.c have been left unmodified since they mention the
full message text in their header comment.

No functional change.

Revision 1.32 / (download) - annotate - [select for diffs], Tue Nov 16 21:01:06 2021 UTC (14 months, 3 weeks ago) by rillig
Branch: MAIN
Changes since 1.31: +4 -0 lines
Diff to previous 1.31 (colored)

lint: fix check for function calls in strict bool mode

Previously, if a function call occurred in the controlling expression,
its return type could be any scalar, not just bool.  This was against
the goal of strict bool mode, which makes bool a separate and
incompabile type to all other types.  For example, it would allow
controlling expressions like 'strcmp(a, b)' without the usual '!= 0',
but only if at least one of 'a' and 'b' came from a macro definition
from a system header.

The fix is that the decision of whether the type of the controlling
expression may be scalar is no longer based on the operand types but on
the main operator of the controlling expression.

Revision 1.31 / (download) - annotate - [select for diffs], Tue Nov 16 18:27:04 2021 UTC (14 months, 3 weeks ago) by rillig
Branch: MAIN
Changes since 1.30: +0 -2 lines
Diff to previous 1.30 (colored)

lint: fix wrong error message in strict bool mode

This fix only affects the last token before a macro, as well as the last
token in the expanded macro.

Revision 1.30 / (download) - annotate - [select for diffs], Tue Nov 16 06:55:03 2021 UTC (14 months, 3 weeks ago) by rillig
Branch: MAIN
Changes since 1.29: +6 -5 lines
Diff to previous 1.29 (colored)

tests/lint: explain the missing error message in strict bool mode

There are 2 separate bugs that lead to the missing error message.

The first bug is that when parsing a name, the information about whether
that name comes from a system header is not properly recorded for the
last token before switching from or to a system header.

The second bug is that for determining whether the type of a function
call expression is relaxed, the types of the function call arguments are
taken into account, even though the type only depends on the function
itself.  The same idea applies to the operators '<<' and '>>', as their
result type only depends on the left operand, at least since C90.

Revision 1.29 / (download) - annotate - [select for diffs], Sun Nov 14 11:23:52 2021 UTC (14 months, 3 weeks ago) by rillig
Branch: MAIN
Changes since 1.28: +5 -0 lines
Diff to previous 1.28 (colored)

tests/lint: demonstrate missing errors for strict bool mode

Seen in bin/echo/echo.c.

Revision 1.28 / (download) - annotate - [select for diffs], Sat Aug 14 12:46:24 2021 UTC (17 months, 3 weeks ago) by rillig
Branch: MAIN
Changes since 1.27: +4 -4 lines
Diff to previous 1.27 (colored)

lint: allow initialization of struct with constant member

The operator INIT, just like RETURN and FARG, initializes an object with
an expression.  The target object of such an initialization may be a
struct with constant members.

The operator ASSIGN, on the other hand, is entirely different.  It
overwrites the existing value of the object, and this is not allowed for
structs that have a constant member.  Therefore it was wrong to use the
operator ASSIGN for initialization.

Revision 1.27 / (download) - annotate - [select for diffs], Sun Jul 4 07:09:39 2021 UTC (19 months ago) by rillig
Branch: MAIN
Changes since 1.26: +1 -0 lines
Diff to previous 1.26 (colored)

lint: in strict bool mode, continue after error message

If a controlling expression is not of type bool but of any other scalar
type, keep the expression.  Its value is still useful for control flow
analysis.

This prevents an assertion failure when running lint on the generated
scan.c, which contains a "while (1)" that does not stem from a system
header.  If it did, lint would accept it, see tn_from_system_header. But
"scan.c" is not considered a system header.  Maybe lint's definition of
a system header needs to be revisited.

After fixing this, there is another assertion failure though, so scan.c
is not yet ready to be inspected by lint.

Revision 1.26 / (download) - annotate - [select for diffs], Fri Jul 2 18:52:20 2021 UTC (19 months ago) by rillig
Branch: MAIN
Changes since 1.25: +92 -92 lines
Diff to previous 1.25 (colored)

lint: no special check for unary operators in strict bool mode

All interesting constellations regarding unary operators are already
covered by the simple model from ops.def.

No functional change.

Revision 1.25 / (download) - annotate - [select for diffs], Fri Apr 9 20:12:00 2021 UTC (21 months, 4 weeks ago) by rillig
Branch: MAIN
CVS Tags: cjep_sun2x-base1, cjep_sun2x-base, cjep_sun2x, cjep_staticlib_x-base1, cjep_staticlib_x-base, cjep_staticlib_x
Changes since 1.24: +3 -3 lines
Diff to previous 1.24 (colored)

lint: quote placeholders in messages for unused variables

Revision 1.24 / (download) - annotate - [select for diffs], Fri Apr 2 22:41:54 2021 UTC (22 months ago) by rillig
Branch: MAIN
Changes since 1.23: +2 -2 lines
Diff to previous 1.23 (colored)

lint: reword message about constant argument to '!'

In the other messages, operators are typically written in their literal
form as well.  Using single quotes disambiguates them from normal
punctuation.

Revision 1.23 / (download) - annotate - [select for diffs], Sun Mar 21 20:44:59 2021 UTC (22 months, 2 weeks ago) by rillig
Branch: MAIN
Changes since 1.22: +146 -146 lines
Diff to previous 1.22 (colored)

lint: prefix error messages with 'error:'

This makes it easier to find these errors in the build logs.

Revision 1.22 / (download) - annotate - [select for diffs], Sun Mar 21 14:36:59 2021 UTC (22 months, 2 weeks ago) by rillig
Branch: MAIN
Changes since 1.21: +1 -0 lines
Diff to previous 1.21 (colored)

lint: fix reachability computation in if statements

Previously, only loop statements were considered for reachability.  This
ignored the possibility of an early return in an if statement, or
unreachable branches.

Revision 1.21 / (download) - annotate - [select for diffs], Sun Mar 21 14:12:46 2021 UTC (22 months, 2 weeks ago) by rillig
Branch: MAIN
Changes since 1.20: +147 -147 lines
Diff to previous 1.20 (colored)

tests/lint: sync redundant documentation in test for strict bool mode

Revision 1.20 / (download) - annotate - [select for diffs], Sat Mar 20 17:18:50 2021 UTC (22 months, 2 weeks ago) by rillig
Branch: MAIN
Changes since 1.19: +2 -0 lines
Diff to previous 1.19 (colored)

lint: in strict bool mode, check initialization as well

C99 6.7.8p11 says for initialization that "the same type constraints and
conversions as for simple assignments apply", so actually apply them.
(I had just forgotten this "operator" when I first implemented strict
bool mode.)

Revision 1.19 / (download) - annotate - [select for diffs], Sat Feb 20 18:55:10 2021 UTC (23 months, 2 weeks ago) by rillig
Branch: MAIN
Changes since 1.18: +0 -1 lines
Diff to previous 1.18 (colored)

lint: do not warn about 'do { ... } while (false)' in strict bool mode

Revision 1.18 / (download) - annotate - [select for diffs], Sat Feb 20 18:52:58 2021 UTC (23 months, 2 weeks ago) by rillig
Branch: MAIN
Changes since 1.17: +2 -0 lines
Diff to previous 1.17 (colored)

lint: add test for 'do { ... } while (false)' in strict bool mode

Right now, this variant of the popular macro pattern is flagged as
needing a /*CONSTCOND*/ annotation.  As with 'do { ... } while (0)',
there is nothing wrong with this pattern, therefore there should be no
warning.

Revision 1.17 / (download) - annotate - [select for diffs], Sat Feb 20 18:49:26 2021 UTC (23 months, 2 weeks ago) by rillig
Branch: MAIN
Changes since 1.16: +15 -0 lines
Diff to previous 1.16 (colored)

lint: enable heuristics in test for strict bool mode

This is a preparation for allowing 'do { ... } while (false)', in
addition to the commonly used 'do { ... } while (0)', without declaring
the controlling expression /*CONSTCOND*/.

Revision 1.16 / (download) - annotate - [select for diffs], Sat Feb 20 18:02:58 2021 UTC (23 months, 2 weeks ago) by rillig
Branch: MAIN
Changes since 1.15: +1 -0 lines
Diff to previous 1.15 (colored)

lint: add test for using a bool as array index in strict bool mode

Revision 1.15 / (download) - annotate - [select for diffs], Sun Jan 17 23:00:41 2021 UTC (2 years ago) by rillig
Branch: MAIN
Changes since 1.14: +0 -3 lines
Diff to previous 1.14 (colored)

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

Revision 1.14 / (download) - annotate - [select for diffs], Sun Jan 17 21:19:06 2021 UTC (2 years ago) by rillig
Branch: MAIN
Changes since 1.13: +3 -0 lines
Diff to previous 1.13 (colored)

lint: add test for macro from system header in strict bool mode

Seen in usr.bin/make/meta.c:1670: FD_ZERO(&readfds).  These macros
cannot be fixed since system headers must not include <stdbool.h>.
Therefore INT constants should be accepted as controlling expressions as
well.

Revision 1.13 / (download) - annotate - [select for diffs], Sun Jan 17 13:50:33 2021 UTC (2 years ago) by rillig
Branch: MAIN
Changes since 1.12: +5 -2 lines
Diff to previous 1.12 (colored)

lint: in strict bool mode, don't treat bool as arithmetic type

Revision 1.12 / (download) - annotate - [select for diffs], Sun Jan 17 13:15:03 2021 UTC (2 years ago) by rillig
Branch: MAIN
Changes since 1.11: +1 -1 lines
Diff to previous 1.11 (colored)

lint: explain failing test case in strict bool mode

Revision 1.11 / (download) - annotate - [select for diffs], Sun Jan 17 11:32:06 2021 UTC (2 years ago) by rillig
Branch: MAIN
Changes since 1.10: +1 -0 lines
Diff to previous 1.10 (colored)

lint: demonstrate wrong error message in strict bool mode

Revision 1.10 / (download) - annotate - [select for diffs], Sat Jan 16 18:58:21 2021 UTC (2 years ago) by rillig
Branch: MAIN
Changes since 1.9: +1 -1 lines
Diff to previous 1.9 (colored)

lint: simplify typeok_strict_bool_compatible

Revision 1.9 / (download) - annotate - [select for diffs], Sat Jan 16 18:48:52 2021 UTC (2 years ago) by rillig
Branch: MAIN
Changes since 1.8: +1 -0 lines
Diff to previous 1.8 (colored)

lint: add missing warning for bool() == int

Revision 1.8 / (download) - annotate - [select for diffs], Sat Jan 16 16:03:47 2021 UTC (2 years ago) by rillig
Branch: MAIN
Changes since 1.7: +28 -2 lines
Diff to previous 1.7 (colored)

lint: in strict bool mode, integer constants do not have type bool

Previously, lint1 allowed integer constants such as 0 and 1 to be used
as bool constants.  This was only half-baked since after fixing all
error messages from that strict mode, there may still be integer
literals in the code that should be replaced with true or false.  This
would stop a migration from int to bool in the middle, leaving
inconsistent code around.

To find the remaining type inconsistencies, treat integers and bool as
completely incompatible, even for compile time constants.

Revision 1.7 / (download) - annotate - [select for diffs], Sat Jan 16 15:02:11 2021 UTC (2 years ago) by rillig
Branch: MAIN
Changes since 1.6: +117 -104 lines
Diff to previous 1.6 (colored)

lint: prepare to make strict bool mode even stricter

Currently, strict bool mode still allows integer constant expressions to
be converted implicitly to bool.  This is something that other languages
such as Go, Java, C#, Pascal don't allow.

By providing a custom implementation of <stdbool.h> that defines false
and true to custom bool constant identifiers, lint will cover these
cases as well.

To prepare for this, reword the rules and restructure the tests in
d_c99_bool_strict.c.

Revision 1.6 / (download) - annotate - [select for diffs], Fri Jan 15 23:15:28 2021 UTC (2 years ago) by rillig
Branch: MAIN
Changes since 1.5: +1 -0 lines
Diff to previous 1.5 (colored)

lint: add test for bool bit fields as operands of '|'

Revision 1.5 / (download) - annotate - [select for diffs], Fri Jan 15 22:07:54 2021 UTC (2 years ago) by rillig
Branch: MAIN
Changes since 1.4: +0 -2 lines
Diff to previous 1.4 (colored)

lint: in strict bool mode, allow bool as operands of the comma operator

Revision 1.4 / (download) - annotate - [select for diffs], Fri Jan 15 22:04:27 2021 UTC (2 years ago) by rillig
Branch: MAIN
Changes since 1.3: +2 -0 lines
Diff to previous 1.3 (colored)

lint: demonstrate wrong message for comma operator

Revision 1.3 / (download) - annotate - [select for diffs], Tue Jan 12 20:42:01 2021 UTC (2 years ago) by rillig
Branch: MAIN
Changes since 1.2: +103 -6 lines
Diff to previous 1.2 (colored)

lint: add new check for strict bool mode

In strict bool mode, bool is considered incompatible with all other
scalar types, just as in Java, C#, Pascal.

The controlling expressions in if statements, while loops, for loops and
the '?:' operator must be of type bool.  The logical operators work on
bool instead of int, the bitwise operators accept both integer and bool.
The arithmetic operators don't accept bool.

Since <stdbool.h> implements bool using C preprocessor macros instead of
predefining the identifiers "true" and "false", the integer constants 0
and 1 may be used in all contexts that require a bool expression.
Except from these, no implicit conversion between bool and scalar types
is allowed.

See usr.bin/tests/xlint/lint1/d_c99_bool_strict.c for more details.

The command line option -T has been chosen because all obvious choices
(-b or -B for bool, -s or -S for strict) are already in use.  The -T may
stand for "types are checked strictly".

The default behavior of lint doesn't change.  The strict bool check is
purely optional.

An example program for strict bool mode is usr.bin/make, which has been
using explicit comparisons such as p != NULL, ch != '\0' or n > 0 in
most places for a long time now, even before the refactoring in 2020.

Revision 1.2 / (download) - annotate - [select for diffs], Mon Jan 11 00:28:28 2021 UTC (2 years ago) by rillig
Branch: MAIN
Changes since 1.1: +6 -2 lines
Diff to previous 1.1 (colored)

lint: extend test for strict _Bool handling

There is no danger in allowing (flags & FLAG) as a controlling
expression, provided that it is immediately compared to zero, such as in
an if statement or as the operand of a logical operator.

Revision 1.1 / (download) - annotate - [select for diffs], Sun Jan 10 17:43:46 2021 UTC (2 years ago) by rillig
Branch: MAIN

lint: add test for treating _Bool as non-scalar type

This strict mode is not yet implemented.  The plan is to use it for
usr.bin/make, to get rid of the many possible variants of defining the
Boolean type in make.h.  These variants did find some bugs, but not
reliably so.  Using static analysis seems more promising for this.

In an early stage of developing this test, lint1 crashed in the enum
definition in line 213, where the node for the '?:' had been NULL.  This
can happen in other situations as well, such as with syntax errors, but
these should be rare, as lint is usually only run if the compiler has
accepted the source code.  Still, there should not be any assertion
failures while running lint1.

This form allows you to request diff's between any two revisions of a file. You may select a symbolic revision name using the selection box or you may type in a numeric name using the type-in text box.




CVSweb <webmaster@jp.NetBSD.org>