In the C++ standard, as opposed to some early implementations, there is no
way to extract the UNIX file descriptor from an fstream.  This is a good
thing because exposing this value would permit the programmer to do
potentially dangerous things like closing the file without letting the
fstream know.  However there are some capabilities which are provided by the
file descriptor interface in POSIX which are not exposed through the fstream
interface.  In particular I am thinking of fstat.  There may be others that
I can't think of, or otherwise the early implementations would not have
exposed the file descriptor.

I suggest that there should be a method fstream_base::stat(struct stat *).
--
Jim Cobban   |  jcobban@nortel.ca                   |  Phone: (613) 763-8013
Nortel (MCS) |                                      |  FAX:   (613) 763-5199
|   "I am not a number.  I am a human being!"
| P. McGoohan, "The Prisoner"
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6gb6t9$4ni@bcarh8ab.bnr.ca>,
  "Jim Cobban" <jcobban@nortel.ca> wrote:
>
> In the C++ standard, as opposed to some early implementations, there is no
> way to extract the UNIX file descriptor from an fstream.  This is a good
> thing because exposing this value would permit the programmer to do
> potentially dangerous things like closing the file without letting the
> fstream know.  However there are some capabilities which are provided by
the
> file descriptor interface in POSIX which are not exposed through the
fstream
> interface.  In particular I am thinking of fstat.  There may be others that
> I can't think of, or otherwise the early implementations would not have
> exposed the file descriptor.
>
> I suggest that there should be a method fstream_base::stat(struct stat *).

Can you give a reasonably portable definition for what is supported by
"struct stat"?

This is typical of what should be an implementation dependant extension.
While the standard doesn't (and shouldn't) say anything about UNIX
file descripters, a good implementation under UNIX will make them
available; for historical reasons, the name of the function will almost
certainly be filebuf::fd().  (At some point in time, Posix may want
to standardize C++ bindings, much like it has done for C.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6gddui$a5p$1@nnrp1.dejanews.com>,
 <jkanze@otelo.ibmmail.com> wrote:
>Can you give a reasonably portable definition for what is supported by
>"struct stat"?

The contents and definition of struct stat are defined in both POSIX and
X/Open.  I haven't checked, but it may also be in ANSI C.  Note that these
standards do not describe UNIX, per se, but rather an abstract system
interface and set of commands which provide a minimal common subset of
functions which can be implemented on a wide range of platforms.  stat is
available, for example, on operating systems as diverse as Windows 95 and
IBM's mainframe OS/390 (formerly known as MVS).  A specific implementation
may add additional fields, but the following is what the standards call for:

          mode_t   st_mode;     /* File mode (see mknod(2)) */
          ino_t    st_ino;      /* Inode number */
          dev_t    st_dev;      /* ID of device containing */
                                /* a directory entry for this file */
          dev_t    st_rdev;     /* ID of device */
                                /* This entry is defined only for */
                                /* char special or block special files */
          nlink_t  st_nlink;    /* Number of links */
          uid_t    st_uid;      /* User ID of the file's owner */
          gid_t    st_gid;      /* Group ID of the file's group */
          off_t    st_size;     /* File size in bytes */
          time_t   st_atime;    /* Time of last access */
          time_t   st_mtime;    /* Time of last data modification */
          time_t   st_ctime;    /* Time of last file status change */
                                /* Times measured in seconds since */
                                /* 00:00:00 UTC, Jan. 1, 1970 */
          long     st_blksize;  /* Preferred I/O block size */
          long     st_blocks;   /* Number of 512 byte blocks allocated*/

>This is typical of what should be an implementation dependant extension.
>While the standard doesn't (and shouldn't) say anything about UNIX
>file descripters, a good implementation under UNIX will make them
>available; for historical reasons, the name of the function will almost
>certainly be filebuf::fd().  (At some point in time, Posix may want
>to standardize C++ bindings, much like it has done for C.)

This requirement was called to mind by a poster on comp.lang.c++ who asked
how to obtain the size of a file given an fstream.  There are a number of
disadvantages to using seek operations to perform this function including
that the value returned by filebuf::seekoff is not guaranteed to be a byte
offset, and that filebuf::seekpos may be time consuming on some media.
Using stat is generally the best way to do this since st_size provides the
exact size for any file up to 4GB and st_blksize can be used for block
oriented files up to 2TB.

--
Jim Cobban   |  jcobban@nortel.ca                   |  Phone: (613) 763-8013
Nortel (MCS) |                                      |  FAX:   (613) 763-5199
|   "I am not a number.  I am a human being!"
| P. McGoohan, "The Prisoner"
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6ge34e$672@bcarh8ab.bnr.ca>,
  "Jim Cobban" <jcobban@nortel.ca> wrote:
>
> In article <6gddui$a5p$1@nnrp1.dejanews.com>,
>  <jkanze@otelo.ibmmail.com> wrote:
> >Can you give a reasonably portable definition for what is supported by
> >"struct stat"?
>
> The contents and definition of struct stat are defined in both POSIX and
> X/Open.

Which are both standards for Unix, or Unix-like operating systems.
Not all C++ runs on such systems.

> I haven't checked, but it may also be in ANSI C.

It's not.  ANSI C does not require an int as file descripter.  Many
systems do not use an int (or any basic type) as file descripter.

> Note that these
> standards do not describe UNIX, per se, but rather an abstract system
> interface and set of commands which provide a minimal common subset of
> functions which can be implemented on a wide range of platforms.

The system that they describe is the one commonly called UNIX.  In the
case of Posix, the name of the standard is not UNIX uniquely for
trademark reasons.

UNIX, in almost any of its variants, can be implemented on a wide range
of platforms.  The fact that UNIX can be implemented on a platform,
however, is not sufficient justification for insisting that C/C++ only
be available under a UNIX like OS.

> stat is
> available, for example, on operating systems as diverse as Windows 95 and
> IBM's mainframe OS/390 (formerly known as MVS).

Well, Windows derives ultimately from MS-DOS, which in version 2.0
adopted a large part of the UNIX IO interface.  (Microsoft was
actually a UNIX distributor back then.)

    [Details of the stat structure deleted...]

My point is only that in standard C++, the only way to find the actual
size of a file is to open it in binary mode and read it, counting the
bytes.  I agree that there can be more efficient ways on many OS's.
If I needed to know the size of a file, and depending on portability
constraints, I would use them.  On the other hand, I wouldn't present
them as part of C++ in comp.std.c++ (although when they are relatively
portable, as fstat is, I won't mind talking about them in other C++
forums).

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]