| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* delay 'empty character constant' warning to phase 5
|
|
Now, diagnostic messages are prepended with the source path.
But if the problem comes from a file included directly from
the command line like:
sparse -include some-buggy-file.c
the prepended message will be:
(null): note: in included file ...
because there isn't a source path yet.
So, initialize the source path to "command-line".
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
A subset of C syntax regarding character constants is:
char-constant:
' c-char-sequence '
c-char-sequence:
char
c-char-sequence char
In short, when tokenized, a character constant must have at least
one character between the quotes. Consequently, sparse will
issue an error on empty character constants (unlike GCC).
However, sparse issues the error during tokenization (phase 3),
before preprocessing directives are handled (phase 4).
This means that code like:
#if 0
... ''
#endif
will throw an error although the corresponding code is discarded.
Fix this by
1) silently accept empty char constants during tokenization
2) issue the diagnostic only when escape sequences are handled.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The function predefine() and its variants are only valid
if they define a single-token value.
Add a testcase for this.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
It seems that some system libraries expect __STDC_HOSTED__ to
be always defined.
So, teach sparse the options flags -f[no-]{hosted,freestanding}
and define __STDC_HOSTED__ accordingly.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Add the trivial methods for the expansion of these macros with:
c_alignas, c_alignof, c_generic_selections and c_static_assert.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The support for these builtin macros is incoming.
So, add some testcases for them.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The presence of preprocessor directives within the arguments
of a macro invocation is Undefined Behaviour but most of
these directives, like the conditionals, are well-defined
and harmless.
OTOH, the redefinition of a macro during its own expansion makes
much less sense. However, it can be given a reasonable meaning:
* use the initial definition for the macro body
* use the new defintion for its arguments, in text order.
It's what gcc & clang do but Sparse can't handle this
because, during the expansion, a reference to the initial
macro's body is not kept. What is used instead is what is
currently associated with the macro.
Fix this by using the body associated with the macro at
the time of its invocation.
Testcase-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
During macro expansion, Sparse doesn't strip newlines from
the arguments as required by 6.10.3p10 and done by gcc & clang.
So, remove these newlines.
Note: the current behaviour may make the preprocessed output
more readable (and so may be considered as a feature).
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The presence of preprocessor directives within the arguments
of a macro invocation is Undefined Behaviour [6.10.3p11].
However, conditional directives are harmless here and are
useful (and commonly used in the kernel).
So, relax the warning by restricting it to non-conditional
directives.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The presence of preprocessor directives within the arguments
of a macro invocation is Undefined Behaviour [6.10.3p11].
Sparse issues an error for this but most often the result is
well defined and is not a problem, processing can continue
(for example, when the directive is one of the conditional ones).
So, downgrade this sparse_error() to warning() (especially
because issuing an error message can hide those coming later).
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The predefines for INT128 were added unconditionally for
all archs but only the 64-bit ones support them.
Fix this by issuing the the predefines only on 64-bit archs.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The warning 'directive in argument list' is about macros'
arguments, not functions' ones.
Make this clearer in the warning message.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
* add predefined macros for __INTMAX_TYPE__, __INT_MAX__, ...
|
|
These are a pain. All LP64 archs use [u]int. Good.
But some LP32 archs use [u]int and some others use [u]long.
Some even use [u]int for some ABI and [u]long for some others
(bare metal).
This really need to be target-specific to be correct.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
All LP32 archs use [u]llong and all LP64 use [u]long for these
but Darwin which seems to always use [u]llong.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
All LP64 & LP32 use [u]char and [u]short for these ones.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Seems to use [u]long for all LP64 archs and [u]llong
and all LP32 ones (but OpenBSD but it seems to not defines
the corresponding macros).
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Luckily, it seems all archs use for them the same types as
size_t & ssize_t.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This allows to have a single function to output the
size, the type, the maximal value, ...
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
size_t_ctype is set to uint, ulong or ullong, depending on
the architecture (ullong is only used for LLP64).
However, when emitting '__SIZE_TYPE__', it's only compared to ulong
or uint.
Fix this by using an small helper directly using the right
struct symbol * and using builtin_typename() to output the
right type. This way we're guaranteed that '__SIZE_TYPE__'
is kept coherent with the internal type: size_t_ctype.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Now these tests should succeed and be meaningful on
all archs.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
* fixes for -dD
* add support for -dM
Luc Van Oostenryck (2):
dump-macro: break the loop at TOKEN_UNTAINT
dump-macro: simplify processing of whitespace
Ramsay Jones (5):
pre-process: suppress trailing space when dumping macros
pre-process: print macros containing # and ## correctly
pre-process: don't put spaces in macro parameter list
pre-process: print variable argument macros correctly
pre-process: add the -dM option to dump macro definitions
|
|
Sparse allows (but warns about) a bare newline (not preceded by
a backslash) inside a string. Since this is invalid C, it's
probable that a terminating '"' is missing just before the newline.
In this case, allowing the newline implies accepting the following
characters until the next '"' is found, which is most case creates
a lot of irrelevant warnings.
Change this by disallowing newlines inside strings, exactly like
already done for character constants.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Add a testcase for "Newline in string or character constant" vs.
"missing delimitator" upcoming change.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Legacy code can be littered with the non-standard "#ident" directive;
ignore it.
Signed-off-by: John Levon <levon@movementarian.org>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The current -dD option outputs the macro definitions, in addition to the
pre-processed text. In contrast, the -dM option outputs only the macro
definitions.
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The dump_macros() function fails to correctly output the definition of
macros that have a variable argument list. For example, the following
macros:
#define unlocks(...) annotate(unlock_func(__VA_ARGS__))
#define apply(x,...) x(__VA_ARGS__)
are output like so:
#define unlocks(__VA_ARGS__) annotate(unlock_func(__VA_ARGS__))
#define apply(x,__VA_ARGS__) x(__VA_ARGS__)
Add the code necessary to print the ellipsis in the argument list to the
dump_macros() function and add the above macros to the 'dump-macros.c'
test file.
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The dump_macros() function adds a ", " separator between the arguments
of a function-like macro. Using a simple "," separator, which aligns the
output with gcc, leads to one less distraction when comparing the output
of sparse and gcc.
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The dump_macro() function fails to correctly output the definitions of
macros that contain the string operator '#', the concatenation operator
'##' and any macro parameter in the definition token list. For example,
the following macros:
#define STRING(x) #x
#define CONCAT(x,y) x ## y
are output like so:
#define STRING(x) unhandled token type '21'
#define CONCAT(x, y) unhandled token type '22' unhandled token type '23' unhandled token type '22'
Add the code necessary to handle those token types to the dump_macros()
function and add the above macros to the 'dump-macros.c' test file.
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Sparse has support for a subset of GCC's large collection of
attributes. It's not easy to know which versions support this
or that attribute. However, since GCC5 there is a good solution
to this problem: the magic macro __has_attribute(<name>)
which evaluates to 1 if <name> is an attribute known to the
compiler and 0 otherwise.
Add support for this __has_attribute() macro by extending the
already existing support for __has_builtin().
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Add a testcase for the incoming support of __has_attribute().
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This will merge the following topic branches:
* builtin-dyn:
Expansion of macros like __FILE__, __DATE__, ... must, contrary
to usual macros, be done dynamically.
This series improves support for them:
- consider them as defined (like GCC do)
- use table + method for their expansion (avoid useless compares)
- add support for __INCLUDE_LEVEL__ & __BASE_FILE__
* builtin-predef:
Add a function: predefine() which allow to directly add
the definition of a simple macro (without args and with
a single number or ident as definition).
Also do the conversion of the concerned predefined macros
and some cleanups.
* builtin-overflow:
Add support for builtins doing overflow checking.
* has-builtin:
Add support for the __has_builtin() macro.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Sparse has support for a subset of GCC's large collection of builtin
functions. As for GCC, it's not easy to know which builtins are
supported in which versions.
clang has a good solution to this problem: it adds the checking macro
__has_builtin(<name>) which evaluates to 1 if <name> is a builtin
function supported by the compiler and 0 otherwise.
It can be used like:
#if __has_builtin(__builtin_clz)
#define clz(x) __builtin_clz(x)
#else
...
#endif
It's possible or probable that GCC will have this soon too:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
Add support for this __has_builtin() macro by extending
the evaluation of preprocessor expressions very much like
it is done to support defined().
Note: Some function-like builtin features, like __builtin_offset(), are
considered as a kind of keyword/operator and processed as such.
These are *not* considered as builtins by __has_builtin().
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Add a few silly testcases doing some expansion of a builtin macro.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
There was some support for it but it was just a define
that expanded to the fixed name "base_file.c".
Implement the real thing by saving the input filename
and replacing __BASE_FILE__ by it.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This macro, which is supported by GCC, wasn't yet by sparse.
Add support for it.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
GCC consider these macros as being defined, sparse doesn't.
Also sparse uses a sequence of comparisons, one for each of
__DATE__, __FILE__, ..., which is not ideal.
Fix this by defining and using a table to associate to the
corresponding symbol a method doing the expansion.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
GCC considers __LINE__, __FILE__, ... as being defined.
Add a testcase for this.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
validation/{phase2/backslash,phase3/comments} are two ancient
testcases that predate ./test-suite and they are ignored by
the testsuite because they do not have a '.c' extension.
Change this by:
- renaming them with a '.c' extension
- moving them to validation/preprocessor/
- adding the testsuite tags & results to them
- remove comments about their previous status
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
GCC's manual or POSIX say about the '-D' option something like:
'−D name[=value]' should be treated as if in directive
'#define name value' (with '1' as default for the value),
including its tokenization.
So an option like '-DM(X, Y)=...' should be processed like a
directive '#define M(X, Y) ...'.
However, the current code treat a space as a separator between
the macro and its definition, just like the '='. As consequence,
the above option is processed like the directive would be
'#define M(X, Y)=...', with 'M(X,' as the macro (name) and
'Y)=...' as its definition.
Fix this by stopping to treat the space character specially,
thus only using '=' as the separator.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Till now, sparse was unneedlessly strict in what it accepted in
'-D' options. More specifically, it doesn't accept:
1) separated '-D' and the macro definition, like:
sparse -D MACRO[=definition] ...
2) a space between the '-D' and the macro name, like:
sparse '-D MACRO[=definition] ...
Case 1) is clearly accepted by GCC, clang and should be
accepted for a POSIX's c99. Case 2's status is less clear
but is also accepted by GCC and clang (leaving any validation
to the corresponding internal #define).
Fix this by accepting separated command line argument for '-D'
and the macro (and removing the check that rejected the macro
part if it started with a space).
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
On Thu, Aug 31, 2017 at 09:54:33PM +0100, Al Viro wrote:
> What a mess... Note that for non-vararg it *is* the right interpretation
> (with #define A(x) [x] we will have A() interpreted as "empty token sequence
> as the only argument", not "no arguments given"). For vararg case we
> normally do not need to distinguish "not given" and "empty" - the only
> thing that cares is exactly the ,## kludge. There with
> #define B(x,...) [x,##__VA_ARGS__]
> B(1) and B(1,) yield [1] and [1,] resp. And for everything other than
> "just ..." we even get it right...
>
> I see what's going on there; will post a fix in a few.
Fix macro argument parsing for (...) case
Nasty corner case for the sake of ,##__VA_ARGS__ perversion - for something
like #define A(x,...) [x,##__VA_ARGS] we want A(1) to expand to [1] and
A(1,) - to [1,]. In other words, "no vararg given" and "vararg empty" are
different and need to be distinguished. Unfortunately, in case when there
was nothing but vararg we got it wrong - #define A(...) ,##__VA_ARGS ended
up with A() interpreted as "one empty argument" (as it would in non-vararg
case) rather than "zero arguments".
Reported-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Christopher Li <sparse@chrisli.org>
|
|
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This test depends on the header <limits.h> which itself depends
on some macros being defined by the compiler.
Now these macros are predefined (at least the obvious ones)
but it's annoying for the tests to depends on external things
like this header.
Remove this dependence by rewriting the test to use the predefined
macros directly.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Some tests or some code depends on these macros being predefined
by the compiler.
Predefine them.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Some tests or some code depends on these macros being predefined
by the compiler.
Predefine them.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Following the C standards conversion of escaped characters
must be done after preprocessing, just before adjacent
string concatenation. This is what is done but escape
sequence were recognized already at tokenization phase
and a warning is given then when an unknonw escape
sequence was encountered.
But there is no reason to give such warning at this
earlier phase, manly because yhere is no reasons
to warn on things which will be discarded during
the preprocessing.
Fix this by moving the diagnostic of unknown escape
sequence together with the escape conversion.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Christopher Li <sparse@chrisli.org>
|
|
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Christopher Li <sparse@chrisli.org>
|
|
__COUNTER__ macro is expanded to a sequential number starting from 0.
This is sometimes used to declare unique variable names.
Implement support for __COUNTER__ in sparse including a set of
small test programs for the test suite.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Christopher Li <sparse@chrisli.org>
|
|
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
#define A(x) #x
A('\12')
should *not* yield "'\\n'"; the problem is that we are doing the conversion
too early.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
a) it actually allows any number of ##<arg>##... in between, as long as all
those args are empty.
b) it does *not* allow ## after __VA_ARGS__ - if it's there magic disappears
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
See http://git.profusion.mobi/cgit.cgi/lucas/codespell/ for more
information on codespell.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Christopher Li <sparse@chrisli.org>
|
|
Instrument validate/preprocessor/preproprocessor*.c to be integrated
into the test-suite where missing and add an additional test case.
Signed-off-by: Hannes Eder <hannes@hanneseder.net>
Signed-off-by: Christopher Li <sparse@chrisli.org>
|
|
test-suite merged stdout and stderr, which relied on the ordering of data from
the two streams in the merged stream. This made test-suite frequently fail on
tests with both output and errors, when the ordering didn't happen to match
what the test assumed. Handle each of the streams separately, and update the
tests accordingly.
Also clean up the output of "test-suite format" to avoid outputting values
equal to the defaults.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
|
|
Signed-off-by: Josh Triplett <josh@freedesktop.org>
|
|
Signed-off-by: Josh Triplett <josh@freedesktop.org>
|
|
Signed-off-by: Josh Triplett <josh@freedesktop.org>
|
|
This only adds comments to tests where current Sparse output seemed obviously
correct, or matched an existing comment in the test describing the output.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
|
|
Remove information redundant with the test-suite comments, such as expected
output, and update comments that disagree with current Sparse behavior, such
as saying that Sparse gets a test wrong when it no longer does.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
|
|
A few examples meant to show the use of test-suite
Signed-off-by: Damien Lespiau <damien.lespiau@gmail.com>
|
|
The preprocessor tests shouldn't run through the entire Sparse compiler, just
the preprocessor (sparse -E).
Signed-off-by: Josh Triplett <josh@freedesktop.org>
|
