fclose

[Jeff]

If this in not an ANSI-C question, then just flame me and I'll be on my
way....

I am using fdopen to associate a FILE with a socket descriptor. (Because
I've mentioned a socket descriptor I anticipate the flame. But I believe
this is a C question.) My problem is this: if the socket is closed and I
pass the FILE returned from fdopen to fclose, my program dies with a
memory fault. My question: why do I get a memory fault with fclose when
the socket descriptor is closed and how can I prevent that?

TIA,
Jeff

 

[Joona I Palaste]

If this in not an ANSI-C question, then just flame me and I'll be on my
way....

I am using fdopen to associate a FILE with a socket descriptor. (Because
I've mentioned a socket descriptor I anticipate the flame. But I believe
this is a C question.) My problem is this: if the socket is closed and I
pass the FILE returned from fdopen to fclose, my program dies with a
memory fault. My question: why do I get a memory fault with fclose when
the socket descriptor is closed and how can I prevent that?

This is not meant to be a flame, but socket descriptors and fdopen() are
not part of ISO standard C. So therefore your question is off-topic on
comp.lang.c. Please ask in comp.unix.programmer.

 

[Eric Sosman]

If this in not an ANSI-C question, then just flame me and I'll be on my
way....

I am using fdopen to associate a FILE with a socket descriptor. (Because
I've mentioned a socket descriptor I anticipate the flame. But I believe
this is a C question.) My problem is this: if the socket is closed and I
pass the FILE returned from fdopen to fclose, my program dies with a
memory fault. My question: why do I get a memory fault with fclose when
the socket descriptor is closed and how can I prevent that?

You've been burned by the anticipated flame ;-)

The problem is with the interaction between the C-defined
fclose() and the non-C components like fdopen() and sockets.
And the upshot is that the unaided C language can't help you
with problems outside its scope. You'll need to seek advice
from a newsgroup or other source that deals with the platform(s)
on which you have the problem.

<off-topic>

It's sometimes possible but always risky to mix different
"access paths" to a single object. On POSIXoid systems it usually
turns out that the FILE* mechanisms are built atop the "lower-
level" file descriptor mechanisms, and as such they are likely to
be confused if you manipulate the lower-level stuff without their
knowledge. By closing the socket while its FILE* object still
thinks it's open you're, you're, uh -- well, imagine getting some
memory from malloc() and then releasing it with munmap(); can
you think of some of the kinds of trouble that might result?

</off-topic>

 

[Karen]

If this in not an ANSI-C question, then just flame me and I'll be on my
way....

I am using fdopen to associate a FILE with a socket descriptor. (Because
I've mentioned a socket descriptor I anticipate the flame. But I believe
this is a C question.) My problem is this: if the socket is closed and I
pass the FILE returned from fdopen to fclose, my program dies with a
memory fault. My question: why do I get a memory fault with fclose when
the socket descriptor is closed and how can I prevent that?

I guess if the socket is closed, the fdopen get a NULL pointer return,
you pass NULL pointer to fclose, it has memory fault.

Why don't you want to check the fdopen reutrn value is NULL or ERROR
condition?


Regards

 

[Dan Pop]

I am using fdopen to associate a FILE with a socket descriptor. (Because
I've mentioned a socket descriptor I anticipate the flame. But I believe
this is a C question.) My problem is this: if the socket is closed and I
pass the FILE returned from fdopen to fclose, my program dies with a
memory fault. My question: why do I get a memory fault with fclose when
the socket descriptor is closed and how can I prevent that?

Once you have built a stream around your socket descriptor, you're no
longer allowed to access that socket descriptor directly, ALL the
accesses must be performed using the stream interface. In this case,
your problem goes away, because the only way of closing the socket is
by closing the associated stream.

This is less off topic than it might look, because the advice is valid
for any low level I/O mechanism used by the stdio stream implementation,
not only for file descriptors.

Dan

 

[Jeff]

Once you have built a stream around your socket descriptor, you're no
longer allowed to access that socket descriptor directly, ALL the
accesses must be performed using the stream interface. In this case,
your problem goes away, because the only way of closing the socket is
by closing the associated stream.

This is less off topic than it might look, because the advice is valid
for any low level I/O mechanism used by the stdio stream implementation,
not only for file descriptors.

If this is true, then why would I get the memory fault when I fclose
the stream?

Jeff

 

[Eric Sosman]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If this is true, then why would I get the memory fault when I fclose
the stream?

Because the socket has already been closed. Hence, some
mechanism other than fclose() closed it. Hence, the program
has failed to observe the "ALL the accesses..." requirement
by allowing this other mechanism to disturb the socket.