Jeff wrote:
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>
--
Er*********@sun.com