Why not FILE instead of FILE*?

[Joona I Palaste]

Why is the standard C type for file handles FILE* instead of FILE?
AFAIK the type FILE is a pre-defined typedef for some other type anyway.
So why not make it instead a typedef for a *pointer* to that type? For
one thing, that would stop people trying to poke around at the insides
of a FILE. For another, it could allow for cases where the "real" type
behind FILE is not a pointer to anything.

 

[Richard Delorme]

Joona I Palaste a écrit :

Why is the standard C type for file handles FILE* instead of FILE?
AFAIK the type FILE is a pre-defined typedef for some other type anyway.
So why not make it instead a typedef for a *pointer* to that type? For
one thing, that would stop people trying to poke around at the insides
of a FILE. For another, it could allow for cases where the "real" type
behind FILE is not a pointer to anything.

If FILE is not a pointer for sure, there is a need to change other parts
of the standard, like fopen returning NULL on failure. I am afraid that
such a change breaks too much well-formed code.
Moreover, it is very easy to create your own typedef if FILE does not
fit your need, so a change in the standard is not required.

 

[Severian]

Why is the standard C type for file handles FILE* instead of FILE?
AFAIK the type FILE is a pre-defined typedef for some other type anyway.
So why not make it instead a typedef for a *pointer* to that type? For
one thing, that would stop people trying to poke around at the insides
of a FILE. For another, it could allow for cases where the "real" type
behind FILE is not a pointer to anything.

FILE * is not a good representation of an opaque type, since
implementation-provided macros may depend on FILE members (i.e.,
getc).

If macro definitions could be hidden, FILE would not need to be so
pubic. (Oops, public.)

 

[Irrwahn Grausewitz]

Why is the standard C type for file handles FILE* instead of FILE?
AFAIK the type FILE is a pre-defined typedef for some other type anyway.
So why not make it instead a typedef for a *pointer* to that type? For
one thing, that would stop people trying to poke around at the insides
of a FILE. For another, it could allow for cases where the "real" type
behind FILE is not a pointer to anything.

IMHO Making FILE a typedef alias for pointer-to-realfiletype would've
caused even more confusion among programmers, and on itself wouldn't
have kept anybody from manipulating the internals of the underlying
type (lookup the struct declaration in stdio.h as before, and use .
instead of ->, that's all).

Actually, the IMNSHO most reasonable solution would've been to keep
the typedef as is, but hide the internals of the underlying type by
moving its declaration from the header to the library source (make
it an opaque type), e.g. something like:


/************* stdio.h *************/
typedef
struct _iobuf
FILE;

FILE *fopen(const char *, const char *);
/* .... */
/***********************************/


/************* stdio.c *************/
#include <stdio.h>

struct _iobuf
{
int _file;
int _flag;
/* etc. */
};

FILE *fopen(const char *filename, const char *mode)
{
/* yaddayaddayadda */;
}
/* .... */
/***********************************/


This approach however has the drawback that getc and putc could
not have been easily implemented as simple macros, but given the
potential dangers that arise from such macro implementations,
it's highly debatable if this would've been a big loss (IMO not).

Regards

 

[CBFalconer]

.... snip ...

This approach however has the drawback that getc and putc could
not have been easily implemented as simple macros, but given the
potential dangers that arise from such macro implementations,
it's highly debatable if this would've been a big loss (IMO not).

IMO yes. Consider:

while ('\n' != (c = getc(stdin))) continue;

If getc is a function this involves a function call, and all its
overhead, for each loop execution. If getc is a macro this is
likely to become (pseudo assembly):

<initialization>
..1: inc R1
eq R1,R2
jf .2
call load; (resets R1, R2, buffer, may be inline)
..2: eq (R1), '\n'
jf .1

and executes roughly 4 instructions per iteration. This allows
buffering input to have a major effect on execution speed. The
registers are all pointing to some offsets within *stdin. If the
eq/jf pairs are single instructions, we have 3 per iteration. If
we can embed auto-increment, we may have 2 instructions per
iteration, with one memory access, which in turn is probably
cached.

Not bad for a simple minded optimizer. There is a reason C is
known as structured assembly.

 

[Irrwahn Grausewitz]

[...], and use . instead of ->, that's all).

Dreaded, no, just the other way round!

 

[Irrwahn Grausewitz]

IMO yes. Consider:

while ('\n' != (c = getc(stdin))) continue;

and executes roughly 4 instructions per iteration. This allows
buffering input to have a major effect on execution speed.

Not bad for a simple minded optimizer. There is a reason C is
known as structured assembly.

IMHO there's good reason to deviate from this POV in the age of
optimizing compilers and 'intelligent' caches. I'd rather have
my programs waste some cycles than use potentially dangerous
macros; furthermore, if I feel the need to produce top-notch
micro-optimized assembly code, well, then I won't rely on a C
compiler for this task in the first place. Other's mileages may
(and will) of course vary.

Regards

 

[Dan Pop]

IMHO there's good reason to deviate from this POV in the age of
optimizing compilers and 'intelligent' caches. I'd rather have
my programs waste some cycles than use potentially dangerous
macros;

What is potentially dangerous in macros like getc and putc? They've
been implemented as macros since the invention of <stdio.h> and I haven't
heard anyone complaining about them...

Dan

 

[Irrwahn Grausewitz]

What is potentially dangerous in macros like getc and putc? They've
been implemented as macros since the invention of <stdio.h> and I haven't
heard anyone complaining about them...

I consider all function-like macros to be potentially dangerous,
even if I wrote them myself. By avoiding them [1], I don't have
to think about possible side effects and can concentrate on more
important things. You may call me lazy.

[1] As with all general rules, I occasionally break it.

Regards

 

[pete]

Why is the standard C type for file handles FILE* instead of FILE?
AFAIK the type FILE is a pre-defined typedef for some other type anyway.
So why not make it instead a typedef for a *pointer* to that type? For
one thing, that would stop people trying to poke around at the insides
of a FILE. For another, it could allow for cases where the "real" type
behind FILE is not a pointer to anything.

Because the address of the FILE type object may be significant.
A copy of a FILE type object, might not work the same as the original.

 

[Dan Pop]

What is potentially dangerous in macros like getc and putc? They've
been implemented as macros since the invention of <stdio.h> and I haven't
heard anyone complaining about them...

I consider all function-like macros to be potentially dangerous,
even if I wrote them myself. By avoiding them [1], I don't have
to think about possible side effects and can concentrate on more
important things. You may call me lazy.

I still miss your point: the standard *guarantees* that all the macros
from the standard library are safe, with the exception of getc and
putc, which have a special licence for multiple evaluation of the
FILE pointer parameter.

When was the last time you felt tempted to use an expression with
side effects in that position, in a getc or putc call?

It is common practice for unsafe user defined macros to be spelled in
all caps, precisely so that the programmer doesn't feel tempted to use
expressions with side effects when calling them.

Being lazy myself (I see this as a quality for programmers) I avoid
such expressions in anything that is or resembles a function call.
This way, I keep the possibility of later turning a function into a macro
open.

Dan

 

[Dan Pop]

Because the address of the FILE type object may be significant.
A copy of a FILE type object, might not work the same as the original.

Non sequitur. FILE itself could be a typedef for a pointer. Which is
precisely Joona's point.

Dan

 

[Keith Thompson]

(e-mail address removed) (Dan Pop) wrote: [...]

What is potentially dangerous in macros like getc and putc? They've
been implemented as macros since the invention of <stdio.h> and I haven't
heard anyone complaining about them...

I consider all function-like macros to be potentially dangerous,
even if I wrote them myself. By avoiding them [1], I don't have
to think about possible side effects and can concentrate on more
important things. You may call me lazy.

[1] As with all general rules, I occasionally break it.

If something as fundamental as getc() or putc() is broken, you
shouldn't trust anything in your C implementation. Conversely (well,
contrapositively), if your implementation is robust enough to handle a
"hello, world" program, you might as well trust getc() and putc() to
work correctly.

The only pitfall is that the getc's or putc's stream argument may be
evaluated more than once, but that's hardly likely to be a problem in
any normal code.

In any case, *any* library function may be additionally implemented as
a function-like macro; if you want to avoid the macro for some reason,
you can "#undef" it or enclose the name in parentheses.