This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: more detailed io state; new_handler and thread safety
- From: Phil Edwards <phil at jaj dot com>
- To: Jonathan Wakely <cow at compsoc dot man dot ac dot uk>
- Cc: Matthias Weiss <matthias dot weiss at inode dot at>, libstdc++ at gcc dot gnu dot org
- Date: Fri, 5 Apr 2002 12:47:11 -0500
- Subject: Re: more detailed io state; new_handler and thread safety
- References: <20020404001715.A512@matthias.weiss@inode.at> <Pine.SOL.3.91.1020404113250.25512A-100000@taarna.cygnus.com> <20020405193129.A2702@matthias.weiss@inode.at> <20020405181110.B71730@compsoc.man.ac.uk>
On Fri, Apr 05, 2002 at 06:11:10PM +0100, Jonathan Wakely wrote:
> On Fri, Apr 05, 2002 at 07:31:29PM +0200, Matthias Weiss wrote:
> >
> > Well, if I read this right, this tells me that *SOMETHING* went
> > wrong while opening the file. But I'd like to know whether the
> > error arose due to a wrong file permissions, or maybe the file
> > doesn't exist or whatever. How do I get this out of the "failbit"?
>
> AFAIK file permissions aren't covered in standard C or C++, as they're an
> OS-specific feature.
Correct.
> Personally I'd use stat() in the event of a failure
> and check the mode, uid and gid, but there are probably better ways.
Since right now we're using the system C library for I/O, you can probably
errno = 0;
try to get the file;
if ((it didn't work) && (failbit is set))
{
check errno;
maybe perror();
}
under the reasonable assumption that the system will do something to errno
in the case of a problem.
It's still outside the standard, though.
Phil
--
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace. We seek
not your counsel, nor your arms. Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen. - Samuel Adams