«

On Jan 29, 1:32*pm, rober...@ibd.nrc-cnrc.gc.ca (Walter Roberson)
wrote:
> In article <9df65f6c-7a79-4218-9e14-60c8415cb...@q39g2000hsf.googlegroups.com>,
>
> user923005 *<dcor...@connx.com> wrote:
> >Sure, people do stupid things that follow the standard exactly all the
> >time.
> >For instance, I know of one compiler vendor who coded to exactly the
> >standard limits.
> >(e.g. nest levels, line lengths, etc.).
> >Now, it was no difficulty whatsoever to allow longer lines and deeper
> >limits.
> >But because the standard says it must be _at least_ x, all values were
> >set to x.
>
> Could be a useful compiler for testing conformance with the
> minimums permitted by the standard. Not necessarily a design flaw
> at all.

It's only a problem when the minimuns are inadequate. In such a case,
it is truly a design flaw, because the design (aka the C Standard) did
not state an adequate miniumum. This can really be a problem, because
the C Standard is designed so that a C compiler can be written for
some itty-bitty microcontroller. The minimums for something like that
do not make sense on a 500 million dollar mainframe.

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".)

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.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <private.php?do=newpm&u=>

On Jan 29, 1:52*pm, Kenneth Brody <kenbr...@spamcop.net> 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".)

I'm sorry, but EACCES is the logical return here, and not telling me
why serves no purpose.

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

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

user923005 wrote:
> Can you please describe for me a scenario where opening a file fails
> and it is not possible to diagnose why?

Depends what you mean by "why". There may be an underlying 'why' which
was not determinable by the requester.

Consider that in some circumstances, knowing that a file exists is
useful information for a hacker. Your OS might therefore refuse to
confirm both the existence and nonexistence of the file.

Sorta like asking MI5 the name of their operative in New york. Their
answer might well be "we neither confirm nor deny that we even have
operatives"

> This is a lazy result for the standards committee. Quite frankly,
> it's a black eye on the C language.

Not so sure. Unless you restrict the errono value to "success" and
"failure" ther are too many reasons for failure to usefully codify.

E-NOTFOUND
E-ACCESS-DENIED
E-DISK-REMOVED
E-FILE-DELETED-BY-OTHER-PROCESS
E-FILE-LOCKED-BY-OTHER-USER
E-FILE-LOCKED-BY-YOU-ALREADY
E-TAPE-MISSING
E-TAPE-NEEDS-REWOUND
E-ITS-MONDAY
.....


--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

In article <97b937df-3f2a-450c-ba6e->,
Kaz Kylheku <> wrote:

>> This is a lazy result for the standards committee. *Quite frankly,
>> it's a black eye on the C language.
>
>Can you describe a situation in which a C implementor would duck out
>of setting errno in fopen, just because the standard allows it?
>
>An implementation can conform, yet demonstrate poor quality in a
>myriad other ways than this.
>
>For instance, suppose that your compiler only emits the message ``this
>translation unit requires a diagnostic''. No filename, no line number,
>no information.

And yet the standard *does* require a diagnostic, even if it's a
useless one. Why doesn't it do the same for fopen(), requiring
errno to be set, even if to a useless value?

>You know you can test whether or not fopen set errno. Assign zero to
>errno before calling fopen. If fopen fails, and errno is found to be
>nonzero, then take advantage of the value.

And what's the advantage of requiring the user to do this test?

-- Richard
--
:wq

user923005 wrote:
> Jack Klein <jackkl...@spamcop.net> wrote:
>
.... snip ...
>>
>> Why lookup errno? fopen() is not required to set it.
>
> Too bad. It works on all the platforms that I care about (POSIX,
> Windows, OpenVMS, MVS), but it is still tragic that a place where
> it would obviously be helpful is left in the cold. I would be
> curious as to why such an obviously helpful diagnostic was deemed
> unnecessary. I mean, even if I am opening a port in a toaster IC,
> I would not see any reason why a hint as to what went wrong would
> not be in order.

Reminds me of the elegant Microsoft error returns from their
interface software. A routine with about umpty-ump parameters
always returned a code (which had to be laboriously looked up)
which translated to "parameter error". It didn't even identify the
parameter. Untangling that took about two days.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

user923005 wrote:
> Kaz Kylheku <kkylh...@gmail.com> wrote:
>
.... snip ...
>>
>> You know you can test whether or not fopen set errno. Assign zero
>> to errno before calling fopen. If fopen fails, and errno is found
>> to be nonzero, then take advantage of the value.
>
> 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.

Not so. For example, it allows a very tight system to be generated
that will fit into a chip/memory combination. If testing/debugging
that lack may be a nuisance, but it is not a gaffe.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

user923005 wrote:

> On Jan 29, 12:28*am, santosh <santosh....@gmail.com> wrote:
>> user923005 wrote:
>> > On Jan 28, 7:35*pm, Jack Klein <jackkl...@spamcop.net> wrote:
>>
>> <snip>
>>
>> >> Why lookup errno? *fopen() is not required to set it.
>>
>> > Too bad. *It works on all the platforms that I care about (POSIX,
>> > Windows, OpenVMS, MVS), but it is still tragic that a place where
>> > it would obviously be helpful is left in the cold. *I would be
>> > curious as to why such an obviously helpful diagnostic was deemed
>> > unnecessary. *I mean, even if I am opening a port in a toaster IC,
>> > I would not see any reason why a hint as to what went wrong would
>> > not be in order.
>>
>> That's exactly the current situation isn't it? In practise errno is
>> set to something meaningful if the system can do so, but since not
>> all systems may have that capability the Standard declined from
>> mandating that errno shall be set by fopen() after a failure.
>
> Can you please describe for me a scenario where opening a file fails
> and it is not possible to diagnose why?

Personally no. The best I can think of is that some primitive or
otherwised brain-damaged systems failed to provide a proper diagnostic
for some file open failures to fopen(), which means that fopen() could
not sensibly set errno for all instances of failure.

As Chris Hills put it, C goes out of it's way to accommodate itself to
the hardware unlike some other languages. If some systems somewhere
were damaged in this way I suppose the Committee would have preffered
to have fopen() adapt for them than insist that it return sensible
error messages and force the system software manufacturers to put out
patches.

> This is a lazy result for the standards committee. Quite frankly,
> it's a black eye on the C language.

(Richard Tobin) wrote:

> Kaz Kylheku <> wrote:
>
> >Can you describe a situation in which a C implementor would duck out
> >of setting errno in fopen, just because the standard allows it?

> >For instance, suppose that your compiler only emits the message ``this
> >translation unit requires a diagnostic''. No filename, no line number,
> >no information.
>
> And yet the standard *does* require a diagnostic, even if it's a
> useless one. Why doesn't it do the same for fopen(), requiring
> errno to be set, even if to a useless value?

Because it adds nothing of importance to that fopen() call. If all you
want to know is _whether_ the call succeeded, and you either don't care
or aren't allowed to know _why_, you don't need errno, you can just
check whether fopen() returned a null pointer.
Granted, this ignores the scenario where you string several function
calls together, one of which is an fopen(), and you want to check
afterwards if any of them set errno. That is a reason to make fopen()
set errno, but I posit that, in the case of fopen(), it is not as likely
a scenario as in the case of, e.g., a string of floating point
computations.

Richard

CBFalconer wrote:
[...]
> Reminds me of the elegant Microsoft error returns from their
> interface software. A routine with about umpty-ump parameters
> always returned a code (which had to be laboriously looked up)
> which translated to "parameter error". It didn't even identify the
> parameter. Untangling that took about two days.

And let's not forget the XP SP2 upgrade, which has a tendency to
give, 25 minutes into the install, the message "Access Denied", and
then spend another 25 minutes undoing what it had done up to that
point. (Yes, that's the entire text of the error message.)

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"?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <private.php?do=newpm&u=>