f



Why not FILE instead of FILE*?

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 (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It sure is cool having money and chicks."
   - Beavis and Butt-head
0
palaste (2323)
4/16/2004 6:12:04 AM
comp.lang.c 30657 articles. 5 followers. spinoza1111 (3246) is leader. Post Follow

12 Replies
1192 Views

Similar Articles

[PageSpeed] 53

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

0
abulmo (47)
4/16/2004 7:18:08 AM
On 16 Apr 2004 06:12:04 GMT, Joona I Palaste <palaste@cc.helsinki.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
0
severian (105)
4/16/2004 7:19:58 AM
Joona I Palaste <palaste@cc.helsinki.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 (irrwahn33@freenet.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
0
irrwahn33 (608)
4/16/2004 8:33:42 AM
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?


0
cbfalconer (19194)
4/16/2004 11:11:39 AM
Irrwahn Grausewitz <irrwahn33@freenet.de> wrote:
>[...], and use . instead of ->, that's all).

Dreaded, no, just the other way round!
-- 
Irrwahn Grausewitz (irrwahn33@freenet.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
0
irrwahn33 (608)
4/16/2004 12:36:55 PM
CBFalconer <cbfalconer@yahoo.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 (irrwahn33@freenet.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
0
irrwahn33 (608)
4/16/2004 12:36:56 PM
In <5nkv70tkj3jpom94a0kjut3d5sto117u8j@4ax.com> Irrwahn Grausewitz <irrwahn33@freenet.de> writes:

>CBFalconer <cbfalconer@yahoo.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: Dan.Pop@ifh.de
0
Dan.Pop (3615)
4/16/2004 2:41:29 PM
Dan.Pop@cern.ch (Dan Pop) wrote:
>Irrwahn Grausewitz <irrwahn33@freenet.de> writes:
>>CBFalconer <cbfalconer@yahoo.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 (irrwahn33@freenet.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
0
irrwahn33 (608)
4/16/2004 6:25:54 PM
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
0
pfiland (6613)
4/17/2004 10:47:00 AM
In <249080h8no18te7gfioo7lsg83hcvdutkl@4ax.com> Irrwahn Grausewitz <irrwahn33@freenet.de> writes:

>Dan.Pop@cern.ch (Dan Pop) wrote:
>>Irrwahn Grausewitz <irrwahn33@freenet.de> writes:
>>>CBFalconer <cbfalconer@yahoo.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.  :-)

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
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
0
Dan.Pop (3615)
4/19/2004 4:23:08 PM
In <40810B27.1DE2@mindspring.com> pete <pfiland@mindspring.com> writes:

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

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

Dan
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
0
Dan.Pop (3615)
4/19/2004 4:26:00 PM
Irrwahn Grausewitz <irrwahn33@freenet.de> writes:
> Dan.Pop@cern.ch (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.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
0
kst-u (21963)
4/20/2004 11:41:43 PM
Reply: