Fix handling of __func__

It's not a string literal, it's a static array

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Fix tab handling in nextchar_slow()

... and streamline it a bit more, now that we get all \t hitting
the damn thing.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Fix ,##__VA_ARGS__ kludge

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>
compile-i386: fix use-after-free in func_cleanup()

compile-i386 sometimes crashes due a use-after-free error.  Since
f->pseudo_list is freed first, which invalidates some atom->op* in
f->atom_list.  Further checks like `atom->op1->flags & STOR_WANTS_FREE'
will read garbage, which may lead to a double free.

This patch switches the cleanup order and frees f->atom_list first.
Those marked as STOR_WANTS_FREE won't appear in f->pseudo_list.

Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Christopher Li <sparse@chrisli.org>
Reviewed-by: Pekka Enberg <penberg@kernel.org>
check missing or duplicate goto labels

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>
Merge branch 'for-chris' of git://github.com/penberg/sparse-llvm

Pull 'for-chris' tree from Pekka Enberg:

"Please pull the latest sparse-llvm tree from:
 git@github.com:penberg/sparse-llvm.git for-chris

 It has one new validation test case and fixes to handle strings properly
 in the LLVM backend."

Pekka Enberg (4):
      sparse, llvm: Add _Bool to cast validation test
      sparse, llvm: Simplify output_data() type logic
      sparse, llvm: Fix string initializer code generation
      sparse, llvm: Fix global string access code generation
sparse: Add '__vector_size__' to ignored attributes

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>
sparse: Add 'error' to ignored attributes

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>
FAQ: update the website address and call it Wiki

Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Christopher Li <sparse@chrisli.org>
ptrlist.c: fix a typo in a comment

Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Christopher Li <sparse@chrisli.org>
Merge branch 'llvm/core' of github.com:penberg/sparse-llvm

Please pull the latest Sparse/LLVM tree from:

  git@github.com:penberg/sparse-llvm.git llvm/core

It contains few LLVM backend fixes from myself and Jonathan Neuschäfer.
Fix wrong array size expression

Signed-off-by: Mauro Dreissig <mukadr@gmail.com>
Signed-off-by: Christopher Li <sparse@chrisli.org>
remove weak define x86_64

This fix the regression report by Dan Carpenter. "x96_64" can be
a valid variable name.

Signed-off-by: Christopher Li <sparse@chrisli.org>
Gentler handling of bitwise warnings in unary operations

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
simplify handling of newline/whitespace flags in expand()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
fix handling of -include

-include foo.h will search not only in the current directory...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
massage handling of wide string literals/character constants in tokenizer

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
switch to delayed handling of escape sequences

	#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>
L ## 'a' is valid; so's L ## "a"

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Merge git://git.kernel.org/pub/scm/linux/kernel/git/viro/sparse into marge

Pull preprocessor fix from Al Viro.

1) we really, really shouldn't convert escape sequences too early;
   #define A(x) #x
   A('\12')
   should yield "'\\12'", *not* "'\\n'".

2) literal merging handles all sequences of string/wide string
   literals; result is wide if any of them is wide.  string_expression() is
   handling that wrong - "ab"L"c" is L"abc"

3) with support (no matter how cursory) of wide char constants
   and wide string literals, we really ought to handle
    #define A(x,y)
    A(L,'a')
   properly; it's not that tricky - combine() needs to recognize <IDENT["L"],CHAR>
   and <IDENT["L"],STRING> pairs.

4) '\777' is an error, while L'\777' is valid - the value should fit
   into unsigned char or unsigned counterpart of wchar_t.  Note that for string
   literals this happens *after* phase 6 - what matters is the type of literal
   after joining the adjacent ones (see (2) above).

5) stringifying should only quote \ and " in character constants and
   string literals,
    #define A(x) #x
    A(\n)
   should produce "\n", not "\\n"

6) we are losing L when stringifying wide string literals; that's
   wrong.

I've patches hopefully fixing the above.  Basically, I delay interpreting
escape sequences (past the bare minimum needed to find where the token ends)
until we are handling an expression with character constant or string literal
in it.

For character constants I'm keeping the token body in token->embedded -
4-character array replacing token->character.  That covers practically
all realistic instances; character constant *may* be longer than that,
but it has to be something like '\x000000000000000000000000041' - sure,
that's 100% legitimate C and it's going to be the same as '\x41' on
everything, but when was the last time you've seen something like that?
So I've split TOKEN_CHAR into 5 values - TOKEN_CHAR+1--TOKEN_CHAR+4 meaning
1--4 characters kept in ->embedded[], TOKEN_CHAR itself used for extremely
rare cases longer than that (token->string holds the body in that case).
TOKEN_WIDE_CHAR got the same treatment.

AFAICS, with those fixes we get the same behaviour as in gcc for
silently ignored by cpp if the string/char constant doesn't make it
out of preprocessor.  sparse still warns about those.  The situation
with this one is frustrating; on one hand C99 is saying that e.g.
'\x' is not a token.  Moreover, in a footnote in 6.4.4.4 it flat-out
requires diagnostics for such.  On the other hand... footnotes are
informative-only and having "other character" token match ' would
puts us in nasal daemon country, so gcc is free to do whatever it feels
like doing.  I think we shouldn't play that kind of standard-lawyering
*and* sparse has always warned on that, so I've left that warning
in place.

Note that real wchar_t handling is still not there; at the very least,
we need to decide what type will be used for that sucker (for gcc it's
int on all targets we care about), fix the handling of wide string literals
in initializers and evaluate_string() and stop dropping upper bits in
get_string_constant().  That would probably mean not using struct string
for wide ones, as well...  Hell knows; I don't want to touch that right
now.  If anything, I'd rather wait until we get to C11 support - they've
got much saner variants of wide strings there (char16_t/char32_t with
u and U as token prefix as L is used for wchar_t; there's also u8"..." for
UTF8 strings).