Segmentation Fault....

[Richard Heathfield]

Tak-Shing Chan said:

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

It's not an excuse, but a reason for avoiding // comments in general
when posting code to Usenet. The fact that the OP's comments were not
so long as to cause line-wrap is of no consequence in the general case.

 

[Tak-Shing Chan]

Tak-Shing Chan said:



It's not an excuse, but a reason for avoiding // comments in general
when posting code to Usenet. The fact that the OP's comments were not
so long as to cause line-wrap is of no consequence in the general case.

It is definitely an excuse. Long lines are the culprit, not
// comments. Take any C program. Mechanically wrap them at 20
characters. I bet that the majority of them will fail to
compile, even if you use /* comments */.

Tak-Shing

 

[Richard Heathfield]

Tak-Shing Chan said:

It is definitely an excuse.

Like most conversations with you, this one looks like it's heading
nowhere, and you're adding nothing of any particular value.

Wake me when you say something interesting.

 

[Tak-Shing Chan]

Tak-Shing Chan said:


Like most conversations with you, this one looks like it's heading
nowhere, and you're adding nothing of any particular value.

Wake me when you say something interesting.

I was demonstrating that your ``reason for avoiding //
comments'' is flawed. If you honestly cannot see where I am
heading, I think I will give up.

Tak-Shing

 

[Richard Heathfield]

Tak-Shing Chan said:

I was demonstrating that your ``reason for avoiding //
comments'' is flawed.

No, you weren't. You were merely pointing out that on some occasions //
comments do not line-wrap. This was already known, so you have provided
no new information.

If you honestly cannot see where I am heading, I think I will give up.

I haven't a clue where you're heading. Your call.

 

[Tak-Shing Chan]

Tak-Shing Chan said:



No, you weren't. You were merely pointing out that on some occasions //
comments do not line-wrap. This was already known, so you have provided
no new information.


I haven't a clue where you're heading. Your call.

Let me repost the bits that you have snipped:

``[...] Long lines are the culprit, not
// comments. Take any C program. Mechanically wrap them at 20
characters. I bet that the majority of them will fail to
compile, even if you use /* comments */.''

Let me expand on this a little bit:

(1) To begin with, if we set our newsreaders to be narrower
than the Usenet convention (67 characters), then we should not
copy-and-paste from a post and expect the results to be
compilable. Why? By forcing a mechanical rewrap, we risk
breaking identifiers (or string literals) in the middle. This is
particularly common with long printf lines.

(2) If original posters obey the Usenet line length
conventions, then our line lengths would match (or exceed)
theirs, so // comments would not and could not cause any
problems in the first place.

In other words, // is not the culprit.

Tak-Shing

 

[Daniel Rudy]

At about the time of 4/12/2007 1:16 AM, Richard Bos stated the following:

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

Richard

There sure is, as I have demonstrated. -std=c89


--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

 

[Daniel Rudy]

At about the time of 4/12/2007 8:52 AM, Charlton Wilbur stated the
following:

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

So this entire argument is my fault?


--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

 

[Richard Heathfield]

Daniel Rudy said:

So this entire argument is my fault?

Well, you were merely the match. The methane has been kicking around for
some time.

 

[Flash Gordon]

Daniel Rudy wrote, On 12/04/07 18:09:

At about the time of 4/12/2007 1:16 AM, Richard Bos stated the following:

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

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

Richard

There sure is, as I have demonstrated. -std=c89

That does not do it. If you read the documentation you will find that
you also need -pedantic to get all the required diagnostics. With "-ansi
-pedantic" or "-std=c89 -pedantic" you get full C90 compliance (modulo
bugs).

 

[Keith Thompson]

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

Rule 1: All software has bugs.

Corollary: No compiler completely conforms to any standard (unless the
standard is defined by the behavior of the compiler itself, bugs and
all).

See <http://gcc.gnu.org/bugzilla/>.

*However*, as far as I know, gcc with the right set of options
(something similar to "-ansi -pedantic -W -Wall") conforms reasonably
well to the C90 standard when used with an appropriate runtime
library. As far as I know, any conformance failures of such an
implementation are unintentional bugs, and I don't know of any major
ones.

By contrast, changing "-ansi" to "-std=c99" yields an implementation
that attempts to conform (but only partially) to C99, but there are
features that are known to be implemented incorrectly, and others that
are not yet implemented at all.

 

[Keith Thompson]

Variable argument macros.
The reason is that the preprocessor of lcc-win32 was written
originally by Dennis Ritchie. I have used it since a
long time, and added some stuff to it, fixed some simple bugs, but I
have left the code running as he conceived it. He wrote that
preprocessor for his Plan 9 system, and put it in the public domain.

I have used it, but I want to leave it somehow untouched. I have
implemented some of the ideas of his Plan 9 system in my compiler, for
instance the structure member lookup, what allows some form of
inheritance. But that is another discussion.

I suggest that, if you want to produce a conforming C99
implementation, you need to forget about leaving DMR's preprocessor
"untouched" and go ahead and implement the required functionality.

 

[Keith Thompson]

For what its worth, RJH has NOT denied that you or some others (myself
included) like the C++ comment style.

[...]

I suggest that referring to them as "C++ comments" is misleading. C90
doesn't allow // comments; C99 does. There's no need to bring C++
into the discussion. (C++ also supports /* ... */ comments, but we
don't call them "C++ comments".)

Just call them // comments, or double-slash comments. Or, if you want
to acknowledge their historical origin, call them BCPL comments.

 

[Kelsey Bjarnason]

[snips]

// comments are accepted by most C compilers: microsoft, gcc, IBM,
and almost all main compilers accept them. This feature is really almost
universal by now.

Not universal; no C89/C90 compiler running in conforming mode will accept
them.

What is strange is that all this people that always speak about
"standard C" do not really mean standard C but some other standard
like C95, C89, or maybe even K&R C from 1975???

Any version of ANSI/ISO C _is_ standard C. There are simply newer
standards and older ones. C89 _is_ standard C, just not the _newest_
standard.

It is already 8 years since 1999, and maybe it is time to look around a
bit?

Or you prefer living in the past, as many people here?

Living in the present, more like it.

Yes, fine, C99 is the newest standard and in theory, one should be writing
code to that. Fine, great, feel free.

There is however a simple reality which that ideal overlooks: not all
compilers support C99, and the ones that do support non-overlapping and
frequently incorrectly implemented subsets of C99.

The reality is that if you write code which needs to be run on a variety
of systems, compiled with a variety of compilers, you cannot rely on most
of what C99 brings, because the compilers themselves simply don't support
it well enough to use it.

Thus, you're left with C89. However, C89 says you cannot use // comments,
regardless of whether compiler A or B supports them, because compiler C is
not required to and you have no control over which compiler will be used.

Further, if you do relax your requirements - say by running compilers A
and B in a less strict mode which does allow // comments - you also relax
the restrictions the compilers work under: they are free to add
non-standard enhancements which may have unforeseen impact upon the of the
code.

So basically, your only hope of producing viable code that will compile
and work correctly in the maximal number of conditions is to produce code
which conforms to a standard which is both old enough to be widely
and correctly implemented, and to not abuse that standard by using
features it doesn't have, in the hopes that these features are the only
way in which the compilers alter what they do from what the standard
mandates that they do.

This is not a good way to develop software.

When C99 is as commonly - and correctly - implemented as C89 is, then
you'll see a migration of code to it. Until then, though, a serious
developer has to stick with what actually works; that means C89 and it
means C89 *without* non-conforming extensions such as // comments.

The *paper* standard may be C99. The real-world standard, as defined not
just by what is used, but in fact by what can be used, is still firmly
C89/C90.

 

[Kelsey Bjarnason]

[snips]

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

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

test.c:
int main()
{
// testing...
return 0;
}

gcc -W -Wall -ansi -pedantic test.c
test.c: In function 'main':
test.c:3: error: expected expression before '/' token
test.c:5: warning: control reaches end of non-void function

ls a.out
ls: a.out: No such file or directory


Hmm. If I tell gcc to compile the code, it spews an error and refuses.
The only way to get around it is to use a different standard - eg C99 -
which brings me smack into the world of non-portability, or to toss the
requirements of the standard to which I am working, which again brings me
smack into the world of non-portability.

Or I could reduce the warnings; that would mean the compiler is failing to
do one of the things it's really good at - telling me where I screwed up -
and it leaves me still in the world of non-portability, I'm just not
getting smacked in the face by it.

No C89/C90 C compiler, at least running in conforming mode, is allowed to
support such comments, and if you want to code in C99 that's fine, but
many can't, because C99 isn't well-enough and widely-enough implemented to
be viable for their needs.

 

[Kelsey Bjarnason]

Because they are legal in the current standard, not the old one.

But gcc, invoked with those arguments, provides an implementation which
(by intent, at least) conforms to an internationally ratified C language
standard; that is, it compiles _C_ code, according to a C language
standard.

Therefore, if // comments are standard C, the compiler either compiles
code with them in it, even invoked as it is, or the compiler is broken.

Er.. umm... except the compiler isn't broken; what's broken is the
assertion that "// comments are standard C". They are standard C _as of
C99_. They are *not* "standard C" as a blanket statement, as they violate
C90.

 

[Keith Thompson]

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.

[..]

I don't entirely agree. In my opinion, discussions of C99, C95, C90,
K&R C, and even older historical versions of C are topical. (I'd say
that B and BCPL are also topical insofar as they illuminate why C is
the way it is.)

Specific discussions of particular implementations, especially of
system-specific extensions that they offer, are off-topic, but in my
opinion general discussions of the general state of conformance to the
various C standards are topical.

It can be difficult to know exactly where the line should be drawn.
The above is my opinion; others are of course, free to differ.

 

[Francine.Neary]

Typical Navia nonsense. // comments go at least as far back as BCPL,
which pre-dates C, let alone Turbo C.

I'm not sure it's a good idea to be so forceful when you reply to
Navia. Sometimes people forget there's another human being at the
other end of the internet, and from this thread Navia seems like a
quite mentally unbalanced one - you don't want to push him over the
edge (or maybe you do?).

This has been a fascinating thread - I've learned a lot about the
different standards.

 

[Keith Thompson]

Any version of ANSI/ISO C _is_ standard C. There are simply newer
standards and older ones. C89 _is_ standard C, just not the _newest_
standard.

There is a significant sense in which that is incorrect. Officially,
the ISO C99 standard "cancels and replaces" the first edition. The
C90 standard, *as far as ISO and ANSI are concerned*, has no official
standing.

However, as users of the C language, we are not obligated to conform
to the official position of ISO (which is a good thing, since it's
often just not possible to do so). There's nothing wrong with
conforming to an obsolete standard.

And, of course, most valid C90 code is also valid C99.

[...]

The *paper* standard may be C99. The real-world standard, as defined not
just by what is used, but in fact by what can be used, is still firmly
C89/C90.

Agreed, with a couple of comments:

Some (but not all) implementations are making progress toward C99
conformance (and a very few have reached it). C99, at the least,
provides guidance for the further development of C90 implementations.
For example, if the author of a C90 implementation wants to provide
complex arithmetic, it would be silly to use anything other than the
C99 definition.

Also, programmers who are interested in maximal portability should
probably stick to the *intersection* of C90 and C99. This is almost
the full C90 language, but there are a few gotchas: provide prototypes
for all functions (which is a good idea anyway), avoid implicit int
(ditto), don't give your own headers names that match C99-specific
headers, avoid using C99-specific keywords as identifers, and probably
a few other things I haven't thought of.

But remember: a well-written C90 program is very likely *also* a valid
C99 program.

 

[Francine.Neary]

I don't entirely agree. In my opinion, discussions of C99,C95, C90,
K&R C, and even older historical versions of C are topical. (I'd say
that B and BCPL are also topical insofar as they illuminate why C is
the way it is.)

Why is C95 never talked about much, but only C90 and C99? Are there
any conforming C95 compilers? If not, why don't people implement C95
as a stepping stone to C99?