FILE pointer

[Chris Torek]

Re: Which standards do the implementation support?

In article <hbf.20061026oh 46_-_@bombur.uio.no >
Hallvard B Furuseth <h.b.furuseth@u sit.uio.nowrote :

>A recent thread mentioned that the C standard does not guarantee
>that failed file operations set errno. To see if it did, set
>errno=0 before the file operation and test errno afterwards.
>
>I don't want to clutter my entire program with errno settings,
>so is there a way for a general error reporting routine check
>for _common_ implementations which set errno?

Rather than answering the POSIX-specific part of this, I will
note that:

errno = 0;

before calling fopen() is probably a good idea anyway, to protect
against broken implementations that do something like this:

FILE *fopen(const char *restrict path, const char *restrict mode) {
FILE *fp;

fp = __stdio_get_new _fp();
if (fp == NULL)
return NULL; /* without setting errno */
... actually try to open the path, which will set errno ...
}

(where __stdio_get_new _fp() returns NULL without setting errno
in at least some cases).

While I do not know that of any specific POSIX implementations that
are broken in this way, I do know of at least one pre-POSIX
implementation that was.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Hallvard B Furuseth]

Re: Which standards do the implementation support?

Al Balmer writes:

>On Thu, 26 Oct 2006 13:52:48 +0200, Hallvard B Furuseth
><h.b.furuseth@ usit.uio.nowrot e:
>

>POSIX says errno should be set (or at least the POSIX version I'm
>looking at) - is there an official 'if (running on POSIX)' test to
>use?

>
<OTYes, there are defined macros which tell what versions and what
particular features of POSIX are available if compiling on a POSIX
implementation, and functions that report the POSIX support at
runtime. Any good POSIX book should detail the steps. If you need
further help, comp.unix.progr ammer is probably a good place to ask.

Well, yes, I'd kind of hoped someone had some more general code already.
It feels like it _ought_ to be a common problem, after all.

But if not, let me rephrase the question: _Which_ other places should I
ask? comp.unix.progr ammer, comp.os.ms-windows.program mer.something,
check. What else? E.g. people talk about embedded systems here, but I
wouldn't know one if it bit me. What kind of OS do these use, and where
do I ask?

--
Hallvard

[Hallvard B Furuseth]

Re: Which standards do the implementation support?

Chris Torek writes:

Rather than answering the POSIX-specific part of this, I will
note that:
errno = 0;
before calling fopen() is probably a good idea anyway, to protect
against broken implementations that do something like this:

Ouch. Thanks, will do. Fortunately I've got rather fewer fopen() calls
than other file operations.

FILE *fopen(const char *restrict path, const char *restrict mode) {
FILE *fp;
fp = __stdio_get_new _fp();
if (fp == NULL)
return NULL; /* without setting errno */
... actually try to open the path, which will set errno ...
}

--
Hallvard

[Al Balmer]

Re: Which standards do the implementation support?

On Fri, 27 Oct 2006 11:00:13 +0200, Hallvard B Furuseth
<h.b.furuseth@u sit.uio.nowrote :

>Al Balmer writes:

>>On Thu, 26 Oct 2006 13:52:48 +0200, Hallvard B Furuseth
>><h.b.furuseth @usit.uio.nowro te:
>>

>>POSIX says errno should be set (or at least the POSIX version I'm
>>looking at) - is there an official 'if (running on POSIX)' test to
>>use?

>>
><OTYes, there are defined macros which tell what versions and what
>particular features of POSIX are available if compiling on a POSIX
>implementation , and functions that report the POSIX support at
>runtime. Any good POSIX book should detail the steps. If you need
>further help, comp.unix.progr ammer is probably a good place to ask.

>
>Well, yes, I'd kind of hoped someone had some more general code already.
>It feels like it _ought_ to be a common problem, after all.

I guess I have to be more explicit. As I noted, this question is Off
Topic here (that's what I meant by OT.) As for code, I encourage you
to do the research and try to write it yourself.

>
>But if not, let me rephrase the question: _Which_ other places should I
>ask? comp.unix.progr ammer,

Yes, as suggested. Have you asked there yet? However, be aware that
c.u.p is not a "sources wanted" newsgroup either, but will help if you
try writing the code and have problems.

comp.os.ms-windows.program mer.something,
>check. What else? E.g. people talk about embedded systems here, but I
>wouldn't know one if it bit me. What kind of OS do these use, and where
>do I ask?

They use a number of operating systems, and many use no operating
system at all. I suggest you ask a general question in
comp.arch.embed ded.

--
Al Balmer
Sun City, AZ

[sjdevnull@yahoo.com]

Re: [OT] Which standards do the implementation support?

Hallvard B Furuseth wrote:

But if not, let me rephrase the question: _Which_ other places should I
ask? comp.unix.progr ammer, comp.os.ms-windows.program mer.something,
check. What else? E.g. people talk about embedded systems here, but I
wouldn't know one if it bit me. What kind of OS do these use, and where
do I ask?

In general, comp.programmin g is not a bad place to start looking for
more specific groups or to get advice about general catch-all
programming questions.

[Hallvard B Furuseth]

Re: Which standards do the implementation support?

Al Balmer writes:

>On Fri, 27 Oct 2006 11:00:13 +0200, Hallvard B Furuseth
I guess I have to be more explicit. As I noted, this question is Off
Topic here (that's what I meant by OT.)

Yes, well, I don't understand why it's supposed to be so firmly
off-topic. I'm looking for how report error descriptions from standard
C library calls, preferably via the common extension that the standard C
feature errno is set at other times than when the standard requires.

I guess I may have expressed it badly, but one point here is that I don'
_know_ many systems, or even which systems to ask about. Yes, I can
find Posix, Windows, Embedded, whatever, once I've thought of such
systems... but that's like searchig Unix manuals for a program for some
task - I can find the answer to which systems to look for if I already
know the answer. comp.programmin g was at least a useful suggestion in
that respect.

As for code, I encourage you to do the research and try to write it
yourself.

And then publish as production code some #ifdef spaghetti I'm unable to
test. This is not a tempting idea. As long as it's just some #ifdefs
to test if I'll use strerror/perror() I guess I can live with it, but I
might just as well just refrain from using strerror/perror(). But
that's why I'd really hoped that someone had some _code_.

For that matter, maybe testing for a _system_ is the wrong idea. E.g.,
maybe #if defined(EBADF) || defined(ENOENT) would be a better idea - if
a system defines these, maybe it'll likely set errno on standard system
calls? Also OT I'm sure since EBADF/ENOENT are not in the standard...

So anyway, why isn't "ask on comp.lang.c" supposed to be a better answer
in comp.programmin g than "ask in comp.programmin g" is here? It
certainly would be with any other language than C. It's a very
language- specific question. Or worse, in comp.arch.embed ded, which
isn't even mostly about programming. And why am I supposed to spam the
maybe 20 newsgroups I find with the same question, when some _C_
programmers from using systems might be reading _this_ group?

--
Hallvard

[Al Balmer]

Re: Which standards do the implementation support?

On Fri, 03 Nov 2006 14:06:59 +0100, Hallvard B Furuseth
<h.b.furuseth@u sit.uio.nowrote :

>Al Balmer writes:

>>On Fri, 27 Oct 2006 11:00:13 +0200, Hallvard B Furuseth
>I guess I have to be more explicit. As I noted, this question is Off
>Topic here (that's what I meant by OT.)

>
>Yes, well, I don't understand why it's supposed to be so firmly
>off-topic.

http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction

I'm looking for how report error descriptions from standard
>C library calls, preferably via the common extension that the standard C
>feature errno is set at other times than when the standard requires.

Then, you have to ask folks who deal with those "other times."

>
>I guess I may have expressed it badly, but one point here is that I don'
>_know_ many systems, or even which systems to ask about.

Only the ones you need to support. There's no way to support all past,
present and future systems.

Yes, I can
>find Posix, Windows, Embedded, whatever, once I've thought of such
>systems... but that's like searchig Unix manuals for a program for some
>task -
>I can find the answer to which systems to look for if I already
>know the answer. comp.programmin g was at least a useful suggestion in
>that respect.
>

>As for code, I encourage you to do the research and try to write it
>yourself.

>
>And then publish as production code some #ifdef spaghetti I'm unable to
>test. This is not a tempting idea. As long as it's just some #ifdefs
>to test if I'll use strerror/perror() I guess I can live with it, but I
>might just as well just refrain from using strerror/perror(). But
>that's why I'd really hoped that someone had some _code_.

Perhaps I wasn't clear enough. Books on POSIX, for example, usually
detail the compile-time and run-time feature tests. Sometimes, they
even supply sample code. If they don't, you write code using the
specifications they provide. If you doubt your ability to write clean
code, try anyway, then come back here for help. (ifdef is standard C.)

>
>For that matter, maybe testing for a _system_ is the wrong idea. E.g.,
>maybe #if defined(EBADF) || defined(ENOENT) would be a better idea - if
>a system defines these, maybe it'll likely set errno on standard system
>calls? Also OT I'm sure since EBADF/ENOENT are not in the standard...

Good grief, no. Assumptions like that can only get you in worse
trouble.

>
>So anyway, why isn't "ask on comp.lang.c" supposed to be a better answer
>in comp.programmin g than "ask in comp.programmin g" is here?

Again, http://clc-wiki.net/wiki/C_community...c:Introduction

It
>certainly would be with any other language than C. It's a very
>language- specific question. Or worse, in comp.arch.embed ded, which
>isn't even mostly about programming.

You asked a specific question about embedded systems, and I gave you a
specific answer. BTW, I didn't notice you asking the question there. I
didn't see any questions about POSIX feature detection in c.u.p.,
either.

And why am I supposed to spam the
>maybe 20 newsgroups I find with the same question, when some _C_
>programmers from using systems might be reading _this_ group?

You aren't supposed to. You're supposed to do sufficient research to
find the one or two groups which are appropriate. Use Google group
search. You may even find that your questions have already been asked
and answered.

I'm puzzled about what you're trying to accomplish. Above, you
intimated that you want to write production code. Other questions make
me think you're writing a book or something. Then you speak of
searching manuals for programs. Manuals usually give you what you need
to write your own programs - you don't expect to find them ready-made.

I don't want to discourage you, but this newsgroup is primarily for
programmers, both neophytes and old hands. I'm not sure what your
goals are, but you don't actually seem to be trying to learn
programming or ask specific questions about the standard C language.
If you can better describe what you're trying to accomplish, maybe we
can be more help.

--
Al Balmer
Sun City, AZ

[Hallvard B Furuseth]

Re: Which standards do the implementation support?

Al Balmer writes:

On Fri, 03 Nov 2006 14:06:59 +0100, Hallvard B Furuseth
<h.b.furuseth@u sit.uio.nowrote :

>>Al Balmer writes:

>>>On Fri, 27 Oct 2006 11:00:13 +0200, Hallvard B Furuseth
>>I guess I have to be more explicit. As I noted, this question is Off
>>Topic here (that's what I meant by OT.)

>>
>>Yes, well, I don't understand why it's supposed to be so firmly
>>off-topic.

>
http://clc-wiki.net/wiki/C_community...c:Introduction

Hmm. I've following this group on and off for years, but I'd not seen
that one. It doesn't seem to be in the C faq.

>I'm looking for how report error descriptions from standard C library
>calls, preferably via the common extension that the standard C
>feature errno is set at other times than when the standard requires.

>
Then, you have to ask folks who deal with those "other times."

Well, that _is_ what I've been trying to do.

>I guess I may have expressed it badly, but one point here is that I
>don' _know_ many systems, or even which systems to ask about.

>
Only the ones you need to support. There's no way to support all past,
present and future systems.

No, but (to answer some of your later questions) I'm not really trying
to support any particular systems at all, except when there is no other
way. I'm trying to write a portable ISO C program of some quality.
That would imply to give error messages of some quality too when
possible, which apparently is very cumbersome in standard C. (Reset
errno before every stdio call, no thanks. I'll reset it before fopen()
though.) A system-dependent #ifdef mess seems the best one can do.

>For that matter, maybe testing for a _system_ is the wrong idea.
>E.g., maybe #if defined(EBADF) || defined(ENOENT) would be a better
>idea - if a system defines these, maybe it'll likely set errno on
>standard system calls? Also OT I'm sure since EBADF/ENOENT are not
>in the standard...

>
Good grief, no. Assumptions like that can only get you in worse
trouble.

Oh well, it was a thought.

>So anyway, why isn't "ask on comp.lang.c" supposed to be a better
>answer in comp.programmin g than "ask in comp.programmin g" is here?
>Again, http://clc-wiki.net/wiki/C_community...c:Introduction
>>
>It certainly would be with any other language than C. It's a very
>language- specific question. Or worse, in comp.arch.embed ded, which
>isn't even mostly about programming.

>
You asked a specific question about embedded systems, and I gave you a
specific answer.

Sigh, I've definitely started this off badly, sorry about that.
I always seem to start out too tecnical and expect people to be
mind-readers, you'd think I'd learn sooner or later.

My point with embedded systems - and Windows for that matter - is that
there are a bunch of systems out there that I don't know anything about,
and when I do know anything about them I usually still can't test them.

BTW, I didn't notice you asking the question there. I didn't see any
questions about POSIX feature detection in c.u.p., either.

Not yet, anyway. As you point out, I _can_ do some research myself if
that's what I have to do. Except I don't even know if I'd use the
result yet:

>And why am I supposed to spam the maybe 20 newsgroups I find with the
>same question, when some _C_ programmers from using systems might be
>reading _this_ group?

>
You aren't supposed to. You're supposed to do sufficient research to
find the one or two groups which are appropriate. Use Google group
search. You may even find that your questions have already been asked
and answered.

Duh, of course, that's what you meant. No. I'd rather not publish code
for some specific OS which nobody who uses that OS has seen and said is
compatible with reality. There is a lot of good info about various
systems out there, but there is a lot of poor and misleading and
vaporvare info also, or "everyone knows"-omissions in the good info. In
this case it's all fairly trivial (a few #ifdefs), but the result of not
including is isn't too earth-shaking either.

I'm puzzled about what you're trying to accomplish. Above, you
intimated that you want to write production code. Other questions make
me think you're writing a book or something.

I've answered that now this time. I hope.

Then you speak of searching manuals for programs. Manuals usually give
you what you need to write your own programs - you don't expect to
find them ready-made.

I was referring to how useless Unix man pages often are if one is
looking for some program for a specific task. You can find the program
if you already know what it's called. (man -k sometimes helps, but only
sometimes.)

--
Hallvard

[Flash Gordon]

Re: Which standards do the implementation support?

Hallvard B Furuseth wrote:

Al Balmer writes:

>On Fri, 03 Nov 2006 14:06:59 +0100, Hallvard B Furuseth
><h.b.furuseth@ usit.uio.nowrot e:

>>Al Balmer writes:
>>>On Fri, 27 Oct 2006 11:00:13 +0200, Hallvard B Furuseth
>>>I guess I have to be more explicit. As I noted, this question is Off
>>>Topic here (that's what I meant by OT.)
>>Yes, well, I don't understand why it's supposed to be so firmly
>>off-topic.

>http://clc-wiki.net/wiki/C_community...c:Introduction

>
Hmm. I've following this group on and off for years, but I'd not seen
that one. It doesn't seem to be in the C faq.

It is comparatively recent. Some people had been talking about about
having something that the regulars could maintain and eventually I and
others decided to set up the resource and let people free on it. That
particular page was created based on the various discussions that have
gone on over the years about topicality, and being a Wiki others can
easily edit it if there is a problem, post comments on it, and set up
monitoring for changes to protect it against vandalism.

<snip>

No, but (to answer some of your later questions) I'm not really trying
to support any particular systems at all, except when there is no other
way. I'm trying to write a portable ISO C program of some quality.
That would imply to give error messages of some quality too when
possible, which apparently is very cumbersome in standard C. (Reset
errno before every stdio call, no thanks. I'll reset it before fopen()
though.) A system-dependent #ifdef mess seems the best one can do.

Unfortunately for you it is. The standard leaves most error reporting as
a QoI matter. It provides standard mechanisms the implementation can use
(allowing errno to be set, strerror etc) but in most cases does not
require it.

Also remember that the C standard does not mandate that an
implementation can't pretend to be POSIX (or anything else) whilst using
all the error codes for different things. E.g.
ENOENT - No Entertainment System.
Set by fopen when opening a file in /dev/media fails

>>For that matter, maybe testing for a _system_ is the wrong idea.
>>E.g., maybe #if defined(EBADF) || defined(ENOENT) would be a better
>>idea - if a system defines these, maybe it'll likely set errno on
>>standard system calls? Also OT I'm sure since EBADF/ENOENT are not
>>in the standard...

>Good grief, no. Assumptions like that can only get you in worse
>trouble.

>
Oh well, it was a thought.

You can sometimes use such things to detect optional parts of some other
standard, or error codes added in later versions of a system that were
not there on earlier versions. However, you first have to detect that
you are in a situation where you can safely use that logic.

<snip>

My point with embedded systems - and Windows for that matter - is that
there are a bunch of systems out there that I don't know anything about,
and when I do know anything about them I usually still can't test them.

<snip>

You will not find anywhere where all systems are known about. After all,
there might be a company that has been developing a new system in secret
and are now ready to release it. The best you can do is cover the
systems that are likely to be of interest and do it in such a way that
you will later be able to extend it for other systems.
--
Flash Gordon

[Dave Thompson]

Re: Which standards do the implementation support?

<mostly OT>
On Thu, 26 Oct 2006 13:52:48 +0200, Hallvard B Furuseth
<h.b.furuseth@u sit.uio.nowrote :
<snip>

I need code for at least Windows and preferably Mac as well,
but I don't know them. I seem to remember there is some weird
Windows error code one should use instead of errno?

In (modern) Windows for _C library_ routines just use errno as usual.

For (most) Windows native routines, _call_ GetLastError().

One gotcha: sockets are not standard C, but on Unix/POSIX like (other)
lowlevel I/O use errno except netdb uses h_errno; winsock originally
had its own WSAGetLastError () but now that aliases GetLastError().
And if you want a string for these errors strerror does not work, you
have to use (Windows) FormatMessage. And there are other differences,
although IF you stick to the basics (connect/accept, send/recv,
shutdown, close) they can be papered over acceptably.


- David.Thompson1 at worldnet.att.ne t

[Hallvard B Furuseth]

Re: Which standards do the implementation support?

Dave Thompson writes:

On Thu, 26 Oct 2006 13:52:48 +0200, Hallvard B Furuseth wrote:

>I need code for at least Windows and preferably Mac as well,
>but I don't know them. I seem to remember there is some weird
>Windows error code one should use instead of errno?

>
In (modern) Windows for _C library_ routines just use errno as usual.
>
For (most) Windows native routines, _call_ GetLastError().

Thanks!

One gotcha: sockets are not standard C,

I don't need them, fortunately:-)

--
Hallvard