printing error messages

G

gsa

Hi,
I am new to C so please bear with my stupid questions. I am
trying to open a file to write, but the code complains that it is
unable to do so. How do I get C to print the reason it is failing?
Something like the $! function in perl. Thanks a lot for all your
help.
 
D

dj3vande

Hi,
I am new to C so please bear with my stupid questions. I am
trying to open a file to write, but the code complains that it is
unable to do so. How do I get C to print the reason it is failing?
Something like the $! function in perl. Thanks a lot for all your
help.

perror() may be what you're looking for.
I don't believe fopen is required to set errno when it fails, but on
every implementation I've encountered it does. (That may be influenced
by the fact that most of the implementations I've used are unixy, and I
think POSIX *does* require the underlying system calls to set errno.)


dave
 
W

Walter Roberson

I am new to C so please bear with my stupid questions. I am
trying to open a file to write, but the code complains that it is
unable to do so. How do I get C to print the reason it is failing?
Something like the $! function in perl.

See the documentation on perror(). (Note: perror has some subtle
limitations that can make it a better idea to use the lower-level
equivilents... which you will likely find references to in the
perror() documentation.)
 
G

gsa

I just stuck the error function call in the if block and it worked.

if((fp = fopen(stretchesFile, "w")) == NULL) {
error(1, errno, "could not open file %s", stretchesFile);
exit(1);
}

Thanks again for your help!!
 
D

dj3vande

I just stuck the error function call in the if block and it worked.

if((fp = fopen(stretchesFile, "w")) == NULL) {
error(1, errno, "could not open file %s", stretchesFile);
exit(1);
}

Thanks again for your help!!

Note that error() is not portable; the man page on my system says:
These functions and variables are GNU extensions, and should not be
used in programs intended to be portable.
So if you plan to use this program anywhere other than on Linux, you
should probably use the portable building blocks (error() appears to be
built on strerror(), exit(), and a few stdio functions, plus an
extension to get the value of argv[0] somewhere outside of main())
instead of the GNU convenience wrapper.
(In your case, it may be acceptable to plan to write your own version
of error() when you want to run somewhere other than Linux, since it
gives you a one-line call that does a set of things that's not-quite-
trivial to write yourself. But you should be aware of the
nonportability and make sure that the benefits do indeed exceed the
costs.)


dave
 
P

pereges

I personally use fprintf. For eg:

typedef struct xyz_struct
{
..
}*xyzptr;

void foo()
{
xyzptr p;

p = malloc(sizeof(*p));

if(p == NULL)
frpintf("Unable to allocate memory: %s %d %s", __FILE__,
__LINE__,__func__);
..
}



I'm not sure if this is a good method though
 
B

Bill Cunningham

gsa said:
I just stuck the error function call in the if block and it worked.

if((fp = fopen(stretchesFile, "w")) == NULL) {
error(1, errno, "could not open file %s", stretchesFile);
exit(1);
}

Thanks again for your help!!

For my 2 cents worth exit(1) isn't portable. Try exit(EXIT_FAILURE) from
stdlib.h. For me it has made the difference between a working and non
working program.

Bill
 
R

Richard

Bill Cunningham said:
For my 2 cents worth exit(1) isn't portable. Try exit(EXIT_FAILURE) from
stdlib.h. For me it has made the difference between a working and non
working program.

Bill

I do not believe you. I would be interested in seeing this program that
suddenly magically worked when you change the code you call exit with.
 
S

santosh

Bill said:
news:dd7b86c4-554d-439d-ac90-a522770ce6ce@l17g2000pri.googlegroups.com...

For my 2 cents worth exit(1) isn't portable. Try
exit(EXIT_FAILURE) from
stdlib.h. For me it has made the difference between a working and non
working program.

exit(1) didn't work? What's your system and what exactly happened, i.e.,
what was the behaviour that made you conclude that exit(1) failed.
 
R

Richard

santosh said:
exit(1) didn't work? What's your system and what exactly happened, i.e.,
what was the behaviour that made you conclude that exit(1) failed.

He is trolling. I replied before realising who it was.
 
K

Keith Thompson

Bill Cunningham said:
For my 2 cents worth exit(1) isn't portable. Try
exit(EXIT_FAILURE) from stdlib.h. For me it has made the difference
between a working and non working program.

Really?

You're absolutely right that exit(1) isn't portable, and
exit(EXIT_FAILURE) is preferred.

But it won't affect the behavior of the program itself until it
terminates -- and on most systems you're likely to be using
(including, I'm fairly sure, all variations of Unix and Windows),
exit(1) and exit(EXIT_FAILURE) happen to behave the same way. (You're
not using VMS, are you?)

Perhaps you happened to make some other fix at the same time that you
changed the exit() call.
 
K

Keith Thompson

CBFalconer said:
"exit(1);" never is portable, and has absolutely no guarantees.
Bill is right here, the only guaranteed values for exit are 0,
EXIT_OK, and EXT_FAILURE. The latter two require include stdlib.h.

Bill is of course 100% correct that exit(1) is not portable. But
that's not all he said. He also said that it "has made the difference
between a working and non working program". I find that claim
surprising (for reasons that happen to be beyond the scope of the C
standard).

Do you have reason to believe that it actually did make such a
difference?
 
V

vippstar

... snip ...



"exit(1);" never is portable, and has absolutely no guarantees.
Bill is right here, the only guaranteed values for exit are 0,
EXIT_OK, and EXT_FAILURE. The latter two require include stdlib.h.
AFAIK exit(1) has guarantees about the behavior of the program. It
doesn't guarantee a meaningful value to be returned.
 
S

santosh

CBFalconer said:
"exit(1);" never is portable, and has absolutely no guarantees.

Of course. But I'm interested to hear the details of the implementation
under which exit(1) resulted in a "non working program", as Bill
claims.
Bill is right here, the only guaranteed values for exit are 0,
EXIT_OK, and EXT_FAILURE. The latter two require include stdlib.h.

It should be EXIT_SUCCESS, not EXIT_OK.
 
R

Richard

AFAIK exit(1) has guarantees about the behavior of the program. It
doesn't guarantee a meaningful value to be returned.

What do you mean AFAIK? What do you expect to go wrong with the program
when exit is called? And talk in standard C in this case - I am not
concerned about return codes to system calls for example.
 
S

santosh

Eric said:
FILE *stream = fopen(filename, mode);
if (stream == NULL) {
perror(filename);
... whatever else ...
}

This is not absolutely airtight, because fopen() is not
*required* to describe its reason for failing by storing a
value in `errno'. So there's a chance you'll get some
completely bogus "reason" for the failure, and that could
confuse the person reading the message. In my experience,
most C implementations *do* set `errno' when fopen() fails,
so I feel the benefit of displaying what `errno' says outweighs
the risk that what it says might be nonsense.

Two warnings: First, display information from `errno'
only after you've determined that there's been a failure;
`errno' itself is not a failure-detection mechanism. Second,
don't call other functions between the point of failure and
the point when you call perror(), because they may change the
value of `errno' even on successful calls.

Also a small additional point. You might want to set errno to zero just
before a call to a library function. Since library functions are
guaranteed to not store zero in errno, you can be sure that the value
you are reading (and it's associated error message) has been set by the
previous function call, and not some "left over" value.
 
S

santosh

gsa said:
I just stuck the error function call in the if block and it worked.

if((fp = fopen(stretchesFile, "w")) == NULL) {
error(1, errno, "could not open file %s", stretchesFile);
exit(1);
}

Thanks again for your help!!

There is no standard function called error. You are using an
implementation specific extension which might not be available under
the next compiler you try your code with.
 
B

Baboon

santosh said:
exit(1) didn't work? What's your system and what exactly happened, i.e.,
what was the behaviour that made you conclude that exit(1) failed.

On my Binford DS 6100, exit(), when passed these values,
behaves as follows:

EXIT_SUCCESS (0)
return to host environment indicating success

EXIT_FAILURE (42)
return to host environment indicating failure

EXIT_NOP (1)
return to the function that called exit()

[further documented exit codes omitted]

Does that violate any standards?
 
N

Nick Keighley

I personally use fprintf [for error reporting]. For eg:

void foo()
{
  xyzptr p;

  p = malloc(sizeof(*p));

  if(p == NULL)
    frpintf("Unable to allocate memory: %s %d %s", __FILE__,
__LINE__,__func__);
  ..

}

I'm not sure if this is a good method though


It's not a bad idea, though it might be a good idea to
specify a file (stream) to write to


frpintf(stderr, "Unable to allocate memory: %s %d %s", __FILE__,
__LINE__,__func__);

and note __func___ is only available with the latest standard
(C99) which is still only patchily supported.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top