Hi,

I created a C program, to read the structure of a database file,
provided at the beginning of the db file, after which the data records
follow. Actually the db file is a simple character text file I
created, and I just ran a C program to extract the info. I got
"Segmentation Fault".I have been trying to debug, somene had mentioned
to me that the S.F.error meansa you are trying access memory which is
inaccessible. My question is normally I will not know the meaning of
an error like this, so I would try to debug 2-3 times then move on to
another program. Well is the trick of learning to program (beyond a
basic course - ie knowing if,while,for,arrays etc conceptually), just
say take up K&R, type in all the programs and see the errors. And
learn "error meanings" by experience from the various executions?

Also, I find working out the logic for a programming question and then
writing the code and then keying in - I mean the concept is simple but
coding means wading through a lot of text, if I'm solving something
new, and then I'm in a different frame of mind. That is why I think
that after knowing the basic programming constructs and solving a few
problems based on them programmatically, one should black box like
execute several ready made programs(ie just type them in, don't work
em out), and then move onto something else, say another language. What
do uyou say???(I don't know how folks just read a program question and
immediately code :) must be gifted!)

grumple wrote:
> Hi,
> 
> I created a C program, to read the structure of a database file,
> provided at the beginning of the db file, after which the data records
> follow. Actually the db file is a simple character text file I
> created, and I just ran a C program to extract the info. I got
> "Segmentation Fault".I have been trying to debug, somene had mentioned
> to me that the S.F.error meansa you are trying access memory which is
> inaccessible.

The majority of segfaults are caused by null pointers in your code. 
Since you can't legally dereference (read or write contents of) a null 
pointer, the OS will throw a memory protection violation message of some 
sort (segfault or other) when your program tries.  So start by looking 
for uninitialized pointers, etc.

>               My question is normally I will not know the meaning of
> an error like this, so I would try to debug 2-3 times then move on to
> another program.

If you're running it through a debugger, and not understanding what 
you're seeing, then you're not debugging.  You're just doing the 
programming equivalent of watching the pretty lights.  Debugging is the 
process of removing bugs from a program.

>                  Well is the trick of learning to program (beyond a
> basic course - ie knowing if,while,for,arrays etc conceptually), just
> say take up K&R, type in all the programs and see the errors. And
> learn "error meanings" by experience from the various executions?

The programs in K&R, and other programming texts, should already be 
error-free... except where the text is leading you through error 
discovery, demonstrating a point, or where it's a code snippet rather 
than a complete program.  If you type one in, compile it and it 
segfaults on run, then odds on you've mistyped something.

> Also, I find working out the logic for a programming question and then
> writing the code and then keying in - I mean the concept is simple but
> coding means wading through a lot of text, if I'm solving something
> new, and then I'm in a different frame of mind. That is why I think
> that after knowing the basic programming constructs and solving a few
> problems based on them programmatically, one should black box like
> execute several ready made programs(ie just type them in, don't work
> em out), and then move onto something else, say another language. What
> do uyou say???(I don't know how folks just read a program question and
> immediately code :) must be gifted!)

If you're just typing in code samples from a book and running them, 
without figuring out what they do or how, then you learn nothing. 
What's the point in that?  You should be working through the code 
samples as teaching exercises.  Figure out what each piece of it does, 
how, why, and try to think of some alternate uses for the techniques 
presented.

You can't learn programming by rote.  It takes some thinking.


-- 
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"

Hi,
Corey Murtagh <emonk@slingshot.co.nz.no.uce> wrote in message 

Wrt below what I'm asking is how to know the meaning of an error in
this case "Segmentation Fault". In this case you have told me. but
normally K&R and other books do not list error messages and their
meanings. How to know the meaning then? Which manual?

Thx
grumple

> The majority of segfaults are caused by null pointers in your code. 
> Since you can't legally dereference (read or write contents of) a null 
> pointer, the OS will throw a memory protection violation message of some 
> sort (segfault or other) when your program tries.  So start by looking 
> for uninitialized pointers, etc.
> 
> >               My question is normally I will not know the meaning of
> > an error like this, so I would try to debug 2-3 times then move on to
> > another program.
>

grumple wrote:
> Hi,
> Corey Murtagh <emonk@slingshot.co.nz.no.uce> wrote in message 
> 
> Wrt below what I'm asking is how to know the meaning of an error in
> this case "Segmentation Fault". In this case you have told me. but
> normally K&R and other books do not list error messages and their
> meanings. How to know the meaning then? Which manual?

Google is your friend.  Enter "segmentation fault definition" into 
Google and see what comes back.  Repeat for any other system error 
message that you don't understand.

You might also find the FOLDOC useful, or at least interesting:

   http://www.foldoc.org

-- 
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"