g++: using fstat on an already open stream

g++: using fstat on an already open stream

Post by Klaus Fle » Mon, 29 Sep 2003 18:11:59



I would like to use the fstat() system-call in a C++-Program on some
sort of stream which is already open.

An example: I have an open stream and want to know the numerical
owner-id of the file that might be associated with that stream.

I can write the code myself if someone tells me how to get the
filedescriptor that must be buried as a member attribute somewhere in
the stream-classes. Eventually all io must pass through such a
descriptor - so it _must_ exist somewhere.

I know how to retrieve the information if I have the filename (call
stat()) --- but I want to use fstat() on an already open stream without
referring to the filename.

The C++ folks continue telling me that accessing file attributes is a
no-no due to portability issues. But if you drive this argument to the
extreme you can't even open a file because everything there is
system-specific. May be one should edit "Shoot yourself into the Foot"
and transfer the remark for Modula-2 to C++.

Any glue?
 
 
 

g++: using fstat on an already open stream

Post by Klaus Fle » Mon, 29 Sep 2003 20:52:43


...
...

Sorry, I was too unspecific. I use a 'fstream' not a FILE*. It's C++,
after all. With <stdio.h> i would have no problems at all. But it's
<iostream>!

 
 
 

g++: using fstat on an already open stream

Post by chaoit » Mon, 29 Sep 2003 21:44:06


Looking into stdio.h gives me the data structure of FILE.
There is a data member called short _file

I guess you may access that like this:
FILE *f;
f = fopen(....);
fstat(f->_file, ...);

BTW, I am using FreeBSD. You may want to check it out on your system.

-
Kevin L
 
 
 

g++: using fstat on an already open stream

Post by Jerry Feld » Mon, 29 Sep 2003 22:35:04

On Sun, 28 Sep 2003 20:44:06 +0800





NO, NO. That is WRONG. NEVER do that. The FILE structure is subject to
change at any release. The proper way to do get the file descriptor from
an opened file is to use the fileno() function.


--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.yqcomputer.com/ PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
 
 
 

g++: using fstat on an already open stream

Post by vitu » Mon, 29 Sep 2003 23:07:11


:> I know how to retrieve the information if I have the filename (call
:> stat()) --- but I want to use fstat() on an already open stream without
:> referring to the filename.

: Looking into stdio.h gives me the data structure of FILE.
: There is a data member called short _file

Looking into library documentation (for instance info) we'll find out
that there is written NEVER, NEVER, NEVER do any assumptions about
internal structure of FILE. Use macro fileno if you need a file
descriptor. If it would be business day I'll check that dozen of
different compilers and systems I use for my job and see how many
different declarations of fileno() they have.

But now we are talking about C++, not plain C. In plain C there is no
way to hide structure members from user of structure. In C++ there is
"private" keyword. Actually, real file descriptor is hidden somewhere
inside some streambuf class, which is stored in private field of stream
class.

As far as I know, the only way to deal with filedescriptors and
iostreams simulateously is to define your own streambuf class, which
would allow construction from file descriptor and provide method to
return file descriptor.

C++ is evil, and standard C++ libraries are twice as evil as lamguage
itself.


: I guess you may access that like this:
: FILE *f;
: f = fopen(....);
: fstat(f->_file, ...);

better to do fstat(fileno(f),...)
it is at least portable.


--
if (instr(buf,sys_errlist[errno])) /* you don't see this */
-- Larry Wall in eval.c from the perl source code
 
 
 

g++: using fstat on an already open stream

Post by vitu » Mon, 29 Sep 2003 23:11:30


: Sorry, I was too unspecific. I use a 'fstream' not a FILE*. It's C++,
: after all. With <stdio.h> i would have no problems at all. But it's
: <iostream>!

About five years ago I've participated in writing some C++ program.
Well, it was my first C++ program, so I thought it is better to use
standard C++ features whenever possible. So, I've used iostream. These
days GCC was not so standard compliant as it is now, so it provided
several methods and constants to do useful things with streams, which
are missing from standard now. But program had to be cross-platform.
After few heated arguments with people who did Win32 porting we decide
to drop iostream and use stdio instead. And immediately both compilers
became happy with our program.

--
Let us be charitable, and call it a misleading feature :-)
-- Larry Wall in < XXXX@XXXXX.COM >
 
 
 

g++: using fstat on an already open stream

Post by Jerry Feld » Mon, 29 Sep 2003 23:12:43

On Sun, 28 Sep 2003 13:52:43 +0200





There is an external stdio_fstream class defined in the __gnu_cxx
namespace. You can use that to associate C file descriptors and C FILEs
with C++ iostream classes.
I'm not sure if you can apply that to an already opened stream.
My comment was based on your using the C FILE structure.

The header file is /usr/include/g++/ext/stdio_filebuf.h.

You'll need to dig a bit more.
--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.yqcomputer.com/ PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
 
 
 

g++: using fstat on an already open stream

Post by Jerry Feld » Tue, 30 Sep 2003 00:33:32

On Sun, 28 Sep 2003 14:11:30 +0000 (UTC)


<snip>

I've been writing C for about 20 years and C++ for 10. I think that
sometimes one must make decisions based on your needs at the time. A
friend of mine refers to C++ as "COBOL by a different name". However, I
have come to appreciate C++ for what it is. You can still use many C
standard IO features in C++. So, I really take exception to your
statement about C++ being evil.
--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.yqcomputer.com/ PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
 
 
 

g++: using fstat on an already open stream

Post by vitu » Tue, 30 Sep 2003 00:46:29


:> C++ is evil, and standard C++ libraries are twice as evil as lamguage
:> itself.

: I've been writing C for about 20 years and C++ for 10. I think that
: sometimes one must make decisions based on your needs at the time. A
: friend of mine refers to C++ as "COBOL by a different name". However, I
: have come to appreciate C++ for what it is. You can still use many C
: standard IO features in C++. So, I really take exception to your
: statement about C++ being evil.

Saying "it is evil" I don't mean "it is unusable". There are areas
where features of C++ give so much advantage that we cannot just ignore
its existense. That is evil. That using of C++ sometimes gives too much
that we cannot just give it up and forget it.

C++ is very nice when you are writing an algorithm.

But if it comes to interfaces, be it filesystem interface as in orginal
question, or even worse, interface to dynamic library, it becomes a much
pain. You can have dozen of C compilers in your system, and all of them
would happily link with certain C-only dynamic library.

But if you try to link C++ dynamic library, say libqt to the code
compiled with some other compiler than library itself...

Only thing you can do if you have to support multiple compilers, is to
hide all C++ features under pure C public interface. But if your project
is heavily object-oriented, it is a pain.


--
<dark> Turns out that grep returns error code 1 when there are no matches.
I KNEW that. Why did it take me half an hour?
-- Seen on #Debian
 
 
 

g++: using fstat on an already open stream

Post by Jerry Feld » Tue, 30 Sep 2003 04:22:32

On Sun, 28 Sep 2003 15:46:29 +0000 (UTC)


Yes, this is certainly an issue because C++ name mangling. Name mangling
is necessary to implement overloading, but the lack of a standard name
mangling does cause the problem you mention. When you deal with shared
objects you are involving the compiler, the linker and the loader.
--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.yqcomputer.com/ PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9