struct FILE in RedHat Linux

[juyi520]

Hello,

I am new in C in Programming,


Where could I find the detail about struct FILE in RedHat Linux ?


I have tried to check the stdio.h in /usr/include, but I could not find
the

typedef struct {

} FILE;


Could someone provide the information or URL to find detail of struct
FILE ?


OS : RedHat Linux 2.4.20-8

gcc version : 3.2.2 20030222 (Red Hat Linux 3.2.2-5)



Thank you all in advance !!

 

[J]

When I tried to compile my code

printf("fout->fd=%d\n", fout->fd);

I got the error message

hw1a.c:259: structure has no member named `fd'

Could anyone give me the detail about the default struct FILE in Linux
?

Thank you

 

[J]

When I tried to compile my code

printf("fout->fd=%d\n", fout->fd);

I got the error message

hw1a.c:259: structure has no member named `fd'

Could anyone give me the detail about the default struct FILE in Linux
?

Thank you

 

[J]

When I tried to compile my code

printf("fout->fd=%d\n", fout->fd);

I got the error message

hw1a.c:259: structure has no member named `fd'

Could anyone give me the detail about the default struct FILE in Linux
?

Thank you

 

[Keith Thompson]

I am new in C in Programming,


Where could I find the detail about struct FILE in RedHat Linux ?


I have tried to check the stdio.h in /usr/include, but I could not find
the

typedef struct {

} FILE;


Could someone provide the information or URL to find detail of struct
FILE ?

You don't need to know. The langauge doesn't define the contents of
type FILE; it doesn't even need to be a struct.

The actual declaration will vary from one system to another; any code
you write that depends on its internals will be unnecessarily
non-portable.

If you're curious, many compilers have an option to show you the
output of the preprocessor phase. Feed it a small source file with a
"#include <stdio.h>". <OT>On your system, use "gcc -E".</OT> The full
declaration of FILE is probably in some other header, included
directly or indirectly from <stdio.h>.

But the only thing you *need* to know about is the functions that take
arguments or return results of type FILE.

 

[Keith Thompson]

When I tried to compile my code

printf("fout->fd=%d\n", fout->fd);

I got the error message

hw1a.c:259: structure has no member named `fd'

Could anyone give me the detail about the default struct FILE in Linux
?

You just posted the same article three times.

Please don't top-post. For details, read the following:

http://www.caliburn.nl/topposting.html
http://www.cpax.org.uk/prg/writings/topposting.php

Whatever "fout" is, it apparently points to a structure that doesn't
have a member called "fd". See response to your original article.

 

[Richard Tobin]

When I tried to compile my code

printf("fout->fd=%d\n", fout->fd);

I got the error message

hw1a.c:259: structure has no member named `fd'

If what you want is the unix file descriptor of a FILE *, you can get
it more portably (though not within pure standard C of course) with
the "fileno" function.

-- Richard

 

[Stephen Sprunk]

You don't need to know. The langauge doesn't define the contents of
type FILE; it doesn't even need to be a struct.

The actual declaration will vary from one system to another; any code
you write that depends on its internals will be unnecessarily
non-portable.

Correct.

<OT>
However, since the OP, in another post, shows that he's looking for a
way to find the POSIX file descriptor for a given FILE*. The correct
answer in that case is to use fileno(); it's still not to try to look
inside the FILE*.

If you're curious, many compilers have an option to show you the
output of the preprocessor phase. Feed it a small source file with a
"#include <stdio.h>". <OT>On your system, use "gcc -E".</OT> The full
declaration of FILE is probably in some other header, included
directly or indirectly from <stdio.h>.

There's no guarantee that <stdio.h> actually defines what's in a FILE.
It may (and is likely to) declare FILE to be an incomplete struct type,
and that is sufficient for the interface into stdio to work, since all
pointers-to-struct are defined to have the same representation. In
fact, any competent implementor will hide the definition of FILE from
users (even with compiler help) and only expose it to the library
internals.

S

 

[Guest]

There's no guarantee that <stdio.h> actually defines what's in a FILE.
It may (and is likely to) declare FILE to be an incomplete struct type,

No, it may not. FILE is required to be an object type. An incomplete
type is not an object type.

 

[Flash Gordon]

No, it may not. FILE is required to be an object type. An incomplete
type is not an object type.

You are correct. However, FILE *could* be a pointer to an incomplete
type, or a pointer to void, or a simple integer type where the integer
is used by the library to find the real information, all of which would
prevent you from findout out much of use by looking at the definition of
FILE.

 

[Keith Thompson]

No, it may not. FILE is required to be an object type. An incomplete
type is not an object type.

In addition, the point of making FILE an object type is so that getc()
and putc(), if implemented as macros, can access its internals.

(This *could* have been done by converting FILE* to some
pointer-to-object type withi getc() and putc(), and it doesn't explain
while FILE is *required* to be an object type, but there's a rationale
in there somewhere.)

 

[CBFalconer]

.... snip ...


There's no guarantee that <stdio.h> actually defines what's in a
FILE. It may (and is likely to) declare FILE to be an incomplete
struct type, and that is sufficient for the interface into stdio
to work, since all pointers-to-struct are defined to have the same
representation. In fact, any competent implementor will hide the
definition of FILE from users (even with compiler help) and only
expose it to the library internals.

If the implementor wants to supply the (more efficient) macro forms
for getc and putc, he must make the details of FILE visible. This
allows getc and putc to avoid unnecessary system calls and operate
directly on the file buffers (until they need to be reloaded).
That implementor may very well be perfectly competent.