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********@yaho o.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********@yaho o.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.
--
"...deficie nt support can be a virtue.
It keeps the amateurs off."
--Bjarne Stroustrup

[Walter Roberson]

In article <11************ **********@g14g 2000cwa.googleg roups.com>,
<se********@yah oo.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*******@gmai l.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.nr c-cnrc.gc.ca (Walter Roberson) writes:

In article <pa************ *************** *@gmail.com>,
Robert Gamble <rg*******@gmai l.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_Keit h) 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.or g>,
Keith Thompson <ks***@mib.or g> 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