returning error from main()

[junky_fellow]

Guys,

If main() calls some function func() and that function returns
the error (errno), then does it make sense to return that value
(errno) from main. (in case main can't proceed further) ?

eg.

int main(void)
{
int error;

if ((error = func()) 0) {
return(error); /* Is this Ok. ? */
}

return 0;
}

Otherwise, if this is not the right thing, what else should be done ?

[Ben Pfaff]

"ju**********@yahoo.co.in" <ju**********@yahoo.co.inwrites:

int main(void)
{
int error;

if ((error = func()) 0) {
return(error); /* Is this Ok. ? */
}

return 0;
}

This seems like a bad idea, for at least three reasons. First, C
only defines the meaning of three return values from main (to
wit, 0, EXIT_FAILURE, and EXIT_SUCCESS). Second, many operating
systems in practice ascribe specific meanings to specific return
values (e.g. VMS) or have a severely limited range of return
values (e.g. Unix). Third, this is not a convention that I have
encountered anywhere.

Otherwise, if this is not the right thing, what else should be done ?

Typical would be to write an explanatory message to stderr and
return EXIT_FAILURE.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[Keith Thompson]

"ju**********@yahoo.co.in" <ju**********@yahoo.co.inwrites:

If main() calls some function func() and that function returns
the error (errno), then does it make sense to return that value
(errno) from main. (in case main can't proceed further) ?

eg.

int main(void)
{
int error;

if ((error = func()) 0) {
return(error); /* Is this Ok. ? */
}

return 0;
}

Functions don't typically return errno values. Instead, many
functions return a value indicating that *some* error occurred and set
the global variable 'errno'.

There's normally no particular relationship between errno values and
values passed to exit(). It's tempting to thing that there is, since
0 means "no error" for both, but the non-zero values don't match,
either in standard C or on any system I'm familiar with.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Army1987]

On Wed, 19 Sep 2007 00:38:43 -0700, Keith Thompson wrote:

"ju**********@yahoo.co.in" <ju**********@yahoo.co.inwrites:

Functions don't typically return errno values. Instead, many
functions return a value indicating that *some* error occurred and set
the global variable 'errno'.

M$ has lots of their "safe" functions returning an errno_t, such
as errno_t fopen_s(FILE **, const char *, const char *);
errno_t is a typedef for int, and the value returned is 0 on
success and errno on failure.
(I'm still trying to figure out why that should be considered
"safer".)
--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes� feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

[jacob navia]

Army1987 wrote:

On Wed, 19 Sep 2007 00:38:43 -0700, Keith Thompson wrote:

>"ju**********@yahoo.co.in" <ju**********@yahoo.co.inwrites:

>Functions don't typically return errno values. Instead, many
functions return a value indicating that *some* error occurred and set
the global variable 'errno'.

M$ has lots of their "safe" functions returning an errno_t, such
as errno_t fopen_s(FILE **, const char *, const char *);
errno_t is a typedef for int, and the value returned is 0 on
success and errno on failure.
(I'm still trying to figure out why that should be considered
"safer".)

Because of a better error analysis. That's why is safer.

1) None of its arguments should be NULL.
Those are constraints in the input arguments.
2) If there is a runtime constraint violation, the FILE ** argument
is set to NULL and an error return code is given to the calling
application.

This is much better than just getting a NULL and
trying to figure out why. The fopen specs just says "fopen returns
NULL on failure", not even leaving some errno mention...
No error analysis, like many other functions of the current
standard.

[Army1987]

On Tue, 18 Sep 2007 21:34:38 -0700, ju**********@yahoo.co.in wrote:

If main() calls some function func() and that function returns
the error (errno), then does it make sense to return that value
(errno) from main. (in case main can't proceed further) ?

The only value guaranteed to portably indicate failure is
EXIT_FAILURE in stdlib.h. For example, on Unix-like systems the
return status is clipped to the last eight bits, so returning
256, or 512 for example, would actually indicate success. (Yes,
errno codes don't usually go that high, but I think you get the
point.)
--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes� feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

[Richard Tobin]

In article <11**********************@q3g2000prf.googlegroups. com>,
ju**********@yahoo.co.in <ju**********@yahoo.co.inwrote:

If main() calls some function func() and that function returns
the error (errno), then does it make sense to return that value
(errno) from main. (in case main can't proceed further) ?

You need to consider the environment in which your program will be
used. Will it be used on an operating system where the full range of
error values can be returned? That's not guaranteed by the C
standard. Will those values be useful to someone running the program?

Someone using the program interactively will find it more useful to
have an error message printed ("foo: file not found" for example)
rather than having to decide a return value. Someone using the
program as part of a script may benefit from being able to test the
exit status, but will it really be useful for the script to
distinguish between all the different values?

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Ben Bacarisse]

jacob navia <ja***@jacob.remcomp.frwrites:

Army1987 wrote:

>On Wed, 19 Sep 2007 00:38:43 -0700, Keith Thompson wrote:

>>"ju**********@yahoo.co.in" <ju**********@yahoo.co.inwrites:

>>Functions don't typically return errno values. Instead, many
functions return a value indicating that *some* error occurred and set
the global variable 'errno'.

M$ has lots of their "safe" functions returning an errno_t, such
as errno_t fopen_s(FILE **, const char *, const char *);
errno_t is a typedef for int, and the value returned is 0 on
success and errno on failure.
(I'm still trying to figure out why that should be considered
"safer".)

Because of a better error analysis. That's why is safer.

This is and odd point of view. fopen can used quite safely and
fopen_s can be used unsafely.

1) None of its arguments should be NULL.
Those are constraints in the input arguments.
2) If there is a runtime constraint violation, the FILE ** argument
is set to NULL and an error return code is given to the calling
application.

You don't mean that (I hope).

This is much better than just getting a NULL and
trying to figure out why. The fopen specs just says "fopen returns
NULL on failure", not even leaving some errno mention...

The standard allows any library function to set errno how it likes
(provided that does not clash with a specified setting) but it wisely
does not require anything more from fopen, since some environments may
not be able to provide anything more.

Good implementations provide error information about fopen failures
through errno. Mandating that this number be returned does not
improve the "error analysis".

The real reason is, I suspect, that MS would like to create a buzz
around the idea that they care about "security". I am not so
absolutist that I think there will be no benefit from these new
"safer" functions -- there may well be a class of programmer who can't
write safe C without them and will be able to with them -- but I
suspect theat class is small, and the improvement will be
insignificant.

I do object to cluttering an already crowded name space with functions
that can be implemented in standard C. If the committee feels obliged
to follow this new proposal I would hope they can find a way to make
it optional for those of us who are happy with what is there already
(e.g. by putting them in new header files -- maybe stdios.h, stdlibs.h
and so on).

--
Ben.

[Army1987]

On Wed, 19 Sep 2007 18:28:05 +0100, Ben Bacarisse wrote:

jacob navia <ja***@jacob.remcomp.frwrites:

[Why is M$'s fopen_s() safer than fopen()?]

>Because of a better error analysis. That's why is safer.

This is and odd point of view. fopen can used quite safely and
fopen_s can be used unsafely.

Indeed. I can't see any difference between using

err = fopen_s(&fp, filename, "rb+");
if (err)
do_something(err);

and

fp = fopen(filename, "rb+");
if (fp == NULL)
do_something(err);

in either ease of use, or usefulness. M$ is allowed to decide that
fopen() should always set errno when it returns NULL, and it is
allowed to decide what happens when either argument is a null
pointer.

>1) None of its arguments should be NULL.
Those are constraints in the input arguments.

Wow. What an error extremely likely to be done. On which fraction
of times you used fopen() or fopen_s() the last argument wasn't
a string literal? As for the filename, it is still very uneasy
to accidentally pass a null pointer...

>2) If there is a runtime constraint violation, the FILE ** argument
is set to NULL and an error return code is given to the calling
application.

You don't mean that (I hope).

Even if he meant that the pointer object pointed by the FILE **
argument is set to NULL, I can't see how this helps...
[snip]

The real reason is, I suspect, that MS would like to create a buzz
around the idea that they care about "security". I am not so
absolutist that I think there will be no benefit from these new
"safer" functions -- there may well be a class of programmer who can't
write safe C without them and will be able to with them -- but I
suspect theat class is small, and the improvement will be
insignificant.

Indeed, there are functions which are saner than their ISO C
counterparts (strncpy_s, gets_s...) or do something different
(rand_s), but in the case of fopen_s() I can't see any
improvement, no matter how hard I try to imagine.

I do object to cluttering an already crowded name space with functions
that can be implemented in standard C. If the committee feels obliged
to follow this new proposal I would hope they can find a way to make
it optional for those of us who are happy with what is there already
(e.g. by putting them in new header files -- maybe stdios.h, stdlibs.h
and so on).

M$'s standard C headers only declare them (or some of them, I'm
not sure) if some macro beginning with underscores is defined
before they're #include'd, unlike some (most?) standard headers of
lcc-win32, which have declarations not in ISO C not guarded by any
#if or #ifdef.

--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes� feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

[jacob navia]

Flash Gordon wrote:

Returning 1 (or any odd value) on VMS will indicate success. I.e. you
should replace "probably safe on all systems" with "definitely wrong on
some systems but probably safe on most current systems."

Ahh VMS...
I am glad it disappeared.

You are right. I stand corrected for VMS.

[CBFalconer]

jacob navia wrote:

Flash Gordon wrote:

>Returning 1 (or any odd value) on VMS will indicate success. I.e.
you should replace "probably safe on all systems" with "definitely
wrong on some systems but probably safe on most current systems."

Ahh VMS... I am glad it disappeared.

You are right. I stand corrected for VMS.

No, you stand corrected for C.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

[Mark McIntyre]

On Thu, 20 Sep 2007 09:04:58 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Flash Gordon wrote:

>Returning 1 (or any odd value) on VMS will indicate success. I.e. you
should replace "probably safe on all systems" with "definitely wrong on
some systems but probably safe on most current systems."

Ahh VMS...

mhm. Returning a positive number causes the OS to print a system error
message specific to that value. For example returning 126 will advise
you "%SYSTEM-?-DEVNOTMOUNT, device is not mounted"

>I am glad it disappeared.

VMS has far from disappeared. You might want to check over in
comp.os.vms where you will be provided with plenty of examples of real
world ongoing use in business applications.

You might also want to ponder why HP maintain an OpenVMS website which
has an extensive support section, and where new releases are still
being made, and where you can buy a license for the OS.

Oh, and you can run VMS on an x86, for what its worth. I'm doing it
right now. <advocacy>For fifty quid you can get a license for the most
stable os ever written. </>
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Malcolm McLean]

"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...

>
The real reason is, I suspect, that MS would like to create a buzz
around the idea that they care about "security". I am not so
absolutist that I think there will be no benefit from these new
"safer" functions -- there may well be a class of programmer who can't
write safe C without them and will be able to with them -- but I
suspect theat class is small, and the improvement will be
insignificant.

The real answer is to implement safe pointers, which consist of three memory
addresses, the pointer itself and the bounds of the object it points to.
It means a slower language, but there just isn't another way I know of of
preventing buffer overruns. If you have an overrun there is a bug in the
program anyway, so whose to say that your length parameter is accurate?

>
I do object to cluttering an already crowded name space with functions
that can be implemented in standard C. If the committee feels obliged
to follow this new proposal I would hope they can find a way to make
it optional for those of us who are happy with what is there already
(e.g. by putting them in new header files -- maybe stdios.h, stdlibs.h
and so on).

I don't really care whether the function to copy a string is

strcpy(char *dest, const char *src)

or

safestrcpy(char *dest, size_t destlen, const char *src, size_t srclen)

however I need to know that the function will be available wherever I want
the code to run, and I would much prefer a call that is familiar to my
readers than a hand-rolled string library.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Ben Bacarisse]

"Malcolm McLean" <re*******@btinternet.comwrites:

"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...

>>
The real reason is, I suspect, that MS would like to create a buzz
around the idea that they care about "security". I am not so
absolutist that I think there will be no benefit from these new
"safer" functions -- there may well be a class of programmer who can't
write safe C without them and will be able to with them -- but I
suspect theat class is small, and the improvement will be
insignificant.

The real answer is to implement safe pointers, which consist of three
memory addresses, the pointer itself and the bounds of the object it
points to.
It means a slower language, but there just isn't another way I know of
of preventing buffer overruns.

We must be thinking of this from opposite ends. The best way to
prevent buffer overruns is to write code that does not allow them to
occur. You must be talking about preventing buffer overruns no matter
how bad the programmer is at writing correct code. That is a solved
problem -- as you say there are languages that simply prevent it.
They can't guard against all nonsense, but buffer overruns are easily
prevented at the language level.

If you have an overrun there is a bug
in the program anyway, so whose to say that your length parameter is
accurate?

Quite. They can't be prevented in traditional C implementations (if
we take your perspective where the programmer must be considered part
of the problem rather than the solution) so I am naturally skeptical
of the "safer C" camp.

>I do object to cluttering an already crowded name space with functions
that can be implemented in standard C. If the committee feels obliged
to follow this new proposal I would hope they can find a way to make
it optional for those of us who are happy with what is there already
(e.g. by putting them in new header files -- maybe stdios.h, stdlibs.h
and so on).

I don't really care whether the function to copy a string is

strcpy(char *dest, const char *src)

or

safestrcpy(char *dest, size_t destlen, const char *src, size_t srclen)

however I need to know that the function will be available wherever I
want the code to run, and I would much prefer a call that is familiar
to my readers than a hand-rolled string library.

So you don't care provided it is available everywhere and familiar?
Sounds like you do care and you want strcpy!

--
Ben.

[Chris Torek]

>"Malcolm McLean" <re*******@btinternet.comwrites:

>The real answer is to implement safe pointers ...
It means a slower language, but there just isn't another way I know of
of preventing buffer overruns.

(There are other ways, some of which are used in other languages.
They all have advantages and disadvantages. This is the fundamental
nature of engineering: we must find a balance between costs and
benefits.)

In article <87************@bsb.me.uk>
Ben Bacarisse <be********@bsb.me.ukwrote:

>We must be thinking of this from opposite ends. The best way to
prevent buffer overruns is to write code that does not allow them to
occur. You must be talking about preventing buffer overruns no matter
how bad the programmer is at writing correct code. That is a solved
problem -- as you say there are languages that simply prevent it.
They can't guard against all nonsense, but buffer overruns are easily
prevented at the language level.

Indeed.

One finds, however, that having prevented bad programmers from
writing buffer overruns, bad programmers simply move on to other
dreadful errors, with -- in the end -- the exact same consequences.
See <http://www.cert.org/advisories/CA-2000-02.htmlfor one
example. There are no buffer overruns involved here.

(Incidentally, "encoding data" is one of the most fundamental issues
in computer science / informatics. One would hope programmers
would have a better understanding of the issues. Alas, one would
be wrong. :-) )
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[jacob navia]

Chris Torek wrote:

>"Malcolm McLean" <re*******@btinternet.comwrites:

>>The real answer is to implement safe pointers ...
It means a slower language, but there just isn't another way I know of
of preventing buffer overruns.

(There are other ways, some of which are used in other languages.
They all have advantages and disadvantages. This is the fundamental
nature of engineering: we must find a balance between costs and
benefits.)

In article <87************@bsb.me.uk>
Ben Bacarisse <be********@bsb.me.ukwrote:

>We must be thinking of this from opposite ends. The best way to
prevent buffer overruns is to write code that does not allow them to
occur. You must be talking about preventing buffer overruns no matter
how bad the programmer is at writing correct code. That is a solved
problem -- as you say there are languages that simply prevent it.
They can't guard against all nonsense, but buffer overruns are easily
prevented at the language level.

Indeed.

One finds, however, that having prevented bad programmers from
writing buffer overruns, bad programmers simply move on to other
dreadful errors, with -- in the end -- the exact same consequences.
See <http://www.cert.org/advisories/CA-2000-02.htmlfor one
example. There are no buffer overruns involved here.

(Incidentally, "encoding data" is one of the most fundamental issues
in computer science / informatics. One would hope programmers
would have a better understanding of the issues. Alas, one would
be wrong. :-) )

let me tell you a tale:

--------------
After many years of efforts, we have gotten people to use security belts
when they drive.

Why use a security belt?

Bad drivers will make accidents even if they have a security belt, and
security belts are pernicious because they allow the bad drivers to
survive and make yet more accidents!

We should make our cars UNSAFER of course. Then, only the very good
drivers would survive, and we would have only good drivers and no
more accidents.
--------------
Obviously you are right Mr Torek. Bad programmers will go on making bad
programs.

But you will agree with me that even good programmers are not good
programmers ALL THE TIME! That they too get tired sometimes and make a
mistake!

Better designed interfaces are like security belts. They will NOT shield
us completely from our mistakes, they will make it easier to avoid them
that's all!

You say:

They all have advantages and disadvantages. This is the fundamental
nature of engineering: we must find a balance between costs and
benefits.)

Exactly. The cost of a better designed interface is slight. The cost
of a bug can be quite HIGH.

fopen_s allows you to establish a callback mechanism in case of a
constraint violation that will reroute the flow of control into your
function that can decide to longjmp to some established
recovery point for instance, instead of just making a hardware
exception and finishing the program maybe with disastrous consequences!

Isn't this a better interface???

Thanks for your attention.

jacob

[Everyman]

On 22 Sep 2007 at 21:23, jacob navia wrote:

let me tell you a tale:

[garbage snipped]

Why don't you just go away and program in Java if you don't like the
freedom (and responsibility) that C gives to programmers?

You always witter on about wanting to improve C, but really you have no
interest in C - you just want to add the stupid misfeatures of a hundred
other languages to it. First among them, forced array bounds checks.

[jacob navia]

Everyman wrote:

On 22 Sep 2007 at 21:23, jacob navia wrote:

>let me tell you a tale:

[garbage snipped]

Why don't you just go away

Can't you argue 'Everyman'???

I mean ARGUMENTS, based on facts or your perception of them.

and program in Java if you don't like the
freedom (and responsibility) that C gives to programmers?

I am saying that the interface of fopen_s is a better interface than
fopen. Since you have no technical arguments apparently, you do not
mention mine, just

[garbage snipped]

You always witter on about wanting to improve C, but really you have no
interest in C - you just want to add the stupid misfeatures of a hundred
other languages to it. First among them, forced array bounds checks.

fopen_s forces array bound checking? That would be news to me.

Mr "Everyman": You post here only to make tirades against me
and do not bring any technical argument into the discussion.

You are posting too (as A N Other, another anonymous poster)
from the AIOE.ORG, anonymous usenet accounts.

Why are you afraid of letting others know your
opinion?

jacob

[Charlie Gordon]

"jacob navia" <ja***@jacob.remcomp.fra écrit dans le message de news:
46**********************@news.orange.fr...

Chris Torek wrote:
[snip]

>(Actually, I *do* like the removal of the global "errno".
Unfortunately, we have to support errno as a per-thread global in
our systems anyway, for many reasons. So all I really need, that
ISO C lacks, is a guarantee that fopen() will set errno on failure.

The errno mechanism is NOT specified for fopen. Why refuse this
interface then?

Thanks for pointing this out, I always assumed otherwise, and probably
rightly so on systems I program to. Unix man pages seem to specify that
errno be set on failure, and I would be surprised it didn't for the various
C library runtimes in use on DOS/Windows.

What exactly was the rationale for not specifying it in the Standard ?

--
Chqrlie.

[Tor Rustad]

Chris Torek wrote:

[...]

Moreover, to really fix the whole "errno" thing, I think the
best approach is to abandon C. I am not sure my position here
is going to be popular, though. :-) )

I read this as abandon UNIX.
Even if ISO C don't require errno set, POSIX do so:

"Upon successful completion, fopen() returns a pointer to the object
controlling the stream. Otherwise, a null pointer is returned, and errno
is set to indicate the error."

http://www.opengroup.org/onlinepubs/...xsh/fopen.html
--
Tor <torust [at] online [dot] no>

[Chris Torek]

>Chris Torek wrote:

>Moreover, to really fix the whole "errno" thing, I think the
best approach is to abandon C. I am not sure my position here
is going to be popular, though. :-) )

(Note, as an aside to Jacob and maybe others: I said *best*, not
*only*, here.)

In article <HP*********************@telenor.com>,
Tor Rustad <to********@hotmail.comwrote:

>I read this as abandon UNIX.

Well, POSIX, more generally. As Rob Pike put it back in 1991:
"Not only is UNIX dead, it's starting to smell really bad."
(Overstatement for effect, perhaps, but still... :-) )

I use Unix-derived systms (BSD, Linux, and others) every day and
like them, but that does not mean I think they are perfect.
Moreover, there is a huge amount of what I consider to be "klunky
stuff" firmly specified in POSIX, much of which was removed in Plan
9, and Plan 9 is a big step in the right direction: it removes
setuid, for instance. Removing the "bad stuff" necessarily renders
the system "not Unix" since there is a standard that requires the
"bad stuff". Of course all of this is off-topic.

>Even if ISO C don't require errno set, POSIX do so:

"Upon successful completion, fopen() returns a pointer to the object
controlling the stream. Otherwise, a null pointer is returned, and errno
is set to indicate the error."

http://www.opengroup.org/onlinepubs/...xsh/fopen.html

Yes. It is not at all clear to me why ISO did not at least pick
this up. This is, I think, a smaller yet even more important change
than most of the various "_r" re-entrant interfaces that are also
in POSIX, but not ISO C.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Ben Bacarisse]

"Charlie Gordon" <ne**@chqrlie.orgwrites:

"jacob navia" <ja***@jacob.remcomp.fra écrit dans le message de news:
46**********************@news.orange.fr...

>Chris Torek wrote:
[snip]

>>(Actually, I *do* like the removal of the global "errno".
Unfortunately, we have to support errno as a per-thread global in
our systems anyway, for many reasons. So all I really need, that
ISO C lacks, is a guarantee that fopen() will set errno on failure.

The errno mechanism is NOT specified for fopen. Why refuse this
interface then?

Thanks for pointing this out, I always assumed otherwise, and probably
rightly so on systems I program to. Unix man pages seem to specify that
errno be set on failure, and I would be surprised it didn't for the various
C library runtimes in use on DOS/Windows.

What exactly was the rationale for not specifying it in the Standard
?

I have no inside information, but I can't really see what could be
specified. That an error has occurred is signaled (the return is
NULL) but anything more is so implementation-dependent that there is
little that could be said. The very most the standard could say would
be to duplicate the wording "... stores an implementation-defined
positive value in errno" used in some other library functions but
fopen can do so if it wants to, so *insisting* that is does simply gives
one a clumsy way to test that return was NULL!

--
Ben.

[jacob navia]

Ben Bacarisse wrote:

"Charlie Gordon" <ne**@chqrlie.orgwrites:

>"jacob navia" <ja***@jacob.remcomp.fra écrit dans le message de news:
46**********************@news.orange.fr...

>>Chris Torek wrote:
[snip]

(Actually, I *do* like the removal of the global "errno".
Unfortunately, we have to support errno as a per-thread global in
our systems anyway, for many reasons. So all I really need, that
ISO C lacks, is a guarantee that fopen() will set errno on failure.
The errno mechanism is NOT specified for fopen. Why refuse this
interface then?

Thanks for pointing this out, I always assumed otherwise, and probably
rightly so on systems I program to. Unix man pages seem to specify that
errno be set on failure, and I would be surprised it didn't for the various
C library runtimes in use on DOS/Windows.

What exactly was the rationale for not specifying it in the Standard
?

I have no inside information, but I can't really see what could be
specified. That an error has occurred is signaled (the return is
NULL) but anything more is so implementation-dependent that there is
little that could be said.

Mmm.

1) ENOTFOUND: File is not there
2) ENOACCESS: File is there but user can't open it.
3) ENOMEM: fopen can't malloc something
4) EINVALIDARG: File name is NULL, or open string is bad formed.
5) EDEVICE: The disk is broken, the hardware is burning, there
is no more electricity, battery is gone!

At least those 5 errors would cover 95% of all possible errors.

Since those would be just #defines, they do not take any
implementation space and can be ignored in systems where
they make no sense. Obviously there are VERY few systems
where error 1) makes not sense...

Then, a program could PORTABLY test the result of fopen
and PORTABLY test for the most common errors. This is
not done, so there is no way in standard C to test for
those errors and for each system and compiler combination
a special piece of code must be used.

Note that TR 24731 doesn't specify those errors either.

Making error analysis is apparently not viewed as important
in C. Each time I repeat this, the same answers pop up.

"Well it failed. You can't open the file.
WHY you ask?
Doesn't matter, there is no portable way to do it anyway."

And there we go.

[Peter J. Holzer]

On 2007-09-23 17:58, Ben Bacarisse <be********@bsb.me.ukwrote:

"Charlie Gordon" <ne**@chqrlie.orgwrites:

>"jacob navia" <ja***@jacob.remcomp.fra écrit dans le message de news:
46**********************@news.orange.fr...

>>Chris Torek wrote:
So all I really need, that ISO C lacks, is a guarantee that fopen()
will set errno on failure.

[...]

>What exactly was the rationale for not specifying it in the Standard
?

I have no inside information, but I can't really see what could be
specified. That an error has occurred is signaled (the return is
NULL) but anything more is so implementation-dependent that there is
little that could be said. The very most the standard could say would
be to duplicate the wording "... stores an implementation-defined
positive value in errno" used in some other library functions but
fopen can do so if it wants to, so *insisting* that is does simply gives
one a clumsy way to test that return was NULL!

No, that wording would assure that after fopen returned NULL errno
contains a value related to the failure and not some random value. This
allows you to write something like

if ((fp = fopen(filename, "r")) == NULL) {
fprintf(stderr, "%s: cannot open %s for reading: %s\n",
cmd, filename, strerror(errno));
exit(EXIT_FAILURE);
}

and get reasonable error messages instead of random garbage.

hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

[Richard Tobin]

In article <87************@bsb.me.uk>,
Ben Bacarisse <be********@bsb.me.ukwrote:

>I have no inside information, but I can't really see what could be
specified. That an error has occurred is signaled (the return is
NULL) but anything more is so implementation-dependent that there is
little that could be said. The very most the standard could say would
be to duplicate the wording "... stores an implementation-defined
positive value in errno" used in some other library functions but
fopen can do so if it wants to, so *insisting* that is does simply gives
one a clumsy way to test that return was NULL!

One of the great (if, with hindsight, obvious) advantages of Unix over
most other operating systems of the time was that it printed out
readable error messages rather than "error 00287". System-independent
C inherits this ability through perror() and strerror().

-- Richard

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[jacob navia]

Richard Tobin wrote:

One of the great (if, with hindsight, obvious) advantages of Unix over
most other operating systems of the time was that it printed out
readable error messages rather than "error 00287". System-independent
C inherits this ability through perror() and strerror().

-- Richard

That is true, and a small effort in the C standard, we would have
more detailed error analysis. Requiring to #define some error
codes is not very much!

But it would mean a HUGE advance in portable programs.

Suppose that I want to see if a file is there. I
could just use fopen, and if the result is NULL AND
errno is ENOTFOUND it's OK, but otherwise it is
some other kind of error.

This simple function is IMPOSSIBLE to write in
standard C today. The error codes are not standardized
and not even the existence of an error code is mandatory
besides the "NULL" result.

[Ben Bacarisse]

"Peter J. Holzer" <hj*********@hjp.atwrites:

On 2007-09-23 17:58, Ben Bacarisse <be********@bsb.me.ukwrote:

>"Charlie Gordon" <ne**@chqrlie.orgwrites:

>>"jacob navia" <ja***@jacob.remcomp.fra écrit dans le message de news:
46**********************@news.orange.fr...
Chris Torek wrote:
So all I really need, that ISO C lacks, is a guarantee that fopen()
will set errno on failure.

[...]

>>What exactly was the rationale for not specifying it in the Standard
?

I have no inside information, but I can't really see what could be
specified. That an error has occurred is signaled (the return is
NULL) but anything more is so implementation-dependent that there is
little that could be said. The very most the standard could say would
be to duplicate the wording "... stores an implementation-defined
positive value in errno" used in some other library functions but
fopen can do so if it wants to, so *insisting* that is does simply gives
one a clumsy way to test that return was NULL!

No, that wording would assure that after fopen returned NULL errno
contains a value related to the failure and not some random value. This
allows you to write something like

if ((fp = fopen(filename, "r")) == NULL) {
fprintf(stderr, "%s: cannot open %s for reading: %s\n",
cmd, filename, strerror(errno));
exit(EXIT_FAILURE);
}

and get reasonable error messages instead of random garbage.

Yes, but you can usually do that now because all fopen's I've seen set
errno on failure. If you get garbage, is that not really a QOI issue?
More specifically, if one does the recommended errno = 0; prior to the
call, are there really implementations of fopen that return NULL and
set errno to some unhelpful value?

I agree that the boilerplate wording should be there, but since
nothing prevents a library function from setting errno[1] (and I've
not used one that dose not) it seemed to me to be a rather minor
defect.

[1] provided that setting does not conflict with a setting that is
required by the standard.
--
Ben.

[Ben Bacarisse]

jacob navia <ja***@jacob.remcomp.frwrites:

Ben Bacarisse wrote:

>"Charlie Gordon" <ne**@chqrlie.orgwrites:

>>"jacob navia" <ja***@jacob.remcomp.fra écrit dans le message de
news: 46**********************@news.orange.fr...
Chris Torek wrote:
[snip]

(Actually, I *do* like the removal of the global "errno".
Unfortunately, we have to support errno as a per-thread global in
our systems anyway, for many reasons. So all I really need, that
ISO C lacks, is a guarantee that fopen() will set errno on failure.
The errno mechanism is NOT specified for fopen. Why refuse this
interface then?
Thanks for pointing this out, I always assumed otherwise, and
probably rightly so on systems I program to. Unix man pages seem
to specify that errno be set on failure, and I would be surprised
it didn't for the various C library runtimes in use on DOS/Windows.

What exactly was the rationale for not specifying it in the Standard
?

I have no inside information, but I can't really see what could be
specified. That an error has occurred is signaled (the return is
NULL) but anything more is so implementation-dependent that there is
little that could be said.

Mmm.

1) ENOTFOUND: File is not there
2) ENOACCESS: File is there but user can't open it.
3) ENOMEM: fopen can't malloc something
4) EINVALIDARG: File name is NULL, or open string is bad formed.
5) EDEVICE: The disk is broken, the hardware is burning, there
is no more electricity, battery is gone!

At least those 5 errors would cover 95% of all possible errors.

The problem is what these mean. They are useful to programmers only
in so far as the standard specifies what you may conclude from them.
Even ENOTFOUND is hardly obvious. What would you require the standard
say about it so it could be used by the programmer?

Don't get me wrong (partly my fault -- I was not very clear in my
reply) I like lots of information about errors. I fully support fopen
setting errno and having any such values map to helpful strings with
strerror (that happens now, at least in practice), but I don't agree
that the reasons for fopen failing can be helpfully standardised by C.

At the risk of making far to much of this, let me say a bit more.
Some of the things that a putative safe fopen can test are internal to
the program, and I can choose to test these myself if I like. These
internal errors are things like NULL arguments, illegal formats and so
on. This is the way I like C to be -- I don't want to pay for these
costs always because I may have arranged things so they are not
needed. If people want an alternate fopen_s that checks these then
this is fine, but I am no keen on it being mandated.

The other types of error are external ones -- like the file "not being
there". I am very happy that, where it makes sense, fopen sets errno
and allows a message explaining this using strerror, but for the
standard to specify the value (and for this to be useful to the
programmer) it must say what the error means. When to you get
ENOTFOUND rather than ENOACCESS? If it does not, then the programmer
can't do very much with the information. Such distinctions are almost
impossible in the system-agnostic language the that standard C uses.

That is why I think the committee decided to leave it well alone. If
Charlie Gordon's question was really why the standard did not included
the common boilerplate "errno set 0 or error" (which I suspect, now
I've thought about it, is what he meant) then I should have just said:
"I don't know, it should, shouldn't it?". As I say elsethread, I
don't think this matters much in practice (because all good fopen
implementations do set errno) but the comfort of it being required
would be an advantage.

Since those would be just #defines, they do not take any
implementation space and can be ignored in systems where
they make no sense.

You do need a string mapping for them (though this can be "" as far
as I can see).

Obviously there are VERY few systems
where error 1) makes not sense...

Then, a program could PORTABLY test the result of fopen
and PORTABLY test for the most common errors.

This is the crux. My reasons for thinking that programs could not do
that are given above.

This is
not done, so there is no way in standard C to test for
those errors and for each system and compiler combination
a special piece of code must be used.

Note that TR 24731 doesn't specify those errors either.

Very wise. I think it would be very hard to this in a way that helps
the programmer take useful action.

--
Ben.

[Flash Gordon]

jacob navia wrote, On 23/09/07 21:19:

Richard Tobin wrote:

>One of the great (if, with hindsight, obvious) advantages of Unix over
most other operating systems of the time was that it printed out
readable error messages rather than "error 00287". System-independent
C inherits this ability through perror() and strerror().

-- Richard

That is true, and a small effort in the C standard, we would have
more detailed error analysis. Requiring to #define some error
codes is not very much!

But it would mean a HUGE advance in portable programs.

I agree that it would be useful to mandate fopen setting errno to
indicate the cause of the error.

Suppose that I want to see if a file is there. I
could just use fopen, and if the result is NULL AND
errno is ENOTFOUND it's OK, but otherwise it is
some other kind of error.

No, not found does *not* mean a file is not there. You might be checking
for a file in a directory you do not have permissions to read. Or the
file might be marked "hidden" and the C library respect this. Or other
possibilities which prevent you from knowing the file exists.

This simple function is IMPOSSIBLE to write in
standard C today. The error codes are not standardized
and not even the existence of an error code is mandatory
besides the "NULL" result.

Standardised error codes might be harder, but just mandating that it be
set would give you something even if it was only "cannot open specified
file or similar as the error message".
--
Flash Gordon

[Mark McIntyre]

n Sun, 23 Sep 2007 01:32:24 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Everyman wrote:

>On 22 Sep 2007 at 21:23, jacob navia wrote:

>>let me tell you a tale:

[garbage snipped]

Why don't you just go away

Can't you argue 'Everyman'???

I mean ARGUMENTS, based on facts or your perception of them.

For the record, he did. See the part where he wrote [garbage snipped]
- this was his perception of your post (or possibly the facts of it).

>Mr "Everyman": You post here only to make tirades against me

Pot, meet mister kettle.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Sun, 23 Sep 2007 22:19:25 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>That is true, and a small effort in the C standard, we would have
more detailed error analysis.

INHO really useful errors would require a system-specfic set of error
codes, which would break portability somewhat. It might also require
the caller to be able to elevate their privileges on the device being
examined, which would break security.

>Suppose that I want to see if a file is there. I
could just use fopen, and if the result is NULL AND
errno is ENOTFOUND it's OK,

Unfortunately this doesn't guarantee the file not to be there. For
example the file could be present but invisible to the user for
security reasons. Unless fopen() were to run with elevated privileges
(!) then the error message could be misleading. This isn't a
theoretical situation.

>This simple function is IMPOSSIBLE to write in
standard C today.

I agree its impossible to code a standard C function which can
absolutely tell you if a file exists. This is not because of lack of
error messages however - its because there is no way to do this
without some really very OS-specific code and without creating a
security loophole. Think about how many security probes begin by
looking for a named file with a known vulnerability.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[jacob navia]

Mark McIntyre wrote:

On Sun, 23 Sep 2007 22:19:25 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>That is true, and a small effort in the C standard, we would have
more detailed error analysis.

INHO really useful errors would require a system-specfic set of error
codes, which would break portability somewhat. It might also require
the caller to be able to elevate their privileges on the device being
examined, which would break security.

>Suppose that I want to see if a file is there. I
could just use fopen, and if the result is NULL AND
errno is ENOTFOUND it's OK,

Unfortunately this doesn't guarantee the file not to be there. For
example the file could be present but invisible to the user for
security reasons. Unless fopen() were to run with elevated privileges
(!) then the error message could be misleading. This isn't a
theoretical situation.

>This simple function is IMPOSSIBLE to write in
standard C today.

I agree its impossible to code a standard C function which can
absolutely tell you if a file exists. This is not because of lack of
error messages however - its because there is no way to do this
without some really very OS-specific code and without creating a
security loophole. Think about how many security probes begin by
looking for a named file with a known vulnerability.

Interesting. POSIX manages to do exactly that, but somehow
the C standard could not manage doing it.

POSIX specifies exactly the type of errors that can be thrown by
fopen!

[Ian Collins]

jacob navia wrote:

Mark McIntyre wrote:

>>
I agree its impossible to code a standard C function which can
absolutely tell you if a file exists. This is not because of lack of
error messages however - its because there is no way to do this
without some really very OS-specific code and without creating a
security loophole. Think about how many security probes begin by
looking for a named file with a known vulnerability.

Interesting. POSIX manages to do exactly that, but somehow
the C standard could not manage doing it.

POSIX specifies exactly the type of errors that can be thrown by
fopen!

One reason why I use POSIX as my "portable" standard.

--
Ian Collins.

[jacob navia]

Ian Collins wrote:

jacob navia wrote:

>POSIX specifies exactly the type of errors that can be thrown by
fopen!

One reason why I use POSIX as my "portable" standard.

The C standard could use the same interface, and in system
where the error makes no sense, it would be just ignored!

All those errors are just #defines that would take no
implementation effort and only be used in the systems
where those errors are supported.

[Richard Tobin]

In article <46***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:

>POSIX specifies exactly the type of errors that can be thrown by
fopen!

Several of them are specific to unix. Presumably Microsoft Windows
has some reasons for fopen() failing that unix doesn't have. And so
on for other operating systems. It would not be approriate for C to
try to list all the kinds of errors that could occur. But I can't see
why it doesn't specify that errno is set to a system-dependent value.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Eric Sosman]

jacob navia wrote On 09/24/07 07:04,:

Ian Collins wrote:

>>jacob navia wrote:

>>>POSIX specifies exactly the type of errors that can be thrown by
fopen!

One reason why I use POSIX as my "portable" standard.

The C standard could use the same interface, and in system
where the error makes no sense, it would be just ignored!

What happens on a system where fopen() can fail for
reasons POSIX doesn't enumerate? I have used a system
where a file specification could (optionally) include an
account name and password; the attempt to open could fail
because of bad credentials. You might, with a stretch,
translate this to POSIX' EACCESS, but that's really not
how EACCESS is described.

File specifications on that same system could also
include network node names, and an open could fail because
of networking issues, permanent or transient. POSIX defines
errno values that describe network problems, but I don't
see any of them among the list that fopen() is allowed to
produce. So, what errno code should be delivered if a
network problem disrupts the open?

Still on the same system: An open could fail because
of invalid combinations of things like "record formats"
(specified in the second argument). Since POSIX has no
notion of "record format," POSIX defines no error codes
to describe problems with them; what code ought fopen()
to produce for this kind of failure?

What POSIX error code corresponds to picking "Cancel"
on the "Retry, Cancel, Abort?" dialog?

All those errors are just #defines that would take no
implementation effort and only be used in the systems
where those errors are supported.

If you try to enumerate all the possible reasons fopen()
could fail on all possible systems, you will find yourself
writing a very large number of #define's ... Also, the
resulting set will probably contain ambiguities.

POSIX is an adequate description of a certain class of
systems. It is not a description of all systems where C
runs, nor does it describe a superset of those systems.
Some systems just don't fall fully in the POSIX shadow.

--
Er*********@sun.com

[Charlie Gordon]

"Eric Sosman" <Er*********@sun.coma écrit dans le message de news:
1190645281.728338@news1nwk...

jacob navia wrote On 09/24/07 07:04,:

>Ian Collins wrote:

>>>jacob navia wrote:

POSIX specifies exactly the type of errors that can be thrown by
fopen!

One reason why I use POSIX as my "portable" standard.

The C standard could use the same interface, and in system
where the error makes no sense, it would be just ignored!

What happens on a system where fopen() can fail for
reasons POSIX doesn't enumerate? I have used a system
where a file specification could (optionally) include an
account name and password; the attempt to open could fail
because of bad credentials. You might, with a stretch,
translate this to POSIX' EACCESS, but that's really not
how EACCESS is described.

File specifications on that same system could also
include network node names, and an open could fail because
of networking issues, permanent or transient. POSIX defines
errno values that describe network problems, but I don't
see any of them among the list that fopen() is allowed to
produce. So, what errno code should be delivered if a
network problem disrupts the open?

Still on the same system: An open could fail because
of invalid combinations of things like "record formats"
(specified in the second argument). Since POSIX has no
notion of "record format," POSIX defines no error codes
to describe problems with them; what code ought fopen()
to produce for this kind of failure?

What POSIX error code corresponds to picking "Cancel"
on the "Retry, Cancel, Abort?" dialog?

>All those errors are just #defines that would take no
implementation effort and only be used in the systems
where those errors are supported.

If you try to enumerate all the possible reasons fopen()
could fail on all possible systems, you will find yourself
writing a very large number of #define's ... Also, the
resulting set will probably contain ambiguities.

POSIX is an adequate description of a certain class of
systems. It is not a description of all systems where C
runs, nor does it describe a superset of those systems.
Some systems just don't fall fully in the POSIX shadow.

I agree with you.
I still think the Standard should mandate the implementation to store an
implementation defined value in errno upon failure by fopen to open the
stream; an informative error message would be produced by strerror(errno).

--
Chqrlie.

[lawrence.jones]

Charlie Gordon <ne**@chqrlie.orgwrote:

>
What exactly was the rationale for not specifying it in the Standard ?

When the original C standard was written, very few (if any)
implementations *reliably* set errno when fopen() failed (many of them
set it most, but not all, of the time and most of them set it under some
conditions when fopen succeeded). It wasn't existing practice, so it
wasn't standardized.

Since then, the world has changed (thanks in part to POSIX) and most
implementations do now reliably set it, so it could have been changed in
C99, but no one proposed it as far as I can recall.

-Larry Jones

Yep, we'd probably be dead by now if it wasn't for Twinkies. -- Calvin

[lawrence.jones]

Ben Bacarisse <be********@bsb.me.ukwrote:

>
More specifically, if one does the recommended errno = 0; prior to the
call, are there really implementations of fopen that return NULL and
set errno to some unhelpful value?

There certainly were when the original C standard was written. In fact,
most implementations would do exactly that in some cases (that were,
thankfully, not very common). Since POSIX requires fopen() to reliably
set errno, I suspect that it no longer occurs.

-Larry Jones

It seems like once people grow up, they have no idea what's cool. -- Calvin

[lawrence.jones]

jacob navia <ja***@jacob.remcomp.frwrote:

>
Interesting. POSIX manages to do exactly that, but somehow
the C standard could not manage doing it.

POSIX specifies exactly the type of errors that can be thrown by
fopen!

That's because POSIX is an OS standard and thus has a priori knowledge
of all the OS-specific details that the C standard does not.

-Larry Jones

My dreams are getting way too literal. -- Calvin

[Al Balmer]

On Sat, 22 Sep 2007 15:29:37 +0100, "Malcolm McLean"
<re*******@btinternet.comwrote:

>The real answer is to implement safe pointers, which consist of three memory
addresses, the pointer itself and the bounds of the object it points to.
It means a slower language, but there just isn't another way I know of of
preventing buffer overruns.

I know another way - just don't write code that's susceptible to
buffer overruns :-)

--
Al Balmer
Sun City, AZ

[Eric Sosman]

Charlie Gordon wrote On 09/24/07 11:34,:

[...]
I still think the Standard should mandate the implementation to store an
implementation defined value in errno upon failure by fopen to open the
stream; an informative error message would be produced by strerror(errno).

I'd go further, and hope/require that *any* library
function set errno in the event of a (reported) failure.
This should not be a big burden on implementations, since
the fallback of reporting EMISC "something went wrong" is
always available; the QoI, though low, would be marginally
higher than just doing nothing. It's somehow dispiriting
to see "malloc failed: no error" on the console ...

One possible glitch in the "should not" above concerns
the expansion of library functions in-line, possibly with
assistance from macros. It may not be easy to control the
on-error behavior of a machine instruction or sequence
without introducing penalties. However, such concerns did
not deter the Standard from specifying how sqrt() must deal
with negative arguments, regardless of what the hardware's
SQRT instruction might or might not do with them.

The errno mechanism is less than wonderful, but as was
once said of the late Gerald Ford, "He's the only Vice
President we've got." It seems to me that wider use of
errno would do no harm and some good, and since no plausible
alternative error-reporting mechanism has been suggested
I wish the Standard would make more use of what's already
there.

--
Er*********@sun.com

[jacob navia]

Eric Sosman wrote:

jacob navia wrote On 09/24/07 07:04,:

>Ian Collins wrote:

>>jacob navia wrote:

POSIX specifies exactly the type of errors that can be thrown by
fopen!
One reason why I use POSIX as my "portable" standard.

The C standard could use the same interface, and in system
where the error makes no sense, it would be just ignored!

What happens on a system where fopen() can fail for
reasons POSIX doesn't enumerate? I have used a system
where a file specification could (optionally) include an
account name and password; the attempt to open could fail
because of bad credentials. You might, with a stretch,
translate this to POSIX' EACCESS, but that's really not
how EACCESS is described.

Why not?
It is an access error.

File specifications on that same system could also
include network node names, and an open could fail because
of networking issues, permanent or transient.

ENXIO could be used. The C specification could simplify
POSIX and use only 4-5 different things, without
forbidding other extended error reporting.

POSIX defines
errno values that describe network problems, but I don't
see any of them among the list that fopen() is allowed to
produce. So, what errno code should be delivered if a
network problem disrupts the open?

This is a hardware failure and could be just Error I/O
or similar.

Still on the same system: An open could fail because
of invalid combinations of things like "record formats"
(specified in the second argument). Since POSIX has no
notion of "record format," POSIX defines no error codes
to describe problems with them; what code ought fopen()
to produce for this kind of failure?

Posix says:
EINVAL: The "mode" argument is invalid (second argument)

What POSIX error code corresponds to picking "Cancel"
on the "Retry, Cancel, Abort?" dialog?

ENXIO: Input/Output error
In any case the Retry option is not seen by fopen() and the
abort bypasses it.

>

>All those errors are just #defines that would take no
implementation effort and only be used in the systems
where those errors are supported.

If you try to enumerate all the possible reasons fopen()
could fail on all possible systems, you will find yourself
writing a very large number of #define's ... Also, the
resulting set will probably contain ambiguities.

No. You misunderstand. C would define just 4 or 5 errors
with
o hardware error,
o not found error
o Access permissions errors
o No more memory or max number of files reached
o Argument error: file name NULL, or invalid mode string

An implementation could extend those errors with all the
detail they care to give.

Or an implementation could ALWAYS return not found, even
if it was some other kind of error.

The only thing that would change is that programs could
do PORTABLE error checking for MOST errors!

POSIX is an adequate description of a certain class of
systems. It is not a description of all systems where C
runs, nor does it describe a superset of those systems.
Some systems just don't fall fully in the POSIX shadow.

[Richard Harter]

On Mon, 24 Sep 2007 10:48:00 -0400, Eric Sosman
<Er*********@sun.comwrote:

>jacob navia wrote On 09/24/07 07:04,:

>Ian Collins wrote:

>>>jacob navia wrote:

POSIX specifies exactly the type of errors that can be thrown by
fopen!

One reason why I use POSIX as my "portable" standard.

The C standard could use the same interface, and in system
where the error makes no sense, it would be just ignored!

What happens on a system where fopen() can fail for
reasons POSIX doesn't enumerate? I have used a system
where a file specification could (optionally) include an
account name and password; the attempt to open could fail
because of bad credentials. You might, with a stretch,
translate this to POSIX' EACCESS, but that's really not
how EACCESS is described.

[snip litany of possible differences]

The obvious thing to do is have a general error code in addition
to the ones imported from posix. The general code would cover
all errors not otherwise classified. Do you have a problem with
that?
Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
But the rhetoric of holistic harmony can generate into a kind of
dotty, Prince Charles-style mysticism. -- Richard Dawkins

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

On Mon, 24 Sep 2007 16:34:06 +0000, Richard Harter wrote:

On Mon, 24 Sep 2007 10:48:00 -0400, Eric Sosman <Er*********@sun.com>
wrote:

> What happens on a system where fopen() can fail for
reasons POSIX doesn't enumerate? I have used a system where a file
specification could (optionally) include an account name and password;
the attempt to open could fail because of bad credentials. You might,
with a stretch, translate this to POSIX' EACCESS, but that's really not
how EACCESS is described.

[snip litany of possible differences]

The obvious thing to do is have a general error code in addition to the
ones imported from posix. The general code would cover all errors not
otherwise classified. Do you have a problem with that?

I do. If fopen can fail for other reasons than specified by POSIX, the
implementation should define additional error codes properly. There's no
point in using something like EIDUNNO, which tells you nothing more than
fopen's NULL return value, when an implementation-specific EBADCRED could
be defined just as easily. It would then make sure a decent message can
get printed by strerror. (As an aside, I don't see the problem with
EACCES for this specific error, but I do agree with some of the other
snipped examples.)

[Keith Thompson]

Al Balmer <al******@att.netwrites:

On Sat, 22 Sep 2007 15:29:37 +0100, "Malcolm McLean"
<re*******@btinternet.comwrote:

>>The real answer is to implement safe pointers, which consist of three memory
addresses, the pointer itself and the bounds of the object it points to.
It means a slower language, but there just isn't another way I know of of
preventing buffer overruns.

I know another way - just don't write code that's susceptible to
buffer overruns :-)

How has that been working out so far?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Harter]

On Mon, 24 Sep 2007 16:47:25 +0000 (UTC),
=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0Fk?=
<tr*****@gmail.comwrote:

>On Mon, 24 Sep 2007 16:34:06 +0000, Richard Harter wrote:

>On Mon, 24 Sep 2007 10:48:00 -0400, Eric Sosman <Er*********@sun.com>
wrote:

>> What happens on a system where fopen() can fail for
reasons POSIX doesn't enumerate? I have used a system where a file
specification could (optionally) include an account name and password;
the attempt to open could fail because of bad credentials. You might,
with a stretch, translate this to POSIX' EACCESS, but that's really not
how EACCESS is described.

[snip litany of possible differences]

The obvious thing to do is have a general error code in addition to the
ones imported from posix. The general code would cover all errors not
otherwise classified. Do you have a problem with that?

I do. If fopen can fail for other reasons than specified by POSIX, the
implementation should define additional error codes properly. There's no
point in using something like EIDUNNO, which tells you nothing more than
fopen's NULL return value, when an implementation-specific EBADCRED could
be defined just as easily. It would then make sure a decent message can
get printed by strerror. (As an aside, I don't see the problem with
EACCES for this specific error, but I do agree with some of the other
snipped examples.)

I don't quite understand your objection. What we are talking
about are the error codes (that should be) required by the
standard. Clearly the standard cannot specify codes for all
possible errors in all possible implementations. What it can do
is specify that there are codes for the commonest errors.

Adding codes for all possible errors is up to the implementation.
However that is necessarily non-portable.

Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
But the rhetoric of holistic harmony can generate into a kind of
dotty, Prince Charles-style mysticism. -- Richard Dawkins

[jacob navia]

Richard Harter wrote:
[snip]

I don't quite understand your objection. What we are talking
about are the error codes (that should be) required by the
standard. Clearly the standard cannot specify codes for all
possible errors in all possible implementations. What it can do
is specify that there are codes for the commonest errors.

Adding codes for all possible errors is up to the implementation.
However that is necessarily non-portable.

This is exactly what I am proposing. This would allow to write
PORTABLE programs that would be able to do some error analysis!

The terrible situation now, i.e. developing code for EACH
combination of OS + compiler is so difficult to implement that
it makes portable error analysis IMPOSSIBLE!!!

[Tor Rustad]

Chris Torek wrote:

>Chris Torek wrote:

>>Moreover, to really fix the whole "errno" thing, I think the
best approach is to abandon C. I am not sure my position here
is going to be popular, though. :-) )

(Note, as an aside to Jacob and maybe others: I said *best*, not
*only*, here.)

Doing the "Right Thing", may not win over "worse is better" design.

In article <HP*********************@telenor.com>,
Tor Rustad <to********@hotmail.comwrote:

>I read this as abandon UNIX.

Well, POSIX, more generally. As Rob Pike put it back in 1991:
"Not only is UNIX dead, it's starting to smell really bad."
(Overstatement for effect, perhaps, but still... :-) )

It's hard to predict, particularly about the future. :)

Anyway, Pike has been proved wrong. I must admit, I didn't see Ubuntu &
friends arriving in 1991 either. The "failure" of Plan 9 and success of
Linux, didn't exactly make Pike positive towards Linux, BSD, ... and the
open source community.

>Even if ISO C don't require errno set, POSIX do so:

"Upon successful completion, fopen() returns a pointer to the object
controlling the stream. Otherwise, a null pointer is returned, and errno
is set to indicate the error."

http://www.opengroup.org/onlinepubs/...xsh/fopen.html

Yes. It is not at all clear to me why ISO did not at least pick
this up. This is, I think, a smaller yet even more important change
than most of the various "_r" re-entrant interfaces that are also
in POSIX, but not ISO C.

Agreed, as long as ISO C don't specify threads and the current (lack of)
signal definition exist, the "_r" functions is better left to POSIX.

--
Tor <torust [at] online [dot] no>

[Keith Thompson]

la************@ugs.com writes:

Ben Bacarisse <be********@bsb.me.ukwrote:

>More specifically, if one does the recommended errno = 0; prior to the
call, are there really implementations of fopen that return NULL and
set errno to some unhelpful value?

There certainly were when the original C standard was written. In fact,
most implementations would do exactly that in some cases (that were,
thankfully, not very common). Since POSIX requires fopen() to reliably
set errno, I suspect that it no longer occurs.

It could occur under implementations that support standard C but don't
claim conformance to POSIX. But I wonder how many hosted C
implementations these days don't at least try to support POSIX.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"