Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Fopen to create a file in a sub-folder (such as "Mygoal").

Thread Tools

Fopen to create a file in a sub-folder (such as "Mygoal").

Posts: n/a
On Feb 1, 9:33*am, Keith Thompson <(E-Mail Removed)> wrote:
> user923005 <(E-Mail Removed)> writes:
> [...]
> > At any rate, it seems logical to me to diagnose problems when they
> > occur. *And I don't believe for a moment that anyone taking up the
> > opposite position is doing anything more than playing devil's
> > advocate. *If there is anyone here who does not want their fopen()
> > error diagnosed in real life, I would be very much surprised.

> Even on a typical real-world system with ordinary security (I'm
> thinking of a typical Windows or Unix-like system), it's not always
> possible to report all the information about why an fopen() call
> failed.
> For example, assuming a Unix-like system, if I try to open
> "/home/fred/foo.txt" and I don't have the right permissions for the
> directory "/home/fred", the result isn't going to distinguish between:
> * * /home/fred/foo.txt exists, but you don't have read access to it;
> * * /home/fred/foo.txt exists, and you'd be able to read it if you
> * * * * had permissions on the directory; and
> * * /home/fred/foo.txt doesn't exist
> It would have been reasonable, IMHO, to require a failing fopen() call
> to set errno to *some* relevant non-zero value for which strerror()
> and perror() will produce some legible message. *It's not necessary to
> specify more than that. *Some implementations might choose to define
> dozens of error codes specifying exactly how and why the attempt
> failed; others might have a single EWHATEVER value with the message
> "Unspecified failure".
> With the current requirements, if I call fopen(), and it fails, and
> errno has been set to a non-zero value, I have no guarantee that that
> value is at all meaningful; perror() might produce some meaningless
> and confusing message. *But in the vast majority of implementations
> (as far as I know), perror() will give me something relevant to the
> error.
> Requiring fopen() and similar functions to set errno would not be a
> large burden on implementers.

That is what I would ask for. As to the quality of the returned
value, that would be up to the compiler vendor.

Obviously, if it is a permissions problem, I would like to know that.
If it is a hardware problem, I would like to know that. If it is a
file name specification error, I would like to know that. The more
detail that they can deliver about what went wrong, the better. But I
think it only makes sense to diagnose the problem. The reason I think
it makes sense is that somewhere along the line, something refused to
open the file. Whatever that something is, it knows why it refused.
If it can pass that information back up to me, then that saves me a
lot of time.

I probably should have chosen adjectives besides "lazy and stupid"
which I admit have an inflamatory tone. And I should add that if I
had written the C language standard, it would probably be a total pile
of junk, because of it's enormous scope and detail. But I think that
it makes sense to discuss problems with the current (and past)
standards so that we are aware of them. That is the only way that
eventually they will ever get fixed.
Reply With Quote
David Thompson
Posts: n/a
On Tue, 29 Jan 2008 16:52:29 -0500, Kenneth Brody
<(E-Mail Removed)> wrote:

> user923005 wrote:
> [...]
> > There are not any compilers that I know of that do not set the errno
> > value on fopen() failure.
> > But the fact that you are allowed to leave errno unchanged is clearly
> > a gaffe.

> The fact that neither you nor I know of any systems which do not
> set errno does not mean that there aren't any. I can imagine a
> "security" system which would prohibit access to some files, but
> for security reasons, refuse to tell you why. (ie: there is no
> way to distinguish between "the file doesn't exist" and "the file
> does exist, but you didn't give the correct encryption key".)

But you can still 'return' an errorcode saying that. Almost exactly
that was done by Multics, one of the biggest completely carried
through efforts at a secure multiuser system. (IIRC it was the only
system at the time to be certified 'orange book' A-something, and one
of the few ever.) I got all too familiar with an errorcode that
decoded as 'insufficient access to return any information', sometimes
because of incorrect ACL settings and sometimes because I had
accidentally requested the wrong thing.

> However, if I were on the committee, I would have suggested making
> something like a generic EUNKNOWN error code, which could be used
> on systems where a failure could occur, but for which the C runtime
> could not determine the "true" cause. (Perhaps the O/S simply
> returns a "failed" condition?) At least, you could then trust that
> errno was set, even if you can't guarantee that it was set to a
> "known" error code. For all I know, the suggestion was made, but
> reject for some reason.

- formerly david.thompson1 || achar(64) ||
Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
fopen() with full path affecting subsequent fopen calls Michel Rouzic C Programming 4 04-28-2008 04:48 PM
What is up with fopen??? FOpen and local directories Nonee HTML 2 10-25-2005 09:18 PM
Re: why fopen( ) can't open a big data file? (single file, as big as 29G) C++ 2 06-21-2005 06:24 PM
How to create folder at fopen? C Programming 15 09-03-2004 05:02 PM
Usoing fopen etc is there a way to find file size Angus Comber C Programming 6 02-10-2004 01:41 AM