KS>> Just that I still think that the most obvious way to
 KS>> implement fopen() and friends is simply just do a malloc() +
 KS>> relevant magic and return the value of the malloc()...
 DM> I disagree - if the implementation doesn't remember all of its
 DM> "pointers", how is it supposed to flush their buffers when the
 AR> So it should NOT loose track of it. Other than 
 AR> returning it it should also keep it itself somewhere in 
 AR> a (dynamic) array. How else ... ;-)
I'd call that more than just "relevant magic".  ;-)  When I see "relevant" I 
think about file-related things, not memory-related things, especially since 
you've started the seperation already by talking about malloc.  I'm not 
convinced that this would be the simplest way, either.  I'm more inclined to 
think that a linked list would be a lot simpler than a growing array of 
pointers.  [With a little relevant magic, fclose could find the array by 
casting the FILE* to a FILE_LIST*, and now use the forward and back pointers 
to clean up... in constant time!  - if the FILE wasn't the first element 
in the FILE_LIST struct, just use OFFSETOF() to subtract from the pointer [as 
a char*], and cast this as the FILE_LIST]
Much simpler, IMO.
---
---------------