The NetBSD Project

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

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

Request diff between arbitrary revisions


Default branch: MAIN


Revision 1.18, Fri Jun 17 20:23:58 2022 UTC (21 months, 4 weeks ago) by rillig
Branch: MAIN
CVS Tags: HEAD
Changes since 1.17: +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.17 / (download) - annotate - [select for diffs], Sat Jun 11 14:17:33 2022 UTC (22 months ago) by rillig
Branch: MAIN
Changes since 1.16: +2 -0 lines
Diff to previous 1.16 (colored)

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

Revision 1.16 / (download) - annotate - [select for diffs], Thu May 19 17:24:14 2022 UTC (22 months, 4 weeks ago) by rillig
Branch: MAIN
Changes since 1.15: +1 -0 lines
Diff to previous 1.15 (colored)

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.

Revision 1.15 / (download) - annotate - [select for diffs], Thu May 19 17:10:50 2022 UTC (22 months, 4 weeks ago) by rillig
Branch: MAIN
Changes since 1.14: +1 -0 lines
Diff to previous 1.14 (colored)

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

Seen in games/gomoku when calling curses functions.

Revision 1.14 / (download) - annotate - [select for diffs], Wed Dec 22 15:36:37 2021 UTC (2 years, 3 months ago) by rillig
Branch: MAIN
Changes since 1.13: +0 -1 lines
Diff to previous 1.13 (colored)

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.

Revision 1.13 / (download) - annotate - [select for diffs], Wed Dec 22 15:20:08 2021 UTC (2 years, 3 months ago) by rillig
Branch: MAIN
Changes since 1.12: +1 -0 lines
Diff to previous 1.12 (colored)

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.

Revision 1.12 / (download) - annotate - [select for diffs], Tue Dec 21 16:25:14 2021 UTC (2 years, 3 months ago) by rillig
Branch: MAIN
Changes since 1.11: +6 -6 lines
Diff to previous 1.11 (colored)

tests/lint: remove false assumptions from comments

https://stackoverflow.com/q/65868752

Revision 1.11 / (download) - annotate - [select for diffs], Sat Aug 14 12:46:24 2021 UTC (2 years, 8 months ago) by rillig
Branch: MAIN
Changes since 1.10: +1 -1 lines
Diff to previous 1.10 (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.10 / (download) - annotate - [select for diffs], Tue Aug 3 18:44:33 2021 UTC (2 years, 8 months ago) by rillig
Branch: MAIN
Changes since 1.9: +1 -1 lines
Diff to previous 1.9 (colored)

lint: add quotes around placeholder in message 214

function '%s' expects to return value

Revision 1.9 / (download) - annotate - [select for diffs], Sun Mar 21 20:44:59 2021 UTC (3 years 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.8: +5 -5 lines
Diff to previous 1.8 (colored)

lint: prefix error messages with 'error:'

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

Revision 1.8 / (download) - annotate - [select for diffs], Sun Jan 24 09:18:42 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.7: +6 -6 lines
Diff to previous 1.7 (colored)

lint: improve introduction of test d_c99_bool_strict_syshdr

Revision 1.7 / (download) - annotate - [select for diffs], Sun Jan 24 07:58:48 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.6: +3 -2 lines
Diff to previous 1.6 (colored)

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

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

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.

Revision 1.5 / (download) - annotate - [select for diffs], Sat Jan 23 22:34:01 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.4: +0 -3 lines
Diff to previous 1.4 (colored)

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.

Revision 1.4 / (download) - annotate - [select for diffs], Sat Jan 23 22:20:18 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.3: +0 -2 lines
Diff to previous 1.3 (colored)

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.

Revision 1.3 / (download) - annotate - [select for diffs], Sat Jan 23 19:03:55 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.2: +8 -5 lines
Diff to previous 1.2 (colored)

lint: extend test for strict bool mode and system headers

Revision 1.2 / (download) - annotate - [select for diffs], Sun Jan 17 23:04:09 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.1: +0 -1 lines
Diff to previous 1.1 (colored)

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

Revision 1.1 / (download) - annotate - [select for diffs], Sun Jan 17 23:00:41 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN

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

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>