conflict in FILE and stdio

Hello everyone,


I am porting a legacy program from other platform to Linux. I am using Red Hat Linux Enterprise 4. In the legacy program, there is a macro definition,

Code:

---

#define __FILE FILE

---

in the legacy program, __FILE will be used in all the places to stands for FILE.

Here is the program to reproduce this issue and the error message from compile, what is the most efficient way to solve this issue? Looking for your advice.

Code:

---

#define __FILE FILE
#include <stdio.h>

int main (int argc, char** argv)
{
    return 0;
}

[root@localhost test_stdio]# gcc -g -O0 -c foo.c
In file included from /usr/include/stdio.h:72,
                from foo.c:2:
/usr/include/libio.h:267: error: redefinition of `struct _IO_FILE'

---

thanks in advance,
George

Well anything beginning with _ (with few exceptions) is a reserved name for the system, so you should not be using it for your own purposes.

I'd say you've managed to find a prior use of __FILE.

Quote:

---

Originally Posted by George2

I am porting a legacy program ...

---

Been there; done that! (And the Boss told me not to change anything; just recompile.)

What happens if you do it as follows?

Code:

---

#include <stdio.h>
#define __FILE FILE

---

More importantly: Do you have a test plan to verify the stuff after you get it to recompile? Getting it 99% correct usually isn't good enough.

D.

Thanks Salem,

Quote:

---

Originally Posted by Salem

Well anything beginning with _ (with few exceptions) is a reserved name for the system, so you should not be using it for your own purposes.

I'd say you've managed to find a prior use of __FILE.

---

I have tried to put #define after #include, and there is no compile error.

I am very interested to learn how compiler works internally. Why put #define after #include <stdio.h> works? Why put it before will cause conflict (redefinition) -- what data types are redefined?

In stdio.h, there is no data type called __FILE. Any ideas? :-)


regards,
George

Thanks Dave,

Quote:

---

Originally Posted by Dave Evans

Been there; done that! (And the Boss told me not to change anything; just recompile.)

What happens if you do it as follows?

Code:

---

#include <stdio.h>
#define __FILE FILE

---

More importantly: Do you have a test plan to verify the stuff after you get it to recompile? Getting it 99% correct usually isn't good enough.

D.

---

Put #define after #include works. But I do not know why put #define before #include will have compile error, since I can not find data type __FILE in stdio.h, why compiler says it is redefined?


regards,
George

Quote:

---

Originally Posted by George2

Thanks Salem,




I have tried to put #define after #include, and there is no compile error.

I am very interested to learn how compiler works internally. Why put #define after #include <stdio.h> works? Why put it before will cause conflict (redefinition) -- what data types are redefined?

In stdio.h, there is no data type called __FILE. Any ideas? :-)


regards,
George

---

Are you sayingt hat stdio.h doesn't contain __FILE or that NONE of the files included by stdio.h contains __FILE? Most gcc header files I've seen will include a bunch of other header files that include further more header files, so one include may well drag in a dozen other files that in turn drag in half a dozen files each, so now you have approximately 70 files that you could have a conflict in.

Pay particular attention to:
/usr/include/libio.h


It is quite clear that there is something that DOES contain __FILE inside your header-files, otherwise the alternative position wouldn't work.

Note that __ something is defined as "implementation specific", and it's quite possiblet that there are things that

Since a #define is only in use AFTER it is present in the file, it works to replace it later on in after the header file (because YOU are not using __FILE, but the internals of the file IO library does).

--
Mats

Quote:

---

Originally Posted by George2

Put #define after #include works....

---

By "works", I assume you mean that the compiler no longer chokes. In my experience, that may or may not mean that the functionality is preserved. I stand by my comment about the importance of a test plan.

You might find that this little thing about __FILE is a problem with some versions of gcc and not with others. For the ones that give problems, there is, I believe, a very long convoluted chain of #include and #ifdef and #ifndef and #undef statements that I have never followed to the bitter end.

From my point of view, the preferred approach would be to find all places the legacy code where __FILE is #defined and then comment out the #define statements. Find all files in the legacy code that use __FILE and replace __FILE with FILE. (Instead of a sed script or some such simple thing, you might have to look at each instance and try to figure if something "funny" is going on there that required __FILE to be something "special".)

As matsp mentioned and salem almost mentioned, identifiers that begin with two underscores are supposed to be reserved for the implementation (the compiler writers), so the legacy code did a Bad Thing.

To be precise, from the C standard: "All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use."

Violations like this are not unheard of.

The problem is when the Boss thinks that, since the legacy code works (and has been working since 1979), that porting to another operating system and/or compiler is a "slam dunk" and orders you to do the deed "without any big changes," and to have it ready by Tuesday.

D.

Hi matsp,


I can not find any __FILE in libio.h. I have attached my libio.h file from /usr/include, could you help check please? Thanks.


regards,
George

Quote:

---

Originally Posted by matsp

Are you sayingt hat stdio.h doesn't contain __FILE or that NONE of the files included by stdio.h contains __FILE? Most gcc header files I've seen will include a bunch of other header files that include further more header files, so one include may well drag in a dozen other files that in turn drag in half a dozen files each, so now you have approximately 70 files that you could have a conflict in.

Pay particular attention to:
/usr/include/libio.h


It is quite clear that there is something that DOES contain __FILE inside your header-files, otherwise the alternative position wouldn't work.

Note that __ something is defined as "implementation specific", and it's quite possiblet that there are things that

Since a #define is only in use AFTER it is present in the file, it works to replace it later on in after the header file (because YOU are not using __FILE, but the internals of the file IO library does).

--
Mats

---

Thanks Dave,


I fully agree with you. I am just interested to learn why there is data type redefinition error, since there is no __FILE in both stdio.h and libio.h. I have attached libio.h in my previous post, could you help to have a look please?


regards,
George

Quote:

---

Originally Posted by Dave Evans

By "works", I assume you mean that the compiler no longer chokes. In my experience, that may or may not mean that the functionality is preserved. I stand by my comment about the importance of a test plan.

You might find that this little thing about __FILE is a problem with some versions of gcc and not with others. For the ones that give problems, there is, I believe, a very long convoluted chain of #include and #ifdef and #ifndef and #undef statements that I have never followed to the bitter end.

From my point of view, the preferred approach would be to find all places the legacy code where __FILE is #defined and then comment out the #define statements. Find all files in the legacy code that use __FILE and replace __FILE with FILE. (Instead of a sed script or some such simple thing, you might have to look at each instance and try to figure if something "funny" is going on there that required __FILE to be something "special".)

As matsp mentioned and salem almost mentioned, identifiers that begin with two underscores are supposed to be reserved for the implementation (the compiler writers), so the legacy code did a Bad Thing.

To be precise, from the C standard: "All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use."

Violations like this are not unheard of.

The problem is when the Boss thinks that, since the legacy code works (and has been working since 1979), that porting to another operating system and/or compiler is a "slam dunk" and orders you to do the deed "without any big changes," and to have it ready by Tuesday.

D.

---

Quote:

---

Originally Posted by George2

Hi matsp,


I can not find any __FILE in libio.h. I have attached my libio.h file from /usr/include, could you help check please? Thanks.


regards,
George

---

As I stated before, the include file hierarchy in gcc is non-trivial.

libio.h includes:

Code:

---

  32:#include <_G_config.h>
  53:# include <stdarg.h>
  62:#  include <sys/cdefs.h>
  171:#  include <bits/stdio-lock.h>
  494:#  include <shlib-compat.h>

---

Some of those may well include other files.

go to /usr/include and do "grep -r __FILE ." and see what comes up - but even if you don't find something, there may be more to it than that - for example something can use macros to generate one name from another, such as

Code:

---

#define name(x) __ ## #x
 
name(FILE) a;

---

will make __FILE a;

Just accept that __FILE is being used internally somewhere.

--
Mats

Why don't you do something like

Code:

---

#ifndef __FILE
#define __FILE FILE
#endif

---

Or undefine it if it was defined... But you'd still be assuming that __FILE is the same as FILE.

Quote:

---

Originally Posted by Salem

Well anything beginning with _ (with few exceptions) is a reserved name for the system, so you should not be using it for your own purposes.

---

He's not "using it," he's porting code.

Thanks zacs7,

Quote:

---

Originally Posted by zacs7

Why don't you do something like

Code:

---

#ifndef __FILE
#define __FILE FILE
#endif

---

Or undefine it if it was defined... But you'd still be assuming that __FILE is the same as FILE.

---

I have found this line. It is my carelessness. ;)

I think the cause of compile error is we define something before typedef, then typedef the same thing -- __FILE. Is that correct?

So the correct behavior is to define a datatype after typedef (typedef is real data type definition). Is that correct?

I am interested to learn how compiler treat this internally.


regards,
George

Yes, brewbuck. I am thinking why compiler has such error.

Quote:

---

Originally Posted by brewbuck

He's not "using it," he's porting code.

---

regards,
George

Thanks Mats,

Quote:

---

Originally Posted by matsp

Code:

---

#define name(x) __ ## #x
 
name(FILE) a;

---

will make __FILE a;

Mats

---

What is the relationship between the above code and my question? I can not find how to use the above code to find where __FILE is defined? Any comments?


regards,
George

That's matsp's point, you can't find where __FILE is defined because it maybe defined in that manor. Ie, '__FILE' is never actually written in the file.

You could try to search for __FILE in all the files in /usr/include using grep.

Code:

---

grep -r "__FILE" /usr/include/*.h

---

I found '/usr/include/stdio.h:typedef struct _IO_FILE __FILE;' on my machine, but I guess it could be different to yours.

Exactly my point. There are several macro definitions that are used by gcc's header files that make it very difficult to find the actual name used. The whole thing is quite convoluted, and that is because the GCC header files are intended to work with many different versions of gcc, different OS's and different C-libraries, each of which may be slightly different in the way things need to be defined.

--
Mats

Thanks zacs7,

Quote:

---

Originally Posted by zacs7

That's matsp's point, you can't find where __FILE is defined because it maybe defined in that manor. Ie, '__FILE' is never actually written in the file.

You could try to search for __FILE in all the files in /usr/include using grep.

Code:

---

grep -r "__FILE" /usr/include/*.h

---

I found '/usr/include/stdio.h:typedef struct _IO_FILE __FILE;' on my machine, but I guess it could be different to yours.

---

Do you know why

#define __FILE something
typedef struct _IO_FILE __FILE

works, but

typedef struct _IO_FILE __FILE
#define __FILE something

Does not work?


regards,
George

Thanks Mats,

Quote:

---

Originally Posted by matsp

Exactly my point. There are several macro definitions that are used by gcc's header files that make it very difficult to find the actual name used. The whole thing is quite convoluted, and that is because the GCC header files are intended to work with many different versions of gcc, different OS's and different C-libraries, each of which may be slightly different in the way things need to be defined.

--
Mats

---

Do you know why

#define __FILE something
typedef struct _IO_FILE __FILE

works, but

typedef struct _IO_FILE __FILE
#define __FILE something

Does not work?


regards,
George

Presumably, based on the error message you have given, because "something" has already been defined elsewhere...

--
Mats

You could also use gcc options to output all the macros define in your code. In fact, you can do quite a lot of stuff...

Code:

---

gcc -E -o ListDef -dM -P YourSrcCode.c

---

will generate a list of `#define' directives for all the macros defined during the execution of the preprocessor, including predefined macros. You might not find __FILE in here because, from what i saw from the result of

Code:

---

gcc -E -o ListDef -dD -P YourSrcCode.c

---

well, __FILE is used in a type definition and used one or two lines after that. So, having a macro expansion for __FILE as something else than a type will result in an error here.

Note that i'm a poor Windows user (yeah, i'll have to install one of those Linux distribution one day heh), thus i don't have a really young version of gcc (3.4.4).

But you may be able to investigate further using the gcc options controlling the preprocessor.

If you have the latest version of gcc, you'll find here some lovely informations.

Foxman has the solution, assuming you are able to read that output.

I would, however, recommend that you just write it down as "One of those things".

--
Mats

Thanks foxman,

Quote:

---

Originally Posted by foxman

You could also use gcc options to output all the macros define in your code. In fact, you can do quite a lot of stuff...

Code:

---

gcc -E -o ListDef -dM -P YourSrcCode.c

---

will generate a list of `#define' directives for all the macros defined during the execution of the preprocessor, including predefined macros. You might not find __FILE in here because, from what i saw from the result of

Code:

---

gcc -E -o ListDef -dD -P YourSrcCode.c

---

well, __FILE is used in a type definition and used one or two lines after that. So, having a macro expansion for __FILE as something else than a type will result in an error here.

Note that i'm a poor Windows user (yeah, i'll have to install one of those Linux distribution one day heh), thus i don't have a really young version of gcc (3.4.4).

But you may be able to investigate further using the gcc options controlling the preprocessor.

If you have the latest version of gcc, you'll find here some lovely informations.

---

What is the differences between #define and typedef in internal operation of compiler? I find redefine a typedef type is error, but re-typedef a typedef type is ok.


regards,
George

Thanks Mats,

Quote:

---

Originally Posted by matsp

Foxman has the solution, assuming you are able to read that output.

I would, however, recommend that you just write it down as "One of those things".

--
Mats

---

I agree with all of your guys' reply. I am interested to learn what is the differences between #define and typedef. Could you see my last post? Any ideas?


regards,
George

Quote:

---

Originally Posted by George2

Thanks foxman,




What is the differences between #define and typedef in internal operation of compiler? I find redefine a typedef type is error, but re-typedef a typedef type is ok.


regards,
George

---

typedef tells the compiler "This is a new name for the type I've just given", e.g. "typedef int blah;" makes the type blah a valid use for everywhere you can use int.

#define is a "text replacement" mechanism. "#define blah int" will replace every place that uses blah into int BEFORE the actual compile takes place. This is called the "preprocessor stage". The preprocessor will take the source file, combine it with any includes into one large file, and as part of that process, replace any #define stuff. [And sort out any #if/#ifdef/#else/#endif sections by removing anything that is "false".].

Sasy now we do:

Code:

---

#define blah int
typedef int blah;

---

This will compile as:

Code:

---

typedef int int;

---

Which is probably not a good thing to do.


--
Mats

Guess you have to understand one thing. The compiler never sees any #define's. All the #define'd symbols have already been replaced by the preprocessor before the compiler sees the code.
Kurt

Quote:

---

Originally Posted by ZuK

Guess you have to understand one thing. The compiler never sees any #define's. All the #define'd symbols have already been replaced by the preprocessor before the compiler sees the code.
Kurt

---

Exactly what I tried to say, but used a few too many words.

--
Mats

Thanks Mats,

Quote:

---

Originally Posted by matsp

typedef tells the compiler "This is a new name for the type I've just given", e.g. "typedef int blah;" makes the type blah a valid use for everywhere you can use int.

#define is a "text replacement" mechanism. "#define blah int" will replace every place that uses blah into int BEFORE the actual compile takes place. This is called the "preprocessor stage". The preprocessor will take the source file, combine it with any includes into one large file, and as part of that process, replace any #define stuff. [And sort out any #if/#ifdef/#else/#endif sections by removing anything that is "false".].

Sasy now we do:

Code:

---

#define blah int
typedef int blah;

---

This will compile as:

Code:

---

typedef int int;

---

Which is probably not a good thing to do.


--
Mats

---

I think #define only affects the code after it, and no impact to code before it. So, it is important where (order and sequence) #define is used, and if used in different places, there will be different effect, right?


regards,
George

Thanks foxman,

Quote:

---

Originally Posted by foxman

Code:

---

gcc -E -o ListDef -dM -P YourSrcCode.c

---

Code:

---

gcc -E -o ListDef -dD -P YourSrcCode.c

---

---

I have tried the above two commands. And they generate a lot of information in ListDef, several hundred lines. :-)

Could you tell me what is the function of gcc -E -o ListDef -dM -P and gcc -E -o ListDef -dD -P please?


regards,
George

RTM - http://gcc.gnu.org/onlinedocs/