So I'm writing a bison (without lex) parser and now I want to read the input code from file and to write the output to another file.
Searching the stackoverflow for some time I found that this way should be good.
bison.y:
%{
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
extern FILE *yyin;
int yylex() { return getc(stdin); }
void yyerror(char *s) {
fprintf (stderr, "%s\n", s);
}
int counter = 1;
char filename2[10] = "dest.ll";
FILE *f2;
%}
%name parse
%%
//grammars
%%
int main(int argc, char *argv[]) {
yyin = fopen(argv[1], "r");
if (argc > 2)
f2 = fopen(argv[2], "w");
else
f2 = fopen(filename2, "w");
yyparse();
return 0;
}
Then i compile it this way:
bison bison.y
cc -ly bison.tab.c
And here the result of cc-compilation:
/tmp/ccNqiuhW.o: In function `main':
bison.tab.c:(.text+0x960): multiple definition of `main'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/liby.a(main.o):(.text.startup+0x0): first defined here
/tmp/ccNqiuhW.o: In function `main':
bison.tab.c:(.text+0x98c): undefined reference to `yyin'
collect2: error: ld returned 1 exit status
The output bison.tab.c file have only 1 main. Ofc int/void main doesn't matter. Can you teach me how to do it correctly?
P.S. By the way, I don't want to spam different posts, and have a little question here. How can I store the string (char *) in $$ in bison? For example, I want to generate a code string after I met the int grammar. I have this error and can't find the answer:
bison.y:94:8: warning: assignment makes integer from pointer without a cast [-Wint-conversion]
INTNUM: NUMBER | DIGIT INTNUM {$$ = "string"};
bison.y: In function ‘yyparse’:
bison.y:28:15: warning: format ‘%s’ expects argument of type ‘char *’, but argument 3 has type ‘int’ [-Wformat=]
PROGRAM: EXPRS { fprintf(f2, "%s: string here %d.\n", $$, counter++) };
will be extremely good if I find the help.
You are linking library liby (linker option -ly). The Bison manual has this to say about it:
The Yacc library contains default implementations of the yyerror and
main functions.
So that's why you have multiple definitions of main. You provide one, and there's one in liby.
Moreover, the docs go on to say that
These default implementations are normally not useful, but POSIX requires them.
(Emphasis added)
You do not need to link liby in order to build a program that includes a bison-generated parser, and normally you should not do so. Instead, provide your own main() and your own yyerror(), both of which you've already done.
Additionally, you are expected to provide a definition of yyin, not just a declaration, whether you link liby or not. To do so, remove the extern keyword from the declaration of yyin in your grammar file.
Your grammar is not complete (there are no rules at all) and the %name directive is not documented and is not recognized by my Bison, but if I add a dummy rule and comment out the %name, in conjunction with the other changes discussed, then bison generates a C source file for me that can be successfully compiled to an executable (without liby).
Related
I am trying to test writing in a file in Contiki. here is the code I used :
#include "contiki.h"
#include <stdio.h>
#define LEN 256
PROCESS(test_process, "Coffee test process");
AUTOSTART_PROCESSES(&test_process);
PROCESS_THREAD(test_process, ev, data)
/**/
{
PROCESS_BEGIN();
FILE * fp;
int i;
/* open the file for writing*/
fp = fopen ("/home/user/contiki/examples/mySim/1.txt","w");
/* write 10 lines of text into the file stream*/
for(i = 0; i < 10;i++){
fprintf (fp, "This is line %d\n",i + 1);
}
/* close the file*/
fclose (fp);
PROCESS_END();
}
I get this error message after compiling in Cooja simulator:
test.c: In function ‘process_thread_test_process’:
test.c:12:1: error: unknown type name ‘FILE’
test.c:15:4: warning: implicit declaration of function ‘fopen’ [-Wimplicit-function-declaration]
test.c:15:7: warning: assignment makes pointer from integer without a cast [enabled by default]
test.c:19:8: warning: implicit declaration of function ‘fprintf’ [-Wimplicit-function-declaration]
test.c:19:8: warning: incompatible implicit declaration of built-in function ‘fprintf’ [enabled by default]
test.c:23:4: warning: implicit declaration of function ‘fclose’ [-Wimplicit-function-declaration]
make: *** [test.co] Error 1
Process returned error code 2
does anyone has any idea about the problem?
Contiki does not provide/support the POSIX file API, the same way it does not have many other things (POSIX sockets API, POSIX process creation and control API). Instead, it provides its own filesystem API ("protosockets" API, "protothreads" API etc.).
There are two filesystem implementations: CFS (Contiki File System) and Coffee. You can use the functions described in the Wiki page; they are analogues to low-level POSIX file API (e.g. cfs_open is similar to POSIX open, cfs_close to POSIX close and so on). There are no analogues for buffered I/O functionality (fopen, fclose) and the FILE structure does not exist.
My C code was as following:
[Linux:/si/usr/hrl]vi test.c
#include <stdio.h>
FILE * hw = stdout;
int main(void)
{
return 0;
}
When I compile on SUSE , it make the error like that:
[Linux:/si/usr/hrl]cc test.c -o test
test.c:3: error: initializer element is not constant
I have a look for the header file stdio.h and find that stdout seems to have be defined as a constant. So why the error produce?By the way, I compile the same code on AIX ,it results of success.
The standard does not require stdin, stdout and stderr to be constants.
The draft n1256 for C99 says in 7.19.1 Input/output <stdio.h>
The header declares ...
...
TMP_MAX
which expands to an integer constant expression ...
stderr
stdin
stdout
which are expressions of type ‘‘pointer to FILE’’ ...
(emphasize mine)
It is explicitely stated that some other values are constant, whereas nothing is said for stdin, stdout and stderr
So you must put initialization in main:
#include <stdio.h>
FILE * hw;
int main(void)
{
hw = stdout;
...
return 0;
}
In AIX standard library, stdout happens to be a constant, but it is just an implementation detail and you cannot rely on that, as it could break in any newer version.
But you should not rely either on stdout being a variable (nor even a lvalue), because it is also an implementation detail in GCC library.
If you cannot change much of your code, and just need a GCC hack to make it compilable, you could try to use the gcc constructor attribute extension.
Extract from gcc documentation
6.31 Declaring Attributes of Functions
In GNU C, you declare certain things about functions called in your program which help the compiler optimize function calls and check your code more carefully.
The keyword __attribute__ allows you to specify special attributes when making a declaration. This keyword is followed by an attribute specification inside double parentheses. The following attributes are currently defined for functions on all targets: ... ,constructor, ...
...
The constructor attribute causes the function to be called automatically before execution enters main () ...
So you could use:
#include <stdio.h>
FILE * hw;
void initHw(void) __attribute__((constructor)) {
hw = stdout;
}
int main(void)
{
return 0;
}
But BEWARE: it is a gcc extension, meaning that your code is not correct C.
I just come across this code and the blog says this works fine on 32 bit architecture. I didn't test it; however, I have a doubt about the linkage of libraries in this case. How will the compiler link the string library to main since its not aware which library to link?
So basically if I include <string.h> then it should work fine; however, if I don't include <string.h> then, as per the blog, it runs in 32 bit architecture and fails to run on 64 bit architecture.
#include <errno.h>
#include <stdio.h>
int main(int argc, char *argv[])
{
FILE *fp;
fp = fopen(argv[1], "r");
if (fp == NULL) {
fprintf(stderr, "%s\n", strerror(errno));
return errno;
}
printf("file exist\n");
fclose(fp);
return 0;
}
The code shown will only compile if you allow the compiler to infer that functions that are not declared always return an int. This was valid in C89/C90 but marked obsolescent; C99 and C11 require functions to be declared before they are used. GCC prior to version 5.1.0 assumes C90 mode by default; you had to turn the 'reject this code' warnings on. GCC 5.1.0 and onwards assumes C11 by default. You will at least get warnings from the code even without any compilation options to turn them on.
The code will link fine because the function name is strerror() regardless of whether it was declared or not, and the linker can find the function in the standard C library. In general, all the functions that are in the Standard C library are automatically made available for linking — and, indeed, there are usually a lot of not so standard functions also available. C does not have type-safe linkage as C++ does (but C++ also insists on having every function declared before it is used, so the code would not compile as C++ without the header.)
For historical reasons, the maths library was separate and you needed to specify -lm in order to link it. This was in large part because hardware floating point was not universal, so some machines needed a library using the hardware, and other machines needed software emulation of the floating point arithmetic. Some platforms (Linux, for example) still require a separate -lm option if you use functions declared in <math.h> (and probably <tgmath.h>); other platforms (Mac OS X, for example) do not — there is a -lm to satisfy build systems that link it, but the maths functions are in the main C library.
If the code is compiled on a fairly standard 32-bit platform with ILP32 (int, long, pointer all 32-bit), then for many architectures, assuming that strerror() returns an int assumes that it returns the same amount of data as if it returns a char * (which is what strerror() actually returns). So, when the code pushes the return value from strerror() onto the stack for fprintf(), the correct amount of data is pushed.
Note that some architectures (notably the Motorola M680x0 series) would return addresses in an address register (A0) and numbers in a general register (D0), so there would be problems even on those machines with a 32-bit compilation: the compiler would try to get the returned value from the data register instead of the address register, and that was not set by strerror() — leading to chaos.
With a 64-bit architecture (LP64), assuming strerror() returns a 32-bit int means that the compiler will only collect 32-bits of the 64-bit address returned by strerror() and push that on the stack for fprintf() to work with. When it tried to treat the truncated address as valid, things would go awry, often leading to a crash.
When the missing <string.h> header is added, the compiler knows that the strerror() function returns a char * and all is happiness and delight once more, even when the file the program is told to look for doesn't exist.
If you are wise, you will ensure your compiler is always compiling in fussy mode, rejecting anything which is plausibly erroneous. When I use my default compilation on your code, I get:
$ gcc -std=c11 -O3 -g -Wall -Wextra -Werror -Wmissing-prototypes \
> -Wstrict-prototypes -Wold-style-definition bogus.c -o bogus
bogus.c: In function ‘main’:
bogus.c:10:33: error: implicit declaration of function ‘strerror’ [-Werror=implicit-function-declaration]
fprintf(stderr, "%s\n", strerror(errno));
^
bogus.c:10:25: error: format ‘%s’ expects argument of type ‘char *’, but argument 3 has type ‘int’ [-Werror=format=]
fprintf(stderr, "%s\n", strerror(errno));
^
bogus.c:10:25: error: format ‘%s’ expects argument of type ‘char *’, but argument 3 has type ‘int’ [-Werror=format=]
bogus.c:4:14: error: unused parameter ‘argc’ [-Werror=unused-parameter]
int main(int argc, char *argv[])
^
cc1: all warnings being treated as errors
$
The 'unused argument' error reminds you that you should be checking that there is an argument to pass to fopen() before you try to open the file.
Fixed code:
#include <string.h>
#include <errno.h>
#include <stdio.h>
int main(int argc, char *argv[])
{
FILE *fp;
if (argc != 2)
{
fprintf(stderr, "Usage: %s file\n", argv[0]);
return 1;
}
fp = fopen(argv[1], "r");
if (fp == NULL)
{
fprintf(stderr, "%s: file %s could not be opened for reading: %s\n",
argv[0], argv[1], strerror(errno));
return errno;
}
printf("file %s exists\n", argv[1]);
fclose(fp);
return 0;
}
Build:
$ gcc -std=c11 -O3 -g -Wall -Wextra -Werror -Wmissing-prototypes \
> -Wstrict-prototypes -Wold-style-definition bogus.c -o bogus
$
Run:
$ ./bogus bogus
file bogus exists
$ ./bogus bogus2
./bogus: file bogus2 could not be opened for reading: No such file or directory
$ ./bogus
Usage: ./bogus file
$
Note that the error messages include the program name and report to standard error. When the file is known, the error message includes the file name; it is much easier to debug that error if the program is in a shell script than if the message is just:
No such file or directory
with no indication of which program or which file encountered the problem.
When I remove the #include <string.h> line from the fixed code shown, then I can compile it and run it like this:
$ gcc -o bogus90 bogus.c
bogus.c: In function ‘main’:
bogus.c:18:35: warning: implicit declaration of function ‘strerror’ [-Wimplicit-function-declaration]
argv[0], argv[1], strerror(errno));
^
$ gcc -std=c90 -o bogus90 bogus.c
$ ./bogus90 bogus11
Segmentation fault: 11
$
This was tested with GCC 5.1.0 on Mac OS X 10.10.5 — which is, of course, a 64-bit platform.
I solved with including strings.h header
#include <string.h>
I don't think the functionality of this code would be affected by whether its 32-bit or 64-bit architecture: it doesn't matter if pointers are 32- or 64-bit, and if long int is 32 or 64 bit. Inclusion of headers, in this case string.h, should not affect linking to libraries, either. Header inclusion matters to the compiler, not linker. The compiler might warn about the function being implicitly declared, but as long as the linker can find the function in one of the libraries being searched by it, it will successfully link the binary, and it should run just fine.
I just built and ran this code successfully on a 64-bit CentOS box, using clang 3.6.2. I did get this compiler warning:
junk.c:10:33: warning: implicitly declaring library function 'strerror' with type 'char *(int)'
fprintf(stderr, "%s\n", strerror(errno));
^
junk.c:10:33: note: include the header <string.h> or explicitly provide a declaration for 'strerror'
1 warning generated.
The program was given a non-existent file name, and the error message, "No such file or directory," was meaningful. However, this is because the strerror() function is a well-known standard library function, and its declaration was correctly guessed by the compiler. If it is a user-defined function, the compiler may not be so "lucky" at guessing, and then the architecture can matter, as suggested by other answers.
So, the lesson learned: make sure function declarations are available to the compiler and heed the warnings!
I am super new to FLEX, I'm trying to write a simple FLEX lex file, but for some reason I get the error in the header.
The complete error is:
bash syntax error near unexpected token '('
The command I am running is:
flex sample.lex
OR
flex sample.l
Where am I going wrong here?
%{
union{
int val;
char name [30];
char str [80];
}yylval;
#include <stdio.h>
%}
%%
. ECHO;
%%
int main(int argc, char **argv)
{
if (argc != 2) {
printf("no input file>\n");
exit (1);
}
printf("token lexeme attribute\n");
printf("--------------------------\n");
yyin=fopen(argv[1], "r");
if(yyin!=0)
{ printf("file opened");
fclose(yyin);}
exit (0);
}
int yywrap () { return 1; }
Are you running Flex on the file, and then GCC? I was able to compile this. First, run
flex test.l
This should generate a file name "lex.yy.c", which is C code generated by Flex. This file contains code to scan the input, and the C code in your .l file. Then running
gcc lex.yy.c
should produce an executable "a.out". Running
./a.out test.txt
produced the output you're printing, including "file opened". As was pointed out, main does not have a return type, but I guess my compiler was able to figure it out.
However, even if you can compile this, it looks like you are misunderstanding a few aspects of Flex.
union{
int val;
char name [30];
char str [80];
}yylval;
is a regular C union. Bison's %union declaration is used when a semantic value can have more than one type, and is not the same thing. %union should not be in the .l file.
Also, you need to call yylex() to actually start scanning the input.
Right now, I would suggest going to the Flex manual and doing some of the starter examples: http://westes.github.io/flex/manual/Simple-Examples.html. If you are using Flex and Bison together, you should also go through some of the Bison examples: http://www.gnu.org/software/bison/manual/html_node/Examples.html#Examples
I am working on a C project where I need to get the list of files that are within a directory. I am using dirent.h but am having some problems getting it to work, I am building the program under Linux.
When I try and build the program I get the following error
myClass:error: âDIRâ undeclared (first use in this function)
myClass:408: error: (Each undeclared identifier is reported only once
myClass:408: error: for each function it appears in.)
myClass:408: error: âdirâ undeclared (first use in this function)
myClass:410: warning: implicit declaration of function âopendirâ
myClass:413: warning: implicit declaration of function âreaddirâ
myClass:413: warning: assignment makes pointer from integer without a cast
myClass:415: error: dereferencing pointer to incomplete type
myClass:417: warning: implicit declaration of function âclosedirâ
Below is the code that I am using
int logMaintenance(void *arg)
{
DIR *dir;
struct dirent *ent;
dir = opendir(directory);
if (dir != NULL)
{
while ((ent = readdir (dir)) != NULL)
{
printf("%s\n", ent->d_name);
}
closedir(dir);
}
else
{
printf("Failed to read directory %i", EXIT_FAILURE);
}
return 0;
}
I don't understand what these errors mean especially when it says that DIR is undeclared when I have included the dirent.h header file for Liunux.
Thanks for your help.
You should make sure that:
You #include <dirent.h>, rather than "dirent.h", so that the system search path for headers is used to locate that file
You don't have a dirent.h file lying around somewhere in your project that could be picked up instead.
When trying to debug this type of strange problem, ask GCC for the pre-processed output with gcc -E. You can see what files (including the paths) it's including. That can help a lot.
And if you're using Microsoft Visual Studio, head over to this question:
Microsoft Visual Studio: opendir() and readdir(), how?
I'm not sure, but it seems like I was always told that you always need a main function...
However I have only a mere 8 months (2 semesters) of C++ under my belt. I just practice it to be safe, however, I would also use:
int main(int argc, char **argv) or
int main(int argc, char *argv[]) rather than
int logMaintenance(void *arg)
(while using dirent.h).