Hacker News Reader

Comment by severino | Hacker News Reader

Out of curiosity. If we have this inside `bits/types/FILE.h` in Linux/GNU, does it mean the type is opaque?

  ...
  struct _IO_FILE;
  
  /* The opaque type of streams.  This is the definition used elsewhere.  */
  typedef struct _IO_FILE FILE;
  ...

View on HN

Unless struct _IO_FILE is expanded elsewhere, yes, it's opaque and can only be interacted through a pointer, as it would otherwise be an unsized object.

The definition of struct _IO_FILE seems to be inside `bits/types/struct_FILE.h`, and goes like this:

  struct _IO_FILE
  {
    int _flags;
    ...

so I suppose this means it's indeed expanded somewhere and, thus, not opaque?

When we're talking about opaque it's really in relation to an individual translation unit - somewhere in the binary or its linked libraries the definition has to exist for the code that uses the opaque type.

Forgive my ignorance in this topic, but if "stdio.h" itself includes "bits/types/struct_FILE.h", is anything preventing me from accessing the individual elements of FILE as they are defined in the latter header file?

It looks like FILE is not opaque in glibc. Create a translation unit that includes <stdio.h> & declares a FILE variable and it compiles fine. For comparison, create a translation unit that declares your own struct (but does not provide a definition) and declares a variable of the same type, and you'll get a "storage size of 'x' isn't known" error when compiling.

Thanks for the explanation. In case FILE was opaque in glibc, would the same test (including <stdio.h> and declaring a variable of type FILE) also fail with the unknown storage size error? If so, would linking again some library (-l) be necessary?

EDIT: after some more thinking I assume the key is that we wouldn't be able to have a variable of type FILE, but a pointer, whose size is always known.

You'd have an error about an incomplete type - see https://godbolt.org/z/G4Gsfn7MT

> a pointer, whose size is always known

Yeah, this is exactly how it works. You work with a pointer that acts like a void* in your code, and the library with the definition is allowed to reach into the fields of that pointer. Normally you'd have a C API like

    struct Op;
    Op* init_op();
    void free_op( Op* );
    void do_something_with_op( Op* );

in the header provided by the library that you compile as part of your code, and the definition/implementation in some .a or .so/.dll that you'll link against.*

Reply on news.ycombinator.com