Or you could attempt to write better code, that does not rely on hard-coded constants. Use the sizeof() compiler operator to get a fix on the size of arrays. Also drill into your mind that array indexing in C begins at 0, not 1.

For this declaration:
the legal indexes for 'usr' range from 0 through 7.

This code:
could be better written to be:
You need to reference the man-pages before you blindly go using the C library functions. There's information that will help you understand the expected behavior when calling a function, such as fgets().

As mentioned earlier, you can use 'gdb' or the GUI front-end 'ddd' for debugging purposes. Compile your code with the -g option, and never (as suggested earlier) use the -O2 option until you are complete with debugging your task.

1 members found this post helpful.

I take it all back. Just looked into the C# language and you can keep it. I'll stick with C any day.

dwhitney67:

D'oh!! I knew that! Shit! Why can't I function when it's 42C and there's no air-con??

Yeah, you are dead right, but I DO actually do this. I have one of these O'Reilly concise guides to the syntax, but the typography used to me at least is completely impenetrable. It's total gobbledegook which bears no resemblance to the code you actually see deployed in practice. It is so far removed from reality that it is far worse, in fact, than useless!

How about man pages (using the man command)?

If you want to remove "\n", you can use the strchr method instead of messing with subscripts. It returns a pointer to its exact location in the string (or NULL if there isn't any) so you'd simply dereference the pointer and replace \n with \0.

I would recommend "C Primer Plus" by Stephen Prata for an excellent introduction to C basics.

OMG! They are the worst of the lot!

Until you learn to learn from the man pages, your fate will be as bad as that of Lot's wife.

+1e9

I think the man pages are of limited use until you know more or less what you are after. I really wouldn't recommend learning any serious programming language that way.

Reading (or listening to a foreign yet unlearned language for that matter) is quite a useful experinece - when done stubbornly and persistently it helps creating in one's mind a "cross-reference table" which in the end is the fundamental prerequisite of getting "the whole picture".

As a number of participants in this forum have shown, they have problems in comprehension in the first place.

If a manpage looks unclear, a motivated reader should first of all has to concentrate and write down what is unclear, and then has to try to find answers to the written down issues/questions.

This is what I call mental work and discipline opposed to mental laziness and sloppiness.

I don't think anyone here is recommending using that as the way to learn a programming language. I would recommend it as a way to learn a certain subset of the C subject matter: the behavior of library functions. Nothing more, nothing less. For this, the man pages are usually quite excellent.

I will post a typical example of precisely what my beef is with these function summaries shortly...

OK, here's the kind of thing we run into all the time. For you people, it's no doubt crystal clear what the following means:-

"Block read and write functions.

size_t fwrite (const void *buf, size_t sz, size_t n, FILE *fp );

Writes n objects of length sz from the buffer addressed by buf to the file."

Not much use to me, though. OK, so the author of this book (it's the C Pocket Reference by O'Reilly) has explained what "n", "sz" and "buf" mean, but has neglected to define "size_t" and "const void". Furthermore the expression "FILE *fp" is confusing. It looks like two seperate tokens, the second of which must contain an asterisk. In practice, however, and taking from my earlier example, "FILE *fp" could be something as simple as just "target".

Also in these concise guides and cheat sheets, they typically neglect to include what the function returns when it succeeds and when it fails. fopen() and fclose() don't return the same value when they succeed and when they fail. This should form part of the function summary IMHO. Also there ought to be a note of any particular quirks you need to know about, for example like with fgets() when it leaves a '\n' behind in the buffer.

OR is it just me? Am I nuts?

So, just read again what the manpage says and answer the question I've asked here "countless" number of times: "what is the very first thing you do not understand (in the above manapage excerpt) ?".