Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > What's the deal with C99?

Reply
Thread Tools

What's the deal with C99?

 
 
Keith Thompson
Guest
Posts: n/a
 
      03-24-2008
"Bartc" <(E-Mail Removed)> writes:
> [from 'The problems in comp.lang.c']
> "Malcolm McLean" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> We're currently in the undesireable situation of having a rejected
>> standard,
>> C99, which means that "standard C" is no longer the precise thing it once
>> was. That doesn't mean it is impossible to hold a coherent discussion. I
>> don't think we can legitimately hold C99 to be off-topic, but we should
>> point out that non-block top declarations are not, de facto, portable.

>
> I've looked at the differences in C99 according to the Wikipedia C article.
>
> It doesn't look like that much to add to C90.
>
> So why the problem with creating compilers for it, is it motivation?


I think motivation is a big part of it.

In the 1980s, there was no C standard other than K&R1. Different
compilers did different things for fundamental features of the
language; for example, I think there was real inconsistency in the
rules for an operator with one signed and one unsigned operand, and
for the semantics of shifts and division for negative operands.
Runtime libraries had differences, subtle and not so subtle. And in
most cases there was no basis for saying that one implementation was
right and another was wrong. Programmers had to use huge nests of
"#ifdef"s to get things to work.

The ANSI standard, released in 1989, changed all this (well, some of
it). It was quickly adopted by vendors. It largely formalized
existing practice, in some cases making specific decisions where
existing practice was inconsistent. The biggest new feature it
introduced (the function prototype) was a clear improvement over what
had gone before.

When ISO introduced the C99 standard, the situation was different.
The C programming community *already* had a standardized language, and
it worked well enough for most purposes.

Compiler vendors aren't in the business of conforming to standards, as
much as we might like that to be the case. They're in the business of
meeting the demands of their customers (and that applies to freeware
compilers such as gcc as well as to commercial compilers). There
wasn't nearly as great a demand for C99 conformance as there had been
for C89/C90 conformance.

[snip]


--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
santosh
Guest
Posts: n/a
 
      03-24-2008
Keith Thompson wrote:
> "Bartc" <(E-Mail Removed)> writes:


>> I've looked at the differences in C99 according to the Wikipedia C
>> article.
>>
>> It doesn't look like that much to add to C90.
>>
>> So why the problem with creating compilers for it, is it motivation?


<snip>

> When ISO introduced the C99 standard, the situation was different.
> The C programming community *already* had a standardized language, and
> it worked well enough for most purposes.
>
> Compiler vendors aren't in the business of conforming to standards, as
> much as we might like that to be the case. They're in the business of
> meeting the demands of their customers (and that applies to freeware
> compilers such as gcc as well as to commercial compilers). There
> wasn't nearly as great a demand for C99 conformance as there had been
> for C89/C90 conformance.


If, as you say, most of the C programming community had a standard with
which they were well pleased and the compiler vendors were pleased that
most of their user base was pleased, why was there another standard at
all? Who were the main driving force behind C99? I was informed that a
section of compiler vendors, users, and other organisations pressed
WG14 for inclusion of greater range of mathematical features, so that
they might replace more of their Fortran code with C, and this was one
of the chief reasons for WG14 to come out with C99. Is this your take
on the matter too? And what of the next, C1x standard in discussion?
Can the community and WG14 ensure that, this time at least, only
features that have the support of a broad swathe of users and compiler
vendors would be added? Should C continue to be a minimalist general
purpose language or should it include specialised support for those
domains that WG14 thinks would constitute the mainstay of C in the
future, at the risk of the language faller further into disuse on
desktops?

 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      03-24-2008
jacob navia <(E-Mail Removed)> writes:
> santosh wrote:
>> Yes. I should have been more precise in what I said. I meant that
>> lcc-win would include only those portions of complex.h which are needed
>> for compiling code involving _Complex, unless of course complex.h was
>> explicitly included by the programmer.
>>
>> But as you say, this might be better placed in a private header or even
>> within the compiler.
>>

>
> Yes, that's a good idea.
>
> I think that in the lexer, the first time I see
> _Complex
> I will include <complexoperators.h>
>
> The standard file
> <complex.h>
> will include
> <complexoperators.h> but define more things like
> I
> and other stuff.


As long as <complexoperators.h> doesn't intrude on user code, that
should be fine. You might run into problems with arithmetic
promotions (are the rules different for functions / overloaded
operators vs. built-in operators?).

Of course you can't include <complexoperators.h> literally the first
time you see _Complex; that could be in the middle of a declaration.
You'd have to retroactively go back and add the header at an
appropriate point, at or near the top of the translation unit, and
re-do the lexical analysis from there. And without a bit more
research, I don't know whether it's possible to encounter a complex
operator without having seen the _Complex keyword.

A simpler solution would be to implicitly include <complexoperators.h>
unconditionally at the top of every translation unit. Since it
declares things that are, as far as the standard is concerned, built
into the language, that might be the best approach.

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      03-24-2008

"Bartc" <(E-Mail Removed)> wrote in message
news:k1MFj.27747$(E-Mail Removed) m...
> Some of the extensions, like Complex support (I've never used complex
> numbers and never will, and I'm sure many others will say the same) are

You've never coded a Mandelbrot? You haven't lived.
>
> really not very interesting; perhaps that should have been optional if it
> made producing the compilers easier.
>

A complex number library is neither here nor there. There's one in my book
Basic Algorithms. The problem with C99 was that the extensions were neither
so trivial as to be doable in a moment, such as adding #defines for true and
false, nor so extensive as to represent a radically improved language that
could be sold for extra money.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      03-24-2008
santosh <(E-Mail Removed)> writes:
> Keith Thompson wrote:
>> "Bartc" <(E-Mail Removed)> writes:

>
>>> I've looked at the differences in C99 according to the Wikipedia C
>>> article.
>>>
>>> It doesn't look like that much to add to C90.
>>>
>>> So why the problem with creating compilers for it, is it motivation?

>
> <snip>
>
>> When ISO introduced the C99 standard, the situation was different.
>> The C programming community *already* had a standardized language, and
>> it worked well enough for most purposes.
>>
>> Compiler vendors aren't in the business of conforming to standards, as
>> much as we might like that to be the case. They're in the business of
>> meeting the demands of their customers (and that applies to freeware
>> compilers such as gcc as well as to commercial compilers). There
>> wasn't nearly as great a demand for C99 conformance as there had been
>> for C89/C90 conformance.

>
> If, as you say, most of the C programming community had a standard with
> which they were well pleased and the compiler vendors were pleased that
> most of their user base was pleased, why was there another standard at
> all? Who were the main driving force behind C99? I was informed that a
> section of compiler vendors, users, and other organisations pressed
> WG14 for inclusion of greater range of mathematical features, so that
> they might replace more of their Fortran code with C, and this was one
> of the chief reasons for WG14 to come out with C99. Is this your take
> on the matter too?


Hmm. I'm not familiar enough with the history to comment on that.

Your account seems to imply that vendors demanded these new features,
and then when they got them in a new standard, they declined to
implement that new standard. Is that really what happened?

> And what of the next, C1x standard in discussion?
> Can the community and WG14 ensure that, this time at least, only
> features that have the support of a broad swathe of users and compiler
> vendors would be added? Should C continue to be a minimalist general
> purpose language or should it include specialised support for those
> domains that WG14 thinks would constitute the mainstay of C in the
> future, at the risk of the language faller further into disuse on
> desktops?


In my opinion, the best chance for the survival of C and for
widespread support for any new standard (note that these are two
different, but related, things) is for C to remain fairly minimalist.
If that makes it a niche language, rather than the universal
programming language it seemed to be a few decades ago, that's not
necessarily a bad thing. (I'm willing to radically change this
opinion at the slightest provocation.)

Of course, what should happen it that the next standard should include
the features *I* like, but reject all other new features in the
interests of simplicity. }

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      03-24-2008
Malcolm McLean wrote:
> A complex number library is neither here nor there. There's one in my
> book Basic Algorithms. The problem with C99 was that the extensions were
> neither so trivial as to be doable in a moment, such as adding #defines
> for true and false, nor so extensive as to represent a radically
> improved language that could be sold for extra money.


The problem is the lack of generality of the proposed changes.

Complex numbers would have been much more interesting in the context
of operator overloading, since that would have allowed ANY kind
of numbers to be defined.

The generic math package proposed by C99 would have been much more
interesting if true generic functions would have been proposed,
that would allow not only a selected set of math functions to be
defined as generic, but ANY function that the user of the language
wants to make generic!

And the problems with the outdated C library remained untouched.
Nothing was done in this respect, not even gets() went away, and is
still there, together with asctime() and many other abominations.




--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
Bartc
Guest
Posts: n/a
 
      03-24-2008

"Malcolm McLean" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "Bartc" <(E-Mail Removed)> wrote in message
> news:k1MFj.27747$(E-Mail Removed) m...
>> Some of the extensions, like Complex support (I've never used complex
>> numbers and never will, and I'm sure many others will say the same) are


> You've never coded a Mandelbrot? You haven't lived.


Of course. But I don't remember complex numbers. If they were needed then I
probably worked with the 2 parts separately.

But, that's all complex numbers are, just a pair of floats given special
treatment.

In that case, why stop there? Far more useful are operations on 3D points
and matrices:

q = m * p; /* transform point p into q */
c = (p+q)/2; /* midpoint of p,q */

instead of the cumbersome:

transformpoint (&m,&p,&q) and so on.

This is where the operator overloads jacob is always on about start to
become useful.

--
Bart


 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      03-24-2008
Keith Thompson wrote:

> santosh <(E-Mail Removed)> writes:
>> Keith Thompson wrote:
>>> "Bartc" <(E-Mail Removed)> writes:

>>
>>>> I've looked at the differences in C99 according to the Wikipedia C
>>>> article.
>>>>
>>>> It doesn't look like that much to add to C90.
>>>>
>>>> So why the problem with creating compilers for it, is it
>>>> motivation?

>>
>> <snip>
>>
>>> When ISO introduced the C99 standard, the situation was different.
>>> The C programming community *already* had a standardized language,
>>> and it worked well enough for most purposes.
>>>
>>> Compiler vendors aren't in the business of conforming to standards,
>>> as
>>> much as we might like that to be the case. They're in the business
>>> of meeting the demands of their customers (and that applies to
>>> freeware
>>> compilers such as gcc as well as to commercial compilers). There
>>> wasn't nearly as great a demand for C99 conformance as there had
>>> been for C89/C90 conformance.

>>
>> If, as you say, most of the C programming community had a standard
>> with which they were well pleased and the compiler vendors were
>> pleased that most of their user base was pleased, why was there
>> another standard at all? Who were the main driving force behind C99?
>> I was informed that a section of compiler vendors, users, and other
>> organisations pressed WG14 for inclusion of greater range of
>> mathematical features, so that they might replace more of their
>> Fortran code with C, and this was one of the chief reasons for WG14
>> to come out with C99. Is this your take on the matter too?

>
> Hmm. I'm not familiar enough with the history to comment on that.
>
> Your account seems to imply that vendors demanded these new features,
> and then when they got them in a new standard, they declined to
> implement that new standard. Is that really what happened?


Well this is what I gathered from various posts here and in comp.std.c:
that it was a fairly small group that lobbied for inclusion of complex
arithmetic, VLAs, fenv.h and tgmath.h.

It does explain (if it is true) why the features listed above are among
the ones that are least widely implemented.

>> And what of the next, C1x standard in discussion?
>> Can the community and WG14 ensure that, this time at least, only
>> features that have the support of a broad swathe of users and
>> compiler vendors would be added? Should C continue to be a minimalist
>> general purpose language or should it include specialised support for
>> those domains that WG14 thinks would constitute the mainstay of C in
>> the future, at the risk of the language faller further into disuse on
>> desktops?

>
> In my opinion, the best chance for the survival of C and for
> widespread support for any new standard (note that these are two
> different, but related, things) is for C to remain fairly minimalist.
> If that makes it a niche language, rather than the universal
> programming language it seemed to be a few decades ago, that's not
> necessarily a bad thing. (I'm willing to radically change this
> opinion at the slightest provocation.)


Maybe C should follow what ISO did for Pascal and include features that
are (or might be) poorly implemented into an "extended" standard for
the language, with the core standard being more or less frozen around
C95?

Then nearly all implementors could have the satisfaction of labelling
their products "fully conforming to the Core C Standard" while
ambitious vendors could implement "the extended C Standard". This way
programmers who want their source to be maximally portable could stick
to the core standard while simultaneously those who want to use widely
implemented but not ubiquitous features could write to the extended
standard.

Features like VLAs, complex arithmetic, fenv.h etc. could be moved to
the extended standard and widely available things like APIs for
traversing directories etc., could be added to it, without
necessitating that either all implementations implement them or risk
being labelled "non-conforming".

<snip humour>

 
Reply With Quote
 
robertwessel2@yahoo.com
Guest
Posts: n/a
 
      03-24-2008
On Mar 24, 7:05*am, (E-Mail Removed) wrote:
> I never understood why Microsoft chose to implement __int64 but *not*
> long long.
> Surely, the semantics aren't the same but the MS operating systems
> don't run on exotic architectures.



MS's __int64 support long predates C99, and "long long" isn't in C++
(yet).

And even as regards C99, it was far from clear until late in the
process if long long was going to be accepted - there was a large, and
very vocal, community that did not want long long in the standard.
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      03-24-2008

"Keith Thompson" <(E-Mail Removed)> wrote in message
> In my opinion, the best chance for the survival of C and for
> widespread support for any new standard (note that these are two
> different, but related, things) is for C to remain fairly minimalist.
> If that makes it a niche language, rather than the universal
> programming language it seemed to be a few decades ago, that's not
> necessarily a bad thing. (I'm willing to radically change this
> opinion at the slightest provocation.)
>
> Of course, what should happen it that the next standard should include
> the features *I* like, but reject all other new features in the
> interests of simplicity. }
>

We need one programming language for everything except the nichiest of niche
areas. I've over twenty years programming experience. Occasionally I have to
knock up little Perl scripts. I find myself puzzling over the Perl handbook
trying to work out how to break out of a loop, or how to sort a list of
files by suffix. Essentially Perl does these things in the same way as C,
but with tiny differences to make it look more like a Unix shell script, or
maybe just to be different to emphasise that it is not C. It's a huge waste
of time. As I said, this is someone with 20 years experience who can't get
his tool to sort files by suffix. However useless the individual concerned,
that would be unacceptable in any other industry. You wouldn't tolerate
eningeers being unable to calculate bolt tolerances because someone had
suddenly decided to use a weird and wonderful new measuring system, or
lawyers unable to read new legislation because the Federal government had
decided on Latin. However we toleratye the same in software.


--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
AMD64 or Semperon, deal or no deal? Tad Confused Computer Information 7 04-13-2006 05:43 PM
deal or no deal rbt Python 7 12-28-2005 08:57 PM
2 for 1 deal on 70-270 jb Microsoft Certification 1 04-07-2005 01:53 AM
Newbie Help: How do I deal with variable length vectors? roninn@gmail.com VHDL 5 03-28-2005 12:33 PM
simple programs to deal with data format, data synchronisation Ram VHDL 1 02-24-2005 05:34 PM



Advertisments