Why not FILE instead of FILE*?

Discussion in 'C Programming' started by Joona I Palaste, Apr 16, 2004.

  1. 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 () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "It sure is cool having money and chicks."
    - Beavis and Butt-head
     
    Joona I Palaste, Apr 16, 2004
    #1
    1. Advertising

  2. 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
     
    Richard Delorme, Apr 16, 2004
    #2
    1. Advertising

  3. Joona I Palaste

    Severian Guest

    On 16 Apr 2004 06:12:04 GMT, 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.


    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
     
    Severian, Apr 16, 2004
    #3
  4. 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.


    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 ()
    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, Apr 16, 2004
    #4
  5. Joona I Palaste

    CBFalconer Guest

    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?
     
    CBFalconer, Apr 16, 2004
    #5
  6. Irrwahn Grausewitz, Apr 16, 2004
    #6
  7. CBFalconer <> 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 ()
    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, Apr 16, 2004
    #7
  8. Joona I Palaste

    Dan Pop Guest

    In <> Irrwahn Grausewitz <> writes:

    >CBFalconer <> 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, Apr 16, 2004
    #8
  9. (Dan Pop) wrote:
    >Irrwahn Grausewitz <> writes:
    >>CBFalconer <> 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 ()
    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, Apr 16, 2004
    #9
  10. Joona I Palaste

    pete Guest

    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
     
    pete, Apr 17, 2004
    #10
  11. Joona I Palaste

    Dan Pop Guest

    In <> Irrwahn Grausewitz <> writes:

    > (Dan Pop) wrote:
    >>Irrwahn Grausewitz <> writes:
    >>>CBFalconer <> 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, Apr 19, 2004
    #11
  12. Joona I Palaste

    Dan Pop Guest

    In <> pete <> 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, Apr 19, 2004
    #12
  13. Irrwahn Grausewitz <> writes:
    > (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) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    Schroedinger does Shakespeare: "To be *and* not to be"
     
    Keith Thompson, Apr 21, 2004
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Horace Nunley

    why why why does function not work

    Horace Nunley, Sep 27, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    500
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=
    Sep 27, 2006
  2. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    981
    Mark Rae
    Dec 21, 2006
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,226
    Smokey Grindel
    Dec 2, 2006
  4. Skybuck Flying
    Replies:
    16
    Views:
    701
    tragomaskhalos
    Aug 25, 2007
  5. Kristian Domke
    Replies:
    11
    Views:
    531
    George Sakkis
    Jan 23, 2008
Loading...

Share This Page