In article <6e590e$qe4$1@nnrp1.dejanews.com>,
  Dylan Nicholson <dnich@noojee.com.au> wrote:
>
> In article <6e36km$9f5$1@nnrp1.dejanews.com>,
>   jkanze@otelo.ibmmail.com wrote:
> >
> > <snip>
> > In practice, if you are only targetting Unix, you are probably safe.
> > Both fopen and filebuf::open will eventually resolve to the POSIX open
> > system request, and it is, in fact, this request that sets errno.  Once
> > you leave the Unix world, this is less likely to work.
>
> Actually, I'm in the win32 world (gasp!).  Microsoft's implementation
> of filebuf::open() calls the POSIX _open(), but then completely ignores
> errno, and simply returns NULL, meaning that errno absolutely the only place
> from which you can get error information.

Well, the POSIX function is called open, not _open, but other than that,
the Windows interface at this level is very UNIX like.  (Don't forget
that Microsoft distributed UNIX for a while during the formative years
of MS-DOS.)

Historically, a lot of C implementations did simulate the UNIX open,
or tried to, because a lot of C programmers thought that this was part
of the standard C interface.

With regards to filebuf::open(), I'm not sure if it is allowed to throw
or not.  The function signature says yes, but the semantics are described
"as if" by calling fopen, and fopen certainly cannot throw.  Note that
the specification of filebuf::underflow is much more vague, without any
specific references to another function which cannot throw.

IMHO: there are two areas that need work here:

1. There should probably be some clarifications in the standard as to
whether functions like filebuf::open or filebuf::underflow can throw.
I am unable to decide myself whether is would be legal or not from the
present wording in the standard.

2. More long term, it would be nice if someone were to develop (and
propose for the next round of standardization) a model for reporting the
why of errors.  This must be fairly abstract, because the actual "whys"
must be implementation defined.  Perhaps a class ioerror, derived from
exception, to begin with, and the specification that the error is
reported (from filebuf, not fstream) by means of this exception, would
be a good starting point.

> By the way, I am somewhat bemused at the way people refer to flags such
> as ios::bad etc as 'error information' - I hardly think a user would
> like to be told "I had a bad bit set when opening your file - sorry". There
> are at least 5 or 6 important possible errors that can occur just when
> opening a file.

I just assumed that they hadn't understood your question.  There
are several types of information which may be interesting:

1. Succeeded/failed.  This is all that is currently provided, but for some
applications, it is enough.

2. Why the failure.  This is usually of more interest to the user than
to the program, although it may sometimes be possible for the program
to take corrective action on its own.  If only the user is considered,
this could be provided as an implementation defined string.

3. How much succeeded?  This is a delicate question, but if a read fails
in a robust program, the program probably wants to know how much data
was read before the failure, whether a new read will reread this data,
etc.  (This is particularly interesting/important if the read is from,
say, a socket or some other connection.)

This point can be summarized by the question: if I clear the error and
try again, what will happen?

--
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              ]

Hi

I just posted a message wrt iostreams and errno, but having
browsed thru various c++ on Deja News, I'm not too hopeful of a response:
it seems as though there is some big taboo discussing it...at least 4 people
have asked about it in the last few years, all them with perfectly
reasonable questions/complaints, but not one single reply has been made!

I guess someone out there secretly withholding information regarding this
subject, probably just another massive conspiracy against C++ programmers.
I suppose I should expect the men in black coming 'round to my door soon...

Typical.

Dylan

-----== 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 <6e06sk$vih$1@nnrp1.dejanews.com>,
  Dylan Nicholson <dnich@noojee.com.au> wrote:

>
> I just posted a message wrt iostreams and errno, but having
> browsed thru various c++ on Deja News, I'm not too hopeful of a response:
> it seems as though there is some big taboo discussing it...at least 4 people
> have asked about it in the last few years, all them with perfectly
> reasonable questions/complaints, but not one single reply has been made!

Perhaps because there is no real reply.  The rules regarding errno remain
unchanged from C.  Which means that unless the effects of a function on
errno are explicitly specified in the standard, the function can do anything
it wishes with errno.

Some implementations may specify more, but that's implementation dependent.

> I guess someone out there secretly withholding information regarding this
> subject, probably just another massive conspiracy against C++ programmers.
> I suppose I should expect the men in black coming 'round to my door soon...

No conspiracy, just nothing to say.

--
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 <6e06sk$vih$1@nnrp1.dejanews.com>,
Dylan Nicholson  <dnich@noojee.com.au> wrote:
>Hi
>
>I just posted a message wrt iostreams and errno, but having
>browsed thru various c++ on Deja News, I'm not too hopeful of a response:
>it seems as though there is some big taboo discussing it...at least 4 people
>have asked about it in the last few years, all them with perfectly
>reasonable questions/complaints, but not one single reply has been made!

According to the C++ specification several of the IOstreams operations are
formally defined in terms of the existing POSIX file operations.  For
example the following is from a version of the draft specification.

  basic_filebuf<charT,traits>* open(
      const char* s,
      ios_base::openmode mode );

  Effects:
    If is_open() != false, returns a null pointer.  Otherwise,  initial-
    izes the filebuf as required.
    It  then  opens  a file, if possible, whose name is the NTBS s (``as
    if'' by calling ::fopen(s,modstr)).

Since it is part of the POSIX specification that fopen sets errno to
describe any problems encountered, therefore filebuf::open (and
fstream::open which uses filebuf::open) should set errno in the same way.

Do I trust that all compiler manufacturers have done so?  No.  YMMV.
I use Gnu C++ and depend upon errno being set to explain to my customers
exactly what went wrong when the file doesn't open, because there is not
enough information passed in the exceptions raised by IOstreams.
--
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 <6e1lq8$agf@bcarh8ab.bnr.ca>,
  "Jim Cobban" <jcobban@nortel.ca> wrote:
>
> In article <6e06sk$vih$1@nnrp1.dejanews.com>,
> Dylan Nicholson  <dnich@noojee.com.au> wrote:
> >Hi
> >
> >I just posted a message wrt iostreams and errno, but having
> >browsed thru various c++ on Deja News, I'm not too hopeful of a response:
> >it seems as though there is some big taboo discussing it...at least 4
people
> >have asked about it in the last few years, all them with perfectly
> >reasonable questions/complaints, but not one single reply has been made!
>
> According to the C++ specification several of the IOstreams operations are
> formally defined in terms of the existing POSIX file operations.

The C++ specification makes no reference to the POSIX standard.  It does
refer to the C standard.

>  For
> example the following is from a version of the draft specification.
>
>   basic_filebuf<charT,traits>* open(
>       const char* s,
>       ios_base::openmode mode );
>
>   Effects:
>     If is_open() != false, returns a null pointer.  Otherwise,  initial-
>     izes the filebuf as required.
>     It  then  opens  a file, if possible, whose name is the NTBS s (``as
>     if'' by calling ::fopen(s,modstr)).
>
> Since it is part of the POSIX specification that fopen sets errno to
> describe any problems encountered, therefore filebuf::open (and
> fstream::open which uses filebuf::open) should set errno in the same way.

The fopen refered to in this paragraph is the one from the C standard,
without the extensions POSIX imposes.  I don't have my C standard here
to verify, so I cannot say whether fopen is *required* to set errno to
a non-zero value in case of error; in any case, the actual codes which
may appear are implementation defined.

POSIX extends this requirement by defining a certain number of codes
(although a given POSIX implementation can also extend these, I think).
It would seem reasonable and likely that an implementation of C++ on
a POSIX compiant system would also use these codes for iostream.  But
even this is not required, and of course, not all systems are POSIX
compliant, or even try to be.

> Do I trust that all compiler manufacturers have done so?  No.  YMMV.
> I use Gnu C++ and depend upon errno being set to explain to my customers
> exactly what went wrong when the file doesn't open, because there is not
> enough information passed in the exceptions raised by IOstreams.

In practice, if you are only targetting Unix, you are probably safe.
Both fopen and filebuf::open will eventually resolve to the POSIX open
system request, and it is, in fact, this request that sets errno.  Once
you leave the Unix world, this is less likely to work.

--
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 <6e36km$9f5$1@nnrp1.dejanews.com>,
  jkanze@otelo.ibmmail.com wrote:
>
> <snip>
> In practice, if you are only targetting Unix, you are probably safe.
> Both fopen and filebuf::open will eventually resolve to the POSIX open
> system request, and it is, in fact, this request that sets errno.  Once
> you leave the Unix world, this is less likely to work.

Actually, I'm in the win32 world (gasp!).  Microsoft's implementation
of filebuf::open() calls the POSIX _open(), but then completely ignores
errno, and simply returns NULL, meaning that errno absolutely the only place
from which you can get error information.

By the way, I am somewhat bemused at the way people refer to flags such
as ios::bad etc as 'error information' - I hardly think a user would
like to be told "I had a bad bit set when opening your file - sorry". There
are at least 5 or 6 important possible errors that can occur just when
opening a file.

However, it is good to finally see some discussion on this topic!

Dylan

-----== 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              ]