include files bug?

[Joerg Sonnenberger]

On Tue, Aug 16, 2005 at 07:46:56AM -0000, Andreas Hauser wrote:
> joerg wrote @ Tue, 9 Aug 2005 20:11:43 +0200:
> > On Tue, Aug 09, 2005 at 04:49:24PM +0100, Stefan Krüger wrote:
> 
> > > here's some code which did not compile:
> > > 
> > > #include <openssl/md5.h>
> > > int main() { return 0; }
> > > 
> > > -------
> > > 
> > > #include <stdio.h>
> > > int main() { sizeof(FILE); return 0; }
> 
> > You are not supposed to access FILE directly, it's opaque simply to
> > avoid any stupid uses. E.g. you can't copy a FILE object to a different
> > location and expect it work, you can't just access it (because the
> > layout is opaque), the only valid way to create a FILE is via stdio --
> > so what should sizeof(FILE) be allowed for?
> 
> You wrote in the commit message:
>   Make FILE an opaque type for normal operation (anything outside libc).
>   This means programs have to use the exported interface, they can neither
>   make static instances on the heap or access fields of their own.
> 
> That seems to break SUSv3:
>   The following data types shall be defined through typedef:
>   FILE
>       A structure containing information about a file.

FILE (!) is defined through typedef. If you can give me any valid
example, why taking a random size of FILE should be allowed, I can
consider changing it. Otherwise it would just complicate libc and don't
allow us to catch the dangerous abuse of FILE declared on the stack.

I'm also willing to take this dispute to SUS, as this can be considered
a valid concern. There are other examples of where SUS allows
incomplete types, e.g. dirent.d_name doesn't have to allow sizeof as
open array.

> > The reason why I haven't fixed ruby is that I don't have any idea what
> > they use it for.
> 
> I think, they just have generic ways to deal with objects and pointers.
> The generic pointer structure contains a field for the size of the pointee.

So it can be replaced by 0 then? I take it that they want to do boundary
checks, so 0 would satisfy the "Don't mess with the implementation"
requirement.

Joerg