Re: fflush & close behavior not well-defined

[Neil R. Ormos]

Andrew J. Schorr wrote:
> Neil R. Ormos wrote:

>> Is there a way to expose a handle or other
>> unambiguous ID corresponding to the most recent
>> operation on a file, pipe, or coprocess?

> Anything is possible. Behind the scenes, each
> open file/pipe/coprocess is represented by a
> structure, so of course the address of the
> structure is a unique identifier. Or one could
> assign an arbitrary identifier. That's not
> hard. Are you suggesting to stick this value
> somewhere in PROCINFO or some other global
> variable every time an I/O occurs? That seems a
> bit heavyweight for something nobody actually
> cares about.

That is what I was suggesting.  I imagined that
once the file had been opened, all that would be
needed to update the global variable, for each
I/O, would be to copy a pointer, which operation I
further imagined to be so cheap, compared to
actually launching the I/O, as to be "in the
noise".

Since you know the internals and I don't, I defer.

>> Then, a user who needs a non-ambiguous call to
>> close() or fflush() could pass the handle instead
>> of, or in addition to, the current filename
>> argument?

> I don't see why this is better than enhancing
> the close & fflush functions to give them the
> info they need to find the correct file, but
> maybe if you flesh out your idea with an
> example, I'll understand better.

I'm not sure it's /better/.  It just seems
/cleaner/ to let the user account for and supply a
single unambiguous identifier, than to require the
user to supply both the name and type of the
something that is to be close()-d or fflush()-ed,
and then for close() or fflush() to hunt around
for a match.

Again, I recognize that you know the internals and
I don't.

And that both you and Arnold see this as something
nobody actually cares about.