Segmentation Fault....

[Mark McIntyre]

Comments should describe code, not remove it.

A comment specifier marks text that the preprocessor removes from the
source, before feeding it to the compiler. There's nothing in the
standard that requires this text to be description rather than
function.

If you want temporarily to disable a block of code, you will find that

#if 0

code to be temporarily disabled

#endif

is much cleaner.

One could argue that the #if method is more typing, more prone to
mistakes of location of the macros etc. For commenting out a small
number of lines, the // technique is much simpler.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Old Wolf]

Having actually learned C (rather than merely the language which the
books and my work colleagues believed to be C, which I'd already been
using for almost a decade), I found that the amount of debugging time I
needed had plummeted, and the number of times I needed to step through
code in a debugger had fallen to - effectively - zero.

I have to agree; I've only ever once had cause to use a
debugger on C code, and that was to find logic errors in
my word-wrapping algorithm when it would cut off words at
the wrong place (as opposed to memory leaks or whatnot).

(Of course, this could be worked through without a debugger,
but it is faster to use the debugger).

 

[Keith Thompson]

Excuse me, I have yet to find a C compiler that does NOT accept
// comments.

Please show me *some* example for those...

More precisely, there are a number of C *implementations" that reject
// comments. One example is gcc with the "-ansi -pedantic" options.

Note the definition of "implementation" in C99 3.12:

particular set of software, running in a particular translation
environment under particular control options, that performs
translation of programs for, and supports execution of functions
in, a particular execution environment

gcc with "-ansi -pedantic" and gcc without "-ansi -pedantic" are two
distinct implementations. (Except that gcc without "-ansi -pedantic",
strictly speaking, isn't really a C implementation at all, since it
doesn't fully conform to *any* C standard.)

(It may be necessary to provide more options to enable full C90
conformance, but I don't remember the details, which aren't
necessarily relevant to the point anyway.)

 

[Default User]

I have to agree; I've only ever once had cause to use a
debugger on C code, and that was to find logic errors in
my word-wrapping algorithm when it would cut off words at
the wrong place (as opposed to memory leaks or whatnot).

I've used debuggers extensively over the years. In particular, we used
to do software testing that would have been near impossible without
one. We had to force failure paths, including those due to failures
from library functions.

A debugger is a perfectly good tool, and I feel the slighest
embarrassment at using it when needed and available.




Brian

 

[Keith Thompson]

I would accept that, but heathfield insists that anything different from
C89 is "off topic in clc".

I'm not going to accuse you of lying, since it's possible that you
actually believe that. It is, however, a blatantly false statement,
and, in my humble opinion, a particularly foolish one.

Please provide a citation in which Richard Heathfield has claimed that
anything other than C89 is off-topic in comp.lang.c. He has
repeatedly acknowleged that C99 is topical. He has also said that C89
(or C90 as I prefer to refer to it) is also topical.

[...]

In the other answer in this same thread he says:

<quoting>
If an implementation is invoked in a non-conforming mode, that
invocation is off-topic in clc. When invoked in conforming mode, all
the compilers I mentioned issue the necessary diagnostic message for a
// syntax error.
< end quote>

With "non conforming" he means in a mode that accepts standard
comments...

No, by "non conforming" he means a mode that does not conform to *any*
C standard. For example, "gcc -std=c99" does not fully conform either
to C90 or to C99. Similarly, lcc-win32, when invoked in a mode that
causes it to accept "//" comments, does not fully conform either to
C90 or to C99. One might debate whether the non-conformance is
significant, but there is no doubt that it does not fully conform.

With "conforming mode" he means "conforming to MY favorite version of
the standard even if it is obsolete"

No, he means conforming to *some* version of the C standard. In the
case of the particular compilers being discussed, the *only* C
standard they are capable of conforming to is the C89/C90 standard.
It would be great if they were also capable of conforming to the C99
standard, but they don't.

And anything else is off topic.

C99 is clearly on topic, even though most compilers don't fully
support it. I don't recall *anybody* *ever* claiming otherwise in
this newsgroup. You repeatedly assert that such claims have been
made. Please provide an example.

[...]

 

[Keith Thompson]

Daniel Rudy a écrit :

This is nonsense.

// comments are standard C!!!

Yes, they are supported by the latest C standard. Daniel's
implication that they're specific to C++ is incorrect.

But then, designated specifiers and variable argument macros are also
supported by the latest C standard, and you've recently stated that
lcc-win32 doesn't support those features.

Very few implementations support all of C99. Most current compilers
support all of C90 (apart from the inevitable bug here and there) in
some mode. And most current compilers support "//" in some mode (a
mode that does not fully conform either to C90 or to C99).

Let's say I want to write code that is purely C90 except for the use
of "//" comments. A compiler that supports "//" comments will usually
support some other C99-specific features as well, and will not warn
about attempts to use those features. But the subset of C99-specific
features varies from one compiler to another, making it quite
difficult to write portable code *unless* I ask the compiler to
diagnose *all* attempts to use C99-specific features.

For example, let's say I write the following program:

#include <stdio.h>
#define DEBUG(...) fprintf(stderr, __VA_ARGS__)
int main(void)
{
int x = 42;
// The following line uses a C99-specific feature.
DEBUG("Diagnostic: x = %d\n", x);
return 0;
}

I compile it with gcc, using a mode in which it doesn't complain about
the "//" comment. In such a mode, it doesn't complain about the
variadic macro either (and maybe I didn't realize that that's a
C99-specific feature).

Since gcc didn't complain, I assume that the code is portable, so I
try to compile it with lcc-win32. lcc-win32, of course, happily
accepts the "//" comment, but ... well, I don't have a copy of
lcc-win32, so maybe you can tell us what happens.

One compiler might not support variadic macros. Another might not
properly support variable-length arrays. Since there are few
conforming C99 compilers, and none in widespread use, those of us who
want to write portable code are forced to program in a *subset* of
C99. And, as it turns out, the only subset that currently can be
*enforced* (i.e., we can expect compilers to warn us when we violate
it) looks very much like C90.

jacob, based on your past history, I'd be pleasantly surprised if you
understood this (the same points have been made before), but perhaps
it will be instructive for others.

 

[Keith Thompson]

Considering that gcc's default is gnu99, which is some c99 with gnu
extensions, that's not really considered standard C either.

Not quite. As of gcc 4.1.1:

The default, if no C language dialect options are given, is
`-std=gnu89'; this will change to `-std=gnu99' in some future
release when the C99 support is complete. Some features that are
part of the C99 standard are accepted as extensions in C89 mode.

 

[Keith Thompson]

Yes. If you tell gcc not to use the current standard but some other old
one it will not accept standard syntax.

So tell us how to tell gcc to use the current standard. (By "use", I
mean "fully conform to".)

 

[Richard Heathfield]

Old Wolf said:

(Of course, this could be worked through without a debugger,
but it is faster to use the debugger).

Absolutely. I'm still ready to use the debugger at the drop of a hat if
I think it the appropriate tool. It's just that nowadays it is hardly
ever the appropriate tool (for *me*).

 

[Richard Heathfield]

Default User said:

A debugger is a perfectly good tool, and I feel the slighest
embarrassment at using it when needed and available.

I guess you're missing a "not" or a "do not" from there - there's no
reason whatsoever to be embarrassed about using a debugger. And I
certainly agree that they are useful for stepping through new code -
especially in... ah, but that would be off-topic.

 

[Richard Bos]

The only person who is saying that is you.

Yeah, but he thinks he's a guru, so he's obviously always right,
including in that post. And therefore, he's always right. After all,
he's a guru, and he said so. QED.

Richard

 

[Richard Bos]

So tell us how to tell gcc to use the current standard. (By "use", I
mean "fully conform to".)

Is there a mode in which it _fully_ conforms to the old Standard, then?

Richard

 

[jacob navia]

Select conforming feature(s) != conforming implementation. This seems
to be the crux of what people are trying to teach you.

As suggested else-thread, I have nightlies that will break if you insist
on using C99 features (including the comment format you insist is so
widely accepted we can ignore any objections otherwise) accepted in some
marginally conforming implementation. You insist that "all main
compilers accept them" but this is not my experience. Those conforming
features do not always match up with each-other, so you have a situation
where you can have a number of C90+some features implementations
consuming the same code.

This is a recipe for disaster.

C90 /is/ a standard. It is the standard most people find in the field.
It really makes no difference that you don't like this.

The age of a standard means little to the millions of lines of code we
have to maintain over the years. Stable code is a Good Thing, and
adoption of C99 /by the system and compiler implementers/ has been slow
and incomplete. Why introduce risk over something you cannot control?

The day a significant compiler can claim full support of the required
parts of the C99 standard then you will see newer code being written to
support that.

It has nothing to do with the age of a standard. A decade is nothing in
terms of software maintenance, especially when expressed in such a
robust and well understood language like C. Change incurs risk, and
unless there are significant gains, that risk is simply not worth it. We
have a situation where few shops /need/ C99, and therefore there are few
implementers willing to undertake the expensive operation of conforming
to that standard. The fact that implementations have slowly started to
conform over the years doesn't change the fact that few people need
anything C99 brings.

Since C99 implementations will not break conforming C90 code, why should
the majority of us care how a comment is formed?

One thing you seem to be missing is that many shops have coding
standards, and a lot of code will already have decades of changes,
including well-formed comments. Just because C99 allows // does not
mean anyone needs to use it. At my shop comments have a specific
format, and even when we move to C99 (on all platforms, so don't hold
your breath) we will not change that because it would mean reformatting
all sorts of existing comments.

For maintaining old code with obsolete tools you have a point.

There is no need to force that decision to newbees writing new programs
however.

This discussion started with people telling a student that he shouldn't
use // comments because they aren't standard...

This is completely wrong, and has nothing to do with your situation,
where maintenance requirements need tools so obsolete that even //
comments aren't understood.

 

[Richard Heathfield]

jacob navia said:

Clever Monkey wrote:


For maintaining old code with obsolete tools you have a point.

He also had points for writing new code with current compilers, which
you failed to address.

This discussion started with people telling a student that he
shouldn't use // comments because they aren't standard...

One person, and he was mistaken, and he was corrected. Since // comments
are part of standard C99, it is clear that "not standard" is not the
reason not to use them. There are, however, other and better reasons
why many people avoid them.

This is completely wrong, and has nothing to do with your situation,
where maintenance requirements need tools so obsolete that even //
comments aren't understood.

Support (or lack of it) for // comments is not a measure of
obsolescence. It is a measure only of support (or lack of it) for //
comments. There are many excellent compilers which, when invoked in
conforming mode, issue diagnostic messages for the syntax error of //.
There are also, we are told, one or two compilers which, when invoked
in conforming mode, correctly accept // comments.

The crux is "to which standard does the implementation in question
conform?" C90 conformance requires the diagnosis, and C99 conformance
does not.

You appear to believe that any implementation not conforming to C99 is
obsolete (and the list of non-C99-conforming implementations includes
Microsoft C, Borland C, gcc/glibc, and of course lcc-win32), and of
course you are entitled to believe that, but the vast number of C
programmers using C90-conforming compilers are not required to agree
with you.

 

[Charlton Wilbur]

RH> One person, and he was mistaken, and he was corrected. Since
RH> // comments are part of standard C99, it is clear that "not
RH> standard" is not the reason not to use them. There are,
RH> however, other and better reasons why many people avoid them.

Er, if this is me you're talking about, I was not mistaken; I said
that // comments were standard in the latest C standard, but that the
use of them frequently indicated a lack of comprehension about C
standards in general and about the importance of adhering to a
standard.

(And my reason for saying this is simple: someone who cares about
adhering to standards will either adhere to C89 or C99; if he attempts
to adhere to C99, he will quickly discover that few to no C
implementations exist that conform to that standard, and thus he will
find himself, if he wishes to both adhere to a standard and actually
compile his code, adhering to C89. Someone who uses whatever features
the compiler supports, on the other hand, will have no problems with
using // comments, because [as Mr Navia correctly points out] many
compilers will accept a non-standard dialect of C that is based on C89
with a few additional features from C99, // comments among them.)

Mr Navia "corrected" this already-correct statement by pointing out
that // comments were standard in the latest C standard, a point that
was never in dispute.

Charlton

 

[Gregor H.]

You appear to believe that any implementation not conforming to C99 is
obsolete (and the list of non-C99-conforming implementations includes
Microsoft C, Borland C, gcc/glibc, and of course lcc-win32), and of
course you are entitled to believe that, but the vast number of C
programmers using C90-conforming compilers are not required to agree
with you.

Actually, I wouldn't dare to program my little (private) projects in C99,
since I would never know if it would be possible to compile them on the
systems I am interested to work with. (gcc is certainly available on MOST
systems, but alas...)

If only K&R had written a 3rd edition of their book, covering C99.


G.

 

[Richard Heathfield]

Charlton Wilbur said:

RH> One person, and he was mistaken, and he was corrected. Since
RH> // comments are part of standard C99, it is clear that "not
RH> standard" is not the reason not to use them. There are,
RH> however, other and better reasons why many people avoid them.

Er, if this is me you're talking about,

It isn't. Daniel Rudy said: "Those comments are C++ style. Are you
coding in C or C++? This group is for C. If you want C++, then head
to the room down the hall." Clearly, he was mistaken.

I was not mistaken

I do not doubt it for a second. In fact, I think you made some excellent
points in this thread, and I can't remember any that I disagreed with.
I do, however, remember nodding a lot, and not through tiredness!

<snip>

 

[Charlton Wilbur]

RH> Charlton Wilbur said:

RH> It isn't. Daniel Rudy said: "Those comments are C++ style.
RH> Are you coding in C or C++? This group is for C. If you want
RH> C++, then head to the room down the hall." Clearly, he was
RH> mistaken.

Thanks for the clarification!

RH> I do not doubt it for a second. In fact, I think you made some
RH> excellent points in this thread, and I can't remember any that
RH> I disagreed with. I do, however, remember nodding a lot, and
RH> not through tiredness!

I appreciate the compliment. I'm always quite pleased when I say
something in here (especially when it's code) and nobody spots an
obvious mistake, or even an inobvious one....

Charlton

 

[Tak-Shing Chan]

jacob navia said:


He also had points for writing new code with current compilers, which
you failed to address.

<snip>

This group is about the C language as defined by ISO 9899.
Discussion about ``current compilers'' are off-topic and should
be redirected to groups dedicated to specific compilers. See
also the ``Welcome to comp.lang.c!'' post.

Note that the line wrapping excuse is not applicable here,
because the OP's comments are very short.

Tak-Shing

 

[Default User]

Default User said:



I guess you're missing a "not" or a "do not" from there

Yes, a negate-o or whatever.




Brian