George said:On Fri, 28 Nov 2008 17:23:53 -0800, Barry Schwarz wrote:
#include <stdio.h>
#include <stdlib.h>
#define PATH "george.txt"
#define NUMBER 100
#define MAXFMTLEN 2000
int main(void)
{
FILE *fp;
char pattern[MAXFMTLEN];
char lbin[NUMBER];
char line[MAXFMTLEN];
if ((fp = fopen(PATH, "r")) == NULL ) {
fprintf(stderr, "can't open file\n");
exit(1);
}
sprintf(pattern, "%*s %40s", NUMBER-1);
This code has been severely mangled. As it stands now, you are
missing two arguments and invoke undefined behavior. But this is NOT
what you want.
Look at your previous code for constructing the format string in
pattern. (Or make life easy on yourself and initialize pattern with a
string literal.)
I want to ignore the first number in each line.
Then go back to something approaching what you had in previous versions
of this code:
sprintf(pattern, "%%*s %%%ds", NUMBER-1);
...error? In general, step through the code with a debugger or add
debugging printf statements so you can determine exactly where the
error occurs.
Can't do it. Gdb is my only tool right now for debugging, and it is a
hardship.
Then insert debugging printf() calls.
...One other question here:
if ((fp = fopen(PATH, "r")) == NULL ) {
fprintf(stderr, "can't open file\n");
exit(1);
}
if(ferror(fp))
perror(PATH);
If there is an error in opening the file, will execution go through both of
these?
Look at the code that executes if fopen fails. Something very special
happens on the second statement (ignoring the portability issue).
I see nothing remarkable in returning one. Under what circumstances does
ferror do something?
The program exit()s immediately if fopen() returns a null pointer.
Therefore, the stream is guaranteed to not be in an error state by the
time that ferror() is called.. As a result, ferror() can never return a
non-zero value, and therefore perror() never gets executed. I doubt that
this is what you intended.
Do to George's excessive trimming, some intervening code was omitted.
His call to ferror followed a call to fgets. The point I was trying
to get him to realize was that if fopen failed his program called exit
and consequently the call to ferror would never be executed.
Then insert debugging printf() calls.
Have you considered just not babbling at all? Surely that would be
better than a "balance" between sense and nonsense.
What event would I be testing for? If C calls windows for a file on this
my only machine, it's gonna get it. Would these events be more appropriate
to the circumstances of a sysadmin?
George said:Usenet, for me, is a multicultural and multilingual Erscheinung.
The above sentence is not comprehensible to some. Oh well.
I think a legitimate criticism of clc for the last few years is that it has
been "fair and balanced," in particular, where *you* tip the scales.
George said:What event would I be testing for? If C calls windows for a file on this
my only machine, it's gonna get it. Would these events be more appropriate
to the circumstances of a sysadmin?
It was a dutch matter.
When I'm given to be cryptic, I don't make much
sense to most people.
It's not unlike one of my expressions for necessary
success, where I tell people, "well, let's return zero and get out of
here."
I've never had someone say, "are you alluding to C?", but they do register
that I want to leave pronto.
You can say that babbling is OT, but I think to balance it by categorically
addressing C in other posts.
>
> so if I emailed this to my Dutch-speaking relatives they'd
> be able to decode it for me? I Strongly suspect not.
For most of my career, include all of the last 12 years, I've written
programs that run in an xterm command line window (comparable to a
console window in Windows), so there's no problem using printf() to
display message. As a result, I tend to forget the needs of other types
of programs. Sorry!
If I understand you correctly (I'm not sure that I do), you're not
working in such an environment, and there's some reason why you can't
open a log file on your machine. In that case, the corresponding GUI
solution would be pop up a message box. The key point is to get the
information about what's going on in your program out to where you can
see it; choosing the appropriate medium to use for this communication is
just a matter of convenience.
What events should you look for? That's where your knowledge of the
program comes in. My own most fundamental rule for debugging programs is
that I must figure out precisely why it is that I don't expect the bug
to occur. I must have an argument, with a series of premises assumed to
be true, that reaches the conclusion that the bug should not be
happening. Since the bug IS happening (and I don't even reach this point
in debugging until after I've verified the existence of the bug), then
here's only two possibilities: either the argument is invalid, or at
least one of the premises is false. I need to determine which.
I review the argument's validity carefully; if it's not valid, then the
bug apparently exploited a hole in that argument, this will often tell
me what I need to do to find the bug.
If the argument appears valid, then I test each of the premises for the
argument. That's where a code review, use of a debugger, or use of
debugging printf()s or fprintf()s or message boxes comes in. I place
them to give me information about whether my assumptions about the
behavior of the code are correct.
I usually find that one of the premises is false. Sometimes that
immediately tells me what's wrong. More often, I need to apply this
procedure recursively: I now need to determine why I incorrectly thought
that the premise should be true. However, the recursion always
terminates eventually.
Thanks for your comment. It seems relevant to the fella who's asking about
fclose elsethread. Making a log makes sense. I think a lot of C
programming overtests for failure, in particular, when the platform and
target is one's own PC as opposed to a memory-mapped device.
The execution in fortran programs is discussed in terms of recursion, which
I didn't read in yesterday's reading of chp 5 of 1256.pdf. Of course,
you're describing the thought process as it works for you.
gdb.exe has been very disapointing for me as a tool as compared to the
visual debuggers I grew accustomed to back when I could afford M$. Now I
call printf a poor man's debugger.
I've heard rumors that they're trying to make a visual version of gdb with
the bells, whistles and ability to step into/over. I won't hold my breath,
though.
--
If you are running Linux, then you can use DDD, which is a visual
version of gdb.
And now, before the regulars interject, I would like to point out that
debuggers are off topic in this forum.
Chad
Thanks for your comment. It seems relevant to the fella who's asking about
fclose elsethread. Making a log makes sense. I think a lot of C
programming overtests for failure, in particular, when the platform and
target is one's own PC as opposed to a memory-mapped device.
The execution in fortran programs is discussed in terms of recursion, which
I didn't read in yesterday's reading of chp 5 of 1256.pdf. Of course,
you're describing the thought process as it works for you.
gdb.exe has been very disapointing for me as a tool as compared to the
visual debuggers I grew accustomed to back when I could afford M$.
Now I call printf a poor man's debugger.
I've heard rumors that they're trying to make a visual version of gdb with
the bells, whistles and ability to step into/over.
I won't hold my breath though.
If you are running Linux, then you can use DDD, which is a visual
version of gdb.
George said:Thanks for your comment. It seems relevant to the fella who's asking about
fclose elsethread. Making a log makes sense. I think a lot of C
programming overtests for failure, in particular, when the platform and
target is one's own PC as opposed to a memory-mapped device.
The execution in fortran programs is discussed in terms of recursion, which
I didn't read in yesterday's reading of chp 5 of 1256.pdf. Of course,
you're describing the thought process as it works for you.
I think you're talking at cross purposes. James Kuyper is saying
IF you have a bug AND gdb is no help to you THEN consider using
printf(). You seem to doubt you have a bug.
in my experience most C programmers don't make enough checks for
failure. What do you mean "memory-mapped device"? Why don't
you care if the programs you run on your PC are correct or not?!
I've just recently used a line based debugger (as opposed to an IDE
based one) I was quite agreeably surprised how easy to use it was.
whatever. I consider a log of program activity pretty
well indespensible.
I'm *really* surprised gdb can't do this already.
I've been using an ancient Sun line based debugger
and *that* did step into and step over.
read the documentation
I'm not sure what that comment means, since I'm not sure what it is that
Fortran describes in term of recursion. n1256.pdf uses the concept of
recursion in many places, but there's only one use of the term in the
first five sections: 5.1.1.2p4.
I suspect that you're thinking in terms of recursive function calls,
which section 6.5.2.2p11 requires to be supported in C. But I was using
the term in a broader sense, like most of the other uses of that term in
the standard, few of which involve function calls.
Let me give a simplified example. I recently investigated a bug where
there were missing packets from the output files of one of my programs.
I started by constructing an argument why the packets should not be
missing. Several of the key premises of that argument were based upon
certain assumptions about the contents of the input files. Because those
were the easiest things to check, they were also the first things I
checked (despite direct orders from upper management that I was not
supposed to "waste" any time investigating the "impossibility" that
those input files were defective). What I found was that the packets
were missing from my program's output for the simple reason that they
were missing from it's inputs; we knew from an alternative source that
those packets should have been there.
At this point, recursion kicks in. Having established that my original
argument was incorrect because one of it's premises was false, my next
step was to consider why I had expected those files to have those two
files to contain the same packets. It was because I had been told,
third-hand, that the alternative source of those packets was created by
processing the primary source. Therefore, there shouldn't be any packets
in the alternative source that weren't in the primary source. I decided
that I needed first hand information, rather than third-hand. It turns
out that neither of the two different sources we were looking at were
produced from the other. Both were produced from the same input files by
different programs.
Once again, recursion kicked in. Having established that the two
different programs were producing inconsistent outputs from the same
input files, it was time to consider why those programs were expected to
produce consistent outputs. I didn't handle that part of the
investigation, and don't know any details about it, because those
programs were someone else's responsibility. However, at my request that
person did investigate, and has reported discovering a bug which should
be fixed sometime in January.
I hope that makes it clearer what I meant about the debugging process
being recursive.
/* An example of overtesting for failure */
f = fopen( filename, "r" );
if( f == NULL )
if( f == NULL && f == NULL )
if( f == NULL )
if( really_really_NULL( f )) {
perror( filename );
exit( EXIT_FAILURE );
}
Although I've never actually seen that in practice.
<dripping sarcasm>I agree that people overtest for failure.
</dripping sarcasm> After all, it's not humanly possible to
inadvertently invoke "my-prog fooo" when you know that
the file foo exists and is the file which doesn't contain
important information while the file fooo sitting in the
same directory contains vital data that cannot be modified
by my-prog. Oops, is that a typo? Did I add an extra 'o' and
fopen failed and the program segfaulted, but only after
destroying months of work. Well, it's a good thing I
saved 10 seconds of time when I was writing the code and
didn't bother checking the return value of a system call!
Phew, 10 seconds of precious programmer time saved!
Checking the return value of a system call is not just
a good idea...it's the law! It doesn't matter if it's
your own PC or someone else's. It doesn't matter if
you "know" that fclose will always succeed (because
you're wrong). I don't know exactly what you mean by
"overtesting for failure", but I suspect it means
that you are a complete idiot.
George said:Not every intermediate stage of a program is bug-infested.
George said:[...]read the documentation
Can't do it. The words sting like "read the Book of Mormon."
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.