Can anyone help me on how to enable C-style included file in ocamlyacc? For example: #include "mylib.txt";.
The #include facility is not part of yacc, it's part of C. You can use it with yacc because yacc generates C as its output. Since OCaml doesn't have a preprocessor, you can't do the same with ocamlyacc.
The usual use of this facility with yacc is for sharing token definitions between your scanner and your parser.
With ocamlyacc, the standard thing to do is to define your token symbols in your ocamlyacc input. Then in your scanner, you use the names from your parser module. Concretely speaking, you might open your parser module in your scanner code.
Related
I trying to debug a the yacc generated component for awk (awk.g.c) but when I define YYDEBUG it includes y.debug which I don't seem to have.
Where does y.debug come from?
Without it there are several references that are undefined.
I'm compiling the old 32v or V7 version of awk so I'm not sure if this is something that still exists.
Some versions of yacc (in particular, the AT&T version, still available as part of Plan 9) generated an additional file with the suffix .debug containing debugging information, notably the table which translated symbol numbers back into names. Modern yacc-alikes just insert this information into the generated C file, on the grounds that the memory consumption is basically trivial these days.
The name table might not be generated if you don't request it, but the way you ask for it depends on the yacc version:
Most bison versions only generate the table if the trace option is enabled. (Posix mandates -t for this, but bison provides a host of alternatives and not all historical yaccs complied.)
As indicated above, some really old yaccs put the name table into y.debug. The AT&T implementation, as I mentioned above, always did this, but guarded the #include line with a preprocessor conditional on YY_DEBUG
However, the yacc implementation you pointed to in a comment, which uses the conditionally-included y.debug mechanism, only generates the y.debug file if you invoke it with the -D flag. So that's what you need to do.
Background notes
I unearthed the information in point 3 from the V10 source linked in a comment. The download link is at the top of this page; that wasn't immediately obvious from the link in the comment. (That's the complete source tarball, which is about 70MB. The individual files linked to by the link in the comment have been HTMLised, which makes them a pain to work with.) I could have saved myself some time by reading the release notes (called yaccnews rather than CHANGES). The last note in that file describes the implementation, and I include the paragraph here since it has all the details on how debugging works in this particular yacc version.
8/11/81
Debugging changed. If the parser starts with %{#define YYDEBUG %} and yacc is invoked as yacc -D (for Debugging), then the parser uses an external variable named yydebug to control debugging output. If yydebug == 1, the parser prints out the text of the reduction when it performs one. If yydebug == 2, the parser also prints out the name of the token returned by each call to yylex, and if yydebug == 3, the parser also prints out the active items each time it changes state (this is uninteresting).
For what it's worth, it should be possible to generate a working, compilable parser using a modern yacc (such as bison or byacc). In the long run, that will probably be easier. (If you use bison and you require legacy yacc compatibility, you can use the -y flag. That flag is not supported by byacc, which claims to be legacy compatible regardless.)
I'm using CodeBlocks and GCC compiler. I'd like to use "string safe functions" e.g strlen_s, strcpy_s, but compiler shows an error:
Undefined reference to strlen_s.
I then add a line to the code:
#define __STDC_WANT_LIB_EXT1__ 1
As well as writing the following in the Compiler Options (settings -> compiler -> global compiler settings -> other compiler options):
-std=c11
In the book that I'm reading there's a code to checking whether my compiler supports these functions. The code is as follows:
#include <stdio.h>
int main()
{
#if defined __STDC_WANT_LIB_EXT1__
printf("optional functions are defined");
#else
printf("optional functions are not defined");
#endif
return 0;
}
When I run this code I see "optional functions are defined". I've also reinstalled CodeBlocks but I still get these errors.
Should I install another compiler? If I should, which one will be the best?
#define __STDC_WANT_LIB_EXT1__ 1 is expected to be defined by your application - you have to define it yourself to enable the use of the bounds-checking interface functions.
In order to see if the bounds-checking interface is at all available, you need to check if __STDC_LIB_EXT1__ is defined by the compiler.
Note that no function called strlen_s exists.
This test is not sufficient, you should also test whether the implementation defines the macro __STDC_LIB_EXT1__.
These functions are from a part of the C standard that is called "Annex K" and that is optional. With this macro you test if your C library provides that feature, with the WANT macro defined before any includes you tell the compiler that you want to use these features from Annex K.
Annex K is much controversial, and not many public domain C libraries implement it. Many people think that its interfaces don't provide the security that it claims.
And for the book that you are reading this doesn't seem to be too reliable. But then, I may be biased on that point.
I'm trying to write a python interface to a shared library. The library has headers provided, and so I'd like to be able to used them as the cdef input.
I realise that I need to preprocess the headers before I load them into CFFI. However, the library headers have code something like this:
#define ONE 1
char something[250+ONE];
which comes out of the preprocessor (gcc -E) as
char something[250+1];
CFFI complains that the 251 is not a simple numerical constant (which as far as parsing is concerned, is true). Is there a way to make GCC evaluate these integer constants at preprocessor time?
(Of course, I realise I can just manually change the header file, but I'd like to see if I can use the header files that are shipped with the library)
I want to use the aspectc++ compiler for a C++11-project. I have read in the manual, that c++11 support will come with version 2. I thought that aspect weaving happens only on the code level, so why does it depend on the used C++ version? Why does aspectc++ care the source code when it just has to weave the aspects to generate a composed piece of code? Is there a way to use aspectc++ for C++11 source code? Or is there an alternative which can handle it?
This post is already a bit older, i know.
Nevertheless I'd like to answer the question why aspectC++ depends on the C++-version:
aspectC++ internally parses the code (amongst other things to identify the locations where to weave the code). Not all of this can be done by external parsers therefore it needs to understand the syntax basically itself.
Some new c++-constructions from C++11 like attributes ([[...]]) could not be handeled by the AspectC++-compiler version < 2.0.
To use c++11 for compiling just use -std=c++11
In assembly language, it's easy to define a section like:
.section foo
How can this be done in C code? I want to put a piece of C code in a special section rather than .text, so I will be able to put that section in a special location in the linker script.
I'm using GCC.
The C standard doesn't say anything about "sections" in the sense that you mean, so you'll need to use extensions specific to your compiler.
With GCC, you will want to use the section attribute:
extern void foobar(void) __attribute__((section("bar")));
There is some limited documentation here, including a warning:
Some file formats do not support
arbitrary sections so the section
attribute is not available on all
platforms. If you need to map the
entire contents of a module to a
particular section, consider using the
facilities of the linker instead.