Segmentation Fault....

[Keith Thompson]

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?

C95 wasn't released as a full standard. It was an amendment to the
C90 standard. It added digraphs and some additional support for wide
and multibyte characters.

Many compilers do support C95. I've never paid much attention to it,
since I've personally never had much need to use any C95-specific
features.

 

[Richard Heathfield]

(e-mail address removed) said:

I'm not sure it's a good idea to be so forceful when you reply to
Navia.

I am already dialling back my forcefulness to the bare minimum I can
manage. Ignorance is curable, but only if the patient is willing to
learn.

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

I'm glad someone got some value out of it.

 

[Kelsey Bjarnason]

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.

The issue becomes one of a disconnect between this theoretical construct
and reality; unless ISO can somehow mandate that every implementation in
use anywhere is updated to C99 - and correctly - then any supposed
"replacement" is irrelevant; that ISO wants C90 to be one with the
dinosaurs has no bearing on what C programmers are faced with in the real
world.

They're faced with, by and large, C89/C90, meaning that despite ISO's
views, C90 _is_, by and large, the C standard. C99 isn't; it's just some
punk kid who hasn't grown up enough to rule the playground yet.

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.

Yes, except it's not obsolete; it's the real deal, in the real world.
It's only "obsolete" as far as a standards body is concerned, but they
don't have to maintain or port umpteen billion lines of existing code.

Agreed, with a couple of comments:

Some (but not all) implementations are making progress toward C99
conformance (and a very few have reached it).

Sure. C99 is coming, slowly but surely - it just ain't there yet. Until
one can write code using every significant aspect of C99 that isn't also
covered by C89, knowing (within reason) that the code will be correctly
handled by pretty much any current compiler, then C99 is more of a
curiosity than a language. That will change, but it's not there yet.

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.

Whereas the converse is not true, and the likelihood of getting that C99
code correctly compiled on an arbitrary system is considerably less than
if it were C90 code - and that is going to drive the selection of which
standard to adhere to; ISO's notions of what is obsolete aren't.

 

[user923005]

C95 wasn't released as a full standard. It was an amendment to the
C90 standard. It added digraphs and some additional support for wide
and multibyte characters.

Many compilers do support C95. I've never paid much attention to it,
since I've personally never had much need to use any C95-specific
features.

???
You've never had to do UNICODE?

 

[Ian Collins]

???
You've never had to do UNICODE?

UNI-what?

 

[Mark McIntyre]

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.

*shrug*. They've always been C++ comments to me, and I'm far too old
to learn a new name for 'em now. :-(
--
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

 

[Mark McIntyre]

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

Oh sure, and if you wrap them at zero characters, tehy'll disappear.

Whats your point? That deliberately mangling programmes screws them
up? Newsflash: thats not news. And who was talking about mechanically
wrapping at 20 chars?

The point is, usenet posts are frequently wrapped by forces beyond
your control, such as other peoples newsreaders. If you provide code
snippets you want people to read and check, you need to do it in a
user-friendly way.
--
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

 

[Keith Thompson]

???
You've never had to do UNICODE?

I've never written C code that has to deal explicitly with Unicode.

 

[Peter Nilsson]

They do if you want help from this group, for two reasons.

First, // comments were only included in the C99 standard.

And? Are you suggesting that comp.lang.c is the wrong place to
discus C99?

While they are technically standard, using them is more often
than not a sign of sloppy thinking about C

I'll bow to your expert knowledge of sloppy thinking.

and a lack of awareness of C standards,

Or a desire to change them for the better.

Contrary to what some believe, WG14 is not responsible for
ensuring that vendours rush to deliver the new standard. Long
before WG14 get involved, it's the programmers who hassle
vendours for useful features. The vendours supply them as
extensions (conforming or otherwise). WG14 get involved when
the utility of those extensions make them viable candidates
for standardising.

Of course, that is a generalisation and not everything that
WG14 introduces fits this pattern, but // style comments is
most certainly in that camp.

You can argue that not all C90 compilers will support them
and that any program that uses it will not be as portable
as others, but I for one will gladly forfeit portability to
the handful of twenty year old compilers in the Ministry
of Abaki building in central Frobnoskistan.

There may not be a present rush towards implementing C99, but
you can bet there will be greater support when C++ is updated
to include many of the new C99 features.

Portability includes looking to the future, not just what's
available now.

which is likely to reflect poorly on the programmer and irritate
the most helpful people here

Anything that is isolated to C99 irritates Richard Heathfield.
[He thinks globally, not locally. ;-]

(who care deeply about what is standard and non-standard in C).

And // comments are C99 standard. Or are you suggesting that
deeply caring about what is standard means deeply rejecting
everything in the C99 standard?

Second, they are a pain on Usenet, especially with long lines;

Bingo. There are easy substitutes though...

/*=================... =====
//
// All the advantages of // comments...
//
//=================... ===*/

if my terminal window is narrower than you expect,

That's life. Even /* */ are not immune from being too long for
some people's liking. Sometimes they're in the wrong language.
Sometimes they relate to past revisions that no longer exist.
The problems with comments are endless.

 

[Richard Bos]

On Thu, 12 Apr 2007 12:12:58 -0700, in comp.lang.c , Keith Thompson


*shrug*. They've always been C++ comments to me, and I'm far too old
to learn a new name for 'em now. :-(

Young whippersnapper... they're BCPL comments.

Richard

 

[jacob navia]

Kelsey Bjarnason a écrit :

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.

C90 is not the C standard since the C99 standard explicitely makes it
obsolete.

 

[Richard Heathfield]

jacob navia said:

C90 is not the C standard since the C99 standard explicitely makes it
obsolete.

This is de jure correct and de facto incorrect.

 

[army1987]

No, I meant c89. I explicitly use -ansi -std=c89 for most of my C code.

So you meant "I perfer c89 for all my stuff, *and* *then* *I* *use*
*C89* when I need to use long long or unsigned long long"?

BTW, aren't -ansi and -std=c89 equivalent?

 

[Tak-Shing Chan]

jacob navia said:



This is de jure correct and de facto incorrect.

Translation: some people use C90 in practice, but this is
actually illegal.

Tak-Shing

 

[Daniel Rudy]

At about the time of 4/12/2007 10:37 AM, Richard Heathfield stated the
following:

Daniel Rudy said:



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

LOL Too bad for those producing the methane. They may not be able to
sit down for weeks from all the burns...

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

 

[Default User]

jacob navia said:



This is de jure correct and de facto incorrect.

So I take you have decided not to flag the posts where you're arguing
with Jacob?




Brian

 

[Daniel Rudy]

At about the time of 4/13/2007 9:30 AM, Tak-Shing Chan stated the following:

Translation: some people use C90 in practice, but this is
actually illegal.

Tak-Shing

And what law says that C90 is illegal?

Even if C99 is the current standard, very few, if anybody uses it. Why?
Because most compilers don't support it, or only support a subset of
the features of C99. This is why code is still written to C89/C90 standard.

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

Default User said:

So I take you have decided not to flag the posts where you're arguing
with Jacob?

Actually, I have decided that I *will* flag articles where this
ridiculous C99 issue arises - let's keep personalities out of it, shall
we? - but on this occasion I simply forgot, for which I apologise.

 

[Richard Heathfield]

Daniel Rudy said:

Tak-Shing Chan stated:
And what law says that C90 is illegal?

He was just taking my 'de jure' analogy too literally, that's all.

 

[Default User]

Default User said:

Actually, I have decided that I will flag articles where this
ridiculous C99 issue arises - let's keep personalities out of it,
shall we? - but on this occasion I simply forgot, for which I
apologise.

Sounds good.




Brian