On Mon, Mar 24, 2003 at 10:29:32AM -0500, Ray Butterworth wrote:
> Note that I wasn't claiming it was portable,
> just that a similar mechanism (e.g. "iob[]", "_iob[]", or "__iob[]")
> exists in all the UNIX versions I've seen over the last 20+ years
> except for in LINUX. And it's not only the SysV versions: BSD 4.3
> had this in 1982:
> extern struct _iobuf {
> char *_ptr;
> char *_rms;
> char *_base;
> long int _sectr;
> short int _flag;
> short int _cnt;
> char _links;
> char _file;
> short int _maxoffset;
> long int _maxsectr;
> } _iob[_NFILE];
> and I'm sure that earlier versions had something similar.
One problem is that the potential number of open files isn't a
compile-time constant on modern versions of Linux. I've spent the last
week on systems where it had to be raised to several hundred thousand,
but having an array that size would obviously be a very significant
waste of memory on small systems.
This is not to say that there isn't a way to get what you want, although
I don't know what it might be, but to offer a potential reason why
__iob[] hasn't survived into modern Unix. Even on systems that have it
I'm not sure whether you can rely on it when there might be large
numbers of open files.
> > Even if it did have an __iob[] you probably shouldn't be relying on
> > somebody else to keep track of the files you have open. You're the only
> > one who knows (or at least you're supposed to know) why you have files
> > open, so you should usually be trying to make an informed decision about
> > what to do with them.
> >
> > Thinking ahead about things like that is a good habit, I've had no end
> > of headaches from listening to programmers going on about how the
> > compiler/runtime/server/whatever "should do that for me" when you tell
> > them their code is crashing because they didn't think about the side
> > effects of what they were doing.
>
> Yes, I agree totally. The problem is that I'm not writing the
> programs themselves, but some general-purpose library functions
> for others to use. For instance, if one of these library functions
> needs to do something like fork a new process, it should do some
> cleanup first, in which case it will need to know which "FILE *"
> descriptors are still open. Until now, that has been a trivial task.
Wouldn't it be easier to set the close-on-exec flag on all file
descriptors using fcntl()? You want to do this on low-level file
descriptors anyway rather than on (FILE *) streams, since not everything
uses stdio.
> But wait, the fflush((FILE *)0) call needs this same information too,
> so what I wanted can't be that unreasonable or difficult.
fflush(NULL) appears to iterate along _chain elements from _IO_list_all
(which I think is basically _IO_stderr). It's very much unclear to me
whether you can get at this from outside the libc, though, or if you can
whether it's safe: it's certainly not portable between libc versions,
for example, and if your code might be used in a multithreaded context
you'd need to know how to lock the list. Even in a library, I'd strongly
recommend finding another way.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
