aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/parse.c
AgeCommit message (Collapse)AuthorFilesLines
2018-06-04Merge branches 'label-redef', 'goto-reserved', 'errmsg-builtin-pos', ↵Luc Van Oostenryck1-40/+25
'fix-builtin-expect' and 'int-const-expr' into tip
2018-05-26label: avoid multiple definitionsLuc Van Oostenryck1-3/+6
If a label is defined several times, an error is issued about it. Nevertheless, the label is used as is and once the code is linearized several BB are created for the same label and this create inconsistencies. For example, some code will trigger assertion failures in rewrite_parent_branch(). Avoid the consistencies by ignoring redefined labels. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2018-05-26context: extra warning for __context__() & friendsLuc Van Oostenryck1-0/+4
Statements with an empty expression, like: __context__(); or __context__(x,); are silently accepted. Worse, since NULL expressions are usually ignored because it is assumed they have already been properly diagnosticated, no warnings of any kind are given at some later stage. Fix this by explicitly checking after empty expressions and emit an error message if needed. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2018-05-26context: stricter syntax for __context__ statementLuc Van Oostenryck1-10/+8
The expected syntax for the __context__ statement is: __context__(<expression>); or __context__(<context>, <expression>); but originally it was just: __context__ <expression> In other words the parenthesis were not needed and are still not needed when no context is given. One problem with the current way to parse these statements is that very few validation is done. For example, code like: __context__; is silently accepted, as is: __context__ a, b; which is of course not the same as: __context__(a,b); And code like: __context__(,1); results in a confusing error message: error: an expression is expected before ')' error: Expected ) in expression error: got , So, given that: * the kernel has always used the syntax with parenthesis, * the two arguments form requires the parenthesis and thus a function-like syntax use a more direct, robust and simpl parsing which enforce the function-like syntax for both forms. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2018-05-26context: fix crashes while parsing '__context__;' or '__context__(;'Luc Van Oostenryck1-1/+3
The expected syntax for the __context__ statement is: __context__(<inc/dec value>); or __context__(<context>, <inc/dec value>); The distinction between the two formats is made by checking if the expression is a PREOP with '(' as op and with an comma expression as inner expression. However, code like: __context__; or __context__(; crashes while trying to test the non-existing expression (after PREOP or after the comma expression). Fix this by testing if the expression is non-null before dereferencing it. Note: this fix has the merit to directly address the problem but doesn't let a diagnostic to be issued for the case __context__; which is considered as perfectly valid. The next patch will take care of this. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2018-05-26context: fix parsing of attribute 'context'Luc Van Oostenryck1-32/+13
Currently the parsing of the attribute 'context' is rather complex and uses a loop which allows 1, 2, 3 or more arguments. But the the real syntax is only correct for 2 or 3 arguments. Furthermore the parsing mixes calls to expect() with its own error reporting. This is a problem because if the error has first been reported by expect(), the returned token is 'bad_token' which has no position so you can have error logs like: test.c:1:43: error: Expected ( after context attribute test.c:1:43: error: got ) builtin:0:0: error: expected context input/output values But the 'builtin:0.0' should really be 'test.c:1.43' or, even better, there shouldn't be a double error reporting. Fix this by simplifying the parsing and only support 2 or 3 args. Also, make the error messages slightly more explicit about the nature of the error. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2018-05-06Merge branches 'unop', 'describe-dirty', 'range-syntax', 'old-testcases', ↵Luc Van Oostenryck1-1/+8
'fix-redef-typedef' and 'fixes' into tip
2018-05-06use function-like syntax for __range__Luc Van Oostenryck1-1/+4
One of sparse's extension to the C language is an operator to check ranges. This operator takes 3 operands: the expression to be checked and the bounds. The syntax for this operator is such that the operands need to be a 3-items comma separated expression. This is a bit weird and doesn't play along very well with macros, for example. Change the syntax to a 3-arguments function-like operator. NB. Of course, this will break all existing uses of this extension not using parenthesis around the comma expression but there doesn't seems to be any. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2018-05-04teach sparse about _Floatn and _FloatnxLuc Van Oostenryck1-0/+5
It seems that some system headers (Debian x32's glibc) use these types based on GCC's version without checking one of the '__STDC_IEC_60559_<something>' macro. This, of course, creates warnings and errors when using sparse on them. Avoid these errors & warnings by letting sparse know about these types. Note: Full support would require changes in the parsing to recognize the suffixes for constants ([fF]32, ...), the conversion rules between these types and the standard ones and probably and most others things, all outside the scope of this patch. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Acked-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
2018-05-01fix: warn on typedef redefinitionLuc Van Oostenryck1-0/+4
check_duplicates() verifies that symbols are not redefined and warns if they are. However, this function is only called at evaluation-time and then only for symbols corresponding to objects and functions. So, typedefs can be redefined without any kind of diagnostic. Fix this by calling check_duplicates() at parsing time on typedefs. Note: this is C11's semantic or GCC's C89/C99 in non-pedantic mode. Reported-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2018-02-16no repetition in unknown attribute warning messageLuc Van Oostenryck1-1/+1
The warning message for unknown attributes is a bit longish and uses the word 'attribute' twice. Change the message for something more direct, shorter and without repetition. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2017-11-11Merge branches 'volatile-loads-are-side-effects', ↵Luc Van Oostenryck1-15/+30
'fix-volatile-simplification', 'struct-asm-ops', 'restricted-pointers', 'fix-f2i-casts', 'symaddr-description', 'flush-stdout' and 'diet-simple' into tip
2017-11-11define MOD_ACCESS for (MOD_ASSIGNED | MOD_ADDRESSABLE)Luc Van Oostenryck1-1/+1
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2017-11-08add support for C11's _Atomic as type qualifierLuc Van Oostenryck1-0/+13
This only add the parsing and checks as a type qualifier; there is no operational semantic associated with it. Note: this only support _Atomic as *type qualifier*, not as a *type specifier* (partly because there an ambiguity on how to parse '_Atomic' when followed by an open parenthesis (can be valid as qualifier and as specifier)). Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2017-11-08associate MOD_RESTRICT with restrict-qualified variablesLuc Van Oostenryck1-5/+11
Note: there is still no semantic associated with 'restrict' but this is a preparatory step. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2017-11-08define MOD_QUALIFIER for (MOD_CONST | MOD_VOLATILE)Luc Van Oostenryck1-1/+1
This is slightly shorter (and thus may avoid long lines) and facilitate the introduction of MOD_RETRICT in a later patch. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2017-11-08remove redundancy in MOD_STORAGELuc Van Oostenryck1-1/+1
MOD_TOPLEVEL & MOD_INLINE are already include in MOD_STORAGE so there is no need to repeat them in MOD_IGNORE & elsewhere where MOD_STORAGE is used. Change this by removing the redundant MOD_TOPLEVEL & MOD_INLINE. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2017-11-08MOD_ACCESSED is not a type modifier ...Luc Van Oostenryck1-1/+1
but is used to track which inline functions are effectively used. So better remove it from the MOD_... and implement the same functionality via a flag in struct symbol. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2017-09-17use a specific struct for asm operandsLuc Van Oostenryck1-9/+5
ASM operands have the following syntax: [<ident>] "<constraint>" '(' <expr> ')' For some reasons, during parsing this is stored as a sequence of 3 expressions. This has some serious disadvantages though: - <ident> has not the type of an expression - it complicates processing when compared to having a specific struct for it (need to loop & maintain some state). - <ident> is optional and stored as a null pointer when not present which is annoying, for example, if null pointers are used internally in ptr-lists to mark removed pointers. Fix this by using a specific structure to store the 3 elements of ASM operands. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2017-07-04Add full list of gcc attributeChristopher Li1-104/+10
This will greatly reduce the "unknown attribute" warning. Signed-off-By: Christopher Li <sparse@chrisli.org>
2017-07-04Let create_symbol check for previous same symbolChristopher Li1-2/+4
Avoid create a new one if same symbol exists. Signed-off-By: Christopher Li <sparse@chrisli.org>
2017-06-23Adding ignored attribute optimizev0.5.1-rc3Christopher Li1-2/+4
It was used in kvm/vmx.c Signed-of-By: Christopher Li <sparse@chrisli.org>
2017-06-08ret-void: warn for implicit typeLuc Van Oostenryck1-0/+9
Currently, no warning is given for symbols for which no type is explicitely given. But for functions we received a pointless warning like here under if the returned type is effectively an int: warning: incorrect type in return expression (invalid types) expected incomplete type got int Fix this by issuing the warning. Also give an implicit type of int, as required by C89, to avoid pointless warning about the expected incomplete type. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2017-05-12keyword: add a comment about NS_TYPEDEF & reserved keywordsLuc Van Oostenryck1-0/+1
There is two ways a keyword can be marked as reserved: - explicitly, by using IDENT_RESERVED() in "ident-list.h" - implicitly, by using NS_TYPEDEF as namespace in parse.c::keyword_table Since the implicit way is not obvious, help to make it more clear by adding a small comment on top of keyword_table[]. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2017-05-12sparse: add support for _Static_assertLance Richardson1-1/+44
This patch introduces support for the C11 _Static_assert() construct. Per the N1539 draft standard, the syntax changes for this construct include: declaration: <declaration-specifiers> <init-declarator-list>[opt] ; <static_assert-declaration> struct-declaration: <specifier-qualifier-list> <struct-declarator-list>[opt] ; <static_assert-declaration> static_assert-declaration: _Static_assert ( <constant-expression> , <string-literal> ) ; Signed-off-by: Lance Richardson <lrichard@redhat.com> Signed-off-by: Chris Li <sparse@chrisli.org> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2017-03-06move 'extern with initializer' validation after the validate methodLuc Van Oostenryck1-4/+5
Before the call to the method external_decl::validate_decl() there is another validation done which check if the declaration linkage is not external, otherwise an error is issued and the 'extern' is removed from the declaration. While also valid for C99 for-loop initializer, this is less desirable because in this context, 'extern' is invalid anyway and removing it from the declaration make it imposible to issue a diagnostic about it. Fix this by moving the 'extern with initializer' check after the call to validate_decl() method, where it is always pertinent and so allowing process_for_loop_decl() to make its own diagnostic. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2017-03-06check the storage of C99 for-loop initializersLuc Van Oostenryck1-1/+12
In C99, it is valid to declare a variable inside a for-loop initializer but only when the storage is local (automatic or register). Until now this was not enforced. Fix this, when parsing declarations in a for-loop context, by calling external_decl() with a validate method doing the appropriate check of the storage. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2017-03-06add an optional validation method to external_declaration()Luc Van Oostenryck1-3/+7
After parsing and validation, the symbols in the declaration are added to the list given in argument, *if* they are not extern symbols. The symbols that are extern are them not added to the list. This is what is needed for usual declarations but ignoring extern symbols make it impossible to emit a diagnostic in less usual situation. This is motivated by the validation of variable declaration inside a for-loop initializer, which is valid in C99 but only for variable with local storage. The change consists in adding to external_declaration() an optional callback 'validate_decl()' which, if present (non-null), is called just before adding the declaration to the list. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2017-03-04make -Wbitwise operational againLuc Van Oostenryck1-2/+14
The flag -Wbitwise have no effect since patch 02a886bfa ("Introduce keyword driven attribute parsing"): the corresponding checks are now always done. Fix that by reintroducing it in the same way as it was: ignore the bitwise attribute if the flag is not set. It's less invasive that checking the flag at each place an corresponding warning is emitted. Also, to not perturb the current situation the flag is now enabled by default. Reported-by: Edward Cree <ecree@solarflare.com> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2017-02-13let identical symbols share their evaluate/expand methodsLuc Van Oostenryck1-1/+3
So far, builtin functions which had some evaluate/expand method couldn't also have a prototype because the declaration of the prototype and the definition of the builtin with its method would each have their own symbol and only one of them will be seen, the last one, the one for the prototype. This also meant that the evaluate/expand methods had to take care to set the correct types for they argumenst & results, which is fine for some generic builtins like __builtin_constant_p() but much less practical for the ones like __builtin_bswap{16,32,64}(). Fix this by letting symbols with same name share their methods. Originally-by: Christopher Li <sparse@chrisli.org> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2017-02-13C11: teach sparse about '_Alignas()'Luc Van Oostenryck1-0/+43
This is quite similar to GCC's 'attribute(aligned(..))' but defined as a new specifier and also accepting a typename as argument. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2017-02-13C11: teach sparse about '_Noreturn'Luc Van Oostenryck1-0/+14
This is mainly a new name for GCC's 'noreturn' attribute but defined as a new function specifier. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2017-02-13C11: teach sparse about '_Thread_local'Luc Van Oostenryck1-0/+1
This is simply a new name for GCC's '__thread' which was already supported. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2017-02-13add support for __int128Luc Van Oostenryck1-0/+10
There is already support for __int128_t & __uint128_t but not yet for GCC's __int128. This patch add support for it and a couple of test cases. Note: it's slightly more tricky that it look because contrary to '__int128_t', '__int128' is not an exact type (it can still receive the 'unsigned' or 'signed' specifier). Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2017-02-13fix missing element in types declarationLuc Van Oostenryck1-1/+1
In the code doing the parsing of type declaration there is a few arrays for the each integer size (short, int, long, long long, ...) The array for the unsigned and explicitely unsigned integer have entry for 'slllong' & 'ulllong' last element but the one for plain integer is missing its 'lllong' entry which make sparse crash when trying to use this type. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2017-02-13Warn on unknown attributes instead of throwing errorsLuc Van Oostenryck1-1/+2
GCC creates new attributes quite often, generaly for specific usages irrelevant to what sparse is used for. Throwing errors on these create needless noise and annoyance which is better to avoid. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2017-01-27make 'ignored_attributes[]' staticLuc Van Oostenryck1-1/+1
And so quiets a warning from sparse about an undeclared symbol when running on its own code. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2017-01-27fix mixup in "Handle SForced in storage_modifiers"Luc Van Oostenryck1-3/+3
The patch used the wrong enum for the maximum size of the array. I just noticed now, while doing some merging, that what have been commited on the master tree is not the patch discussed here. What have been commited is the same change but with 'CMax' (integer class) while it was supposed to be 'SMax' (for the array of specifier). The version on sparse-next is correct though. Here is a patch fixing this: Fixes: 1db3b627 ("Handle SForced in storage_modifiers") Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2016-11-17Handle SForced in storage_modifiersJeff Layton1-2/+2
We have been seeing errors like this for a while now in the sparse Fedora package, when doing kernel builds: ./include/linux/err.h:53:25: warning: dereference of noderef expression ./include/linux/err.h:35:16: warning: dereference of noderef expression This spews all over the build because this comes from IS_ERR(), which is called everywhere. Even odder, it turns out that if we build the package with -fpic turned off, then it works fine. With some brute-force debugging, I think I've finally found the cause. This array is missing the SForced element. When this is added then the problem goes away. As to why this goes away when -fpic is removed, I can only assume that we get lucky with the memory layout and have a zeroed out region just beyond the end of the array. Fixes: 3829c4d8b097776e6b3472290a9fae08a705ab7a Cc: Al Viro <viro@ftp.linux.org.uk> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2016-10-26sparse: add no_sanitize_address as an ignored attributeRui Teng1-0/+2
Add attribute "no_sanitize_address" or "__no_sanitize_address__" as an ignored attribute. Fixes this sparse warning: include/linux/compiler.h:232:8: error: attribute 'no_sanitize_address': unknown attribute Also add test case for 'no_sanitize_address': validation/attr-no_sanitize_address.c. 'make check' says for this test case: TEST attribute no_sanitize_address (attr-no_sanitize_address.c) Signed-off-by: Rui Teng <rui.teng@linux.vnet.ibm.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2016-10-13sparse: ignore __assume_aligned__ attributeLance Richardson1-0/+2
The __assume_aligned__ attribute can be safely ignored, add it to the list of ignored attributes and add a test to verify that this attribute is ignored. Signed-off-by: Lance Richardson <lrichard@redhat.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2016-10-13sparse: add 'alloc_align' to the ignored attributesRamsay Jones1-0/+2
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2015-08-15Add default case to switches on enum variablesTony Camuso1-0/+3
Missing enum members in case statements in c2xml.c and parse.c were causing compile time complaints by gcc 5.1.1. Adding a default case satisfies the compiler and notifies the reviewer that there are cases not explicitly mentioned being handled by the default case. Signed-off-by: Tony Camuso <tcamuso@redhat.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2015-06-11sparse/parse.c: ignore hotpatch attributeHeiko Carstens1-0/+2
gcc knows about a new "hotpatch" attribute which sparse can safely ignore, since it modifies only which code will be generated just like the "no_instrument_function" attribute. The gcc hotpatch feature patch: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=11762b8363737591bfb9c66093bc2edf289b917f Currently the Linux kernel makes use of this attribute: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=61f552141c9c0e88b3fdc7046265781ffd8fa68a Without this patch sparse will emit warnings like "error: attribute 'hotpatch': unknown attribute" Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2014-11-10parse.c: remove duplicate 'may_alias' ignored_attributesRamsay Jones1-2/+0
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2014-10-10sparse: add 'gnu_inline' to the ignored attributesRamsay Jones1-0/+2
Add some more ignored attributes which are used in glibc header files, along with a simple test case which includes all three inline attributes (__gnu_inline__, __always_inline__ and __noinline__). Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2014-10-10Add the __restrict__ keywordRamsay Jones1-1/+2
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2014-08-02Make same_symbol list share the same scopeChristopher Li1-0/+1
Consider the following case, extern inline declare after extern declare of the same function. extern int g(int); extern __inline__ int g(int x) { return x; } Sparse will give the first function global scope and the second one file scope. Also the first one will get the function body from the second one. That cause the failure of the validation/extern-inlien.c This change rebind the scope of the same_symbol chain to the new scope. It will pass the extern-inline.c test case. Signed-off-by: Christopher Li <sparse@chrisli.org>
2014-04-17parse: support c99 [static ...] in abstract array declaratorsCody P Schafer1-1/+17
The n1570 specifies (in 6.7.6.2.3) that either type-qualifiers (ie: "restrict") come first and are followed by "static" or the opposite ("static" then type-qualifiers). Also add a test. Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2014-04-01Support GCC's transparent unionsJohn Keeping1-1/+6
This stops warnings in code using socket operations with a modern glibc, which otherwise result in warnings of the form: warning: incorrect type in argument 2 (invalid types) expected union __CONST_SOCKADDR_ARG [usertype] __addr got struct sockaddr *<noident> Since transparent unions are only applicable to function arguments, we create a new function to check that the types are compatible specifically in this context. Also change the wording of the existing warning slightly since sparse does now support them. The warning is left in case people want to avoid using transparent unions. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2013-11-29sparse: Relicense under the MIT licenseFranz Schrober1-1/+17
The old code was relicensed by Novafora Corporation, successor in interest to Transmeta Corporation, in 2009. Other authors were also asked about the change of their contributions to the MIT license and all with copyrightable changes agreed to it. Signed-off-by: Franz Schrober <franzschrober@yahoo.de> Acked-by: Adam DiCarlo <adam@bikko.org> Acked-by: Al Viro <viro@ZenIV.linux.org.uk> Acked-by: Alberto Bertogli <albertito@blitiri.com.ar> Acked-by: Alecs King <alecs@perlchina.org> Acked-by: Alexander Shishkin <alexander.shishckin@gmail.com> Acked-by: Alexey Dobriyan <adobriyan@gmail.com> Acked-by: Alexey Zaytsev <alexey.zaytsev@gmail.com> Acked-by: Andries E. Brouwer <Andries.Brouwer@cwi.nl> Acked-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net> Acked-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Acked-by: Ben Pfaff <blp@nicira.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Bernd Petrovitsch <bernd@petrovitsch.priv.at> Acked-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> Acked-by: Blue Swirl <blauwirbel@gmail.com> Acked-by: Chris Forbes <chrisf@ijw.co.nz> Acked-by: Chris Wedgwood <cw@f00f.org> Acked-by: Christopher Li <sparse@chrisli.org> Acked-by: Damien Lespiau <damien.lespiau@gmail.com> Acked-by: Dan Carpenter <error27@gmail.com> Acked-by: Dan McGee <dan@archlinux.org> Acked-by: Daniel De Graaf <danieldegraaf@gmail.com> Acked-by: Daniel Sheridan <dan.sheridan@postman.org.uk> Acked-by: Dave Jones <davej@redhat.com> Acked-by: David Given <dg@cowlark.com> Acked-by: David Miller <davem@redhat.com> Acked-by: David Mosberger-Tang <dmosberger@gmail.com> Acked-by: David Olien <David.Olien@lsi.com> Acked-by: Diego Elio Pettenò <flameeyes@flameeyes.eu> Acked-by: Emil Medve <Emilian.Medve@Freescale.com> Acked-by: Ethan Jackson <jacksone@nicira.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Frank Zago <fzago@systemfabricworks.com> Acked-by: Frederic Crozat <fcrozat@suse.com> Acked-by: Geoff Johnstone <geoff.johnstone@gmail.com> Acked-by: Hannes Eder <hannes@hanneseder.net> Acked-by: Jan Pokorný <pokorny_jan@seznam.cz> Acked-by: Jeff Garzik <jgarzik@redhat.com> Acked-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Joe Perches <joe@perches.com> Acked-by: Joel Soete <rubisher@scarlet.be> Acked-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Acked-by: Josh Triplett <josh@kernel.org> Acked-by: Kamil Dudka <kdudka@redhat.com> Acked-by: Kim Phillips <kim.phillips@linaro.org> Acked-by: KOSAKI Motohiro <kosaki.motohiro@gmail.com> Acked-by: Kovarththanan Rajaratnam <kovarththanan.rajaratnam@gmail.com> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Acked-by: Martin Nagy <nagy.martin@gmail.com> Acked-by: Masatake YAMATO <yamato@redhat.com> Acked-by: Mauro Dreissig <mukadr@gmail.com> Acked-by: Michael Büsch <m@bues.ch> Acked-by: Michael Stefaniuc <mstefani@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Mika Kukkonen <mikukkon@iki.fi> Acked-by: Mike Frysinger <vapier@gentoo.org> Acked-by: Mitesh Shah <Mitesh.Shah@synopsys.com> Acked-by: Morten Welinder <mortenw@gnome.org> Acked-by: Namhyung Kim <namhyung@gmail.com> Acked-by: Nicolas Kaiser <nikai@nikai.net> Acked-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Pavel Roskin <proski@gnu.org> Acked-by: Pekka Enberg <penberg@cs.helsinki.fi> Acked-by: Peter Jones <pjones@redhat.com> Acked-by: Peter A Jonsson <pj@sics.se> Acked-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de> Acked-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Acked-by: Randy Dunlap <rdunlap@xenotime.net> Acked-by: Reinhard Tartler <siretart@tauware.de> Ached-by: Richard Knutsson <richard.knutsson@gmail.com> Acked-by: Rob Taylor <rob.taylor@codethink.co.uk> Acked-by: Rui Saraiva <rmpsaraiva@gmail.com> Acked-by: Ryan Anderson <ryan@michonline.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Samuel Bronson <naesten@gmail.com> Acked-by: Santtu Hyrkkö <santtu.hyrkko@gmail.com> Acked-by: Shakthi Kannan <shakthimaan@gmail.com> Acked-by: Stephen Hemminger <shemminger@linux-foundation.org> Acked-by: Thomas Schmid <Thomas.Schmid@br-automation.com> Acked-by: Tilman Sauerbeck <tilman@code-monkey.de> Acked-by: Vegard Nossum <vegardno@ifi.uio.no> Acked-by: Xi Wang <xi.wang@gmail.com> Acked-by: Yura Pakhuchiy <pakhuchiy@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2013-04-26Allow forced attribute in function argumentv0.4.5-rc1Christopher Li1-0/+1
It will indicate this argument will skip the type compatible check. It allow PTR_ERR() to accept __iomem pointer without complaining. Signed-off-by: Christopher Li <sparse@chrisli.org>
2013-02-21sparse patch v2: add noclone as an ignored attributeRandy Dunlap1-0/+3
Add attribute "noclone" or "__noclone" or "__noclone__" as an ignored attribute. Fixes this sparse warning: arch/x86/kvm/vmx.c:6268:13: error: attribute '__noclone__': unknown attribute Also add test case for 'noclone': validation/attr-noclone.c. 'make check' says for this test case: TEST attribute noclone (attr-noclone.c) Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Christopher Li <sparse@chrisli.org>
2012-06-25sparse: Add 'error' to ignored attributesKOSAKI Motohiro1-0/+2
Add some more ignored attributes which are used in glibc header files. It silences the warnings such as the following: /usr/include/bits/fcntl2.h:36:1: error: attribute '__error__': unknown attribute Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@gmail.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2012-06-25sparse: Add '__vector_size__' to ignored attributesKOSAKI Motohiro1-0/+1
We already had "vector_size" but we also need __vector_size__ to silence some warnings in glibc: /usr/include/bits/link.h:67:45: error: attribute '__vector_size__': unknown attribute Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@gmail.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2012-06-04check missing or duplicate goto labelsXi Wang1-1/+5
This patch sets ->stmt of a SYM_LABEL to the corresponding label statement. If ->stmt was already set, it is a duplicate label. On the other hand, if ->stmt of a goto label is not set during evaluation, the label was never declared. Signed-off-by: Christopher Li <sparse@chrisli.org>
2012-01-18sparse: Add 'leaf' to ignored attributes.Ethan Jackson1-0/+2
This patch adds the 'leaf' GCC attribute to the list of ignored attributes. Glibc uses this attribute causing the following warnings in userspace projects: /usr/include/stdlib.h:514:26: error: attribute '__leaf__': unknown attribute Signed-off-by: Ethan Jackson <ethan@nicira.com> Acked-by: Pekka Enberg <penberg@kernel.org> Signed-off-by: Christopher Li <sparse@chrisli.org>
2011-08-25sparse: Fix __builtin_safe_p for pure and const functionsPekka Enberg1-5/+5
This patch fixes __builtin_safe_p() to work properly for calls to pure functions. Cc: Christopher Li <sparse@chrisli.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Pekka Enberg <penberg@kernel.org> Signed-off-by: Christopher Li <sparse@chrisli.org>
2011-08-23Fix parsing empty asm clobberChristopher Li1-1/+2
Skip the expression instead of adding a null one. Signed-off-by: Christopher Li <sparse@chrisli.org>
2011-08-23Ignore the ms_hook_prologue attribute.Michael Stefaniuc1-0/+2
Signed-off-by: Michael Stefaniuc <mstefani@redhat.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2011-06-28sparse: Add 'artifical' to ignore attributesPekka Enberg1-0/+2
This patch adds the 'artifical' GCC attribute to list of ignore attributes. It's an attribute that's used by glibc which causes the following bogus sparse warnings when using it for userspace projects: /usr/include/bits/stdlib.h:37:1: error: attribute '__artificial__': unknown attribute /usr/include/bits/stdlib.h:64:1: error: attribute '__artificial__': unknown attribute Signed-off-by: Pekka Enberg <penberg@kernel.org> Signed-off-by: Christopher Li <sparse@chrisli.org>
2011-05-31Ignore attribute vector_sizeChristopher Li1-0/+1
Report by Randy Dunlap, attribute vector_size is causing error. Ignore it for now. Signed-off-by: Christopher Li <sparse@chrisli.org>
2011-04-26parse.c: "if(" -> "if (" adjustmentJan Pokorný1-3/+3
Signed-off-by: Jan Pokorny <pokorny_jan@seznam.cz> Signed-off-by: Christopher Li <sparse@chrisli.org>
2010-10-08parser: add Blackfin gcc infoMike Frysinger1-0/+6
The Blackfin port uses some custom attributes to control memory placement, and it has some custom builtins. So add the ones that the kernel actually utilizes to avoid massive build errors with sparse. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Christopher Li <sparse@chrisli.org>
2010-07-19skip may_alias and declare builtin_fabsMorten Welinder1-0/+2
Signed-off-by: Morten Welinder <terra@gnome.org> Signed-off-by: Christopher Li <sparse@chrisli.org>
2010-07-13parser: fix and simplify support of asm gotoJiri Slaby1-1/+2
1) We now handle only "asm (volatile|goto)?", whereas "asm volatile? goto?" is correct. 2) We need to match only goto_ident, so do it explicitly against token->ident without match_idents. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Christopher <sparse@chrisli.org>
2010-06-17parser: add support for asm gotoJiri Slaby1-0/+23
As of gcc 4.5, asm goto("jmp %l[label]" : OUT : IN : CLOB : LABELS) is supported. Add this support to the parser so that it won't choke on the newest Linux kernel when compiling with gcc 4.5. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Christopher Li <sparse@chrisli.org>
2010-06-17Ignore the may_alias GCC attributeDamien Lespiau1-0/+2
may_alias is used in the wild (glib) and makes sparse spew a lot of unhelpful warning messages. Ignore it (for now?). Signed-off-by: Damien Lespiau <damien.lespiau@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2010-03-28Pointer don't inherent the alignment from base typeChristopher Li1-0/+1
Signed-off-by: Christopher Li <sparse@chrisli.org>
2010-03-28Ignore "naked" attributeMichael Buesch1-0/+2
The GCC "naked" attribute is used on certain architectures to generate functions without a prologue/epilogue. Ignore it in sparse. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: Christopher Li <sparse@chrisli.org>
2010-03-28ignore attributes "externally_visible" and "signal"Michael Buesch1-0/+4
This adds more ignored gcc-style attributes. externally_visible is a standard gcc attribute. signal is an AVR8 attribute used to define interrupt service routines. Ignore these attributes, as they are currently not useful for sparse checking. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: Christopher Li <sparse@chrisli.org>
2010-03-28New attribute designated_init: mark a struct as requiring designated initJosh Triplett1-0/+15
Some structure types provide a set of fields of which most users will only initialize the subset they care about. Users of these types should always use designated initializers, to avoid relying on the specific structure layout. Examples of this type of structure include the many *_operations structures in Linux, which contain a set of function pointers; these structures occasionally gain a new field, lose an obsolete field, or change the function signature for a field. Add a new attribute designated_init; when used on a struct, it tells Sparse to warn on any positional initialization of a field in that struct. The new flag -Wdesignated-init controls these warnings. Since these warnings only fire for structures explicitly tagged with the attribute, enable the warning by default. Includes documentation and test case. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Christopher Li <sparse@chrisli.org>
2010-03-28Handle __builtin_ms_va_list.Michael Stefaniuc1-0/+1
For Win64 compiles Wine does #ifndef __ms_va_list # if defined(__x86_64__) && defined (__GNUC__) # define __ms_va_list __builtin_ms_va_list # define __ms_va_start(list,arg) __builtin_ms_va_start(list,arg) # define __ms_va_end(list) __builtin_ms_va_end(list) # else Wouldn't be as bad if sparse cannot handle those but it trips over WINBASEAPI DWORD WINAPI FormatMessageA(DWORD,LPCVOID,DWORD,DWORD,LPSTR,DWORD,__ms_va_list*); WINBASEAPI DWORD WINAPI FormatMessageW(DWORD,LPCVOID,DWORD,DWORD,LPWSTR,DWORD,__ms_va_list*); producing this errors for basically every file: wine/include/winbase.h:1546:96: error: Expected ) in function declarator wine/include/winbase.h:1546:96: error: got * wine/include/winbase.h:1547:97: error: Expected ) in function declarator wine/include/winbase.h:1547:97: error: got * Signed-off-by: Michael Stefaniuc <mstefaniuc@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2010-03-28Ignore the alloc_size attribute.Michael Stefaniuc1-0/+2
Wine has annotated the Win32 alloc functions with the alloc_size attribute. This cuts down the noise a lot when running sparse on the Wine source code. Signed-off-by: Michael Stefaniuc <mstefaniuc@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2010-03-28Ignore the ms_abi/sysv_abi attributes.Michael Stefaniuc1-0/+4
This is needed for getting a meaningful sparse run on a Wine 64-bit compile. Else the basic Win32 headers will produce tons of error: attribute 'ms_abi': unknown attribute which end in error: too many errors. The sysv_abi attribute was just added for symmetry. Signed-off-by: Michael Stefaniuc <mstefaniuc@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2010-03-28Declare ignored attributres into a list of string.Christopher Li1-71/+82
Adding ignored attributes is much easier now. Signed-off-by: Christopher Li <sparse@chrisli.org>
2010-03-28Move noreturn attribute out of ignore attr areaChristopher Li1-2/+2
Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-10-16do not ignore attribute 'noreturn'...Kamil Dudka1-2/+2
Hello, enclosed is a simple patch adding support for attribute 'noreturn' to the parser. The enhancement makes it possible to optimize walk through CFG and thus help us to fight with the state explosion. The benefit is demonstrated on a simple real-world example. Generated CFG before patch: http://dudka.cz/devel/html/slsparse-before/slplug.c-handle_stmt_assign.svg Generated CFG after patch: http://dudka.cz/devel/html/slsparse-after/slplug.c-handle_stmt_assign.svg It's one of the key features I am currently missing in SPARSE in contrast to gcc used as parser. Thanks in advance for considering it! Signed-off-by: Kamil Dudka <kdudka@redhat.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-08-01Add support for TImode type (__int128_t)Blue Swirl1-3/+22
GCC provides a 128 bit type called internally as TImode (__int128_t)on 64 bit platforms (at least x86_64 and Sparc64). These types are used by OpenBIOS. Add support for types "long long long", __mode__(TI) and __(u)int128_t. Signed-off-by: Blue Swirl <blauwirbel@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-08-03Ignore attribute __bounded__, used by OpenBSD headers.Blue Swirl1-0/+2
Signed-off-by: Blue Swirl <blauwirbel@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-18Avoid "attribute 'warning': unknown attribute" warningLinus Torvalds1-0/+2
This avoids getting annoying warnings from <curl/typecheck-gcc.h> and from <bits/string3.h>, which use the "__attribute__((__warning__ (msg)))" gcc attribute. [ The attribute causes gcc to print out the supplied warning message if the function is used. We should some day support it, but this patch just makes us ignore it. ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-18Allow array declarators to have 'restrict' in themLinus Torvalds1-0/+2
Otherwise sparse is very unhappy about the current glibc header files (aio.h, netdb.h. regex.h and spawn.h at a minimum). It's a hack, and not a proper parsing with saving the information. It just ignores any "restrict" keyword at the start of an abstract array declaration, but it's better than what we have now. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-18Support the __thread storage classAlberto Bertogli1-3/+31
GCC supports a __thread storage class, used to indicate thread-local storage. It may be used alone, or with extern or static. This patch makes sparse aware of it, and check those restrictions. Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-18Print an error if typeof() lacks an argumentMartin Nagy1-1/+5
We weren't checking if the initializer isn't NULL, which caused sparse to segfault later on when performing lazy evaluation in classify_type(). Signed-off-by: Martin Nagy <nagy.martin@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-18Add missing checks for Waddress-spaceMartin Nagy1-1/+1
Remove all previous checks for Waddress_space and add one centralized to the address_space attribute handler. If user passes the -Wno-address-space option, we behave as if every pointer had no address space. Signed-off-by: Martin Nagy <nagy.martin@gmail.com> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-18Segfault at evaluate.c:341Al Viro1-0/+1
On Thu, Mar 19, 2009 at 09:52:50PM +0000, Al Viro wrote: Yeah... It's an old b0rken handling of calls for K&R + changes that exposed that even worse. Status quo is restored by the patch below, but it's a stopgap - e.g. void f(); void g(void) { f(0, 0); } will warn about extra arguments as if we had void f(void); as sparse had been doing all along. B0rken. Testcase for the segfault is void f(x, y); void g(void) { f(0, 0); } Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-18Sanitize pointer()Al Viro1-15/+5
There's no need to concat the context list into (empty) one of new node, only to free the original one. Moving the pointer to list instead works fine... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <chrisl@hera.kernel.org>
2009-07-18Don't mix storage class bits with ctype->modifiers while parsing typeAl Viro1-29/+78
Keep storage class (and "is it inline") explicitly in decl_state; translate to modifiers only when we are done with parsing. That avoids the need to separate MOD_STORAGE bits while constructing the type (e.g. in alloc_indirect_symbol(), etc.). It also allows to get rid of MOD_FORCE for good - instead of passing it to typename() we pass an int * and let typename() tell whether we'd got a force-cast. Indication of force-cast never makes it into the modifier bits at all. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <chrisl@hera.kernel.org>
2009-07-18Simplify get_number_value() and ctype_integer()Al Viro1-11/+2
There's no point whatsoever in constructing modifiers for chosen type when decoding integer constant only to have them picked apart by ctype_integer(). Seeing that the former is the only caller of the latter these days, we can bloody well just pass the rank and signedness explicitly and save a lot of efforts. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <chrisl@hera.kernel.org>
2009-07-18Fix __label__ handlingAl Viro1-28/+27
a) __label__ in gcc is not a type, it's a statement. Accepted in the beginning of compound-statement, has form __label__ ident-list; b) instead of crapping into NS_SYMBOL namespace (and consequent shadowing issues), reassign the namespace to NS_LABEL after we'd bound it. We'll get block scope and label namespace, i.e. what we get in gcc. c) MOD_LABEL can be dropped now. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-18Fix declaration_specifiers() handling of typedef name shadowed by NS_SYMBOLAl Viro1-2/+3
Doing lookup_symbol() with NS_TYPEDEF will happily skip the redeclarations of the same identifier with NS_SYMBOL. We need to check that we are not dealing with something like typedef int T; void f(int T) { static T a; /* not a valid declaration - T is not a typedef name */ or similar (e.g. enum member shadowing a typedef, etc.). While we are at it, microoptimize similar code in lookup_type() - instead of sym->namespace == NS_TYPEDEF we can do sym->namespace & NS_TYPEDEF; the former will turn into "fetch 32bit value, mask all but 9 bits, compare with NS_TYPEDEF", the latter - "check that one bit in 32bit value is set". We never mix NS_TYPEDEF with anything in whatever->namespace, so the tests are equivalent. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-18Fix enumeration constants' scope beginningAl Viro1-4/+3
It starts after the end of enumerator; i.e. if we have enum { ... Foo = expression, ... }; the scope of Foo starts only after the end of expression. Rationale: 6.2.1p7. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-18Restore __attribute__((mode)) handlingAl Viro1-21/+97
... at least to the extent we used to do it. It still does _not_ cover the perversions gcc can do with that, but at least it deals with regressions. Full solution will have to wait for full-blown imitation of what gcc people call __attribute__ semantics, the bastards... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-18Pass decl_state down to ->attribute()Al Viro1-18/+19
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Pass decl_state down to ->declarator() and handle_attributes()Al Viro1-48/+48
Other than for attributes of labels (completely ignored, and we can simply use skip_attributes() there), all callers of handle_attributes actually get ctype == &ctx->ctype for some ctx. Ditto for ->declarator(). Switch both to passing ctx instead (has to be done at the same time, since we have handle_attributes() called from ->declarator() for struct). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Clean up and split declaration_specifiers()Al Viro1-30/+29
At this point there's not much in common between qualifiers-only and full cases; easier to split the sucker in two and lose the qual argument. Clean it up, while we are at it... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Have ->declarator() act directly on ctype being affectedAl Viro1-73/+161
... and don't do full-blown apply_ctype() every damn time. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Rewrite and fix specifiers handlingAl Viro1-160/+207
Make sure that we accept the right set; kill ad-hackery around checks for banned combinations. Instead of that we keep a bitmap describing what we'd already seen (with several extra bits for 'long long' and for keeping track of can't-combine-with-anything stuff), check and update it using the values in ..._op and keep track of size modifiers more or less explicitly. Testcases added. A _lot_ of that used to be done wrong. Note that __attribute__((mode(...))) got more broken by this one; the next several changesets will take care of that. One more thing: we are -><- close to getting rid of MOD_SPECIFIER bits for good. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Saner type for __builtin_va_listAl Viro1-1/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Take the rest of specifiers to parse.cAl Viro1-2/+26
... and yes, right now it's ucking fugly. Will get sanitized shortly. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17preparations to ->declarator() cleanup - separate typedef handlingAl Viro1-9/+11
Take typedef handling in declaration_specifiers() into separate branch; kill useless check for qual in case the type we've got has non-NULL base_type (we'd have already buggered off in that situation before we get to the check in question). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Fix handling of typedefs with several declaratorsAl Viro1-0/+3
We set MOD_USERTYPE only on the first one, so declaration_specifiers didn't recognize something like unsigned P; where P had been such a typedef as redefinition (see the testcase). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Take the rest of storage class keywords to parse.cAl Viro1-0/+6
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Fix regression created by commit af30c6df74f01db10fa78ac0cbdb5c3c40b5c73fAl Viro1-0/+2
const and friends are reserved words, TYVM... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Propagate decl_state to declaration_specifiers()Al Viro1-37/+37
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Separating ctype and parser state, part 1Al Viro1-44/+54
Introduce struct decl_state that will hold the declaration parser state. Pass it to declarator() and direct_declarator(). Note that at this stage we are putting more stuff on stack *and* get extra copying; that's temporary and we'll deal with that in subsequent patches. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Sanitize direct_declarator logicsAl Viro1-75/+65
a) handling of nested declarator does not belong in the loop, for fsck sake b) functions and arrays don't mix (and functions don't mix with functions) Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Fix braino in which_kind()Al Viro1-1/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Don't mess with passing symbol to declarator/direct_declaratorAl Viro1-16/+14
There's no reason to pass symbol to declarator/direct_declarator; we only use &sym->ctype, so passing ctype * is fine. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Leave applying attributes until we know whether it's a nested declaratorAl Viro1-23/+63
Don't mess with applying attributes in which_kind(); leave that until we know whether that's function declarator or a nested one. We'll need that to deal with scopes properly. Clean parameter_type_list() and parameter_declaration(), get rid of a leak. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Apply attributes after ( to the right placeAl Viro1-8/+15
In int f(__user int *p) __user applies to p, not to f... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Warn about non-empty identifier list outside of definitionAl Viro1-2/+10
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17more direct_declarator() sanitizingAl Viro1-51/+87
* new helper function - which_kind(). Finds how to parse what follows ( in declarator. * parameter-type-list and identifier-list handling separated and cleaned up. * saner recovery from errors * int f(__attribute__((....)) x) is prohibited by gcc syntax; attributes are not allowed in K&R identifier list, obviously, and gcc refused to treat that as "int is implicit if missing" kind of case. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Fix attribute/asm handlingAl Viro1-7/+10
a) asm aliases are accepted by gcc *only* directly after the top-level declarator within external declaration (and they make no sense whatsoever elsewhere - field names, function parameter names, casts, etc. simply do not reach the assembler). Anyway, gcc parser will reject those anywhere else. b) post-declarator attributes are *not* accepted in nested declarators. In bitfield declarations they must follow the entire thing, _including_ :<width>. They are not accepted in typenames either. Basically, gcc has distinction between the attributes of type and attributes of declaration; "after the entire declaration" is for the latter and they get applied to type only as a fallback. So that's deliberate on part of gcc... c) no attributes in direct-declarator in front of [.....] or (.....). Again, gcc behaviour. d) in external declarations only attributes are accepted after commas. IOW, you can't write int x, const *y, z; and get away with that. Replacing const with __attribute__((...)) will get it accepted by gcc, so we need to accept that variant. However, any qualifiers in that position will get rejected by anything, including gcc. Note that there's a damn good reason why such syntax is a bad idea and that reason applies to attributes as well. Think what happens if later we remove 'x' from the example above; 'z' will suddenly become const int. So I think we want eventually to warn about the use of attributes in that position as well. For now I've got it in sync with gcc behaviour. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17More nested declarator fixesAl Viro1-0/+2
no nested declarators after [...] or (parameters) Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Separate parsing of identifier-list (in K&R-style declarations)Al Viro1-2/+26
Don't mix it with parameter-type-list, add saner checks. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17Fix handling of ident-less declarationsAl Viro1-1/+9
The rule for ident-less declaration is declaration -> declaration-specifiers ; not declaration -> declaration-specifiers abstract-declarator; IOW, struct foo; is OK and so's struct foo {int x; int y;} (and even simply int; is allowed by syntax - it's rejected by constraints, but that's a separate story), but not struct foo (void); and its ilk. See C99 6.7p1 for syntax; C90 is the same in that area and gcc also behaves the same way. Unlike gcc I've made it a warning (gcc produces a hard error for those). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17fun with declarations and definitionsAl Viro1-11/+15
On Thu, Feb 05, 2009 at 09:19:21PM +0000, Al Viro wrote: > IOW, direct_declarator() (which doubles for direct-abstract-declarator) should > have more than one-bit indication of which case we've got. Right now it's > done by "have we passed a non-NULL ident ** to store the identifier being > declared"; that's not enough. What we need is explicit 'is that a part of > parameter declaration' flag; then the rule turns into > if (p && *p) > fn = 1; /* we'd seen identifier already, can't be nested */ > else if match_op(next, ')') > fn = 1; /* empty list can't be direct-declarator or > * direct-abstract-declarator */ > else > fn = (in_parameter && lookup_type(next)); Umm... It's a bit more subtle (p goes NULL after the nested one is handled), so we need to keep track of "don't allow nested declarator from that point on" explicitly. Patch follows: Subject: [PATCH] Handle nested declarators vs. parameter lists correctly Seeing a typedef name after ( means that we have a parameter-type-list only if we are parsing a parameter declaration or a typename; otherwise it might very well be a redeclaration (e.g. int (T); when T had been a typedef in outer scope). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2009-07-17fun with declarations and definitionsAl Viro1-0/+15
There are several interesting problems caused by the fact that we create a separate symbol for each declaration of given function. 1) static inline int f(void); static int g(void) { return f(); } static inline int f(void) { return 0; } gives an error, since the instance of f in g is not associated with anything useful. Needless to say, this is a perfectly valid C. Moreover, static inline int f(void) { return 0; } static inline int f(void); static int g(void) { return f(); } will step on the same thing. Currently we get the former case all over the place in the kernel, thanks to the way DEFINE_SYSCALLx() is done. I have a kinda-sorta fix for that (basically, add a reference to external definition to struct symbol and update it correctly - it's not hard). However, that doesn't cover *another* weirdness in the same area - gccisms around extern inline. There we can have inline and external definitions in the same translation unit (and they can be different, to make the things even more interesting). Anyway, that's a separate story - as it is, we don't even have a way to tell 'extern inline ...' from 'inline ...' 2) More fun in the same area: checks for SYM_FN in external_declaration() do not take into account the possibility of void f(int); typeof(f) g; Ergo, we get linkage-less function declarations. Fun, innit? No patch. 3) Better yet, sparse does _NOT_ reject typeof(f) g { ... } which is obviously a Bloody Bad Idea(tm) (just think what that does to argument list). Similar crap is triggerable with typedef. IMO, we really ought to reject _that_ - not only 6.9.1(2) explicitly requires that, but there's no even remotely sane way to deal with arguments. 4) static void f(void); ... void f(void); triggers "warning: symbol 'f' was not declared. Should it be static?" which is at least very confusing - it *is* declared and it *is* static. IOW, we do not collect the linkage information sanely. (2) will make fixing that one very interesting. Anyway, proposed patch for (1) follows: Subject: [PATCH] Handle mix of declarations and definitions Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>
2008-12-24Revert the context tracking codeJohannes Berg1-124/+10
> Do you want to resend your change which revert the context changes? > Make it base on Josh's git's tree and I will merge your changes in my > branch. Below. Or I can give it to you in git if you prefer. I still think we should redo this in some form so that annotations with different contexts can work properly, but I don't have time to take care of it right now. johannes >From ca95b62edf1600a2b55ed9ca0515d049807a84fc Mon Sep 17 00:00:00 2001 From: Johannes Berg <johannes@sipsolutions.net> Date: Tue, 23 Dec 2008 10:53:19 +0100 Subject: [PATCH] Revert context tracking code
2008-12-18Add enum member list to the parentChristopher Li1-4/+2
Signed-Off-By: Christopher Li <sparse@chrisli.org> Acked-by: Thomas Schmid <Thomas.Schmid@br-automation.com>
2008-12-18Warning should be enough for an unhandled transparent unionAlexey Zaytsev1-1/+1
An error would be issued if such union is actually used. Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>
2008-06-27Ignore "cold" and "hot" attributes, which appeared in gcc 4.3Pavel Roskin1-0/+4
They describe how likely the function is to be executed, which can affect optimization. Also ignore the attributes with underscores. Signed-off-by: Pavel Roskin <proski@gnu.org>
2008-04-21Add -Wno-declaration-after-statementGeoff Johnstone1-3/+1
This adds -W[no-]declaration-after-statement, which makes warnings about declarations after statements a command-line option. (The code to implement the warning was already in there via a #define; the patch just exposes it at runtime.) Rationale: C99 allows them, C89 doesn't. Signed-off-by: Geoff Johnstone <geoff.johnstone@googlemail.com>
2008-04-21sparse: simple conditional context trackingJohannes Berg1-0/+52
This patch enables a very simple form of conditional context tracking, namely something like if (spin_trylock(...)) { [...] spin_unlock(...); } Note that __ret = spin_trylock(...); if (__ret) { [...] spin_unlock(...); } does /not/ work since that would require tracking the variable and doing extra checks to ensure the variable isn't globally accessible or similar which could lead to race conditions. To declare a trylock, one uses: int spin_trylock(...) __attribute__((conditional_context(spinlock,0,1,0))) {...} Note that doing this currently excludes that function itself from context checking completely. Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
2008-04-21make sparse keep its promise about context trackingJohannes Berg1-10/+72
The sparse man page promises that it will check this: Functions with the extended attribute __attribute__((context(expression,in_context,out_context)) require the context expression (for instance, a lock) to have the value in_context (a constant nonnegative integer) when called, and return with the value out_context (a constant nonnegative integer). It doesn't keep that promise though, nor can it, especially with contexts that can be acquired recursively (like RCU in the kernel.) This patch makes sparse track different contexts, and also follows up on that promise, but with slightly different semantics: * the "require the context to have the value" is changed to require it to have /at least/ the value if 'in_context', * an exact_context(...) attribute is introduced with the previously described semantics (to be used for non-recursive contexts), * the __context__ statement is extended to also include a required context argument (same at least semantics), Unfortunately, I wasn't able to keep the same output, so now you'll see different messages from sparse, especially when trying to unlock a lock that isn't locked you'll see a message pointing to the unlock function rather than complaining about the basic block, you can see that in the test suite changes. This patch also contains test updates and a lot of new tests for the new functionality. Except for the changed messages, old functionality should not be affected. However, the kernel use of __attribute__((context(...)) is actually wrong, the kernel often does things like: static void *dev_mc_seq_start(struct seq_file *seq, loff_t * pos) __acquires(dev_base_lock) { [...] read_lock(&dev_base_lock); [...] } rather than static void *dev_mc_seq_start(struct seq_file *seq, loff_t * pos) __acquires(dev_base_lock) { [...] __acquire__(dev_base_lock); read_lock(&dev_base_lock); [...] } (and possibly more when read_lock() is annotated appropriately, such as dropping whatever context read_lock() returns to convert the context to the dev_base_lock one.) Currently, sparse doesn't care, but if it's going to check the context of functions contained within another function then we need to put the actual __acquire__ together with acquiring the context. The great benefit of this patch is that you can now document at least some locking assumptions in a machine-readable way: before: /* requires mylock held */ static void myfunc(void) {...} after: static void myfunc(void) __requires(mylock) {...} where, for sparse, #define __requires(x) __attribute__((context(x,1,1))) Doing so may result in lots of other functions that need to be annoated along with it because they also have the same locking requirements, but ultimately sparse can check a lot of locking assumptions that way. I have already used this patch and identify a number of kernel bugs by marking things to require certain locks or RCU-protection and checking sparse output. To do that, you need a few kernel patches which I'll send separately. Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
2008-04-03saner warnings for restricted typesAl Viro1-2/+9
* don't crap the type->ident for unsigned int just because somebody did typedef unsigned int x; only structs, unions, enums and restricted types need it. * generate saner warnings for restricted, include type name(s) into them. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2007-11-13Handle ignored attribute mallocEmil Medve1-0/+1
This avoids error messages like this: error: attribute 'malloc': unknown attribute Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
2007-10-20Perform local label lookupChristopher Li1-0/+13
This patch fix the sparse breakage triggered by rcu_read_lock() lockdep annotations. Now sparse look up the local label in symbol node name space as well, just like looking up a normal symbol node. Now a lable symbol can be both type SYM_LABEL or SYM_NODE with MOD_LABEL. Singed-Off-By: Christopher Li <sparse@chrisli.org>
2007-07-29[PATCH] file and global scopes are the same for purposes of struct redefiningAl Viro1-1/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2007-07-27parse.c: Adding va_end().ricknu-0@student.ltu.se1-7/+7
Adding va_end(). Signed-off-by: Richard Knutsson <ricknu-0@student.ltu.se>
2007-07-13add end position to symbolsRob Taylor1-1/+20
This adds a field in the symbol struct for the position of the end of the symbol and code to parse.c to fill this in for the various symbol types when parsing. Signed-off-by: Rob Taylor <rob.taylor@codethink.co.uk>
2007-07-10fix handling of address_space in casts and assignmentsAl Viro1-2/+5
Turn FORCE_MOD into storage class specifier (that's how it's actually used and that makes for much simpler logics). Introduce explicit EXPR_FORCE_CAST for forced casts; handle it properly. Kill the idiocy in get_as() (we end up picking the oddest things for address space - e.g. if we have int __attribute__((address_space(1))) *p, we'll get warnings about removal of address space when we do things like (unsigned short)*p. Fixed. BTW, that had caught a bunch of very odd bogosities in the kernel and eliminated several false positives in there. As the result, get_as() is gone now and evaluate_cast() got simpler. Kill the similar idiocy in handling pointer assignments; while we are at it, fix the qualifiers check for assignments to/from void * (you can't assign const int * to void * - qualifiers on the left side should be no less than on the right one; for normal codepath we get that checked, but the special case of void * skips these checks). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2007-06-27Bitfield without explicit sign should be a warning, not an errorPavel Roskin1-1/+1
The -Wdefault-bitfield-sign is supposed to control a warning, just like other -W options. Signed-off-by: Pavel Roskin <proski@gnu.org>
2007-06-26[PATCH] fix handling of integer constant expressionsAl Viro1-5/+5
Hopefully correct handling of integer constant expressions. Please, review. Rules: * two new flags for expression: int_const_expr and float_literal. * parser sets them by the following rules: * EXPR_FVALUE gets float_literal * EXPR_VALUE gets int_const_expr * EXPR_PREOP[(] inherits from argument * EXPR_SIZEOF, EXPR_PTRSIZEOF, EXPR_ALIGNOF get int_const_expr * EXPR_BINOP, EXPR_COMPARE, EXPR_LOGICAL, EXPR_CONDITIONAL, EXPR_PREOP[+,-,!,~]: get marked int_const_expr if all their arguments are marked that way * EXPR_CAST gets marked int_const_expr if argument is marked that way; if argument is marked float_literal but not int_const_expr, we get both flags set. * EXPR_TYPE also gets marked int_const_expr (to make it DTRT on the builtin_same_type_p() et.al.) * EXPR_OFFSETOF gets marked int_const_expr When we get an expression from parser, we know that having int_const_expr on it is almost equivalent to "it's an integer constant expression". Indeed, the only checks we still have not done are that all casts present in there are to integer types, that expression is correctly typed and that all indices in offsetof are integer constant expressions. That belongs to evaluate_expression() and is easily done there. * evaluate_expression() removes int_const_expr from some nodes: * EXPR_BINOP, EXPR_COMPARE, EXPR_LOGICAL, EXPR_CONDITIONAL, EXPR_PREOP: if the node is marked int_const_expr and some of its arguments are not marked that way once we have done evaluate_expression() on them, unmark our node. * EXPR_IMLICIT_CAST: inherit flags from argument. * cannibalizing nodes in *& and &* simplifications: unmark the result. * EXPR_CAST: unmark if we are casting not to an integer type. Unmark if argument is not marked with int_const_expr after evaluate_expression() on it *and* our node is not marked float_literal (i.e. (int)0.0 is fine with us). * EXPR_BINOP created (or cannibalizing EXPR_OFFSETOF) by evaluation of evaluate_offsetof() get int_const_expr if both arguments (already typechecked) have int_const_expr. * unmark node when we declare it mistyped. That does it - after evaluate_expression() we keep int_const_expr only if expression was a valid integer constant expression. Remaining issue: VLA handling. Right now sparse doesn't deal with those in any sane way, but once we start handling their sizeof, we'll need to check that type is constant-sized before marking EXPR_SIZEOF int_const_expr. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2007-06-25[PATCH] deal with enum members without excessive PITAAl Viro1-0/+1
mark symbols for enum members, have primary_expression() copy their ->initializer instead of dancing through the EXRP_SYMBOL with expand_expression() finally getting to the damn thing. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2007-06-18[PATCH] tie the fields of struct in simple listAl Viro1-1/+19
get a linked list through fields of struct, skipping unnamed bitfields. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2007-05-22Add no-double-underscore variant format_arg.Josh Triplett1-0/+1
Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-05-22Add double-underscore variant __syscall_linkage__.Josh Triplett1-0/+1
Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-05-22Add no-double-underscore variant "used", ignored like "__used__".Josh Triplett1-0/+1
Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-05-22Add double-underscore variant __noinline__.Josh Triplett1-0/+1
Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-05-22Add double-underscore variant __always_inline__.Josh Triplett1-0/+1
Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-05-22Ignore the GCC constructor and destructor attributesJosh Triplett1-0/+4
Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-05-22Add (more) support for WIN32 attribute namesRamsay Jones1-0/+6
In particular, the following identifiers (along with their __X__ variants) are now accepted as attribute names: fastcall, dllimport and dllexport. (cdecl and stdcall were added in baf2c5a84e by Michael Stefaniuc). For now, at least, these attributes are just ignored. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> [josh: modified to fix whitespace damage] Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-05-22Fix an __attribute__() parsing errorJosh Triplett1-1/+4
The test case for this was abstracted from an example in the "expat.h" header file: typedef void (__attribute__((__cdecl__)) *FP)(void *u, const char *n); void set_FP(void *cb, FP f); Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> [josh: modified to apply to current Sparse] Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-05-22Add -Wno-old-initializer to turn off warnings about non-C99 struct initializersJosh Triplett1-1/+2
Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-05-15Ignore the cdecl and stdcall attributes for now.Michael Stefaniuc1-0/+4
Wine uses the __stdcall__ attribute extensively. The effects of the patch on a sparse run on the Wine code are: - Removes 143000 "attribute '__stdcall__': unknown attribute" errors. - Removes 116 "attribute '__cdecl__': unknown attribute" errors. - Reduces the amount of "error: too many errors" from 1992 to 1459. Signed-off-by: Michael Stefaniuc <mstefani@redhat.com>
2007-05-02Pass a bitmask of keywords to handle_attributesChristopher Li1-7/+7
The reason I use bitmask in the keyword so that it can allow the caller to select a sub set of keywords. If we want, we can fine tune exactly what keyword is allowed. It also makes the caller of handle_attributes show exactly what kind of attribute it takes. [original patch] Signed-Off-By: Christopher Li <sparse@chrisli.org> [type fix] Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-05-01Parse asm after a label as a statement, not an attributeJosh Triplett1-7/+7
Commit aec53c938c34c47cdbdd6824552e0f2a5104b1cb, "handle label attributes", caused sparse to parse asm after a label as an attribute, not a statement. Fix this by adding a new allow_asm flag to handle_attributes, and passing 0 when parsing label attributes. Expand validation/asm-volatile.c to include the test case that demonstrated this bug. Thanks to Randy Dunlap for reporting the problem. Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-05-01Fix most -Wshadow warnings in Sparse.0.3Josh Triplett1-1/+0
Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-04-20handle label attributesChristopher Li1-1/+2
On Fri, Mar 23, 2007 at 03:04:59PM -0700, Randy Dunlap wrote: > 1. net/sched/cls_api.c, lines 593-611: > > return 0; > rtattr_failure: __attribute__ ((unused)) > return -1; > } Signed-Off-By: Christopher Li<sparse@chrisli.org> Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-04-20Parse and ignore the __regparm__ attribute, just like regparm.Josh Triplett1-0/+1
pthreads from glibc 2.5 uses __attribute__ ((__regparm__ (1)) on some functions (indirectly through the macro __cleanup_fct_attribute). Sparse already parsed and ignored regparm, but not __regparm__. Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-03-09Use GCC format and sentinel attributes on appropriate functionsJosh Triplett1-1/+1
Expose the FORMAT_ATTR portability macro in lib.h, and use it on the various printf-like functions in sparse. Add a new SENTINEL_ATTR portability macro for the GCC sentinel attribute, and use it on match_idents in parse.c. match_oplist in expression.c should use SENTINEL_ATTR, but GCC does not accept an integer 0 as a sentinel, only a pointer 0 like NULL. Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-03-09Fix typos in commentsJosh Triplett1-2/+2
Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-03-09Introduce keyword driven attribute parsingChristopher Li1-193/+262
Now we are really parsing the attribute rather than building the expression tree first. Signed-Off-By: Christopher Li <sparse@chrisli.org> Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-03-07Introduce top level parsing for asm parsing.Josh Triplett1-2/+7
Signed-Off-By: Christopher Li <sparse@chrisli.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-03-07Introducing statement keywordsJosh Triplett1-38/+90
This change using keyword lookup for statement parsing instead of a order compare. Signed-Off-By: Christopher Li <sparse@chrisli.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-03-07Free up some special bits in modifiers.Josh Triplett1-26/+115
This change using symbol_op to contain the specifier parsing function. It is easier to add new specifiers. We don't need special bits any more. Signed-Off-By: Christopher Li <sparse@chrisli.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-03-07Moving statement parsing into smaller functions.Josh Triplett1-93/+139
This is the preparation step for the keyword table driven parsing. Those statement parsing function will later turn into function call back. The patch should not introduce any functional changes. Signed-Off-By: Christopher Li <sparse@chrisli.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Josh Triplett <josh@freedesktop.org>
2007-02-25Fix a bug that match_idents forget to end with NULLChristopher Li1-1/+1
Pavel Roskin manage to hit this bug with struct st { char c; } __attribute__ ((aligned(2))); struct st s1; struct st s2; Signed-Off-By: Christopher Li <sparse@chrisli.org>
2007-02-22Fix double semicolon in struct declarationChristopher Li1-1/+2
Pavel discovered this test case: void test(void) { struct { int foo;; } val; memset(&val, 0, sizeof(val)); } That generates this warning: test.c:5:8: warning: memset with byte count of 0 Sparse ends up creating a node with empty ctype in the member list. Avoid doing that, which eliminates the warning. Signed-Off-By: Christopher Li<spase@chrisli.org>
2007-02-21Handle structure attributes between the structure keyword and the nameChristopher Li1-0/+2
struct __attribute__((__aligned__(16))) foo { int a; }; Signed-Off-By: Christopher Li <sparse@chrisli.org>
2007-01-27Another attempt to fix the attribute parsing.Christopher Li1-29/+56
This patch delay the finalized of the abstract int type so it can take the __attribute__ in the end of declaration. It complicate the bit field parsing because abstract type can show up in the base type of bit field. Signed-off-by: Christopher Li <sparse@chrisli.org>
2006-10-17Recognize and ignore __alias__ and __visibility__Josh Triplett1-2/+4
They are equivalent to "alias" and "visibility" except that gcc won't complain about them in ANSI programs. Original patch from Pavel Roskin, modified by Josh Triplett. Signed-off-by: Josh Triplett <josh@freedesktop.org> Signed-off-by: Pavel Roskin <proski@gnu.org>
2006-10-01Merge branch 'for-linus' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/viro/sparse
2006-10-01Add warning message for naked do-whileLinus Torvalds1-0/+3
Does it necessarily make sense? Dunno, but it does tend to be bad practice, or at least result in code that can be hard to mentally parse. Maybe that mental parsing is just me. Or maybe it should be warned about. You decide. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-01[PATCH] handle fouled-bitwiseAl Viro1-0/+1
This stuff comes from handling smaller-than-int bitwise types (e.g. __le16). The problem is in handling things like __be16 x, y; ... if (x == (x & ~y)) The code is bitwise-clean, but current sparse can't deduce that. Operations allowed on bitwise types have the following property: (type)(x <op> y) can be substituted for x <op> y in any expression other than sizeof. That allows us to ignore usual arithmetical conversions for those types and treat e.g. | as __be16 x __be16 -> __be16, despite the promotion rules; resulting semantics will be the same. However, ~ on smaller-than-int does not have such property; indeed, ~y is guaranteed to _not_ fit into range of __be16 in the example above. That causes a lot of unpleasant problems when dealing with e.g. networking code - IP checksums are 16bit and ~ is often used in their (re)calculations. The way to deal with that is based on the observation that even though we do get junk in upper bits, it normally ends up being discarded and sparse can be taught to prove that. To do that we need "fouled" conterparts for short bitwise types. They will be assigned to (sub)expressions that might carry junk in upper bits, but trimming those bits would result in the value we'd get if all operations had been done within the bitwise type. E.g. in the example above y would be __be16, ~y - fouled __be16, x & ~y - __be16 again and x == (x & ~y) - boolean. Basically, we delay reporting an error on ~<short bitwise> for as long as possible in hope that taint will be cleansed later. Exact rules follow: * ~short_bitwise => corresponding fouled * any arithmetics that would be banned for bitwise => same warning as if we would have bitwise * if t1 is bitwise type and t2 - its fouled analog, then t1 & t2 => t1, t1 | t2 => t2, t1 ^ t2 => t2. * conversion of t2 to t1 is silent (be it passing as argument or assignment). Other conversions are banned. * x ? t1 : t2 => t2 * ~t2 => t2 (_not_ t1; something like ~(x ? y : ~y) is still fouled) * x ? t2 : t2 => t2, t2 {&,|,^} t2 => t2 (yes, even ^ - same as before). * x ? t2 : constant_valid_for_t1 => t2 * !t2 => warning, ditto for comparisons involving t2 in any way. * wrt casts t2 acts exactly as t1 would. * for sizeof, typeof and alignof t2 acts as promoted t1. Note that fouled can never be an lvalue or have types derived from it - can't happen. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2006-08-30[PATCH] Parse and track multiple contexts by expressionJosh Triplett1-11/+25
sparse currently only tracks one global context for __context__ and __attribute__((context)). This adds support for parsing an additional argument to each of these which gives a context expression. For __attribute__((context)), store each context attribute as a separate context structure containing the expression, the entry context, and the exit context, and keep a list of these structures in the ctype. For __context__, store the context expression in the context instruction. Modify the various frontends to adapt to this change, without changing functionality. This change should not affect parsing of programs which worked with previous versions of sparse, unless those programs use comma expressions as arguments to __context__ or __attribute__((context)), which seems highly dubious and unlikely. sparse with -Wcontext generates identical output with or without this change on Linux 2.6.18-rc4. Signed-off-by: Josh Triplett <josh@freedesktop.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-07-05[PATCH] Ignore no_instrument_function attributesJosh Triplett1-0/+3
Ignore the GCC attributes no_instrument_function and __no_instrument_function__, used to turn off instrumentation for a particular function when using GCC's -finstrument-functions option. Signed-off-by: Josh Triplett <josh@freedesktop.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-28[PATCH] Attribute "sentinel"Morten Welinder1-0/+3
This makes sparse ignore the "sentinel" attribute. Signed-off-by: Morten Welinder <terra@gnome.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-12-31Make local declarations be statements of their ownLinus Torvalds1-6/+11
This removes the list of symbols for block statements, and instead makes a declaration be a statement of its own. This is necessary to correctly handle the case of mixed statements and declarations correctly, since the order of declarations and statements is meaningful. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-12-20[PATCH] fix "wrong" NS_STRUCT symbol->posOleg Nesterov1-1/+4
NS_STRUCT symbol gets it's ->pos from alloc_symbol(), it could be called when sparse sees struct's forward declaration. This patch ensures that ->pos identifies position where this struct/union is actually defined. Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-22[PATCH] new flag - Wone-bit-signed-bitfieldAl Viro1-1/+1
Make the warnings about one-bit signed bitfields conditional; default is the old behaviour Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-16Fix up stupid thinko in K&R parameter parsing.Linus Torvalds1-22/+26
We can have multiple parameters declared with the same base declaration. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-16Re-name "error()" function to "sparse_error()"Linus Torvalds1-27/+27
Mitesh Shah (and others) report that broken libc's will have their own "error()" that the sparse naming clashes with. So use a sed-script to rewrite all the occurrences. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-16Fix K&R argument scopingLinus Torvalds1-1/+8
The K&R argument parsing was a quick hack, and horribly buggy. Because it used external_declaration() to parse the argument, it bound the name of the argument at totally the wrong scope. Noted by Mitsh Shah. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-03Cast all enum values to the final typeLinus Torvalds1-0/+22
The type of an enum is determined by the type of all of its entries, which means that while we may parse it in one type, it might end up with another type in the end. We used to just switch the types around, but that didn't properly upgrade the actual values to the new type. The trivial fix is to just keep a list of entries around, and then go back and cast the values at the end. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-03Make sure we keep enum values in a sufficiently large type for parsingLinus Torvalds1-2/+17
We do enum type handling in two passes: one while parsing the values, and then afterwards we determine the final type that depends on the range of the results. Make sure that the intermediate stages keep the intermediate types big enough to cover the full range. (The final type-casting is also buggy, but that's a separate issue) Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-22[PATCH] replaced warnings with errors.Mitesh Shah1-29/+29
This replaceq calls to warning() with error() at places where (I think) the gcc reports an error. Also added a global variable die_if_error which is set if there is one or more errors. If someone wants to stop processing further, can check for the variable. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09[PATCH] Fix address space ordering problemviro@ZenIV.linux.org.uk1-1/+2
We used to get "__user void *" wrong - it ended up with address space 0 instead of address space 1. What happens is actually pretty simple - we get address_space(1) handled in declaration_specifiers(), which sets ctype->as to 1. Then we see "void" and eventually get to ctype->base_type = type; } check_modifiers(&token->pos, s, ctype->modifiers); apply_ctype(token->pos, &thistype, ctype); with thistype coming from lookup for "void". And that, of course, has zero ->as. Now apply_ctype merrily buggers ctype->as and we have 0... So AFAICS proper fix for sparse should be to check thistype->as to see if it really has any intention to change ->as. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-17[PATCH] enum: improve error messagesOleg Nesterov1-1/+3
In case of malformed enum definition: enum E {}; the error will be reported from examine_symbol_type(), this could be very confusing. Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-17[PATCH] enum: fix sparse segfault with incomplete enumOleg Nesterov1-1/+7
Incomplete enum type has ->ctype.base_type == NULL, so almost any usage of it segfaults in is_int_type(), example: enum E *p; *p == 0; It is not possible (and wrong) to fix only the is_int_type(), we also need valid ->base_type in integer_promotion, get_sym_type, etc. This patch also "fixes" false error message: The code: extern enum E e; static void *p = &e; output: enum.c:1:13: warning: invalid enum type Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-15Fix parsing of top-level asm statementsLinus Torvalds1-6/+4
This also simplifies the code - don't bother to make it look like a real function. Bug pointed out by Oleg Nesterov.
2005-08-15Clean up iterator handlingLinus Torvalds1-2/+2
Instead of having a special case for "post_condition == pre_condition", make a NULL post_condition mean that it's the same as the pre-condition. That's how while/for loops work anyway. This avoids the double warnings for conditionals that Oleg Nesterov noted.
2005-08-14[PATCH] de-anonymize typedefsOleg Nesterov1-2/+6
Code: atomic_t v; v.xxxx = 0; without patch: warning: no member 'xxxx' in struct <unnamed> with patch: warning: no member 'xxxx' in struct atomic_t Actually I want this patch because I started the simple libsparse client, and I don't see the simple way to resolve SYM_STRUCT's name in typedef case. Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-03Get closer to parsing multiple files correctly.Linus Torvalds1-14/+1
This actually seems to do some sane things when parsing even complex multiple files. In particular, it actually works right when used for multiple kernel C files together in limited testing.
2005-06-26[PATCH] avoid segfault after parse errors in array designated initializerLuc Van Oostenryck1-0/+4
Avoid deferencing a null pointer after parse errors in array designated initializer. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@looxix.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-20[PATCH] __attribute__ handling for attributes used in the userlandPeter Jones1-5/+25
Here's a patch that adds stubs for several attributes used in userland. This version of the patch includes a warning, which defaults to on, if you use gcc's "transparent_union" attribute, and has a flag (-Wno-transparent-union) to turn the warning off.
2005-05-31[IDENT] Add some more attributesArnaldo Carvalho de Melo1-0/+8
And, like others, ignore it for now. Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
2005-05-19[PATCH] Fix segfault on non-ANSI function-like declaration for realLuc Van Oostenryck1-1/+1
The fix by Linus was half-assed, since it wasn't *p that was NULL, but 'p' itself. Fix it for real this time. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@looxix.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-17Fix SIGSEGV on non-ANSI function-line declarations without a direct name.Linus Torvalds1-1/+1
Noted by Luc Van Oostenryck.
2005-04-07[PATCH] static declearChristopher Li1-7/+7
This patch add static declare to make sparse happy of checking itself.
2005-04-07Give function name in non-ANSI declaration warning.Linus Torvalds1-5/+5
Suggested by Bernhard Fischer
2005-04-07[PATCH] sparse: add function name to warningBernhard Fischer1-2/+2
This adds the function name to the warning about 'function with external linkage has definition'. This saves me from having to open the file in order to look up the function name. When the name is printed, i can quickly grep for possibly other occurances.
2005-04-07Make enum symbols be regular symbols with constant initializers.Linus Torvalds1-6/+19
This removes SYM_ENUM as a special case for symbol handling, and makes it possible to follow the types much better.
2005-04-07Handle bad enum expression types gracefully.Linus Torvalds1-1/+3
2005-04-07Make sure to re-examine a struct/union/enum type afterLinus Torvalds1-0/+3
we did the real definition. It may have been declared and used as a pointer before.
2005-04-07Add compile-time "range-check" infrastructure to sparseLinus Torvalds1-1/+10
2005-04-07[PATCH] Diff to make sparse not complain about __format_arg__santtu.hyrkko@gmail.com1-1/+2
Another gcc format thing...
2005-04-07Save off the asm parameter name too.Linus Torvalds1-1/+5
The asm_inputs/outputs "expression list" is not really an expression list any more: it is a list of "triples", where the first entry is the identifier name, the second one is the constraint string, and the third one is the expression.