Thank you for comment. I think now I'm able to describe a problem a
bit more clear.
Assume I have the following C code in my emacs buffer:
semantic-complete-analyze-inline raises «Inline completion not
needed.» message, but it should complete the malloc() function though.
I think I understand why that happens.
File /usr/include/stdlib.h contains something like this:
extern void *malloc (size_t __size) __THROW __attribute_malloc__ __wur;
__attribute_malloc__ macro is defined in the file
/usr/include/sys/cdefs.h which is included to the file
used in stdlib.h.
cdefs.h has something like this:
#if __GNUC_PREREQ (2,96)
# define __attribute_malloc__ __attribute__ ((__malloc__))
# define __attribute_malloc__ /* Ignore */
As I can see using semanticdb-find-adebug-scanned-includes command,
semantic has scanned sys/cdefs.h
*scanned stdlib.h : /home/dk/development/test/semantic/test.c
*scanned features.h : /usr/include/stdlib.h
*scanned stddef.h : /usr/include/stdlib.h
*scanned bits/predefs.h : /usr/include/features.h
*scanned sys/cdefs.h : /usr/include/features.h
*scanned gnu/stubs.h : /usr/include/features.h
*duplicate features.h : /usr/include/sys/cdefs.h
*scanned bits/wordsize.h : /usr/include/sys/cdefs.h
*duplicate bits/wordsize.h : /usr/include/gnu/stubs.h
But for some reason it didn't inserted __attribute_malloc__ to its
What should I say to semantic to make it add macros defined in header
files to its spp table?
The problem can be fixed by explicitly adding /usr/include/sys/cdefs.h
to semantic-lex-c-preprocessor-symbol-file list:
On Thu, Apr 7, 2011 at 10:32 PM, David Engster <deng@...> wrote:
> Dan Kruchinin writes:
>> As I understood the second case works because it parser thinks that
>> __THROW is throw from C++.
> No, it's because __THROW is explicitly included in
> semantic-lex-c-preprocessor-symbol-map-builtin. This preprocessor stuff
> is a never-ending issue, unfortunately. You can circumvent that problem
> by doing
> (add-to-list 'semantic-lex-c-preprocessor-symbol-map '("SOMESYMBOL" . ""))
> As you can see in the *-symbol-map-builtin variable, we also include
> some symbols from the glibc by default; if you think there are some
> important ones missing, please let us know and we'll include them there.