Review: My C FAQ Page

  • Thread starter Vijay Kumar R Zanvar
  • Start date
V

Vijay Kumar R Zanvar

Hi c.l.c.

I think it's time that I bring it up. Over the last 2-3 months,
I have been trying to build my C FAQ page which has around
40 C questions. Few of them have been adopted from c.l.c. The
same page has 3 Linux questions, and can be ignored. There
are few other sections, too, which are are a little OT here, and can
also be ignored.

(Oh My God! Flames are gonna pour in...)
 
J

Jeremy Yallop

Vijay said:
I think it's time that I bring it up. Over the last 2-3 months,
I have been trying to build my C FAQ page which has around
40 C questions. Few of them have been adopted from c.l.c. The
same page has 3 Linux questions, and can be ignored. There
are few other sections, too, which are are a little OT here, and can
also be ignored.
Click to expand...

Unfortunately a large proportion of the information on your page is
misleading or simply wrong. Here are two examples:

[Regarding http://www.geocities.com/vijoeyz/faq/c/struct_cmp.txt]
Using memcmp() to compare structures is a bad idea, because

"When a value is stored in an object of structure or union type,
including in a member object, the bytes of the object
representation that correspond to any padding bytes take
unspecified values." [6.2.6.1]

This means that memcmp may indicate that two structures are not
"equal", even though they are equal according to a memberwise
comparison. In other words, the following may print "false":

struct { int a; char b; } a = { 3, 2 }, b = a;
if (memcmp(&a, &b, sizeof a) == 0)
puts("true");
else
puts("false");

[Regarding http://www.geocities.com/vijoeyz/faq/c/sizeof_impl.txt,
where the macro
#define sizeof_type( type ) (size_t)((type*)0 + 1 )
appears]

This invokes undefined behaviour: pointer arithmetic on null pointers
is not defined. Even if the arithmetic were guaranteed to work, the
conversion from pointer to integer is implementation-defined and may
not give the results you expect.

Jeremy.
 
D

Darrell Grainger

Hi c.l.c.

I think it's time that I bring it up. Over the last 2-3 months,
I have been trying to build my C FAQ page which has around
40 C questions. Few of them have been adopted from c.l.c. The
same page has 3 Linux questions, and can be ignored. There
are few other sections, too, which are are a little OT here, and can
also be ignored.

(Oh My God! Flames are gonna pour in...)
Click to expand...

This is pretty good. The pop-ups from geocities is a little annoying but
the content of your web site is good. Once or twice I have seen replies
you received but there is no credit for who wrote the reply. Not sure why.
You kept the names of most the people who replied to your inquiries.

Question 9: when reading the answer I get the feeling some people might
assume all floating point numbers in C are IEEE 754. They are not. Maybe
put a note at the top of the answer indicating this.

Question 10: starts with 'four important differences' but only lists
three. What happened there? Additionally, I'm not sure the answer you have
posted is really the best answer.

Question 11: this is not a generic C answer. This is answer the question
for a specific compiler on a specific architecture and operating system.
That should be made clear.

Question 12: the definition of memory leak is good but the information on
how to trace a memory leak is very UNIX specific.

Question 16: when you transcribe from a text book it is proper to quote a
proper reference to the book. This would include the author(s), title,
publisher, date of publication, edition and ISBN.

Question 18: this should really be, "Why can't I increment an array like a
pointer?" since that is what the answer is dealing with.

Question 19: there is more to learn here. It shows how changes in a
function do not affect the original variable. Don't you want to know how
you CAN affect the original variable?

Question 20: this is not the most efficient way to allocate the 2-d array.
You have ROW+1 calls to malloc. It would be better to have 2 calls to
malloc. Allocate ROW pointers (one call to malloc). Allocate one large
block of memory (ROW*COLUMN big; one call to malloc). Finally, assign
memory locations inside the large block of memory to the ROW pointers (no
call to malloc). I believe your tutorial on pointers by Ted Jensen uses
the more efficient method.

Additionally, you have no error checking as you allocate the rows in the
for loop.

Question 23: not nice. First, don't start function and variable names with
underscore. Second, put some notes about how this only works if your
compiler is using ASCII characters. With that restriction and those
already part of the quiz the answer becomes much easier than what you
have.

Question 30: could use a little work. It is not immediately clear that
'#pragma once' is a specific use of the #pragma directive and that the
#pragma directive can have many implementation defined uses.

Question 37: (I'm skimming now) this could be better written. If the input
to del_node is an empty list, i.e. ptr == NULL then the first if statement
will crash.

All in all a good collection of answers to questions. Some of the
questions are more about figuring it out then the actual final answer,
e.g. question 21. I would not post the answers to these.
 
T

Thomas Matthews

Vijay said:
Hi c.l.c.

I think it's time that I bring it up. Over the last 2-3 months,
I have been trying to build my C FAQ page which has around
40 C questions. Few of them have been adopted from c.l.c. The
same page has 3 Linux questions, and can be ignored. There
are few other sections, too, which are are a little OT here, and can
also be ignored.

(Oh My God! Flames are gonna pour in...)
Click to expand...

I suggest that you direct people to Steve Summit's FAQ
first and then compliment it with stuff you haven't found
there. The C language FAQ is in my signature.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library
 
S

Sidney Cadot

Thomas Matthews wrote:

[...] The C language FAQ is in my signature.
Click to expand...

Well, the HTML version of it at least, which is out-of-date with respect
to the 1999 text version. As Steve puts it:

"Beware: as of 1999, the web-based version is somewhat out-of-date with
respect to the plain-text versions below."

Best regards,

Sidney
 
I

Irrwahn Grausewitz

Sidney Cadot said:
Thomas Matthews wrote:

[...] The C language FAQ is in my signature.
Click to expand...

Well, the HTML version of it at least, which is out-of-date with respect
to the 1999 text version. As Steve puts it:

"Beware: as of 1999, the web-based version is somewhat out-of-date with
respect to the plain-text versions below."
Click to expand...

However, the 1999 text version of the FAQ is posted monthly
to (not only) this group, last on 2004-02-01:

# Newsgroups:comp.lang.c,comp.lang.c.moderated, ...
# Subject: comp.lang.c Answers to Frequently Asked Questions ...
# Date: 1 Feb 2004 11:00:08 GMT
# Lines: 6929
# Expires: 3 Mar 2004 00:00:00 GMT
# Message-ID: <[email protected]>

The same version is alternatively available at:

http://www.faqs.org/faqs/C-faq/faq/

(I changed the FAQ-link in my signature to above one,
until the HTML version gets updated.)

Regards
 
S

Sidney Cadot

Irrwahn said:
[...]
Click to expand...
However, the 1999 text version of the FAQ is posted monthly
to (not only) this group, last on 2004-02-01:
Click to expand...

Yes, and the 5-year discrepancy doesn't seem to strike many people here
as particularly bothersome, I noticed.

Best regards,

Sidney
 
P

pete

Sidney said:
Irrwahn said:
[...]
Click to expand...
However, the 1999 text version of the FAQ is posted monthly
to (not only) this group, last on 2004-02-01:
Click to expand...

Yes, and the 5-year discrepancy doesn't seem to strike
many people here as particularly bothersome, I noticed.
Click to expand...

The fundamental problem with maintaining the FAQ,
is that it's a lot of work.
Vijay Kumar R Zanvar has taken the correct approach.
He wrote a FAQ, and posted it.
 
S

Sidney Cadot

pete said:
Sidney said:
Irrwahn Grausewitz wrote:

[...]
Click to expand...
However, the 1999 text version of the FAQ is posted monthly
to (not only) this group, last on 2004-02-01:
Click to expand...

Yes, and the 5-year discrepancy doesn't seem to strike
many people here as particularly bothersome, I noticed.
Click to expand...


The fundamental problem with maintaining the FAQ,
is that it's a lot of work.
Click to expand...

Well, that's one explanation for the 5-year discrepancy.
Vijay Kumar R Zanvar has taken the correct approach.
He wrote a FAQ, and posted it.
Click to expand...

Yes, and just griping about it (like I do) isn't, you seem to imply.
Please spell it out for me, I'm terrible at reading between the lines.

I say, first things first. Let's first establish there /is/ a problem.
What surprises me is that many here cannot get themself to acknowledge
even that (or so it seems).

After that, it's best if we can mend the current situation, by improving
the current FAQ (with Steve's help or permission).

If that turns out to be impossible, then an effort /could/ be started to
produce an independent FAQ, if the community thinks it would be
worthwhile. I, for one, would be quite willing to invest some time to
write some questions and answers, and also to do some review work. But
it's too early to have a head-count.

Best regards,

Sidney
 
P

pete

Sidney said:
Sidney said:
Irrwahn Grausewitz wrote:


[...]

However, the 1999 text version of the FAQ is posted monthly
to (not only) this group, last on 2004-02-01:

Yes, and the 5-year discrepancy doesn't seem to strike
many people here as particularly bothersome, I noticed.
Click to expand...


The fundamental problem with maintaining the FAQ,
is that it's a lot of work.
Click to expand...

Well, that's one explanation for the 5-year discrepancy.
Vijay Kumar R Zanvar has taken the correct approach.
He wrote a FAQ, and posted it.
Click to expand...

Yes, and just griping about it (like I do) isn't, you seem to imply.
Please spell it out for me, I'm terrible at reading between the lines.
Click to expand...

It's something like that.
Vijay Kumar R Zanvar is addressing the fundamental problem directly.
Who else besides him, should be working on a new FAQ ?
 
V

Vijay Kumar R Zanvar

A realistic attitude is good.
Click to expand...

As you can make out from my line above, my English is
still in improving phase. I did not understand your
statement. Is it a compliment?

This one
http://www.geocities.com/vijoeyz/faq/knr/1/swap.txt
is the opposite of Summits FAQ:
The first swap has unsequenced multiple side-effects and the
other two swaps, have overflow problems for signed ineger types.

http://www.eskimo.com/~scs/C-faq/q10.3.html
Click to expand...

I will provide the above link, too.

Thank You.
 
V

Vijay Kumar R Zanvar

[..]
Unfortunately a large proportion of the information on your page is
misleading or simply wrong. Here are two examples:
Click to expand...

I understand your point. This is my first ever attempt in doing such
work, and moreover, my industry experience is mere 11 months old.
I had flunked out of the college for 2 years, you see!
[Regarding http://www.geocities.com/vijoeyz/faq/c/struct_cmp.txt]
Using memcmp() to compare structures is a bad idea, because

"When a value is stored in an object of structure or union type,
including in a member object, the bytes of the object
representation that correspond to any padding bytes take
unspecified values." [6.2.6.1]

This means that memcmp may indicate that two structures are not
"equal", even though they are equal according to a memberwise
comparison. In other words, the following may print "false":

struct { int a; char b; } a = { 3, 2 }, b = a;
if (memcmp(&a, &b, sizeof a) == 0)
puts("true");
else
puts("false");
Click to expand...

I got it. I will explictly mention this point in the FAQ page.
[Regarding http://www.geocities.com/vijoeyz/faq/c/sizeof_impl.txt,
where the macro
#define sizeof_type( type ) (size_t)((type*)0 + 1 )
appears]

This invokes undefined behaviour: pointer arithmetic on null pointers
is not defined. Even if the arithmetic were guaranteed to work, the
conversion from pointer to integer is implementation-defined and may
not give the results you expect.
Click to expand...

How can this be implemented, then?
 
V

Vijay Kumar R Zanvar

Hi.


Despite the problems pointed elsewhere in this NG, I liked DMR's answer to
your One Question...
Click to expand...

With due respect to Dennis M Ritchie, that day a discussion -- "Whether
Dennis Ritchie is alive or not?" -- among my colleagues, here, aroused.
So I Googled, found out his homepage and email. It was just within 2
hours that his reply came. That was my day!
 
I

Irrwahn Grausewitz

Sidney Cadot said:
Irrwahn said:
[...]
Click to expand...
However, the 1999 text version of the FAQ is posted monthly
to (not only) this group, last on 2004-02-01:
Click to expand...

Yes, and the 5-year discrepancy doesn't seem to strike many people here
as particularly bothersome, I noticed.
Click to expand...

Well, I, for one, agree with the points you made elsethread
about outdated information in the FAQ, and also noticed and
appreciate your message to Steve Summit.

Maybe it would be a good idea to maintain an (unofficial)
supplemental update in a fashion that makes it easy
to incorporate it in the FAQ [1], once Steve updates it
or explicitly gives permission to someone else to do so.
This document could be submitted periodically to the group
(ideally synchronized with the original FAQ posting), so
that proposals or comments can easily be posted as follow-ups.
That's IMHO better than having several writings (no matter
how excellent they are) from several people scattered
all over the web. I think it's not desirable to have N
different, incomplete clc-FAQ-lists floating around.

Oh, and: sorry, no, I'm not volunteering for the job,
but I'd like to contribute, if possible. :-}


[1] A little bit like the collection of DRs to the
C standard, until a new TC is released.


Regards
 
V

Vijay Kumar R Zanvar

[..]
C FAQs - http://www.geocities.com/vijoeyz/faq/
This is pretty good. The pop-ups from geocities is a little annoying but
the content of your web site is good.
Click to expand...

Thank you.
Once or twice I have seen replies
you received but there is no credit for who wrote the reply. Not sure why.
You kept the names of most the people who replied to your inquiries.
Click to expand...

One name missing in http://www.geocities.com/vijoeyz/faq/c/entry.txt
is "pzinnc296". Probably, I found it to be little awkard. This point is
noted, as well.
Question 9: when reading the answer I get the feeling some people might
assume all floating point numbers in C are IEEE 754. They are not. Maybe
put a note at the top of the answer indicating this.

Done.

Question 10: starts with 'four important differences' but only lists
three. What happened there? Additionally, I'm not sure the answer you have
posted is really the best answer.
Click to expand...

Oops! I didn't notice how I missed the fourth point. Yes, I do think
the answer is not at its best. I think I can add some more points.
Question 11: this is not a generic C answer. This is answer the question
for a specific compiler on a specific architecture and operating system.
That should be made clear.

Done.

Question 12:
[..]

Question 16: when you transcribe from a text book it is proper to quote a
proper reference to the book. This would include the author(s), title,
publisher, date of publication, edition and ISBN.
Click to expand...

Is it allowed?
Question 18: this should really be, "Why can't I increment an array like a
pointer?" since that is what the answer is dealing with.

Marked.

Question 19: there is more to learn here. It shows how changes in a
function do not affect the original variable. Don't you want to know how
you CAN affect the original variable?
Click to expand...

I am not able to interprete your last point. Can you throw some more
light?
Question 20: this is not the most efficient way to allocate the 2-d array.
You have ROW+1 calls to malloc. It would be better to have 2 calls to
malloc. Allocate ROW pointers (one call to malloc). Allocate one large
block of memory (ROW*COLUMN big; one call to malloc). Finally, assign
memory locations inside the large block of memory to the ROW pointers (no
call to malloc). I believe your tutorial on pointers by Ted Jensen uses
the more efficient method.
Click to expand...

Whatever I write, there always seems to be better solution than it!
Additionally, you have no error checking as you allocate the rows in the
for loop.
Click to expand...

I will add error checking.
Question 23: not nice. First, don't start function and variable names with
underscore. Second, put some notes about how this only works if your
compiler is using ASCII characters. With that restriction and those
already part of the quiz the answer becomes much easier than what you
have.
Click to expand...

Two points noted.
Question 30: could use a little work. It is not immediately clear that
'#pragma once' is a specific use of the #pragma directive and that the
#pragma directive can have many implementation defined uses.

Question 37: (I'm skimming now) this could be better written. If the input
to del_node is an empty list, i.e. ptr == NULL then the first if statement
will crash.
Click to expand...

if ( ptr && ptr -> next )

should solve it.
All in all a good collection of answers to questions. Some of the
questions are more about figuring it out then the actual final answer,
e.g. question 21. I would not post the answers to these.
Click to expand...

Thank you for mailing me personally, also.
 
T

Tristan Miller

Greetings.

Vijay Kumar R said:
I think it's time that I bring it up. Over the last 2-3 months,
I have been trying to build my C FAQ page which has around
40 C questions. Few of them have been adopted from c.l.c. The
same page has 3 Linux questions, and can be ignored. There
are few other sections, too, which are are a little OT here, and can
also be ignored.
Click to expand...

It seems that most of the items you have on your list are neither
frequently-asked (e.g., "Is it OK to say sizeof ( main );?") nor questions
(e.g., "Code review.", "Program to add/subtract two integers without using
+ or - ."). Some of the items (e.g., "Did you know this?") have titles
which are so vague as to be completely meaningless, and useless to anyone
using your site as a resource for C questions.

I don't object in principle to what you're trying to do here, but I think
the list needs a lot of work and cleanup, and almost certainly a retitling.
It's not a FAQ, so try to think of a more descriptive name. Also, it would
be helpful if you could put the "answers" below the "questions" instead of
a separate page, or at the very least repeat the "question" on each
"answer" page to provide some context.

I was also going to point out that there are a number of factual errors and
misleading statements in your document, but I see that others have already
mentioned these.

Regards,
Tristan
 
A

Arthur J. O'Dwyer

[Please don't snip attributions]
I got it. I will explictly mention this point in the FAQ page.
Click to expand...

But then, who uses 'memcmp' to compare _structs_ anyway? That
just seems like asking for unspecified behavior! Much better to
write

if (a.a == b.a && a.b == b.b)
puts("true");
else puts("false");

if you really absolutely _have_ to compare structs for some
unknown reason.

[Regarding http://www.geocities.com/vijoeyz/faq/c/sizeof_impl.txt,
where the macro
#define sizeof_type( type ) (size_t)((type*)0 + 1 )
appears]

This invokes undefined behaviour: pointer arithmetic on null pointers
is not defined. Even if the arithmetic were guaranteed to work, the
conversion from pointer to integer is implementation-defined and may
not give the results you expect.
Click to expand...

How can this be implemented, then?
Click to expand...

Duh.

#define sizeof_type( type ) (sizeof (type))

This implementation has the added benefit that

foo bar;
sizeof_type(bar);

compiles and works just as well as

sizeof_type(foo);

which is a feature not supplied by your buggy "implementation."

-Arthur
 
S

Sidney Cadot

pete wrote:

It's something like that.
Vijay Kumar R Zanvar is addressing the fundamental problem directly.
Who else besides him, should be working on a new FAQ ?
Click to expand...

As I explained in my previous post, I think you're jumping the gun.
We're not at the stage of having to answer this question by a long way,
and we will hopefully avoid getting there.

Best regards,


Sidney
 

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

Similar Threads

Suggestion: allow multiple updaters of the C FAQ 3
Chatbot 0
I'm tempted to quit out of frustration 1
Review(2): My C FAQ Page 1
Connected SQLite to my java program but information are not submitted 2
Sending data from web page to Raspberry Pi 0
A Brief Review of jQuery 1.5 13
The C FAQ 94

Members online

No members online now.
Total: 2,462 (members: 2, guests: 2,460)
Robots: 127

Forum statistics

Threads
474,139
Messages
2,570,805
Members
47,352
Latest member
DianeKulik

Latest Threads

Top