code

[Keith Thompson]

Even though I believe you know this, I'd like to clarify because this
might confuse some.

'\0' is an integer constant, with type int in C. (however, in that
other language, C++, its type is char)
char *error = '\0'; is correct because whenever an integer constant
with value 0 is encountered in pointer context it becomes a null
pointer constant.

It's "correct", but it's horribly bad style. I didn't want to confuse
Bill with the distinction. If I'd been talking to anyone else, I'd
probably have gone into it in a bit more depth.

 

[Barry Schwarz]

[snip]

Did you not look up what perror does? On what did you base your
assumption? After all the previous discussions advising against it,
you are still just guessing.

This comes from a C reference I have. It is not kandr2 but it helps.

If it gives you incorrect information, it doesn't help at all. Is
this the same useless abbreviated reference you discussed in previous
posts?

"After a system function call has resulted in an error, you can use perror()
to write the string pointed to by string to stderr, followed by a colon and
the appropriate system error message."

That really doesn't help me much. Not with perror. void perror(const
char* string) is the parameter of course. I assumed I had to pass a string
to perror. Hince the char *error string. I know I've done something wrong

You do have to pass a string to perror. Does a char* with an
indeterminate value qualify? Does a char* set to NULL qualify. Do
you even read what you write?

here but I must admit, my lack of use and understanding of perror does have
me a little dumbfounded. I have used perror successfully before but it's
been so long. As I say I don't use it much.

Interesting style of programming you have adopted. You don't know how
to use a function so you just post any code that comes to mind.

 

[Barry Schwarz]

I didn't know my pointer was unassigned. I passed it to perror.

Did you ever assign a value to the pointer? Did you ever initialize
the pointer? How could you not know?

 

[Nick Keighley]

    if ((fp = fopen(argv[5], "a")) == NULL)
        perror(error);

The line above is not portable, fopen() is not required to set errno
on failure.  If it was me, I would have just written:

  fprintf(stderr, "Can't open %s\n", argv[5]);

[snip]

    So using perror with fopen is not a good idea? That sounds to me like
what you're saying.

hmmm. The Standard does not guarantee that fopen() sets errno
(which is what the machinary of perror() uses underneath). But
many implementaions *do* set errno. This includes such obscure
platforms as Windows and most (all?) Unix platforms. This is one
place where I accept the technically non-portability and call
perror() after a failed fopen() (well actually I prefer strerror()).
You need to decide how hyper-portable you need to be.

This is what I usually type becuase I actually don't
much use perror of feof either.

finding an End-Of-File indication IS NOT AN ERROR!

if ((fp=fopen(argv[5],"a"))==NULL) {
puts("fopen failure");
exit(EXIT_FAILURE);

}

Something like that is portable isn't it? That's my normal modus operandi..

yes. Portable. Nice to know what file failed tho

 

[Nick Keighley]

    I'm a little confused as to perror (filename); I declared char *error to
pass to perror. Again though perror is something I rarely use.

did you read the manual?

 

[Jean-Marc Bourguet]

hmmm. The Standard does not guarantee that fopen() sets errno
(which is what the machinary of perror() uses underneath). But
many implementaions *do* set errno. This includes such obscure
platforms as Windows and most (all?) Unix platforms.

AFAIK, it's mandated by POSIX.

Yours,

 

[Nick Keighley]

AFAIK, it's mandated by POSIX.

ah, but are all unixen posixen?

 

[Jean-Marc Bourguet]

ah, but are all unixen posixen?

POSIX is vast and I wouldn't bet anything for some part, but on that point,
I think POSIX just describes what was already the normal unix way in the
80s.

Yours,

 

[Bill Cunningham]

I'm going to regret getting into this, but ...
Bill, you wrote (with minor edits by me):
int main(int argc, char *argv[])
{
FILE *fp;
char *error;
/* error is indeterminate at this point */
if ((fp = fopen(argv[5], "a")) == NULL)
perror(error); /* passing uninitialized value to perror */


perror does not set the char * passed to it, it just
reads it. If you wrote:
error = "foo"; perror( error );
or
perror( "foo" );

then the text "foo:" and a system specified string based
on the current value of errno will be written to stderr.
Since error might be pointing to "garbly-gook", you
might get the string: "garbly-gook: permission denied"
printed to stderr. However, more likely error points
to nowhere useful, and reading that value (which perror
does) invokes UB.

C is pass by value. When you pass it a char *, the
function has no ability to modify it. It can modify
the char that is pointed to (but that's not what
perror does), but in your case it
doesn't point anywhere because you haven't
initialized it.

For your program, change the name of 'error' to
filename and assign it: filename = argv[ 5 ];

I think I might understand this now. For that fopen call perhaps I
should've used perror(fp); But I read in my book that there is a colon so I
'm going to go out on the limb here and say this,

perror(fp:"open error");

Does that look correct?

Bill

 

[Bill Cunningham]

Bill Cunningham said:



No. Stop going out on limbs, and read K&R2, page 248.

I looks for 248 that it prints whatever you want it to. Like another
puts. Then mentions strerror in section B3. Is perror(fp) right? Or
perror("This is wrong"); I don't want to irritate you Richard I value your
wisdom but this irritates me.

Bill

 

[Bill Cunningham]

I looks for 248 that it prints whatever you want it to. Like another
puts. Then mentions strerror in section B3. Is perror(fp) right? Or
perror("This is wrong"); I don't want to irritate you Richard I value your
wisdom but this irritates me.

Bill

It's not quite like puts I guess in the respect. I will figure it out.

Bill

 

[Bill Cunningham]

did you read the manual?

Page 248 of kandr2. Not very helpful but I'm coming to terms on this
one...I'm working on it.

Bill

 

[Bill Cunningham]

AFAIK, it's mandated by POSIX.

If perror's use isn't portable as it sounds like your saying, maybe it
shouldn't be used. My system is partly posix since linux doesn't completely
conform but I do have solaris too. If it's not totally portable I don't want
to get into the habit of using it. Atleast til I'm more experience in
portability.

Bill

 

[Keith Thompson]

I think I might understand this now. For that fopen call perhaps I
should've used perror(fp); But I read in my book that there is a colon so I
'm going to go out on the limb here and say this,

perror(fp:"open error");

Does that look correct?

No, it looks stupid. It looks like you're making wild guesses and
posting them here without the slightest effort to find the real
answer.

perhaps I should've used perror(fp);

Where on Earth did you get that idea? fp is of type FILE*; you should
know, you declared it yourself. Does perror take an argument of type
FILE*? If you don't know, how would you find out *before* making a
fool of yourself by posting here?

You're calling a standard library fucntion

LOOK IT UP. You have a copy of K&R2; use it. It explains how to use
perror.

If you had even bothered to compile it before posting (and you should
never post code here if you haven't first tried to compile it), you
would have gotten an error message from the compiler.

But I read in my book that there is a colon so I'm going to go out
on the limb here and say this,

perror(fp:"open error");

That's a syntax error. The limb just broke under you.

You read in your book that "there is a colon"? What does that even
mean? It didn't say that there's a colon in the call to perror, did
it? You saw the word "colon" somewhere, and this prompted you to add
a ':' character to a function call. Whatever thought process led you
to think that *might* be a good idea is fundamentally flawed.

Re-read what I told you two months ago today:

http://groups.google.com/group/comp.lang.c/msg/6da991ad26d30ed9

 

[Bill Cunningham]

LOOK IT UP. You have a copy of K&R2; use it. It explains how to use
perror.

Keith I looked at page 248 of kandr2. It wasn't helpful to me at all. I
am having some doubts by what others have said concerning the portability of
perror. If it's not portabile it probably shouldn't be used. Not by me until
I'm more experienced in portability.

Bill

 

[vippstar]

I am having some doubts by what others have said concerning the portability of
perror. If it's not portabile it probably shouldn't be used. Not by me until
I'm more experienced in portability.

perror is as portable as any other function in the standard library.

 

[Keith Thompson]

perror is as portable as any other function in the standard library.

Sure, but its behavior depends on the value of errno, and his implicit
assumption that fopen() sets errno on an error is not entirely
portable.

But the worst thing that can happen is a confusing error message,
perhaps something like "Error opening file: No error", or "Error
opening file: Your fly is open" (the latter is admittedly unlikely).

As it happens, fopen() does set errno on failure on the systems he
uses. It's up to him whether he wants to depend on that, or to write
maximally portable code that will work as expected on *all*
implementations. (And it may well be the case that fopen sets errno
on all existing implementations; the standard just doesn't require
it.)

The real problem is that he hasn't yet demonstrated the ability to use
it properly at all, so for now perhaps he should limit himself to a
simpler error reporting mechanism.

 

[Bill Cunningham]

What about this Keith,

FILE *fp;
if((fp=fopen("data","wb"))=='\0' {
perror("fopen");
clearerr("fopen");
exit(EXIT_FAILURE);
}

Is the string passed to perror a function name ?

Bill

 

[Default User]

On Wed, 1 Oct 2008 19:50:58 -0400, "Bill Cunningham"


Interesting style of programming you have adopted. You don't know how
to use a function so you just post any code that comes to mind.

"Don't change horses in midstream," I guess. He's done that all along.





Brian

 

[Keith Thompson]

What about this Keith,

FILE *fp;
if((fp=fopen("data","wb"))=='\0' {
perror("fopen");
clearerr("fopen");
exit(EXIT_FAILURE);
}

Is the string passed to perror a function name ?

Why are you wasting our time posting this crap?

You obviously haven't tried to compile it. I see at least one syntax
error, at least one constraint violation. (There are several other
serious errors as well, aside from the fact that you've posted a code
fragment rather than a complete program.)

Do not attempt to call a standard library function without first
reading and understanding its documentation, particularly its expected
arguments and return value. Do not post code here that you haven't at
least attempted to compile. Until that sinks in, nothing else I can
say will be of any help to you.