Unix Programming - disabling parse error in gcc

Author

disabling parse error in gcc

sayantan.chowdhury@gmail.com

2006-04-27, 7:56 am

Hi,
I am compiling C code in gcc, later cross compiling for arm
board.During compilation I am getting a lot of parse errors due to
inter dependancy in header files i.e. there is cross reference in the
headers which I'm not being able to remove(as it is leading to a whole
lot of restructuring in headers).The same problem gives rise to
warnings in intel C compiler, but there I can disable them using
pragma.
So I would like to know if there is a possible way to disable the parse
errors in gcc so that I can compile the code without restructuring.
Any input will be of great help.

Thanks in advance,
Sayantan Chowdhury

David Spencer

2006-04-27, 7:56 am

"sayantan.chowdhury@gmail.com" <sayantan.chowdhury@gmail.com> writes:

>Hi,
>I am compiling C code in gcc, later cross compiling for arm
>board.During compilation I am getting a lot of parse errors due to
>inter dependancy in header files i.e. there is cross reference in the
>headers which I'm not being able to remove(as it is leading to a whole
>lot of restructuring in headers).The same problem gives rise to
>warnings in intel C compiler, but there I can disable them using
>pragma.
>So I would like to know if there is a possible way to disable the parse
>errors in gcc so that I can compile the code without restructuring.
>Any input will be of great help.

No.

Your code is apparently not C code; that's what "parse error" means.
A C compiler won't compile Fortran code; this is exactly the same
problem. The code may look like C, but it's not.

The intel compiler's pragma allows it to compile the language in which
your code is written. gcc may have an option that allows it to
compile that language, too. But without knowing what that language is,
there's no way to tell.

What pragma allows the intel compiler to compile the code? What are
the actual parse errors in gcc? Armed with that information, someone
who knows gcc's (countless) options may be able to help.

--
dhs spencer@panix.com

Gordon Burditt

2006-04-27, 7:56 am

>>I am compiling C code in gcc, later cross compiling for arm
>
>No.
>
>Your code is apparently not C code; that's what "parse error" means.

"parse error" or "syntax error" errors in header files (including
compiler-supplied system header files) often mean that a prerequesite
header file that defines a typedef are not included first.

Gordon L. Burditt

sayantan.chowdhury@gmail.com

2006-04-27, 7:56 am

I think I need to explain a little more.First and foremost , my code is
written in plain and simple "C" language and nothing else.
Gordon , you have hit the nail on the head, my problem is exactly as
you have told. Let me explain -
my code goes like this -

#include "header1.h"
#include "header2.h"
int main()
{
//code follows
return 0;
}

Now, the problem is with headers and nowhere else.Suppose a int has
been typedefed in header2.h as -

// in header2.h
typedef int D_TYPE

But let's say D_TYPE is used as a parameter of a structure while
declaring the structure in header1.h.

// in header1.h
typedef struct MYSTRUCT{
//other parameters
D_TYPE a;
//other parameters
}MYSTRUCT;

Now, gcc returns a parse error when it encounters D_TYPE in header1.h
as the declaration of D_TYPE is actually in header2.h
The problem will get really wild when MYSTRUCT is heavily used in
header2.h [let's say in other structures

-] so that you cann't change
the order (first header1, then header2).This is what I meant by
cross-reference between headers in my first mail.

Here I'm taking the case of a simple int and so, one can get away by
putting the declaration of D_TYPE in header1.h, before MYSTRUCT.
But think of a structure (instead of int) having parameters of
datatypes declared in header2.h itself.In that case you'll be in a soup
if you want to play the cut-copy-paste game.

I know it's a very bad way of programming but the code has been written
in this way only and I cann't help it now.The same problem gave rise to
warnings in "icc" but somehow it was disabled using pragma.But the
cross compiler I have now is gcc-arm and I have to compile the same
code in gcc.
That's why I want to know if there is any possible way out of disabling
parse errors in gcc.Any other suggestions will also be of great help.

Thanks and warm regards,
Sayantan Chowdhury

Pascal Bourguignon

2006-04-27, 7:56 am

"sayantan.chowdhury@gmail.com" <sayantan.chowdhury@gmail.com> writes:
> That's why I want to know if there is any possible way out of disabling
> parse errors in gcc.

The only way to disable parse errors, is to correct them.

> Any other suggestions will also be of great help.

The solution to your problem is to include header2.h in header1.h,
because header1.h uses a type defined in header2.h. You can still
include header2.h in your source.c, and in any order, but in general,
you want to avoid to include twice the same header. This can be done
easy as follow:

in header1.h:

#ifndef header1_h
#define header1_h

#include <header2.h>

struct {
D_TYPE a;
}

#endif

in header2.h:

#ifndef header2_h
#define header2_h

typedef int D_TYPE;

#endif

in source.c:

#include <header1.h>
#include <header2.h>

int main(...){ ... }

--
__Pascal Bourguignon__ http://www.informatimago.com/

The world will now reboot. don't bother saving your artefacts.

Gordon Burditt

2006-04-27, 7:56 am

>I think I need to explain a little more.First and foremost , my code is
>written in plain and simple "C" language and nothing else.
>Gordon , you have hit the nail on the head, my problem is exactly as
>you have told. Let me explain -
>my code goes like this -
>
>#include "header1.h"
>#include "header2.h"
>int main()
>{
>//code follows
>return 0;
>}
>
>Now, the problem is with headers and nowhere else.Suppose a int has
>been typedefed in header2.h as -
>
>// in header2.h
>typedef int D_TYPE
>
>But let's say D_TYPE is used as a parameter of a structure while
>declaring the structure in header1.h.
>
>// in header1.h
>typedef struct MYSTRUCT{
>//other parameters
>D_TYPE a;
>//other parameters
>}MYSTRUCT;

My rules for dealing with this, which might get messy if it wasn't
coded that way in the first place:

1. A header file shall (unconditionally) include its prerequesite
header files (for example, needed typedefs, structure definitions,
etc.) so that a source file containing only a #include of
it will compile correctly. (Note: some compilers reject empty
source files or source files that don't contain any function or
variable declarations, which I think is allowed by ANSI C but I
have yet to encounter a compiler that actually does this. In any case,
you could add the line int main(){} to the end of the source file.)
2. A header file shall permit multiple inclusion of itself.
In practice, this means bracketing the guts of the include file
with:
#ifndef H_FOO_H
#define H_FOO_H 1
... guts of include file ...
#endif
so that a source file containing only TWO #includes of it will compile,
even if the guts of the include file includes typedefs.
3. The "guard symbol" used for an include file shall not be referenced
in any other file.
4. The "guard symbol" used for an include file shall not be referenced
in any other file for the purpose of speeding up compilation.
5. The "guard symbol" used for an include file shall not be referenced
in any other file for the purpose of even talking about speed of
compilation.
6. A source file consisting only of any number of #includes of header
files in any order and any number of times shall compile correctly.

One problem this style does have: if a source file requires stuff
from header1.h and header2.h, and header1.h includes header2.h and
header2.h includes header1.h (with the include guards this is NOT
a problem), then it's easy to forget to include BOTH header1.h and
header2.h in foo.c, but you might not figure this out until a
big re-organization of what's in header1.h and header2.h so they
don't include each other.

You can use something like "grep -v" to not see the errors but there
are still fundamental problems about getting a compiler to resume
parsing after such an error.

Gordon L. Burditt