Re: questions on ftell and fopen

On Mar 4, 8:52 pm, Keith Thompson <k...@xxxxxxx> wrote:
"Bill Pursell" <bill.purs...@xxxxxxxxx> writes:
On Mar 3, 8:06 pm, Keith Thompson <k...@xxxxxxx> wrote:
"Bill Pursell" <bill.purs...@xxxxxxxxx> writes:
On Mar 2, 5:52 am, "subramanian10...@xxxxxxxxx, India"
<subramanian10...@xxxxxxxxx> wrote:
Consider the following program:
<some code snipped>

if ((fp = fopen(argv[1], "r")) == NULL)
{
printf("Could not open input file :%s:\n", argv[1]);
exit(EXIT_FAILURE);
}

Just a note, you may be much happier replacing the printf line with:
perror(argv[1]);
It will print a much more meaningful message. eg:
[tmp]$ ./a.out foo
foo: No such file or directory
[tmp]$ touch foo; chmod 000 foo; ./a.out foo
foo: Permission denied

It's likely to do so on most systems, but the standard doesn't
actually guarantee that a failing fopen() sets errno.

True. However, it strikes me that it is NOT the
programmer's responsibility to account for inadequacies
of the implementation.

Yes, it is. Whose responsibility do you think it is?

A standard is a contract between the implementer and the programmer.
If an implementer claims his compiler conforms to the C standard, the
programmer may reasonably rely on that claim and make use of any
features guaranteed by the standard. If the programmer relies on
something *not* guaranteed by the standard (in this case, that fopen()
sets errno on failure), and the program misbehaves as a result, who is
responsible for the failure?

We're not talking about a failure here, we're talking about
the quality of an error message. On a good implementation,
perror() will generate a reasonable error message. On
a poor implementation, the error messsage will be less
helpful. Is it any more helpful to output:
"operation failed, and this implementation is so broken
that I can't tell you why." than it is to output a message
based on an incorrect value of errno? (well, yeah, I
guess it is...but not by much.)

I suppose I'll raise my standards and make a point
to only claim POSIX conformance for my code. Time
to remove -ansi from CFLAGS, I guess...

.

Relevant Pages

  • Re: questions on ftell and fopen
    ... foo: ... A standard is a contract between the implementer and the programmer. ... If an implementer claims conformance to POSIX as well as to ...
    (comp.lang.c)
  • Re: questions on ftell and fopen
    ... actually guarantee that a failing fopensets errno. ... Since the standard doesn't guarantee that a failing fopendoes *NOT* ... A standard is a contract between the implementer and the programmer. ...
    (comp.lang.c)
  • Re: WaitForSingleObject() will not deadlock
    ... But what is TSO? ... Technical Standard Order, a minimum performance standard issued by the FAA for certain ... have been more commonly referred to as the "cache coherency" ... A mutex is sufficient to guarantee visibility, ...
    (microsoft.public.vc.mfc)
  • Re: generic INTERFACE and name clash
    ... Looks like the standard could need some clarification on this point. ... other than generic interfaces or ... may have the same identifier only if the identifier ... INTERFACE FOO ...
    (comp.lang.fortran)
  • Re: Segfault City
    ... Realizing ... What, if anything, can it be guaranteed will be> '9' in standard C? ... there /isn't/ any guarantee of a character greater than '9' in C. ...
    (comp.lang.c)