Segmentation Fault....

[Francine.Neary]

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.

<offtopic>

It's interesting to compare the situation with Java, which is the
language they taught me (and in doing so taught me to hate) in my
degree course. There you had a language that started off promisingly,
then was updated to include really big and useful features that were
lacking, but then eventually degenerated into complexity and bloat by
the 5th and 6th generation.

It looks like this is a case of deja vu, and that C had followed the
same pattern before it: first off there's an attractive but
undeveloped new language (K&R C), which then gets solidified and
genuinely improved in the next version (C90/C95), but then eventually
disappears up its own ass and forgets the simplicity that made it
attractive in the first place (C99).

 

[Kelsey Bjarnason]

[snips]

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

The C99 document may state that the C90 standard is obsolete. It can also
state that the moon is made of green cheese; this does not make it so.

In the real world, C90, not C99, is the functional C standard. C99 is
barely implemented, hence useless. At some future point, it may become
commonly - and correctly - implemented; at that point it may become the
actual applicable standard, but not until then.

 

[jacob navia]

Kelsey Bjarnason a écrit :

[snips]

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

The C99 document may state that the C90 standard is obsolete. It can also
state that the moon is made of green cheese; this does not make it so.

In the real world, C90, not C99, is the functional C standard. C99 is
barely implemented, hence useless. At some future point, it may become
commonly - and correctly - implemented; at that point it may become the
actual applicable standard, but not until then.

You are talking nonsense.

Gcc's implementation is almost finished, lacking some very minor details.

IBM and Intel have implemented it in their compilers. Together with HP,
if I remember correctly. Under windows several compilers are available.

To say that is "barely" implemented is nonsense. According to that
criteria C++ is "barely" implemented too, and even much more since
there are VERY FEW (I would say onlytwo) compilers that implement
the WHOLE C++ standard.

 

[Richard Heathfield]

jacob navia said:

Kelsey Bjarnason a écrit :


You are talking nonsense.

No, he isn't.

Gcc's implementation is almost finished, lacking some very minor
details.

Yes, and it has been almost finished, lacking some very minor details,
for some years. The implication is clear.

IBM and Intel have implemented it in their compilers. Together with
HP, if I remember correctly. Under windows several compilers are
available.

Wake me when at least two of Borland, MS, and gcc are C99-conforming.
The others are really just icing sugar, not proper cake.

 

[Kelsey Bjarnason]

[snips]

You are talking nonsense.

Gcc's implementation is almost finished, lacking some very minor
details.

"Almost" - so I don't even have GCC as a C99-conforming compiler. It's
only been what, 8 years? Kinda tells you something, don't it? And let's
not forget that, despite its popularity, GCC is *not* available for every
platform where C code is used.

IBM and Intel have implemented it in their compilers. Together with HP,
if I remember correctly. Under windows several compilers are available.

And every single one of them provides *full* C99 conformance, and does so
correctly? Nope.

To say that is "barely" implemented is nonsense. According to that
criteria C++ is "barely" implemented too, and even much more since there
are VERY FEW (I would say onlytwo) compilers that implement the WHOLE
C++ standard.

The missing features in C++ implementations tend to be common across the
compilers. However, you make the point without even realizing it: some
developers still use C, rather than C++, not because of its technical
superiority, but precisely because they can get good quality C compilers,
with high degrees of conformance to an accepted standard - C90 - in places
they *cannot* get viable C++ compilers.

If you cannot rely on getting a decent C++ or C99 implementation, what do
you do? Write everything in VB? No; you use what actually works: the
one, widely-adopted, generally-well-implemented thing you can expect to
actually find out there: C90. Or give up and switch to VB, ADA, or
Fortran.

C90 is a real-world standard. C99, for all ISO may decree otherwise, is
simply a paper tiger.

 

[David Thompson]

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.

C99 only requires some declaration of a function, not necessarily a
prototype one. Using prototypes for all function declarations and
definitions, in either C90 or C99, is a Good Idea, but not required.

You need to avoid as identifiers the new keywords and the new macros
added to old standard headers that you use (the only ones I recall
offhand are LLONG_MAX et al and va_copy), and it's probably wise to
avoid the (new) macros in new headers in case some external module or
3rd-party library that you use decides to even conditionally #include
some C99 features into its headers.

Officially you need to avoid as external (i.e. linker) names all of
the new library functions, although sane implementions will select a
user entity over a system routine that your code doesn't need.

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

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[jacob navia]

[snips]

You are talking nonsense.

Gcc's implementation is almost finished, lacking some very minor
details.

"Almost" - so I don't even have GCC as a C99-conforming compiler. It's
only been what, 8 years? Kinda tells you something, don't it? And let's
not forget that, despite its popularity, GCC is *not* available for every
platform where C code is used.

Gcc doesn't implement the C++ standard either

So what?

The C++ standard doesn't exist?

None of the commercial databases implement SQL 1999. Most stay at the
level of SQL 1992.

So WHAT?

 

[Kelsey Bjarnason]

[snips]

None of the commercial databases implement SQL 1999. Most stay at the
level of SQL 1992.

So WHAT?

So you must, immediately, convert all your code to SQL 1999, thereby
ensuring it won't work on, well, anything. This makes sense? No; you
stick with what actually *will* work - SQL 1992. Or, as pertains here,
C90.

C99 is, for the time, a pipe dream. C90 is the real world. Paper tigers
don't count; what counts is what gets the code working where it needs to
work. C99 doesn't. C90 does. Simple as that.

 

[Ian Collins]

C99 is, for the time, a pipe dream. C90 is the real world. Paper tigers
don't count; what counts is what gets the code working where it needs to
work. C99 doesn't. C90 does. Simple as that.

I think you should qualify that as "portable C99 is, for the time, a
pipe dream". A lot of C gets written for platforms where C99 (or a high
percentage of it) is supported.

 

[Joe Wright]

I think you should qualify that as "portable C99 is, for the time, a
pipe dream". A lot of C gets written for platforms where C99 (or a high
percentage of it) is supported.

A lot? If you write a C program whose source will be distributed fairly
widely would the program use C99 stuff like VLA's or not?

My C program would not. I will write to C90. My program will have a good
chance of compiling and running with most of the C compilers out there.

A C99 program has a lesser chance. The recipient of the program which
doesn't work for her is left with two options; demand of me a C90
version of the code or modify the C99 code to be C90. With all due
respect, I don't know who she is and I don't want her to attempt C99 to
C90 conversions of my code since she implicitly has little or no C99
experience.

C90 is the clear answer for me.

 

[Ian Collins]

A lot? If you write a C program whose source will be distributed fairly
widely would the program use C99 stuff like VLA's or not?

I'd imaging there is a fair bit of code written for Linux and Solaris.

My C program would not. I will write to C90. My program will have a good
chance of compiling and running with most of the C compilers out there.

Most of the C I write these days is for Solaris, where C99 is
acceptable. Other projects use whatever the client specifies.

That's why I added "portable".

 

[Kelsey Bjarnason]

I think you should qualify that as "portable C99 is, for the time, a
pipe dream". A lot of C gets written for platforms where C99 (or a high
percentage of it) is supported.

No, I meant what I said. Try it this way: define the subset of C99 which
I can write to with a reasonable expectation it will actually work, as
intended, on say five platforms - Windows, OSX, Linux and two more of your
choice - and work, on each of those platforms, with all the major
compilers for that platform.

Now, exactly what subset of C99 are we left with? Can you even define
it? Now try the same with C90.

Any implementation is subject to bugs, fine, we'll agree on that. However
I don't have to ask whether a given C90 implementation features, say,
arrays - it does. Does a given C99 implementation support VLAs fully?

Hmm... gcc's pages tell us entire sets of features are missing or broken.
VLAs... extended identifiers... extend integer types... others...

Visual C++'s C99 conformance seems to be, from what I can see in MSDN,
somewhere between minor and virtually non-existent.

Mingw? Not sure, but I wouldn't bet on it.

Okay, fine: what is the subset of C99 I can expect to get working on GCC,
Microsoft's compiler and Mingw?

Yeah, sure, if you're focusing on a single implementation in a single
environment, you can rely on that specific feature set. If you need to
write code that works elsewhere - different compilers, different
platforms, different OSen - forget it. C99 is a non-starter.

Heck, MS's pet response is, in essence, "We don't care - use C++." Don't
expect what is arguably the most popular compiler in Windows to be C99
conforming any time soon.

If you can't rely on a standard to be implemented, correctly and widely,
then the standard may as well not exist: you're not dealing with a
standard language, you're dealing with implementation-specific extensions.

 

[Kelsey Bjarnason]

[snips]

Most of the C I write these days is for Solaris, where C99 is
acceptable. Other projects use whatever the client specifies.

Most of the C code I write these days is for Linux, using gcc - where C99
support is, according to their own page, missing significant features and
broken in others.

Meanwhile, C90 support might not be perfect... but one thing I don't have
to do is ask whether the most significant features (to me, at least) of the
language even _exist_ in the implementation. They do. They exist in MS's
compiler, Mingw, Intel's C compiler... the list is essentially endless.

 

[Ian Collins]

[snips]

Most of the C I write these days is for Solaris, where C99 is
acceptable. Other projects use whatever the client specifies.

Most of the C code I write these days is for Linux, using gcc - where C99
support is, according to their own page, missing significant features and
broken in others.

You should try Sun Studio, it's free.

Meanwhile, C90 support might not be perfect... but one thing I don't have
to do is ask whether the most significant features (to me, at least) of the
language even _exist_ in the implementation. They do. They exist in MS's
compiler, Mingw, Intel's C compiler... the list is essentially endless.

I think we are in violent agreement that portable C == C90.

 

[Ian Collins]

No, I meant what I said. Try it this way: define the subset of C99 which
I can write to with a reasonable expectation it will actually work, as
intended, on say five platforms - Windows, OSX, Linux and two more of your
choice - and work, on each of those platforms, with all the major
compilers for that platform.

Exactly, portable C99 is a pipe dream. On my platform, I can and do use
C99, so for me, it's reality.

 

[Keith Thompson]

No, I meant what I said. Try it this way: define the subset of C99 which
I can write to with a reasonable expectation it will actually work, as
intended, on say five platforms - Windows, OSX, Linux and two more of your
choice - and work, on each of those platforms, with all the major
compilers for that platform.

Now, exactly what subset of C99 are we left with? Can you even define
it?

[...]

Yes, it's very close to C90.

Remember that most valid C90 code is also valid C99 code. By using
C90, we are not necessarily rejecting C99; we're simply choosing to
use a subset of it.

 

[Kelsey Bjarnason]

[snips]

Now, exactly what subset of C99 are we left with? Can you even define
it?

[...]

Yes, it's very close to C90.

Remember that most valid C90 code is also valid C99 code. By using
C90, we are not necessarily rejecting C99; we're simply choosing to
use a subset of it.

Exactly. However, that doesn't mean we're writing C99 code; it means
we're writing C90 code which simply _happens_ to also be C99 code. The
notion we can ignore C90 and focus on C99, apart from a few strictly
limited cases, is silly.

 

[Keith Thompson]

[snips]

Now, exactly what subset of C99 are we left with? Can you even define
it?

[...]

Yes, it's very close to C90.

Remember that most valid C90 code is also valid C99 code. By using
C90, we are not necessarily rejecting C99; we're simply choosing to
use a subset of it.

Exactly. However, that doesn't mean we're writing C99 code; it means
we're writing C90 code which simply _happens_ to also be C99 code. The
notion we can ignore C90 and focus on C99, apart from a few strictly
limited cases, is silly.

It means we're writing in the intersection of C90 and C99. Yes, the
intersection is much closer to C90 than to C99, but whether we
emphasize C90 or C99 is a matter of choice.