Release file descriptor in c/c++

[yinglcs]

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.

 

[Alf P. Steinbach]

* (e-mail address removed):

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.

abort() has even stronger guarantees about what will /not/ happen.

What happens elsewhere, e.g. OS cleanup, is off-topic in this group.


Cheers, & hth.,

- Alf

 

[werasm]

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

 

[Guest]

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).

 

[Pete Becker]

* (e-mail address removed):

"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.

 

[Alf P. Steinbach]

* Pete Becker:

* (e-mail address removed):

"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)".

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").

Additionally, AFAIK C++ iostreams are not necessarily implemented in
terms of or associated with corresponding C streams, except for the
named stream objects (std::cin & family), which are associated.

In short, in C++ there's no guarantee about "file descriptors", and the
guarantee about all "files" being closed in C (considering that the OP
states the program is "c/c++") is probably just a reference to C
streams, imperfectly worded.

As someone else remarked else-thread, the OP could try to achieve his
goal by registering every open "file descriptor" in some global
variable(s), and using atexit().

However, that's tricky, and still doesn't help with abort().

In the end the practical solution is probably to rely on the operating
system closing those "file descriptors", assuming they're managed by the OS.

For C++ does not give any guarantees about them.

Cheers,

- Alf

 

[Pete Becker]

* Pete Becker:

* (e-mail address removed):
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.

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.

 

[Alf P. Steinbach]

* Pete Becker:

* Pete Becker:

On 2007-10-07 20:04:47 -1000, "Alf P. Steinbach" <[email protected]> said:

* (e-mail address removed):
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.

Indeed. What I said is, nevertheless, true, and what you said is not.

I'm not averse to admitting mistakes, did that just one day ago in this
group, and neither am I averse to pointing out others' mistakes, but hey.

Cheers,

- Alf

 

[Pete Becker]

* Pete Becker:

* Pete Becker:
On 2007-10-07 20:04:47 -1000, "Alf P. Steinbach" <[email protected]> said:

* (e-mail address removed):
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.