./theheader.h:349: Error: Syntax error in input(3).
Offending line:
string read_gdbm(GDBM_FILE dbf, string key_str, bool show_err = gbls.verbose);
Any ideas?
Typically, a syntax error in SWIG means that it can't understand the line in question (which can be annoying, because the line numbers don't follow macros such as %defines). So I suggest you check that string (should it be std::string? has it been defined?), GDBM_FILE (has it been defined? should it be in a namespace?) and maybe gbls.verbose (has it been defined?) make sense to SWIG. It may help to run swig with the -E option (be sure to redirect the stdout), find the corresponding line and search backward for each type involved. You may need to add some #includes.
Also check the previous line, to ensure you're not missing a semicolon, or something like that.
As a side note, I've run into the same issue for different reasons: I was trying to use a vector < vector < double >>. Now the ">>" character sequence mustn't be used with templates according to the C++99 standard, hence the swig error message popped up. The solution was to simply add an extra space to separate them.
I hit a similar error. I'll clarify my process, hope it can be helpful.
lib.i:
...
%begin %{
#include "header1.h"
%}
...
%include "header1.h"
header1.h:
19 typedef struct T {
...
23 } PACKED TlvHdr;
The error message just as below
./header1.h:23: Error: Syntax error in input(3).
I check the SWIG doc(http://www.swig.org/Doc1.3/SWIG.html 5.7.1) and found that the syntax error is so common, it's probably caused by a SWIG bug.
The doc recommended when encountering a syntax error to use #ifndef SWIG to omit statements that will make SWIG parser issue an error. So I changed the header1.h file, then the error disappeared.
header1.h:
#ifndef SWIG
19 typedef struct T {
...
23 } PACKED TlvHdr;
#endif
If you can't modify theheader.h file, you can make a new header file that just contains the declarations you need and replace the file from theheader.h to your new header file at %include directive
I had a similar issue and -E helped me understand that a macro definition was hidden inside an #ifndef SWIG block. I suspect that here it does not see the definition of GDBM_FILE, likely because it does not recurse.
Related
So I am trying to use bison's semantic predicate feature, but I've been running into a few issues trying to have it work.
The problem comes when I try to compile the generated .tab.c file with gcc. I am using gcc 7.1.0 and bison 3.0.4. Here's a snippet of the compile error:
test2.tab.c: In function ‘yyuserAction’:
test2.tab.c:811:12: error: stray ‘#’ in program
if (! (#line 19 "test2.y" /* glr.c:816 */
^
test2.tab.c:811:13: error: ‘line’ undeclared (first use in this function); did you mean ‘uint’?
if (! (#line 19 "test2.y" /* glr.c:816 */
^~~~
uint
So I've taken bison's example for semantic predicate, and made it a working example:
%{
int new_syntax = 0;
int yyerror(const char* msg) { /* some error handling */ }
%}
%token id
%glr-parser
%%
prog: %empty
| prog widget
| prog flip
;
widget: %?{ new_syntax } "widget" id old_arg
| %?{ !new_syntax } "widget" id new_arg
;
flip: "flip" { new_syntax = !new_syntax; }
;
old_arg: /* something here */
;
new_arg: /* something else here */
;
%%
After playing around with the tab file, I realized that adding a newline before the #line directives resolves the syntax error, (but it feels kinda hacky directly modifying the generated file. Plus, you would have to align with some spaces in order for gcc to compute the right column position of the code).
I wonder if is this a bug with bison itself, or is it that I'm using semantic predicates wrong, or if this syntax was correct in an earlier version of gcc, or something else.
I've also tried searching the web for this issue, or for a bug already filed with bison, but I found none. (The latest bison version seems to be 3-ish years old. I would be surprised if this issue has not been addressed anywhere at all). Can someone enlighten me about this issue? Thanks.
If necessary, I could try filing a bug with bison (need to figure out how to do that), but I'm not sure if it's my own issue or what not.
As far as I can see, this bug has been present for some time (possibly since the semantic predicate feature was introduced, although it seems like someone should have tested it at some point with some version of bison.)
The simplest workaround is to turn off the generation of #line directives, which you can do by simply adding -l (or --no-lines) to the bison command line. However, that will make it harder to interpret error messages which would otherwise refer to line numbers in your bison grammar file.
As a second workaround, you could find the file c.m4, which is probably in /usr/share/bison/c.m4 (of course, that depends on your distribution). Line 462 of that file (in bison 3.0.4) reads:
if (! ($2)) YYERROR;
If you add a newline just before $2, so that it reads
if (! (
$2)) YYERROR;
then everything should work out fine. (At least, it did when I tested it.)
I'm debugging a very large project and I added in one file: "file_1.c" an include statement for another file #include "header_2.h". I got 2 compilation errors:
error (dcc:1633): parse error near '100' (Built from Project 'project_3')
error (dcc:1100): member is incomplete (Built from Project 'project_3')
but the locations of the errors didn't make sense, because the code there was part of a typedef:
typedef struct
{
unsigned char A:1, // <- first error here (dcc:1633)
B:1,
C:6;
}TYPE_A;
typedef struct
{
TYPE_A D; // <- second error here (dcc:1100)
TYPE_B E;
TYPE_C F;
}FOO_T;
Now, this header header_2.h is included in other c files and gave me no problems.
I thought that the case here could be circular include but I checked the header and there are include guards there. Once I remove the include, the parse errors disappeared and the compilation run OK (since the include was planted there for some code piece I removed).
I also checked the actual include line (in file_1.c) to see if maybe there was a parse error there, but nope.
What can cause this problem and how should I handle it?
Note: the header itself is error free. It is included in other c files and shows no errors there. Also, without this specific include, the compiler runs fine.
Probably the header which causes the problem contains something like
#define A 100
which changes the meaning of the token A.
That will only cause issues if the macro defined in the header is inadvertently used in another file; by themselves, the header and the other file are unproblematic.
How can I be able to write C code with different command names instead of the existing, and also to get different compiling warning, errors etc?
For example, replace the 'while' loop declaration with 'foobar', so that:
foobar (i<10) i++;
will act as:
while (i<10) i++;
and to replace a compilation error message from:
prog.c:4:2: error: 'i' undeclared
to:
prog.c:4:2: banana kiwi: 'i' orange apple tomato
A use case for this is making C based on a human-language other than english.
For the input language, you can use macros to define alternate names for things.
#define foobar int
Or better to use typedef for types.
typedef int foobar;
Neither of these removes int from the namespace.
If the compiler is made using a grammar file and a compiler-compiler, then you may be able to edit the keywords in the grammar to change the names without introducing new names. This will be the .yacc or .bison or .antlr or sthg file.
For the error messages, those are going to be baked-in to the compiler or in a strings or config file. You'll have to edit those files, or better copy into new locale-variant and modify.
Or run the compiler with a filter that replaces error with banana kiwi. sed, awk, m4 -- many common tools for substitutions.
To give an alias to a type you can use typedef:
typedef int foobar;
foobar i; // is a int
About the error message, it's more complicated and is inside the compiler code...
I am including two diferent lex parsers in my C code so to include the second one defined a Prefix on it:
%option prefix="prep"
When I integrated this one in the global proyect It compiles without errors but on execution, If I try to call prepparse (formerly yyparse) I get this error:
undefined symbol: prepparse
I have tried including an external reference (not quite sure if this is correct):
extern int prepparse(void);
And defining it in the Lex header:
#define yyparse prepparse
But I still get the same error.
Any idea of what I am doing wrong?
I think I got it. I have found I omited one information that has proben important. As I only wanted to alter some tokens and not defining a full language (it is only preparsing) I dind't define a Yacc file, so I was not actually a parser but a Lexer what I had to call. So the command is not preparse but preplex.
I stil don't have it working but I guess it is another different issue.
I have been trying to compile netcat.c on AIX for some time (using the command make aix), but the compiler gives me some weird feedback such as :
"netcat.c", line 117.12: 1506-275 (S) Unexpected text 'int' encountered.
when checked the file netcat.c at line 117, I would find the line (second line in code below):
#ifdef HAVE_BIND
extern int h_errno;
/* stolen almost wholesale from bsd herror.c */
even if I changed the int into char for the same of testing, save the file and re-run the command I get the same error
am I missing something in reading the error code?
If you're using xlc (especially older ones), it's normally caused by declarations after statements, something like:
i = i + 1;
int x;
You probably need to give us a little more context, such as 10 or so lines before the error line.
My advice would be to get gcc running on that box if you are using an older xlc. IBM makes some fine compilers now but the earlier ones weren't so crash hot (in my opinion).
When innocent-looking code produces bizarre errors, try running the code through the C preprocessor stage, and looking at it then. Sometimes macros do very funny things.
Also note that a problem on an earlier line (missing semicolon, etc.) might produce an error message on a later line.
The post maybe already a little outdated, but just in case someone else comes along with the same problem ...
Here (AIX 7.1) h_errno is defined as macro in netdb.h.
/usr/include/netdb.h:#define h_errno (*(int *)h_errno_which())
Therefore the declaration in netcat.c line 117 does not work.
I just changed the line into
#ifndef h_errno
extern int h_errno;
#endif
and the compilation worked smoothly.
#A.Rashad, I moved the HAVE_BIND #ifdef block from line 117 to line 30 which is just under the #include "generic.h" declaration. This permitted the xlc to compile it. The (S)yntax error messages are gone and while there are some (W)arning messages, I do get an nc binary at the end!
hth,
Kevin