What is required of FILE (stdio.h)

[skyking]

From what I've seen the standards C99 and POSIX does not imply any contents of the file struct (the ISO draft doesn't even mention that it is a struct). Does the mentioning of that is a struct imply that it has to be completely defined (or is a forward declaration of the struct sufficient)? May it even be typedefed as void? (Both will work for sane use cases for FILE AFAIK)

[Brynet-Inc]

I'm pretty sure it's implementation specific, no portable code manipulates the members of the FILE structure directly... only other system functions should do that.

http://en.wikipedia.org/wiki/Stdio.h#Member_types

[skyking]

To clarify, this was a question for the requirements implied by POSIX or C99. What's not in the requirements is of course implementation specific. More specific is the following programs guaranteed to be valid for an standard complying implementation of POSIX or C99 (not whether they are meaningful or not):

Code: Select all

#include <stdio.h>

extern FILE fubar;

int main()
{
  return 0;
}

Code: Select all

#include <stdio.h>

int main()
{
  FILE fubar;

  return 0;
}

[qw]

From the TC3 draft:

FILE [...] is an object type capable of recording all the information needed to control a stream, including its file position indicator, a pointer to its associated buffer (if any), an error indicator that records whether a read/write error has occurred, and an end-of-file indicator that records whether the end of the file has been reached [...]

I guess this means that FILE could be any type except void. So yes, your example code should be guaranteed to be valid.

Roel

[Solar]

Yes, both programs are C99 compliant.

The standard says:

[FILE is] an object type capable of recording all the information needed to control a
stream, including its file position indicator, a pointer to its associated buffer (if any), an
error indicator that records whether a read/write error has occurred, and an end-of-file
indicator that records whether the end of the file has been reached;

Means, you can handle FILE just as any other object, but you are not allowed to make any assumptions of its contents, as they are implementation-specific.

Most importantly, there is no way for a compliant program to initialize a FILE object itself, or copy one such object. It is an opaque type you get either pre-defined (stdin, stdout, stderr), or as return-value from fopen().

Edit: Hobbes beat me to it.

[qw]

Always nice beating a five-star.

[earlz]

I remember reading somewhere when I was looking at implementing it in my old OS.. "Only a mad-man would dare to mess with the internals of the FILE structure from a user program"