Other issues with the FAQ

[jacob navia]

1: The section about "main" doesn't mention that
main has an automatic zero return value.
I do not agree with this part of the standard but
it should be mentioned in the FAQ anyway.
Question 11.12b

2: The remarks about "printf" being undefined and the
Microsoft compiler are not reproducible. Personally I
never saw a microsoft compiler like that. In any case
this is obsolete now and should be discontinued...

3: The question about rounding (14.6) doesn't mention the
standard functions lround, round, and the others defined
in the standard.

4: There are too many references to MSDOS but almost none
to Win32 even if it has almost 10 years of age. The FAQ could
get rid of all those (MSDOS is almost gone as an active devlopment
platform. For instance the references to the 64K limit, (19.23) etc
could very well be dropped They are 10 years obsolete!
The same for the DGROUP question (19.24), and question 19.40
stil speaking about TSR's!!!
5: The successor of C "could" be called "D", since Walter Bright has
designed a language that claims this (www.digitalmars.com). This
is an issue in question 20.38

 

[Dan Pop]

1: The section about "main" doesn't mention that
main has an automatic zero return value.

Most likely because it doesn't:

fangorn:~/tmp 485> cat test.c
#include <stdio.h>

int main()
{
printf("Hello world\n");
}
fangorn:~/tmp 486> gcc -ansi -pedantic test.c
fangorn:~/tmp 487> ./a.out
Hello world
fangorn:~/tmp 488> echo $status
12

I do not agree with this part of the standard but
it should be mentioned in the FAQ anyway.
Question 11.12b

Read this until it penetrates your thick skull: it is the c.l.c FAQ,
NOT the C99 FAQ.

2: The remarks about "printf" being undefined and the
Microsoft compiler are not reproducible. Personally I
never saw a microsoft compiler like that.

Other people obviously did. The FAQ is not written for your egocentric
universe, where other people's experiences don't matter.

In any case
this is obsolete now and should be discontinued...

Sez who?

3: The question about rounding (14.6) doesn't mention the
standard functions lround, round, and the others defined
in the standard.

Most likely because the standard doesn't define them:

fangorn:~/tmp 492> cat test.c
#include <math.h>

int main()
{
round();
return 0;
}
fangorn:~/tmp 493> gcc -c -ansi -pedantic -Wall test.c
test.c: In function `main':
test.c:5: warning: implicit declaration of function `round'

Have I included the wrong header? Have I invoked gcc in non-conforming
mode? Anything wrong with my headers?

4: There are too many references to MSDOS but almost none
to Win32 even if it has almost 10 years of age. The FAQ could
get rid of all those (MSDOS is almost gone as an active devlopment
platform. For instance the references to the 64K limit, (19.23) etc
could very well be dropped They are 10 years obsolete!

A reality check shows plenty of MSDOS-related questions in the newsgroup
but very few Win32-related ones. Windows programmers seem to be quite
aware that their stuff belongs to comp.os.ms-windows.programmer.win32.
It's mostly Unix and MSDOS programmers that seem to think that c.l.c is
the right place for their stuff.

The same for the DGROUP question (19.24), and question 19.40
stil speaking about TSR's!!!

Yeah, it's true that TSR fans went somewhere else lately...

5: The successor of C "could" be called "D", since Walter Bright has
designed a language that claims this (www.digitalmars.com). This
is an issue in question 20.38

There were at least half a dozen languages named D by their creators,
because they were designed to become C's successors. None of them
succeeded. There's no indication that Walter Bright's is going to
be any different (it's been ignored by the programming community
for years).

BTW, if you have (finally) read the FAQ, why don't you follow its advice?

This article can always be improved. Your input is welcome. Send your
comments to (e-mail address removed) .

There is exactly one person who decides what goes and what doesn't in the
FAQ. Ditto for what needs to be changed in the FAQ. It is enough to
convince him, you don't need our consensus. OTOH, our consensus is
worth zilch if you don't manage to convince him. Would you change lcc
in a manner you don't approve of simply because c.l.c has unanimously
told you to do so? Why would be Steve any different?

Dan

 

[Keith Thompson]

1: The section about "main" doesn't mention that
main has an automatic zero return value.
I do not agree with this part of the standard but
it should be mentioned in the FAQ anyway.
Question 11.12b

I agree that it should be mentioned. It also needs to mention that
this is specific to C99, since a lot of programmers are using pre-C99
compilers.

[snip]

3: The question about rounding (14.6) doesn't mention the
standard functions lround, round, and the others defined
in the standard.

Again, these are specific to C99.

In general, I think it's definitely worth mentioning C99-specific
issues in the FAQ, but it should always be pointed out that they're
C99-specific. The C99 standard is highly relevant (despite what some
people might claim), but it's not universal.

[snip]

5: The successor of C "could" be called "D", since Walter Bright has
designed a language that claims this (www.digitalmars.com). This
is an issue in question 20.38

As Dan points out, there have been several languages called "D"; none
of them has a unique claim on being C's successor.

In the latest version, 20.38 says, in part:

For a while, there was speculation that C's successor might be
named P (the third letter in BCPL) instead of D, but of course
the most visible descendant language today is C++.

It might be worth mentioning the existence of languages calling
themselves "D", but it's not a big deal.

 

[Keith Thompson]

Most likely because it doesn't:

fangorn:~/tmp 485> cat test.c
#include <stdio.h>

int main()
{
printf("Hello world\n");
}
fangorn:~/tmp 486> gcc -ansi -pedantic test.c
fangorn:~/tmp 487> ./a.out
Hello world
fangorn:~/tmp 488> echo $status
12

Dan, you know as well as anyone that the behavior of a single
implementation does not definitively address questions about the
standard. Only the standard itself does that.

It's true that the C90 standard doesn't define an automatic zero
return value for main, though the C99 standard does. If you want to
make that point, make it.

Read this until it penetrates your thick skull: it is the c.l.c FAQ,
NOT the C99 FAQ.

The latest version mentions C99 extensively. There are still several
places where C99 features are relevant and the FAQ doesn't yet mention
them.

[...]

Most likely because the standard doesn't define them:

[demonstration of gcc behavior snipped]

The C90 standard doesn't mention them. The C99 standard does. You
know that, of course, but you choose to make your point by showing how
gcc behaves rather than by coming out and saying it.

[...]

(I've skipped the Windows and MSDOS questions because I have no
significant expertise in that area.)

BTW, if you have (finally) read the FAQ, why don't you follow its advice?

This article can always be improved. Your input is welcome. Send your
comments to (e-mail address removed) .

There is exactly one person who decides what goes and what doesn't in the
FAQ. Ditto for what needs to be changed in the FAQ. It is enough to
convince him, you don't need our consensus. OTOH, our consensus is
worth zilch if you don't manage to convince him. Would you change lcc
in a manner you don't approve of simply because c.l.c has unanimously
told you to do so? Why would be Steve any different?

It's perfectly reasonable to discuss the content of the comp.lang.c
FAQ in comp.lang.c. Steve follows the group (at least he's been doing
so lately), and I suspect he's influenced by any reasonable points
that are made here.

Just today, in the "boolean values and the FAQ" thread, Steve wrote:
] jacob navia wrote:
] >> The section about boolean values should mention
] >> <stdbool.h> at least.
]
] Indeed it should. I'll make a note. Thanks.

I understand that you probably didn't have a chance to see that
article before you posted, but if Steve doesn't have a problem
accepting feedback from the newsgroup, perhaps you shouldn't worry
about it.

If you want a FAQ that ignores the C99 standard, feel free to write
one. I'd probably even read it and give you feedback on it.

Assuming I have Steve's attention (if I don't, I'll send him an e-mail
message later), I have a couple of questions that are probably of
interest to the readers of this newsgroup:

When will the HTML version be updated to match the latest plain-text
version? If the conversion isn't automated, I'm sure someone would be
glad to volunteer to help make it so.

What's the story on the Korean translation we discussed here a few
weeks ago? There was some concern that it seems to include material
that's in the book but not in the English on-line version. (Steve
told me by e-mail that there's no real problem, but he didn't have
time to elaborate.)

 

[Dan Pop]

Dan, you know as well as anyone that the behavior of a single
implementation does not definitively address questions about the
standard. Only the standard itself does that.

A *single* conforming implementation can be used for rebutting claims
as above, if its behaviour is different from the claimed behaviour.

It's true that the C90 standard doesn't define an automatic zero
return value for main, though the C99 standard does. If you want to
make that point, make it.

I have already made it, at least 100 times, in this very newsgroup.
The issue has been discussed at length, a zillion times. Hence the
"nonconformist" way used this time.

The latest version mentions C99 extensively. There are still several
places where C99 features are relevant and the FAQ doesn't yet mention
them.

C99 features are seldom relevant in comp.lang.c. They're mentioned as
trivia stuff. C programming doesn't mean C99 programming, at least for
the time being and the near future.

Most likely because the standard doesn't define them:

[demonstration of gcc behavior snipped]

The C90 standard doesn't mention them. The C99 standard does. You
know that, of course, but you choose to make your point by showing how
gcc behaves rather than by coming out and saying it.

Note that the [ISO] tag in the FAQ means C90. Therefore, when we're
talking about the C standard, without any other qualifiers, in the
context of the FAQ, we're talking about the C90 standard. If you don't
like this, take the issue to Steve.

If you haven't noticed, Jacob was meaning C99 any time wrote about the
C standard. See the underlined text above as an example.

It's perfectly reasonable to discuss the content of the comp.lang.c
FAQ in comp.lang.c. Steve follows the group (at least he's been doing
so lately), and I suspect he's influenced by any reasonable points
that are made here.

As Steve repeatedly mentioned, he's not always following the newsgroup.
Hence his request for any suggestions being sent by private email to him.

I agree that, if someone has any problems with one FAQ item or another,
they're perfectly topical here, however, when one wants the FAQ to be
changed, Steve's advice is to be followed. If Steve feels any need to
consult the newsgroup, there is nothing preventing him from doing it.

If you want a FAQ that ignores the C99 standard, feel free to write
one. I'd probably even read it and give you feedback on it.

Don't be idiot! Have I ever complained about the C99 coverage in the FAQ?
I was merely objecting to the claims and implications that C99 is or
should be the *default* standard covered by the FAQ. It isn't and Steve
shows no signs of intending to change the FAQ in this direction. So,
Steve's FAQ is good enough for me.

Besides, If I wanted a FAQ that ignores C99, all I had to do was removing
all the references to C99 from the current FAQ. But it would be an
exercise in futility...

What I would object about is giving extensive coverage to the C99 standard
in the FAQ, as suggested by Jacob. But this is not the case now, so I
have no reason to object. Having seen how Steve managed the transition
from K&R C to ANSI C, I am confident that he will do a good job with
the transition to C99, *when* and *if* this transition happens. Right now
for anyone interested in portable C programming, C99 issues are purely
academic.

Dan

 

[jacob navia]

If you haven't noticed, Jacob was meaning C99 any time wrote about the
C standard.

In the edition of 99 we can read: (page 11, Foreword)

This second edition cancels and replaces the first edition, ISO/IEC
9899:1990, as
amended and corrected by ISO/IEC 9899/COR1:1994, ISO/IEC 9899/AMD1:1995

There is only one edition of the C standard. The current one.

I have been working the last 5-6 years (I do not even remember) trying to
implement this standard and making a freely available version of it for
everyone.

That is why I wanted that the FAQ of comp.lang.c mentions the relevant
parts of it when possible.

The function lround and round are part of the standard. The gcc compiler
(that you cite very often) will recognize many of the C99 directives when
invoked

gcc -std=c99

including round and lround that have in my linux system even a man page.

jacob

 

[Allin Cottrell]

I was merely objecting to the claims and implications that C99 is or
should be the *default* standard covered by the FAQ. It isn't and Steve
shows no signs of intending to change the FAQ in this direction. So,
Steve's FAQ is good enough for me.
[snip]

What I would object about is giving extensive coverage to the C99 standard
in the FAQ, as suggested by Jacob. But this is not the case now, so I
have no reason to object. Having seen how Steve managed the transition
from K&R C to ANSI C, I am confident that he will do a good job with
the transition to C99, *when* and *if* this transition happens. Right now
for anyone interested in portable C programming, C99 issues are purely
academic.

This is an important matter for clc, very important. I'd hope we can
discuss it in a civil manner. (I agree with the substance of Dan's
comments but dislike the you're-an-idiot-if-you-don't-agree-with-me
tone.)

As a group, we discuss "standard" C, and are quick to point out the
advantages in portability and maintainability of programming in
"standard" C to the greatest possible extent (using platform-specific
extensions when necessary, but only when necessary).

But what is the C standard? There is no question, officially it is
C99 (as Jacob Navia has said upthread). Yet, as Dan has stated, if
you program to the C99 standard, to the extent your code departs from
C90 its portability is practically nil. People who have written
"niche" compilers that conform to C99 need to recognize this point
clearly. It's no good saying, "Well my compiler does C99 so why
are you dragging your feet?", since at least 99 percent of the C
programming world (at my rough estimate) is using either Microsoft's
C compiler or gcc, neither of which is C99-conforming and neither
of which seems to be in any hurry to achieve that status.

In a practical sense, then, the standard to which we appeal in
clc is the "obsolete" C90. This is not a happy situation, but it
is not of our choosing. Whether or not it was visible ahead of
time, we can see with hindsight that the C standards body made a
big mistake in promulgating C99: this action has in fact undermined
via ambiguity the case for "standard C".

Clc has to find a way to live with this undesirable situation.
Upthread, the FAQ has been discussed. If you're reading this, Steve,
I'd say that one important update to the FAQ is some sort of
comment for the new programmer in C about this very issue: the
conflict between

* a standard that is official, but in effect unimplemented, and
* a standard that is officially obsolete but that in effect
defines the limits of portable C.

Good luck in phrasing it!

Allin Cottrell
Wake Forest University

 

[Mark McIntyre]

are you dragging your feet?", since at least 99 percent of the C
programming world (at my rough estimate) is using either Microsoft's
C compiler or gcc, neither of which is C99-conforming and neither
of which seems to be in any hurry to achieve that status.

actually, I think you'll find that gcc is moving towards C99 quite
quickly. Certainly compared to some of the other major providers.

 

[Steve Summit]

As a group, we discuss "standard" C, and are quick to point out the
advantages in portability and maintainability...
But what is the C standard? There is no question, officially it is
C99 (as Jacob Navia has said upthread). Yet, as Dan has stated...
its portability is practically nil.

These points are well taken. And while the situation is indeed
uncomfortable, I'm not sure it's any more dire than it was back
in the early 90's, when compilers that were ANSI compatible at
all (i.e. compatible with the then-new C90) were not yet
widespread, and we all had to worry about levels of pre-ANSI
compatibility.

(We might, however, use this situation as a cue to be a little
more tolerant of those who, for one pragmatic reason or another,
find it necessary to write code or comp.lang.c posts which hew to
something other than The-Totally-Official-ISO-C-Standard-Of-Today,
since for the next little while just about all of us are going to
be engaging in that kind of pragmatism.)

I'd say that one important update to the FAQ is some sort of
comment for the new programmer in C about this very issue:

Good suggestion; thanks.

the conflict between
* a standard that is official, but in effect unimplemented, and
* a standard that is officially obsolete but that in effect
defines the limits of portable C.
Good luck in phrasing it!

On the contrary -- I think I've got a good candidate phrasing
already! (I.e. thanks again. ;-) )

Since the question has come up: I do intend to mention C99 in the
FAQ list wherever appropriate, with its features presumed (for
now) to be an option, not a requirement, for use. The omission
of <stdbool.h> in the recent round of updates was a simple
oversight -- I had a note to myself to find out whether, in fact,
it existed at all, but I neglected to follow through. (And then
there's this stupid little logistical problem which is that my
electronic copy of C99 got lost when my laptop got stolen a while
back, and I still haven't made it over to www.ansi.org to pick up
another one.)

Steve Summit
(e-mail address removed)

 

[Allin Cottrell]

These points are well taken. And while the situation is indeed
uncomfortable, I'm not sure it's any more dire than it was back
in the early 90's, when compilers that were ANSI compatible at
all (i.e. compatible with the then-new C90) were not yet
widespread, and we all had to worry about levels of pre-ANSI
compatibility.

I hope you're right. My worry is that while C90 had history
working in its favour, one can't be sure of that in the case of
C99. I hope I'm wrong.

Allin Cottrell

 

[Dan Pop]

I hope you're right. My worry is that while C90 had history
working in its favour, one can't be sure of that in the case of
C99. I hope I'm wrong.

Most importantly, five years after C89 was released (i.e. by 1994)
pre-ANSI C was mostly history and all major platforms in use had
vendor-supported ANSI C implementations (one could buy one even for
SunOS 4). gcc was also a conforming, freely available translator.
Compare to C99's availability status now.

Dan

 

[Dan Pop]

actually, I think you'll find that gcc is moving towards C99 quite
quickly.

Very quickly, indeed, considering that it hasn't made *any* progress
during the last three years!

Dan

 

[Dan Pop]

This is an important matter for clc, very important. I'd hope we can
discuss it in a civil manner. (I agree with the substance of Dan's
comments but dislike the you're-an-idiot-if-you-don't-agree-with-me
tone.)

Such tone exists *only* when people behave like idiots. It is immaterial
whether they agree or not with me. I'm perfectly willing to discuss in
a civil manner, as long as presented with *rational* arguments. And *you*
should know that, as we disagreed in a civil manner many times before.
And, since I credit you with (much) more brain power than Mark McIntyre,
I see this as a *gratuitous* attack against me.

Dan

 

[Allin Cottrell]

Such tone exists *only* when people behave like idiots...

Well, I suppose it's a matter of how one calibrates one's
"idiot threshold".

Allin Cottrell.

 

[lawrence.jones]

Most importantly, five years after C89 was released (i.e. by 1994)
pre-ANSI C was mostly history and all major platforms in use had
vendor-supported ANSI C implementations (one could buy one even for
SunOS 4). gcc was also a conforming, freely available translator.
Compare to C99's availability status now.

In 1989, most C compiler vendors only had C compilers to worry about.
Now, most of them have C++ compilers to worry about, too, and a "new"
C++ standard that isn't very new anymore that's significantly more
difficult to implement than C99 and in more demand.

-Larry Jones

I sure wish I could get my hands on some REAL dynamite. -- Calvin

 

[Mark McIntyre]

Well, I suppose it's a matter of how one calibrates one's
"idiot threshold".

And since Dan's threshold is apparently set to "if you make any mistakes at
all then you're an idiot"...

Actually he reminds me of an historian I once knew. Expert in late Roman
battlefield strategy. Considered anyone who didn't know Roman battlefield
theory inside out to be an idiot. I ignored him too, after a while, even
when I was looking for an expert in Roman battlefield strategy.

 

[Keith Thompson]

Such tone exists *only* when people behave like idiots. It is immaterial
whether they agree or not with me. I'm perfectly willing to discuss in
a civil manner, as long as presented with *rational* arguments. And *you*
should know that, as we disagreed in a civil manner many times before.
And, since I credit you with (much) more brain power than Mark McIntyre,
I see this as a *gratuitous* attack against me.

Dan, his attack is not gratuitous. You frequently respond abusively
to posters who have not in any way behaved like idiots. I for one am
sick and tired of it, and I get the impression that the majority of
the regulars are also sick and tired of it.

Yes, you are capable of disagreeing in a civil manner. Please do so
more often.

This newsgroup would be a significantly more pleasant place if you
would continue to provide your excellent technical expertise without
going off on rants with little or no provocation.

In my opinion, of course.

 

[Mark McIntyre]

Dan, his attack is not gratuitous. You frequently respond abusively
to posters who have not in any way behaved like idiots.

Keith, you're wasting your time. Dan won't change his spots. See for
instance the ad hominem mention of myself in the quote above. The easiest
answer is to killfile him.

Yes, you are capable of disagreeing in a civil manner. Please do so
more often.

Hear hear.

 

[Dan Pop]

In 1989, most C compiler vendors only had C compilers to worry about.
Now, most of them have C++ compilers to worry about, too, and a "new"
C++ standard that isn't very new anymore that's significantly more
difficult to implement than C99 and in more demand.

Comeau C++ and the Dinkumware library render this argument ludicrous.
If two microscopic companies could do it, what was preventing the
larger vendors from getting their own implementations, assuming that they
saw any *real* demand for such things?

Furthermore, C++ implementations were not unheard of by 1989.

Dan

 

[Dan Pop]

Well, I suppose it's a matter of how one calibrates one's
"idiot threshold".

My threshold is way below what can be reasonably considered rational
behaviour.

Dan