It seems that antlr-3.5.1-complete.jar and antlr-3.5.1-complete-no-st3.jar generates
code targeting C runtime that has a lot of the "_empty" identifier in the DFA that
is not defined anywhere.
antlr-3.4 generates the code using dfa31_T_empty which should be the correct id.
I could probably fix this by defining _empty as NULL but that's a hack.
Is there any antlr-3.5.2 or so available that fixes this error?
Cheers,
Adrian Pop/
I have encountered this error too. The simplest and cleanest solution indeed seems to be to add this to your grammar:
#header
{
#define _empty NULL
}
The other solution is to add this define to your compiler macro list (/D _empty=null seems to work in both GCC and MSVC).
Related
I see that there are syslog(2) and syslog(3).
https://man7.org/linux/man-pages/man2/syslog.2.html
https://man7.org/linux/man-pages/man3/syslog.3.html
Since they have the same function time, I don't see how the linker can distinguish them at link time. Could anybody help me understand how the linker correctly resolve the object code under the hood? Thanks.
It doesn't.. syslog(2) has to be called using klogctl() wrapper or using syscall() at your own peril.. syslog(3) is the only definition present in the C library.
This is my code :
int x=65;
char ch{x};
And this is the warning when compiled with `-std=C++11 flag:
Narrowed conversion from "int to char"
But I think there should be an error as x is not a constant and we are initializing ch with a non-constant value. What actually happens?
You're right that the standard treats this as an error, and allows implementations to flat out reject this code.
However, implementations are almost never required to reject code that does not conform to the standard. They have to diagnose the problem, but if they attach the label "warning" to it and continue to accept the code, there is no problem.
In this case, C++11 made perfectly well-formed C++03 code into an error (not entirely your code, but char ch[] = {x}; used to be valid), so compilers have a good reason to treat it as only a warning: they want to accept as much formerly valid code as reasonable, or users might have a good reason to switch to another compiler.
clang will give you an error:
main.cpp:23:9: error: non-constant-expression cannot be narrowed from type 'int' to 'char' in initializer list [-Wc++11-narrowing]
gcc as far as I remember decided to issue warning as there is too many source code that would be broken by such decision.
when you initialize variable using uniform initialization then narrowing conversions are forbidden.
MingGW's gcc (4.8.1) reports the following error (and more to come) when I try to compile Expstack.c:
parser.h:168:20: error: field '__p__environ' declared as a function
struct term *environ;
where 'environ' is declared inside 'struct term{ ... }'. In unistd.h you find
char **environ
but nowhere a '__p__environ'.
Some other fields are declared likewise, but are accepted. Subsequent errors related to environ are reported as follows
Expstack.c:1170:38: error: expected identifier before '(' token
case Term_src: return e->item.src->environ;
^
Cygwin's gcc (4.8.3) accepts these constructs and has done so over various versions since
2006 at least, and gcc with various versions of Linux before that.
The source text uses CRLF despite my attempts to convert to DOS, and this is my only guess for an explanation.
I'll appreciate clues or ideas to fix the problem, but renaming the field is not especially attractive and ought to be totally irrelevant.
This is very unlikely to have to do with CR/LF.
The name ought to be irrelevant but it isn't: this one relates to the Windows integration that MinGW does and Cygwin does not, as alluded to in http://sourceforge.net/p/mingw/mailman/message/14901207/ (that person is trying to use an extern environ that it expects to be defined by the system. Clearly, the fashion in which MinGW developers have made this variable available breaks the use of the name as a struct member).
You should report this as a MinGW bug. Unpleasant as it may be, in the interim, renaming the member is the simplest workaround. It is possible that a well-placed #undef environ might help, but no guarantees.
I'm getting the error
Cannot Initialize a variable of type 'LineVertex*' (aka '_Line Vertex*) with an rvalue of type 'void*'
This is the line of code:
LineVertex *vertices = calloc(sizeof(LineVertex*), numberOfVertices);
This worked until I switched my class from .m to .mm and now it's throwing me that error and I don't know how to fix it. I am using Xcode 5 and the latest version of Cocos2D. I read that it might have something to do with casting but I honestly don't know how to do that, I couldn't get it to work correctly. Thank you so much in advance!
It should be like this.
LineVertex *vertices = static_cast<LineVertex *>(calloc(sizeof(LineVertex*), numberOfVertices));
For further information, please take a look at the FAQ.
Bjarne Stroustrup's C++ Style and Technique FAQ: Why must I use a cast to convert from void*?
I'm building a project on XCode 3.2.6 gcc 4.2 which uses the boost graph library (1.45). The build results in an annoying warning:
/include/boost/concept/detail/concept_def.hpp:34:1: warning: "BOOST_concept" redefined
concept_def.hpp does not appear to contain any protection to prevent this sort of multiple definition and the boost graph library seems to be constructed so as to ensure it is included multiple times. In my case the include sequences are:
One definition:
/include/boost/concept/detail/concept_def.hpp:34
/include/boost/graph/buffer_concepts.hpp:9,
/include/boost/graph/graph_concepts.hpp:21,
/include/boost/graph/detail/adjacency_list.hpp:31,
Another definition:
/include/boost/concept/detail/concept_def.hpp:34
/include/boost/graph/graph_concepts.hpp:25,
/include/boost/graph/detail/adjacency_list.hpp:31,
While this is only a warning I find it hard to believe this was released with boost and hence expect I am doing something wrong.
Any ideas?
Thanks,
Barrie
Error only seems to happen on XCode, all of our other platforms (linux gcc4, msvc2010) build fine.
Here is our workaround:
boost/concept/detail/concept_def.hpp:12
#ifdef BOOST_concept
# undef BOOST_concept
#endif
PS:
In case you are wondering why we don't put an #ifndef guard around the whole file then know that for some strange reason this does not work!
The issue posted in the page is the same one we encountered. Following is our solution based on the concention
add #include in the end of a hpp file if is included in the beginning of the file.
we added the include concept_undef.hpp in the end of buffer_concepts.hpp accordingly and it does solve the compiling error.