include files bug?

Simon 'corecode' Schubert corecode at fs.ei.tum.de
Tue Aug 16 05:29:55 PDT 2005


On 16.08.2005, at 09:46, Andreas Hauser wrote:
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.
The problem is, that if we make FILE a complete type, we won't catch 
uses of sizeof(FILE) and FILE variables (in contrast to FILE*).  If we 
can't prevent programs use those, we effectively can't change FILE 
without breaking binary compatibility.  It's a two-edged sword, as 
usual.

How many ports break because of this?

Maybe if one uses something like:

struct FILE { char opaque[SOME_SIZE]; };
well, I guess the SOME_SIZE is the problem :)

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.
well, but if they don't allocate the memory for the pointee, they don't 
have to know about its size, arguably.

Where does the standard say something about the (claimed by joerg) fact 
that FILEs may not be instanciated (except by libc) or copied, nor 
their size taken?

If this is allowed, we need to change it back.  Well, we still could do:

struct __real_FILE {
	all stuff...
};
struct FILE {
	struct __real_FILE *_therealfile;
};
typedef struct FILE FILE;

#define _FILESIZE	(sizeof(struct FILE) + sizeof(struct __real_FILE))

FILE *
fopen(...)
{
	FILE *f;
	f = malloc(_FILESIZE);
	f->_therealfile = (struct __real_FILE *)(f + 1);
	...
}
other_func(FILE *f)
{
	struct __real_FILE *rf = f->_therealfile;
	...
}
fclose(FILE *f)
{
	free((struct FILE *)f->_therealfile - 1);
	...
}
For a non-copied FILE *, __therealfile will be in the same cacheline as 
the FILE itself, otherwise there is a (small) speed penalty, but so 
what.

Or am I talking foo?

cheers
  simon
	
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low $$$ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \
Attachment:
PGP.sig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: This is a digitally signed message part"
URL: <http://lists.dragonflybsd.org/pipermail/bugs/attachments/20050816/c8ee92e4/attachment-0020.obj>


More information about the Bugs mailing list