By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,876 Members | 1,239 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,876 IT Pros & Developers. It's quick & easy.

Release file descriptor in c/c++

P: n/a
I have a c/c++ program in linux.

I would like to know if I kill my program (e.g. exit(1)), will it
release all the file descriptors my program held (regardless if I call
close(fd) of each file descriptor)?

Thank you.

Oct 8 '07 #1
Share this Question
Share on Google+
5 Replies


P: n/a
On Oct 8, 6:33 am, "ying...@gmail.com" <ying...@gmail.comwrote:
I have a c/c++ program in linux.

I would like to know if I kill my program (e.g. exit(1)), will it
release all the file descriptors my program held (regardless if I call
close(fd) of each file descriptor)?

Thank you.
Someone could correct me if I'm wrong, but a guarantee that the
standard does make is that functions registered with atexit will
get called following the call to exit. This implies that you
could bind files to objects with static storage if you want
to ensure they get closed.

Regards,

Werner

Oct 8 '07 #2

P: n/a
On 2007-10-08 15:14, werasm wrote:
On Oct 8, 6:33 am, "ying...@gmail.com" <ying...@gmail.comwrote:
>I have a c/c++ program in linux.

I would like to know if I kill my program (e.g. exit(1)), will it
release all the file descriptors my program held (regardless if I call
close(fd) of each file descriptor)?

Thank you.

Someone could correct me if I'm wrong, but a guarantee that the
standard does make is that functions registered with atexit will
get called following the call to exit. This implies that you
could bind files to objects with static storage if you want
to ensure they get closed.
That should work, but it will not help if abort() is called. On the
other hand, most modern OSes will release file-handles and other
resources associated with a process when it terminates (however it might
or might not flush any buffered data).

--
Erik Wikström
Oct 8 '07 #3

P: n/a
On 2007-10-07 20:04:47 -1000, "Alf P. Steinbach" <al***@start.nosaid:
* yi*****@gmail.com:
>I have a c/c++ program in linux.

I would like to know if I kill my program (e.g. exit(1)), will it
release all the file descriptors my program held (regardless if I call
close(fd) of each file descriptor)?

"File descriptor" is not defined by, or even mentioned in, the C++ standard.

However, possibly you mean "will all open files be closed".

And the answer is that the C++ standard only makes a guarantee in the
opposite direction, what will /not/ happen, namely that exit() will not
call destructors of local objects.
Gosh, are all those words in [support.start.term]/8 that seem to be
talking about what exit() does just spares?

In both C and C++, among other things, exit() flushes buffers and
closes all C streams.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Oct 8 '07 #4

P: n/a
On 2007-10-08 08:57:51 -1000, "Alf P. Steinbach" <al***@start.nosaid:
* Pete Becker:
>On 2007-10-07 20:04:47 -1000, "Alf P. Steinbach" <al***@start.nosaid:
>>* yi*****@gmail.com:
I have a c/c++ program in linux.

I would like to know if I kill my program (e.g. exit(1)), will it
release all the file descriptors my program held (regardless if I call
close(fd) of each file descriptor)?

"File descriptor" is not defined by, or even mentioned in, the C++ standard.

However, possibly you mean "will all open files be closed".

And the answer is that the C++ standard only makes a guarantee in the
opposite direction, what will /not/ happen, namely that exit() will not
call destructors of local objects.

Gosh, are all those words in [support.start.term]/8 that seem to be
talking about what exit() does just spares?

No, the standard just doesn't mention "file descriptors", nor "close(fd)".
Sigh. I knew you'd pretend you said something different from what you
actually said, which is all still quoted above.
>
>In both C and C++, among other things, exit() flushes buffers and
closes all C streams.

close(fd), mentioned by the OP, is not an operation on a C stream.
I.e., the flushing and closing of C streams is generally irrelevant to
the OP's "file descriptors", except that it may close those "file
descriptors" that correspond to C streams (but there is no guarantee
that a C stream is implemented in terms of a "file descriptor").
Indeed. What I said is, nevertheless, true, and what you said is not.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Oct 8 '07 #5

P: n/a
On 2007-10-08 10:11:40 -1000, "Alf P. Steinbach" <al***@start.nosaid:
* Pete Becker:
>On 2007-10-08 08:57:51 -1000, "Alf P. Steinbach" <al***@start.nosaid:
>>* Pete Becker:
On 2007-10-07 20:04:47 -1000, "Alf P. Steinbach" <al***@start.nosaid:

* yi*****@gmail.com:
>I have a c/c++ program in linux.
>>
>I would like to know if I kill my program (e.g. exit(1)), will it
>release all the file descriptors my program held (regardless if I call
>close(fd) of each file descriptor)?
>
"File descriptor" is not defined by, or even mentioned in, the C++ standard.
>
However, possibly you mean "will all open files be closed".
>
And the answer is that the C++ standard only makes a guarantee in the
opposite direction, what will /not/ happen, namely that exit() will not
call destructors of local objects.
>

Gosh, are all those words in [support.start.term]/8 that seem to be
talking about what exit() does just spares?

No, the standard just doesn't mention "file descriptors", nor "close(fd)".

Sigh. I knew you'd pretend you said something different from what you
actually said, which is all still quoted above.

I think that when you read the text and ended up with some meaning that
didn't make sense, whatever it was, you knew that that interpretation
was silly.
What you said:

"However, possibly you mean 'will all open files be closed'."
"And the answer is that the C++ standard only makes a guarantee in the
opposite direction, what will /not/ happen, namely that exit() will not
call destructors of local objects.

The C++ standard guarantees that exit() flushes buffers and closes C
streams. That is more than a guarantee of what will not happen.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Oct 8 '07 #6

This discussion thread is closed

Replies have been disabled for this discussion.