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.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It sure is cool having money and chicks."
- Beavis and Butt-head

[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.

--
Richard

[Severian]

On 16 Apr 2004 06:12:04 GMT, Joona I Palaste <pa*****@cc.hel sinki.fi>
wrote:

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.)

--
Sev

[Irrwahn Grausewitz]

Joona I Palaste <pa*****@cc.hel sinki.fi> wrote:

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
--
Irrwahn Grausewitz (ir*******@free net.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html

[CBFalconer]

Irrwahn Grausewitz wrote:

.... 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.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Irrwahn Grausewitz]

CBFalconer <cb********@yah oo.com> wrote:

Irrwahn Grausewitz wrote:

... 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;

<snip>and executes roughly 4 instructions per iteration. This allows
buffering input to have a major effect on execution speed. <snip>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
--
Irrwahn Grausewitz (ir*******@free net.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html

[Irrwahn Grausewitz]

Irrwahn Grausewitz <ir*******@free net.de> wrote:

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

Dreaded, no, just the other way round!
--
Irrwahn Grausewitz (ir*******@free net.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html

[Dan Pop]

In <5n************ *************** *****@4ax.com> Irrwahn Grausewitz <ir*******@free net.de> writes:

CBFalconer <cb********@yah oo.com> wrote:

Irrwahn Grausewitz wrote:

... 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;

<snip>

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

<snip>

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;

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Irrwahn Grausewitz]

Da*****@cern.ch (Dan Pop) wrote:

Irrwahn Grausewitz <ir*******@free net.de> writes:

CBFalconer <cb********@yah oo.com> wrote: <snip>

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;

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
--
Irrwahn Grausewitz (ir*******@free net.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html

[pete]

Joona I Palaste wrote:

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.

--
pete