4 ms·
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, cr
by yrro 1y ago
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.
- severino 1y agoThanks 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.
- clappski 1y agoYou'd have an error about an incomplete type - see https://godbolt.org/z/G4Gsfn7MT 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.*