How to write this?

[seema_coma]

Hi all,
I am new to C programming,
All I just need to know is how to write the
following in C,
if (open STDOUT){
close the STDOUT
}

Can anyone guide me
Thanks

[Robert Harris]

se********@yahoo.co.in wrote:

Hi all,
I am new to C programming,
All I just need to know is how to write the
following in C,
if (open STDOUT){
close the STDOUT
}

Can anyone guide me
Thanks

Just close it; the close won't do anything if it isn't open.

Robert

[Ben Pfaff]

se********@yahoo.co.in writes:

All I just need to know is how to write the
following in C,
if (open STDOUT){
close the STDOUT
}

You might say what you are actually trying to do.
What you are proposing does not make much sense,
because stdout is already open when main() is called.
--
"...deficient support can be a virtue.
It keeps the amateurs off."
--Bjarne Stroustrup

[Walter Roberson]

In article <11**********************@g14g2000cwa.googlegroups .com>,
<se********@yahoo.co.in> wrote:

I am new to C programming,
All I just need to know is how to write the
following in C,
if (open STDOUT){
close the STDOUT
} Can anyone guide me

There is no equivilent in standard C itself: what you are asking
about is one of the very common implementation-dependant system
extensions.

C itself does not have STDOUT, only stdout -- and uppercase vs
lowercase *does* matter for this purpose.

C's stdout is a macro which evaluates to a FILE* -- a pointer to
a structure. The operation to close stdout is fclose(stdout).

There is no specific call in C to determine whether a particular
FILE* is open: you just try an operation on it and check to see
if the operation failed with a code indicating the file is closed.
Or for your purposes, as one of the posters pointed out, just
go ahead and close it: you won't bomb if it is already closed.
STDOUT on the other hand is not a FILE*; it is generally part of
an I/O extension in which STDOUT is a macro which evaluates to the
"underlying descriptor" number of C's FILE* stdout . File descriptor
numbers are not part of C itself; many operations with file descriptors
are formalized in POSIX.1 . The typical operation to close a
file associated with a file descriptor is close(). There is no
standardized specific call to find out whether a file descriptor is
open, but you can fstat() the descriptor and look to see whether
you received the error that indicates the descriptor is not open.
--
Look out, there are llamas!

[Kenneth Brody]

Walter Roberson wrote:
[...]

There is no specific call in C to determine whether a particular
FILE* is open: you just try an operation on it and check to see
if the operation failed with a code indicating the file is closed.
Or for your purposes, as one of the posters pointed out, just
go ahead and close it: you won't bomb if it is already closed.

So, the following is well-defined, assuming you pass a valid FILE*?

int my_fclose(FILE *f)
{
fclose(f);
return(fclose(f));
}

[...]

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[tedu]

Kenneth Brody wrote:

Walter Roberson wrote:
[...]

There is no specific call in C to determine whether a particular
FILE* is open: you just try an operation on it and check to see
if the operation failed with a code indicating the file is closed.
Or for your purposes, as one of the posters pointed out, just
go ahead and close it: you won't bomb if it is already closed.

if it was already closed, a call to fopen() could return the same
pointer, and then the "test" fclose() will close the wrong one.
So, the following is well-defined, assuming you pass a valid FILE*?

int my_fclose(FILE *f)
{
fclose(f);
return(fclose(f));
}

if you did the above in a threaded environment, it could have
unintended side-effects.

[Robert Gamble]

On Wed, 07 Sep 2005 13:44:29 -0400, Kenneth Brody wrote:

Walter Roberson wrote:
[...]

There is no specific call in C to determine whether a particular
FILE* is open: you just try an operation on it and check to see
if the operation failed with a code indicating the file is closed.
Or for your purposes, as one of the posters pointed out, just
go ahead and close it: you won't bomb if it is already closed.

So, the following is well-defined, assuming you pass a valid FILE*?

int my_fclose(FILE *f)
{
fclose(f);
return(fclose(f));
}

[...]

Nope, the value of f is indeterminate after the first fclose, the second
fclose invokes undefined behavior.

Robert Gamble

[Walter Roberson]

In article <pa****************************@gmail.com>,
Robert Gamble <rg*******@gmail.com> wrote:

On Wed, 07 Sep 2005 13:44:29 -0400, Kenneth Brody wrote:

So, the following is well-defined, assuming you pass a valid FILE*? int my_fclose(FILE *f)
{
fclose(f);
return(fclose(f));
}

Nope, the value of f is indeterminate after the first fclose, the second
fclose invokes undefined behavior.

The value of f cannot change as a result of fclose, as it is passed
by value. What f points -to- might change, of course.

The C standard says that FEOF is returned if an error is encountered,
and places no constraints about what kind of error that might be.

If one drops over to POSIX.1 then fclose() is defined in terms of
close() and write(), and close() is defined with a specific errno
if the descriptor is not open; so for POSIX.1 at least, fclose() of
something already closed is defined.
--
"Never install telephone wiring during a lightning storm." -- Linksys

[Keith Thompson]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

In article <pa****************************@gmail.com>,
Robert Gamble <rg*******@gmail.com> wrote:

On Wed, 07 Sep 2005 13:44:29 -0400, Kenneth Brody wrote:

So, the following is well-defined, assuming you pass a valid FILE*? int my_fclose(FILE *f)
{
fclose(f);
return(fclose(f));
}

Nope, the value of f is indeterminate after the first fclose, the second
fclose invokes undefined behavior.

The value of f cannot change as a result of fclose, as it is passed
by value. What f points -to- might change, of course.

The C standard says that FEOF is returned if an error is encountered,
and places no constraints about what kind of error that might be.

If one drops over to POSIX.1 then fclose() is defined in terms of
close() and write(), and close() is defined with a specific errno
if the descriptor is not open; so for POSIX.1 at least, fclose() of
something already closed is defined.

The C standard says:

A successful call to the fclose function causes the stream pointed
to by stream to be flushed and the associated file to be
closed. Any unwritten buffered data for the stream are delivered
to the host environment to be written to the file; any unread
buffered data are discarded. Whether or not the call succeeds, the
stream is disassociated from the file and any buffer set by the
setbuf or setvbuf function is disassociated from the stream (and
deallocated if it was automatically allocated).

It looks like the effect of fclose() on a file that's already been
closed isn't specified, which makes it undefined behavior.

And given a sequence like this:

fclose(foo);
bar = fopen("whatever");
fclose(foo);

it's possible (I think) that bar could point to a FILE object at the
same address as the one released by the first fclose(). The second
fclose() would then close bar.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Tobin]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

And given a sequence like this:

fclose(foo);
bar = fopen("whatever");
fclose(foo);

it's possible (I think) that bar could point to a FILE object at the
same address as the one released by the first fclose(). The second
fclose() would then close bar.

The description of freopen() says that it "attempts to close any file that
is associated with the specified stream". The use of "any" suggests that
the stream may already have been closed - compare fclose() which talks
about "the" file.

-- Richard

[Lawrence Kirby]

On Thu, 08 Sep 2005 10:18:21 +0000, Richard Tobin wrote:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

And given a sequence like this:

fclose(foo);
bar = fopen("whatever");
fclose(foo);

it's possible (I think) that bar could point to a FILE object at the
same address as the one released by the first fclose(). The second
fclose() would then close bar.
The description of freopen() says that it "attempts to close any file that
is associated with the specified stream". The use of "any" suggests that
the stream may already have been closed - compare fclose() which talks
about "the" file.

When a stream is closed it ceases to be a stream, like when a malloc()'d
object is freed it ceases to be an object.

freopen() requires that you pass it a pointer to valid stream; a stream
that has been closed doesn't meet that requirement and you get undefined
behaviour. The same is true for all functions that take a FILE * argument,
except that you can pass a null pointer to those that say explicitly that
you can (fflush). In particular passing a pointer to anything that a
proper open stream to fclose() invokes undefined behaviour.

Lawrence


closed isn't a stream
any more (loke an object that has been freed isn't an object any more).

-- Richard

[Flash Gordon]

Keith Thompson wrote:

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

In article <pa****************************@gmail.com>,
Robert Gamble <rg*******@gmail.com> wrote:

On Wed, 07 Sep 2005 13:44:29 -0400, Kenneth Brody wrote:

So, the following is well-defined, assuming you pass a valid FILE*?

int my_fclose(FILE *f)
{
fclose(f);
return(fclose(f));
}

Nope, the value of f is indeterminate after the first fclose, the second
fclose invokes undefined behavior.

The value of f cannot change as a result of fclose, as it is passed
by value. What f points -to- might change, of course.

The C standard says that FEOF is returned if an error is encountered,
and places no constraints about what kind of error that might be.

If one drops over to POSIX.1 then fclose() is defined in terms of
close() and write(), and close() is defined with a specific errno
if the descriptor is not open; so for POSIX.1 at least, fclose() of
something already closed is defined.

The C standard says:

A successful call to the fclose function causes the stream pointed
to by stream to be flushed and the associated file to be
closed. Any unwritten buffered data for the stream are delivered
to the host environment to be written to the file; any unread
buffered data are discarded. Whether or not the call succeeds, the
stream is disassociated from the file and any buffer set by the
setbuf or setvbuf function is disassociated from the stream (and
deallocated if it was automatically allocated).

It looks like the effect of fclose() on a file that's already been
closed isn't specified, which makes it undefined behavior.

And given a sequence like this:

fclose(foo);
bar = fopen("whatever");
fclose(foo);

it's possible (I think) that bar could point to a FILE object at the
same address as the one released by the first fclose(). The second
fclose() would then close bar.

Or it might not, in which case when it deallocates any buffer it might
call free on a pointer that has already been freed thus causing anything
to happen and a good (IMHO) example of why the C standard leaves it
undefined.

POSIX is, of course, allowed to define what happens on POSIX systems
when you invoke some specific case that C leaves undefined, but as far
as C is concerned it is still undefined.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Robert Gamble]

On Thu, 08 Sep 2005 03:38:35 +0000, Walter Roberson wrote:

In article <pa****************************@gmail.com>,
Robert Gamble <rg*******@gmail.com> wrote:

On Wed, 07 Sep 2005 13:44:29 -0400, Kenneth Brody wrote:

So, the following is well-defined, assuming you pass a valid FILE*? int my_fclose(FILE *f)
{
fclose(f);
return(fclose(f));
}

Nope, the value of f is indeterminate after the first fclose, the second
fclose invokes undefined behavior.

The value of f cannot change as a result of fclose, as it is passed
by value. What f points -to- might change, of course.

That is of course what I meant, thanks for the correction.
The C standard says that FEOF is returned if an error is encountered,
That's EOF, not FEOF.
and places no constraints about what kind of error that might be.
But it mandates that even in failure, the function disassociates the
stream from the file. If you are saying that the first fclose could fail
and the second one could succeed without invoking undefined behavior then
I'll have to disagree for now (the wording in the standard regarding
this is a little sticky, it may be possible to persuade me otherwise).
If one drops over to POSIX.1 then fclose() is defined in terms of
close() and write(), and close() is defined with a specific errno
if the descriptor is not open; so for POSIX.1 at least, fclose() of
something already closed is defined.

Your logic is flawed, just because fclose performs a close (actually, the
"equivalent" of close() according to the standard), that doesn't mean that
is all it does. It could very well free other resources associated with
the stream for example. In any case, POSIX.1 states "After the call to
fclose(), any use of stream results in undefined behavior". I hope
you'll agree that calling fclose on a stream qualifies as a use of
that stream. This appears to include the case where fclose fails.

Robert Gamble

[Richard Tobin]

In article <pa***********************@netactive.co.uk>,
Lawrence Kirby <lk****@netactive.co.uk> wrote:

The description of freopen() says that it "attempts to close any file that
is associated with the specified stream". The use of "any" suggests that
the stream may already have been closed - compare fclose() which talks
about "the" file.

When a stream is closed it ceases to be a stream, like when a malloc()'d
object is freed it ceases to be an object.

A good theory, but it doesn't explain why freopen() says "any" instead
of "the".

-- Richard

[Michael Wojcik]

In article <df**********@canopus.cc.umanitoba.ca>, ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

In article <pa****************************@gmail.com>,
Robert Gamble <rg*******@gmail.com> wrote:

Nope, the value of f is indeterminate after the first fclose, the second
fclose invokes undefined behavior.
The value of f cannot change as a result of fclose, as it is passed
by value. What f points -to- might change, of course.

I believe the same principles apply here as with free():

The representation of the value of f cannot change (maybe; I'm not
sure anyone ever definitively established that for free), but the
interpretation of that value can. For example, if the implemen-
tation of fopen returns a malloc'd pointer, and fclose frees that
pointer, then any reference to the value of f after a successful
fclose invokes undefined behavior.
If one drops over to POSIX.1 then fclose() is defined in terms of
close() and write(), and close() is defined with a specific errno
if the descriptor is not open; so for POSIX.1 at least, fclose() of
something already closed is defined.

Not if fclose() frees the FILE*. The fclose implementation may
never reach the call to close().

--
Michael Wojcik mi************@microfocus.com

The guy who's fast in the mountain pass is the coolest.
-- _Initial D: Second Stage_

[Dave Thompson]

On Wed, 7 Sep 2005 17:21:14 +0000 (UTC), ro******@ibd.nrc-cnrc.gc.ca
(Walter Roberson) wrote:
<snip>

There is no specific call in C to determine whether a particular
FILE* is open: you just try an operation on it and check to see
if the operation failed with a code indicating the file is closed.
Or for your purposes, as one of the posters pointed out, just
go ahead and close it: you won't bomb if it is already closed.
As others have already said, there is no such guarantee in C; the
memory to which a FILE * points can be deallocated on fclose() and any
use of it (or formally even of the pointer) is undefined and can fail.

<OT> Even in SUS2 and 3, which are what I have to hand, [EBADF]
says "The file descriptor underlying stream is not valid." Note,
nothing about the _stream_ not being valid.

In SUS/POSIX, if you only close() the underlying fd but _not_ fclose()
the stdio stream, then at least operations that actually try to use
the underlying file seem guaranteed to reject with EBADF. </>

STDOUT on the other hand is not a FILE*; it is generally part of
an I/O extension in which STDOUT is a macro which evaluates to the
"underlying descriptor" number of C's FILE* stdout . File descriptor
numbers are not part of C itself; many operations with file descriptors
are formalized in POSIX.1 . The typical operation to close a
file associated with a file descriptor is close(). There is no
standardized specific call to find out whether a file descriptor is
open, but you can fstat() the descriptor and look to see whether
you received the error that indicates the descriptor is not open.

Or fcntl(,F_GETFL). Or lseek(,0,SEEK_CUR). The "low-level" I/O
operations are guaranteed to fail cleanly, no undefined behavior.

Note however that file descriptors can be and almost always are
reused. (Stdio FILE *'s also _can_ be reused, but only sometimes are.)
If you have a stale fd-number and test it before doing I/O, it may
have been reused by an open() (or socket() etc.) elsewhere in the
program, so your test mistakenly thinks it is "still open" but your
I/O does something almost certainly wrong. There is no adequate
alternative to remembering for yourself which files you have open.

- David.Thompson1 at worldnet.att.net