Review: My C FAQ Page

[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...)

--
Vijay Kumar R Zanvar
C FAQs - http://www.geocities.com/vijoeyz/faq/

[Jeremy Yallop]

Vijay Kumar R Zanvar wrote:

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.

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.

[pete]

Vijay Kumar R Zanvar wrote:

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

A realistic attitude is good.

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

--
pete

[José de Paula]

Em Fri, 06 Feb 2004 16:17:08 +0530, Vijay Kumar R Zanvar escreveu:

Hi c.l.c.

Hi.
Vijay Kumar R Zanvar
C FAQs - http://www.geocities.com/vijoeyz/faq/

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

--
Quidquid latine dictum sit altum viditur

[Darrell Grainger]

On Fri, 6 Feb 2004, Vijay Kumar R Zanvar wrote:

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...)

--
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. 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.

--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vi************@whitehouse.gov

[Thomas Matthews]

Vijay Kumar R Zanvar wrote:

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...)

--
Vijay Kumar R Zanvar
C FAQs - http://www.geocities.com/vijoeyz/faq/

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

[Sidney Cadot]

Thomas Matthews wrote:

[...] The C language FAQ is in my signature.

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

[Irrwahn Grausewitz]

Sidney Cadot <si****@jigsaw.nl> wrote:

Thomas Matthews wrote:

[...] The C language FAQ is in my signature.

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."

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: <20*********************@eskimo.com>

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
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Sidney Cadot]

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.

Best regards,

Sidney

[pete]

Sidney Cadot wrote:

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.

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.

--
pete

[Sidney Cadot]

pete wrote:

Sidney Cadot wrote:

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.

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

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.

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

[pete]

Sidney Cadot wrote:

pete wrote:

Sidney Cadot wrote:

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.

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

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.

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.

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 ?

--
pete

[Vijay Kumar R Zanvar]

(Oh My God! Flames are gonna pour in...)
A realistic attitude is good.

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

I will provide the above link, too.

Thank You. --
pete

--
Vijay Kumar R Zanvar

[Vijay Kumar R Zanvar]

[..]

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

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");

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.

How can this be implemented, then?
Jeremy.

--
Vijay Kumar R Zanvar

[Vijay Kumar R Zanvar]

Hi.

Vijay Kumar R Zanvar
C FAQs - http://www.geocities.com/vijoeyz/faq/
Despite the problems pointed elsewhere in this NG, I liked DMR's answer to
your One Question...

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!
--
Quidquid latine dictum sit altum viditur

[Irrwahn Grausewitz]

Sidney Cadot <si****@jigsaw.nl> wrote:

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.

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
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[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.
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.

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.

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.

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?

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.

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.

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.

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.

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.

Thank you for mailing me personally, also.
--
Vijay Kumar R Zanvar

[Tristan Miller]

Greetings.

In article <bv*************@ID-203837.news.uni-berlin.de>, Vijay Kumar R
Zanvar wrote:

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.

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

--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= <> In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you

[Arthur J. O'Dwyer]

On Sun, 8 Feb 2004, Vijay Kumar R Zanvar wrote:

[Please don't snip attributions]

Unfortunately a large proportion of the information on your page is
misleading or simply wrong. Here are two examples: 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");

I got it. I will explictly mention this point in the FAQ page.

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.

How can this be implemented, then?

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

[Jeremy Yallop]

Vijay Kumar R Zanvar wrote:

[I wrote:]

[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.

How can this be implemented, then?

It can't, in general, I think. It can't be done in the way you
suggest because there's no way to form type names representing
'pointer to T' from type names representing type T (hence the
restrictions on the type argument to va_arg). It /can/ be implemented
in GNU C using statement expressions, but there's no need to implement
it at all given that sizeof is already part of the language.

Jeremy.