I have two lexers - shell.l and javascript.l with prefixes (%option prefix) shell and javascript respectively(%option prefix="shell" in shell.l and %option prefix="javascript" in javascript.l).
I am calling the lexers from another file ( main_file.c) sequentially as:
somefunc(){
.....
shelllex();
......
javascriptlex();
}
In order to call these, I have included the header files of these two lexers in main_file.c as:
#include <.....>
#include "lex.shell.h"
#include "lex.javascript.h"
And, I create these headers when I compile the flex files as:
flex --header-file=lex.shell.h shell.l
flex --header-file=lex.javascript.h javascript.l
gcc -o lang lex.shell.c lex.javascript.c main_file.c -lfl
When I compile main_file.c, I get redefiniton error as below:
In file included from code_detector.c:16:0:
lex.javascript.h:227:29: error: redefinition of ‘yy_nxt’
static yyconst flex_int16_t yy_nxt[][128] =
^
In file included from code_detector.c:15:0:
lex.shell.h:227:29: note: previous definition of ‘yy_nxt’ was here
static yyconst flex_int16_t yy_nxt[][128] =
I have gone through several other SO posts, but didn't find much help.
I would greatly appreciate any help in resolving these!
Thanks!
Apparently, there was a bug which causes the scanner transition table yy_nxt to be incorrectly written to the header file if %option full is present. This should be fixed in the latest version of flex (2.5.39).
If you don't want to upgrade your version of flex, a simple workaround would be to avoid using %option full. You may well find that the speed penalty is not measurable.
Related
I'm currently toying around with the C library NanoVG library. The library depends on OpenGL fucntions and has 2 header files nanovg.h and nanovg_gl.h. The latter file contains part of the implementation. For convenience, I have placed these two header files in /usr/include/nanovg.
When I try to compile the following code to an object file, gcc does not complain:
// working.c
#include <GL/gl.h>
#include <nanovg/nanovg.h>
#define NANOVG_GL3_IMPLEMENTATION
#include <nanovg/nanovg_gl.h>
(Command: gcc -c working.c -o working.o)
Now, I copy the header files from /usr/include/nanovg/ to the working directory, and replace the code with:
// notworking.c
#include <GL/gl.h>
#include "nanovg.h"
#define NANOVG_GL3_IMPLEMENTATION
#include "nanovg_gl.h"
(Command: gcc -c notworking.c -o notworking.o)
Gcc now complains that some OpenGL functions are not declared:
... (many more similar complaints)
src/nanovg_gl.h: In function ‘glnvg__renderDelete’:
src/nanovg_gl.h:1540:3: warning: implicit declaration of function ‘glDeleteBuffers’; did you mean ‘glSelectBuffer’? [-Wimplicit-function-declaration]
1540 | glDeleteBuffers(1, &gl->fragBuf);
| ^~~~~~~~~~~~~~~
...
Why does one file compile smoothly but not the other?
A bit deeper:
Using the cpp tool, I found that the difference between the two pre-processed files is limited to # directives but I don't see any difference as far as the "C content" goes. Below is a snippet of the pre-processed working.c. If I add the # lines from the pre-processed notworking.c, then gcc no longer compiles the pre-processed working.c and complains about a missing declaration for glDeleteBuffers.
// ...
if (gl ==
// # 1533 "src/nanovg_gl.h" 3 4 // <- uncomment this line and glDeleteBuffers is considered missing by gcc
((void *)0)
// # 1533 "src/nanovg_gl.h" // <- idem
) return;
glnvg__deleteShader(&gl->shader);
if (gl->fragBuf != 0)
glDeleteBuffers(1, &gl->fragBuf); // <- the function that gcc complains about is here
// ...
Edit: Just to make sure that I did not do anything sneaky that might have caused the difference, I followed the following steps which hopefully should be reproducible on another computer:
GCC version: gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0
Copy the version of GL/gl.h can be found here to working directory and call it glfoo.h
Copy the headers of nanovg (as found in the repo) to /usr/include/nanovg/ and nanovg/ (relative to working directory).
Save the following as test.c in the working dir:
#include "glfoo.h"
#include <nanovg/nanovg.h>
#define NANOVG_GL3_IMPLEMENTATION
#include <nanovg/nanovg_gl.h>
Run gcc -c test.c -o test.o => compilation works
Replace <...> with ".." on lines 2 and 4 and run command => compilation fails.
Just tried these exact steps and I was able to reproduce it.
After investigating this a bit I found the solution. gcc does not apply the same warning level to system headers as it does for "normal" files (this is mainly because system headers are sometimes doing weird things which are not backed up by the C standard, but are "safe" for the platform they are coming with).
The gcc documentation states (emphasis mine):
-Wsystem-headers:
Print warning messages for constructs found in system header files. Warnings from system headers are normally suppressed, on
the assumption that they usually do not indicate real problems and
would only make the compiler output harder to read. Using this
command-line option tells GCC to emit warnings from system headers as
if they occurred in user code. However, note that using -Wall in
conjunction with this option does not warn about unknown pragmas in
system headers—for that, -Wunknown-pragmas must also be used.
When you include nanovg via <...>, it is treated as a system header.
So doing gcc -Wsystem-headers working.c actually will bring on the warning.
Note that your code is neither working in working.c nor notworking.c, as working.c just hides the warning messages. The proper way to access any GL function beyond what is defined in GL 1.1 is to use the GL extension mechanism, which means you have to query the GL function pointers at run-time. Full GL loader libs like GLEW and glad can do that for you automatically. Many of these loaders (including GLEW and GLAD) work by re-#define-ing every GL function name to an internal function pointer, so when you include the header which comes with the loader, every GL function called in your code (and nanovg's) will be re-routed to the loader-libraries function pointers, and your code can actually work (provided you properly initialize the loader at run-time before any of the GL functions is called).
simply
#include <file.h>
include file from the path listed default to the compiler, while
#include "file.h"
include file from the current folder (where you are compiling).
As in your case , switching from <> to "" makes come files missing which makes that compiler error coming.
I'm trying to set up clang-tidy for enforcing naming conventions in a C project. This project is composed of multiple external sources and uses a plain makefile environment, thus no tool like cmake or bear is available to generate a compilation database.
This is also what I want: Using the custom environment I'd like to selectively invoke clang-tidy for each file that should be checked.
I was configuring the tool, mainly for the check readability-identifier-naming. For testing I have a .c and .h file, both in the same directory, with the following content:
dummy.c
#include "dummy.h"
#include "MISSING_module.h"
// EOF
dummy.h
#ifndef _DUMMY_H_
#define _DUMMY_H_
#include <stdlib.h>
// EOF
The command I'm invoking is
clang-tidy dummy.c -checks='-*,readability-identifier-naming' -- -DCMAKE_EXPORT_COMPILE_COMMANDS=ON`
However, clang-tidy is still following the #include within the C-file and checks for existing headers:
dummy.h:4:10: error: 'stdlib.h' file not found [clang-diagnostic-error]
#include <stdlib.h>
^
Found compiler error(s).
Is there any way to disable this? clang-diagnostic-error is not even enabled as check. Or are there alternative tools I should know of to enforce naming conventions?
Look at the way you are using clang-tidy: the -- option is used to specify compilation options.
clang-diagnostic-error doesn't have anything to do with clang-tidy itself. Those are compiler warnings and you cannot turn them off. Clang-tidy needs the analyzed file to be compile-able to build an AST which it uses internally for the checks. You'll find more on clang-diagnostic-error in clang-tidy documentation.
I am attempting to build a project that comes with an automake/autoconf build system. This is a well-used project, so I'm skeptical about a problem with the configure scripts, makefiles, or code as I received them. It is likely some kind of environment, path, flag, etc problem - something on my end with simply running the right commands with the right parameters.
The configuration step seems to complete in a satisfactory way. When I run make, I'm shown a set of errors primarily of these types:
error: ‘TRUE’ undeclared here (not in a function)
error: ‘struct work’ has no member named ‘version’
error: expected ‘)’ before ‘PRIu64’
Let's focus on the last one, which I have spent time researching - and I suspect all the errors are related to missing definitions. Apparently the print-friendly extended definitions from the C standard library header file inttypes.h is not being found. However, in the configure step everything is claimed to be in order:
configure:4930: checking for inttypes.h
configure:4930: /usr/bin/x86_64-linux-gnu-gcc -c -g -O2 conftest.c >&5
configure:4930: $? = 0
configure:4930: result: yes
All the INTTYPES flags are set correctly if I look in confdefs.h, config.h, config.log Output Variables, etc:
HAVE_INTTYPES_H='1'
#define HAVE_INTTYPES_H 1
The problem is the same whether doing a native build, or cross-compiling (for arm-linux-gnueabihf, aka armhf).
The source .c file in question does have config.h included as you'd expect, which by my understanding via the m4 macros mechanic should be adding an
#include <inttypes.h>
line. Yes, as you may be inclined to ask, if I enter this line myself into the .c file it appears to work and the PRIu64 errors go away.
I'm left with wondering how to debug this type of problem - essentially, everything I am aware of tells me I've done the configure properly, but I'm left with a bogus make process. Aside from trying every ./configure tweak and trick I can find, I've started looking at the auto-generated Makefile.in itself, but nothing so far. Also looking into how I can get the C pre-processor to tell me which header files it's actually inserting.
EDIT: I've confirmed that the -DHAVE_CONFIG_H mechanic looks good through configure, config.log, Makefile, etc.
autoconf does not automatically produce #include directives. You need to do that on your own based on the HAVE_* macros. So you'll have to add something like this:
#ifdef HAVE_INTTYPES_H
# include <inttypes.h>
#endif
If these lines show up in confdefs.h, a temporary header file used by configure scripts, this does excuse your application from performing these #includes. If configure writes them to confdefs.h, this is solely for the benefit of other configure tests, and not for application use.
First, run make -n for the target that failed. This is probably some .o file; you may need some tweaking to get its path correctly.
Now you have the command used to compile your file. If you don't find the problem by meditating on this command, try to run it, adding the -E to force preprocessor output text instead of invoking the compiler.
Note that now the .o file will be text, and you must rebuild it without -E later.
You may find some preprocessor flags useful to get more details: -dM or -dD, or others.
There are two ways to include a file in C :
#include <headerpath/header.h>
or
#include "headerpath/header.h"
The first one will look for the file by using a directory known by the compiler, so we can include standard files without knowing where they are.
The second way will look for the file by using only the path between quotes. (if the search fails, the compiler tries the first way instead).
We have the possibility to add one or more directories into the directories's list that the compiler know (first way). For example with gcc we have the -I option.
So at the end, these two following codes are equivalent (path_to_header is a directory) :
1)
#include "path_to_header/header.h"
int main(void)
{
return (0);
} // Compiling with : gcc main.c
2)
#include <header.h>
int main(void)
{
return (0);
} // Compiling with : gcc main.c -I path_to_header
So my questions are :
With my own header files for example, should I use the 1) or the 2) ? Why ? Maybe it's just a personal choice ? Are there different situations to know ?
Thank's for reading :)
Edit :
I'm not looking for the difference between the two ways (I think I understood them as I explained, thanks to this post), I wanted to know if there are some special situations to know about, maybe for group work or using different compilers for the same program ... Maybe I do not know how to formulate my thoughts (or it's a silly question without real answer), I have to try to know :).
For headers of the standard libraries (which probably are precompiled) use:
#include <stdio.h>
For headers of your project use:
#include "project/header.h"
Use the option -I on the command line for additional libraries.
According to the C standard the only standard difference between them is that #include <...> includes a header while #include "..." includes a source file (and falls back to the <...> behavior if no source file is found). All other differences are implementation-defined.
The distinction is important because, for example, a standard header like stdlib.h might not actually be a file, and is instead injected by the compiler at compile time.
For your own code, since you won't have such header magic, and should know exactly which source files you want included from your own work and which you want the compiler to handle (system libraries and such) you should only use <...> for includes that are not part of your project's file structure.
If your own header files are in a defined path, like the same folder with your files that use your headers you must use this way "header.h".
You must use < header.h > when the header is a system header that is not with your sources where you are including it.
I'm fairly new to programming with c and i am having a hard time including the squash library into my program.
I cloned the repository and ran ./configure and make sudo make install.
That installed the files:
/usr/local/lib/pkgconfig/squash-0.8.pc
/usr/local/lib/libsquash0.8.so.0.8
/usr/local/lib/libsquash0.8.so.0.8.0
/usr/local/lib/libsquash0.8.so
/usr/local/lib/cmake/Squash-0.8.0/SquashConfig.cmake
/usr/local/bin/squash
And some more files in this directories:
/usr/local/include/squash-0.8/
/usr/local/lib/squash/0.8/plugins/
In the squash examples the library is included by #include <squash/squash.h> but when i am trying to compile it i get fatal error: squash/squash.h: No such file or directory
Also #include <squash-0.8/squash.h> doesnt work because then i get fatal error: hedley/hedley.h: No such file or directory That file is located at
/usr/local/include/squash-0.8/squash/hedley/hedley.h
I guess the solution is pretty simple for an experienced c programmer but i am failing here..
Do i need to set some sort of environment variable to let the compiler find the library?
And how do i link the library to the compiler anyway?
I found something like:
-rdynamic ../squash/libsquash0.8.so.0.8 but could not test it yet because of the error above.
Try to change
#include <squash/squash.h>
to
#include "squash/hedley/hedley.h"
or
#include "<squash-0.8/squash/hedley/hedley.h>"
easier and faster solution would be adding the path to your includes during compilation:
-I/usr/local/include/squash-0.8/squash/