I am running ctags on this file and it is ignoring the get_read_pos() function. This is what I'm doing:
$ ctags AIOContinuousBuffer.c
$ grep get_read_pos tags || echo Not Found
Not Found
Shouldn't it find the function? I am running on Ubuntu 14.04.2 LTS
The file is being parsed as C. If you use --language-force=C++ the function you are referring to appears in the output tags file. And, as far as I understand, namespace is still processed by the C parser, but since it is not a contextual language its parentheses are skipped. Note that ctags will not understand the #ifdef __cplusplus to ignore the name space declaration.
Related
I am trying to run static analysis on my code using a tool. The Makefile contains:
export TASK=MY_TASK_NAME
my_static_code_tool.exe <arguments> -- gcc <arguments..> -D__TASK_NAME__=\"$(TASK)\" -o missionFile.o missionFile.c
I find that this executes without an issue on RedHat but fails to run on my Cygwin environment. I assign __TASK_NAME__ variable to an unsigned char in a C file such as:
const unsigned char TASK_NAME[] = __TASK_NAME__;
I get the error as:
gcc: no input files
I am very sure my arguments are all correct and I am referring to sources in the correct directory. To me it looks as if the -- stops the parsing of escape sequences in the command on Windows. Can anybody help me with a workaround?
The -- is used by the tool to introduce the compiler and its arguments [and thereby inform the tool that the following is compiler specific]. The GCC had all the required source/files/configuration defined in the Makefile. However it was not processed completely in the Cygwin shell (the command processing stopped with the escaping hence the corresponding gcc error).
The solution I employed to make this work was pre-processor stringification.
C file:
#define STRINGIFY_IT(str) STRING_OF(str)
#define STRING_OF(str) #str
const unsigned char TASK_NAME[] = STRINGIFY_IT(__TASK_NAME__);
Makefile:
export TASK=MY_TASK_NAME
my_static_code_tool.exe <arguments> -- gcc <arguments..> -D__TASK_NAME__=$(TASK) -o missionFile.o missionFile.c
So, if any of you face such problems in the future with 3rd party tools, try not to pass string arguments through the command line to GCC (as they will need to be escaped and might break the command)
I've currently run in such a problem, in fact caused by the package maintainer(s), who simply did not consider that a certain preprocessor definition was not available until version X of a certain toolkit package required in the dependencies (which is currently in testing stage). It was fixable by simply adding an additional #define to a header file in the base system, making the project compile fine again.
However, what if I had no root access to the system? Could I also add a #define new_macro "i am from the future" at compile time, e. g. to configure?
When reading myself through the matter, I thought that it might maybe work with the DEFS environment variable, but apparently this is not meant to be used for C preprocessor directives.
So can this be accomplished at all?
Thanks, but unfortunately a huge problem is the strings in quotes
Create a file, for example at ~/somedir/mycompiler with content:
#!/bin/sh
gcc -Dnew_macro="i am from the future" "$#"
add executable permissions chmod +x ~/somedir/mycompiler and then pass that as parameter to configure:
./configure CC="$HOME"/somedir/mycompiler ...
Configure script in turn will use that script to compile everything, passing -D everywhere, and quotes will be properly parsed by sh.
I have seen makefiles use the -DLINUX flag but can't find any documentation on it.
Is there a place to find information on tools like 'gcc' that are more up-to-date than
the officially released manuals?
It just defines the LINUX symbol for the C preprocessor.
Probably there are pieces of the code that look like:
#ifdef LINUX
//Linux-specific code
#elif defined WINDOWS
//Windows-specific code
#endif
It's the -D option controlling the preprocessor. It defines the LINUX macro, that you can then use with #ifdef.
According to man gcc:
-D name
Predefine name as a macro, with definition 1.
Hence, it let define a constant from the compilation command line.
It defines a preprocessor macro named LINUX. That's it. The macro itself, LINUX, is not a predefined one, it's probably used for a cross-platform codebase where specific sections of code are enabled for a Linux target. For this purpose, one could actually have re-used the predefined linux or __linux__ ones (see the output of gcc -dP -E - < /dev/null to get all the predefined macros on your system).
See http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/ for the standard documentation on gcc (that's obviously for GCC 4.8.2). To my knowledge, that's the best place to look for if this documentation is not already installed (or up-to-date) on your system.
I am (was) using the __FILE__ and __LINE__ macros for printing diagnostic messages out of my code. This works quite well when you use GCC with make, the file is as short as you specified it on the command line. I recently switched to using CodeLite which uses fully qualified file names (at least under windows) when building. Suddenly my diagnostic output is almost not readable.
It there a way to get only the file component of the filename in the preprocessor? I can live with a non portable GCC specific solution. (I will fallback to plain __FILE__ other cases.)
Sure I can pass the contents of __FILE__ through a function and extract only the file component, but string operations was not what I had in mind for diagnostic messages that should not change runtime behavior...
NOTE: I use the filename the way GNU uses it. A Path is collection of filenames and a filename is either a relative or absolute identifier of a file. A filename can be made up of a directory component and file component.
If you are using GNU Make then you can simply pass -D BASE_FILE_NAME=\"$*.c\" in on the preprocessing stage of compilation (if you're doing them separately, or at compilation if in a single stage, which is the norm).
This depends upon the way you have your file names determined. Mine come from a list of plain file names and are prefixed with directories using functions in the makefile at a later stage.
IE, this works well for me, but your mileage may vary! :-)
A simplified version of my make "code" :
CLASSES = main.c init.c
PREPROCESSED = $(patsubst %.c,$(PPCDIR)/%.pp.c,$(CLASSES))
$(PREPROCESSED): $(PPCDIR)/%.pp.c: %.c $(ALLH)
$(GCC) $(GCCOPTS) -D BASE_FILE_NAME=\"$*\" -E $< > $#
The simply use BASE_FILE_NAME in your code as you like :-)
There is no known preprocessor macro that provides the functionality. Passing __FILE__ through a function seams like the only sensible option.
In reply to FredCooke above, you can exchange this line:
-D BASE_FILE_NAME=\"$*.c\"
With:
-D BASE_FILE_NAME=\"$(<F)\"
This will give you proper file name expansion, for .cpp as well.
As has already been mentioned in other answers, the only portable way to do this is by passing in a define from the compiler, there are however compiler spesific extensions:
Clang: __FILE_NAME__
GCC: __BASE_FILE__
i'm currently refactoring a C-project, throwing about 1000 warnings at me.
is there a way to highlight and filter these warnings.
(eg make all index warnings red, unused blue, and some other)
most likely some ides can do that, but that's no solution for me.
This is really basic, but I've been using grep...
make 2>&1 | grep --color -iP "\^|warning:|error:|"
just to quickly draw the eye to the error line and offending section pointed to by ^.
I've found other methods over-use colour and you end up with the same problem. I guess you could also inject colour escape sequences with sed.
Try the colorgcc Debian package. There are also three other packages I found: Johannes Schlüter's colorgcc, or this package in German, or this Sourceforge project
Gcc 4.9 seems to have added this feature via the -fdiagnostics-color flag: http://gcc.gnu.org/onlinedocs/gcc/Language-Independent-Options.html#index-fdiagnostics-color-246
The warn_summary script is pretty nice
You can get a count of all your warnings, the type and also just print out the warnings without all the other output from gcc.
gcc <...> | tee buildoutput
warn_summary -s 0 -wpass buildoutput
warn_summary -s 0 buildoutput
You could pipe the output of your compile through grep:
make 2> error.txt; grep -e error error.txt
Compiling in emacs gives you some highlighting. Presumable the details are amenable to customization.
Use M-x compile and issue you usual build command (defaults to make -k).
I've been using pretty make, which formats and colorizes gcc output nicely. The indented format for command options is very clear.
I did end up hacking it to swap the deprecated popen2 to subprocess.
This answer is more about the general approach to reworking old C code.
Large volumes of warnings usually are repetitions of the same small group of warnings because of some errors in header files that are included all over the place by other source code files.
If you're refactoring an old C project, quite often most warning come down to various things such as old K'n'R function dec's, previously allowed casts now being highlighted with a warning, using deprecated functions, etc.
Assuming you're using (g)make to build the project, I'd run the compile using the following command:
gmake 2>&1 | tee results
Then you can have a look at the results file and see what are the most popular warnings you're getting. Start with eliminating all existing warnings before getting on to any refactoring of the code base.
Running the make from within vim gives you lots of possibilities to couple the error and warning messages with the source files.