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

[Eric Sosman]

[...]
I'm not buying it. It was a lazy and stupid decision.

While I agree that a failing fopen() (and fread() and
getenv() and time() and ...) *ought* to set errno, I see
no evidence that the omission of such a requirement was due
either to laziness or to stupidity.

If you have direct evidence that any of the Standard
writers were lazy or that any were stupid, please reveal it.
Otherwise, lay off the name-calling.

 

[Eric Sosman]

[...]
However, your example does relate back to the original "why doesn't
the Standard require fopen() to set errno" question. If the
Standard were to require errno to be set, wouldn't it also need to
define all of the possible error values? Would it make sense for
the Standard to say "errno must be set to an implementation-defined
value"?

That would, IMHO, be an improvement. We've already got
perror() and strerror() to extract human-readable meaning from
these mysterious values, and could use them to improve the
quality of our error messages. "foobar.txt: file not found"
and "foobar.txt: too many open files" are more helpful to the
end user than "foobar.txt: not opened".

The task of enumerating all possible error conditions is
out of the question, I think. This means that a portable
program can't hope to handle an error with a big `switch(errno)'
and a lot of cases -- even if two environments share the same
symbolic Exxxx names and attach similar meanings, there are
likely to be cases where "the same" failure produces different
Exxxx results on the two systems. Programs written for a
single environment (or class of close relatives) can use the
big-switch approach, relying on the system documentation but
not on the language standard.

 

[user923005]

[...]
I'm not buying it.  It was a lazy and stupid decision.

     While I agree that a failing fopen() (and fread() and
getenv() and time() and ...) *ought* to set errno, I see
no evidence that the omission of such a requirement was due
either to laziness or to stupidity.

     If you have direct evidence that any of the Standard
writers were lazy or that any were stupid, please reveal it.
Otherwise, lay off the name-calling.

I did not say that the standard writers were lazy or stupid. I said
that the decision to not have a failed fopen() set errno was lazy and
stupid. There is a difference between lazy and stupid people and lazy
and stupid decisions (though lazy and stupid people are far more prone
to lazy and stupid decisions than energetic and intelligent ones). My
direct evidence that a lazy and stupid decision was made is that there
is no requirement in the standard for fopen() to set errno.

 

[Gordon Burditt]

Can you please describe for me a scenario where opening a file fails

and it is not possible to diagnose why?

I believe that in UNIX V6, and perhaps UNIX V7, if open() (yes,
it's a non-standard function used in some implementations to implement
fopen()) failed, you'd get a proper errno. However, if fopen()
failed to allocate an open file slot (This was a fixed-size array
of 20 FILE structures), there wasn't any error return from the
kernel since the error happened at the user-program level. There
wasn't any error code for "Out of FILE array slots": the kernel
controlled the list of error codes. For some reason it wasn't
suitable to use ENOMEM, like no dynamic memory allocation was being
done. This is a case not of being "not possible to diagnose why",
but more of "didn't bother to diagnose why".

There may have been other errors diagnosed at the user level that
didn't have error codes, like fopen(name, "Q"). However, I wouldn't
put it past the code to check for "r" and "a", and if it didn't
find either, assume "w" rather than return an error.

I think this was a rather lame excuse, but at the time of
standardization, there was a large base of existing code, and
probably most of it without a support contract.

There are a number of situations where a file open may fail and it
is *NOT PERMITTED* to tell you why it failed. For example, consider
a situation where the file names may be classified, and at a different
classification than the file contents. Perhaps there's a directory
/home with subdirectories named after the code name of the agent.

If you (with a low security level) get ENOENT for some and EACCES
for others, you can guess the code names of agents even if you can't
list them all. Try to open it, and see which failure you get.
That's not allowed. However, I don't believe that *ALL* reasons
for failure would be classified (e.g. failure to allocate memory,
or disk errors could legitimately be distinguished), so there is
no excuse for having only one error code EFAILED. You could use
ENOENT to include all the cases where you're not allowed to see the
files in question, or make up one like ENOENT_OR_NOACCES.

You're never going to be able to put a complete list of error codes in
the standard. People will always be inventing new hardware with new
failure modes. Someone will stick in an error code for violating the
MPAA content rating. There will be plenty of opportunity for error
codes related to bad credit card number, credit limit exceeded, or
similar payment failure. This, however, means that there's no short
list of error codes that, if they exist, means "file does not exist",
so it can be treated specially (like ask "do you want to create it?").

 

[user923005]

I believe that in UNIX V6, and perhaps UNIX V7, if open() (yes,
it's a non-standard function used in some implementations to implement
fopen()) failed, you'd get a proper errno.  However, if fopen()
failed to allocate an open file slot (This was a fixed-size array
of 20 FILE structures), there wasn't any error return from the
kernel since the error happened at the user-program level.  There
wasn't any error code for "Out of FILE array slots":  the kernel
controlled the list of error codes.  For some reason it wasn't
suitable to use ENOMEM, like no dynamic memory allocation was being
done.  This is a case not of being "not possible to diagnose why",
but more of "didn't bother to diagnose why".

There may have been other errors diagnosed at the user level that
didn't have error codes, like fopen(name, "Q").  However, I wouldn't
put it past the code to check for "r" and "a", and if it didn't
find either, assume "w" rather than return an error.

I think this was a rather lame excuse, but at the time of
standardization, there was a large base of existing code, and
probably most of it without a support contract.

There are a number of situations where a file open may fail and it
is *NOT PERMITTED* to tell you why it failed.  For example, consider
a situation where the file names may be classified, and at a different
classification than the file contents.  Perhaps there's a directory
/home with subdirectories named after the code name of the agent.

If you (with a low security level) get ENOENT for some and EACCES
for others, you can guess the code names of agents even if you can't
list them all.  Try to open it, and see which failure you get.
That's not allowed.  However, I don't believe that *ALL* reasons
for failure would be classified (e.g. failure to allocate memory,
or disk errors could legitimately be distinguished), so there is
no excuse for having only one error code EFAILED.  You could use
ENOENT to include all the cases where you're not allowed to see the
files in question, or make up one like ENOENT_OR_NOACCES.

You're never going to be able to put a complete list of error codes in
the standard.  People will always be inventing new hardware with new
failure modes.  Someone will stick in an error code for violating the
MPAA content rating.  There will be plenty of opportunity for error
codes related to bad credit card number, credit limit exceeded, or
similar payment failure.  This, however, means that there's no short
list of error codes that, if they exist, means "file does not exist",
so it can be treated specially (like ask "do you want to create it?").

If someone names file folders after their secret agents on a public
accessible share, then access errors is the least of their worries.
If open() can return an error code and fopen() cannot return an error
code, then that is a bug created by the compiler vendor or a bug in
the operating system that should be repaired.

 

[Gordon Burditt]

Can you please describe for me a scenario where opening a file fails

If someone names file folders after their secret agents on a public
accessible share, then access errors is the least of their worries.

Who said anything about a public share? Different people can have
different security clearances (Both Top Secret vs. Ultra Top Secret,
and compartmentalized information).

If open() can return an error code and fopen() cannot return an error
code, then that is a bug created by the compiler vendor or a bug in
the operating system that should be repaired.

I said nothing about open() being able to return an error code and
fopen() not being able to return that code. However, the design
of UNIX V6 said the error code list was defined by the kernel, so
there were no error codes for numerous possible errors in user-level
programs (e.g. E_MISSING_ARGUMENT, ESYNTAX_ERROR, EEXTRA_ARGUMENT,
etc.), which is arguably a bug.

What's your solution for an extensible error code system that doesn't
require registration of all error codes with a central authority,
but it still allows functions like strerror() to come up with a
meaningful message for errors it doesn't natively know about.
libcom_err is an attempt at this, but it is far from perfect.

 

[Richard Bos]

If someone names file folders after their secret agents on a public
accessible share, then access errors is the least of their worries.
If open() can return an error code and fopen() cannot return an error
code, then that is a bug created by the compiler vendor or a bug in
the operating system that should be repaired.

You forget to take into account the situation where, if you do not have
GAME ANDES REDSHIFT clearance, you are not only not allowed to know what
operation SCORPION STARE is, you are not allowed to know that operation
SCORPION STARE even exists.

Richard

 

[user923005]

Who said anything about a public share?  Different people can have
different security clearances (Both Top Secret vs. Ultra Top Secret,
and compartmentalized information).


I said nothing about open() being able to return an error code and
fopen() not being able to return that code.  However, the design
of UNIX V6 said the error code list was defined by the kernel, so
there were no error codes for numerous possible errors in user-level
programs (e.g. E_MISSING_ARGUMENT, ESYNTAX_ERROR, EEXTRA_ARGUMENT,
etc.), which is arguably a bug.

What's your solution for an extensible error code system that doesn't
require registration of all error codes with a central authority,
but it still allows functions like strerror() to come up with a
meaningful message for errors it doesn't natively know about.
libcom_err is an attempt at this, but it is far from perfect.

Invent an error code that says "ENOPUZZ" meaning, "I'm puzzled what
this means." That's the default answer. If you can get that far
anyway someone should be court-martialed. And if there is a top
secret file that somehow I can see but I am not allowed to open, then
return ENOPUZZ. And if I am a secret agent with TS-BI, CNWDI then if
I fail to open the file, it can give me a better message. We should
also be asking the questions, "How was I able to log on?" "Why was I
able to navigate to the proper subdirectory?" If I am on a military
base, and I am going to store classified material on a computer, then
we should have it certified EAL 4, FIPS 140-2, L3, store it in a vault
with a guard and all the other stuff you are supposed to do to protect
military secrets.

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.

 

[Keith Thompson]

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.

 

[lawrence.jones]

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.

Maybe. When ANSI first standardized C, the vast majority of
implementations would coincidentally return with errno set to a
meaningful value in most failure cases (typically where the underlying
device open failed), but would indeed return with it set to a
meaningless and confusing value in other failure cases (such as running
out of memory). Very few, if any, implementations documented fopen() as
reliably setting errno, so ANSI didn't require it. Over the years, some
implementations have certainly been changed to reliably set errno in all
cases, but I have no idea whether most implementations now guarantee to
set it reliably or if they still just happen to set it meaningfully in
most cases.

Requiring fopen() and similar functions to set errno would not be a
large burden on implementers.

That's probably true and may be something that should be considered for
the next revision of the C Standard.

-Larry Jones

Even my FRIENDS don't do what I want. -- Calvin

 

[user923005]

[...]

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.

 

[David Thompson]

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) || worldnet.att.net