C99 is not a failure (continued)

J

jacob navia

The most important argument of the people in this group
trying to deny the importance of C99 is that

"There are not enough C99 implementations"

DID YOU KNOW?

There is ONE (yes ONE) full implementation of C++98?
(Edison Design Group front end)

And C++98 is 12 years old, compared to his younger cousin
C99 only 11 years old :)

Would you say that C++98 is a failure? An aborted standard?

I wouldn't say so.

ALL the other implementations of C++98 are PARTIAL implementations,
at different stages of completion.

jacob
 
I

Ian Collins

jacob said:
The most important argument of the people in this group
trying to deny the importance of C99 is that

"There are not enough C99 implementations"

DID YOU KNOW?

There is ONE (yes ONE) full implementation of C++98?
(Edison Design Group front end)

And C++98 is 12 years old, compared to his younger cousin
C99 only 11 years old :)

Would you say that C++98 is a failure? An aborted standard?

I wouldn't say so.

ALL the other implementations of C++98 are PARTIAL implementations,
at different stages of completion.

That's stretching a comparison too far. All bar one C++ compiler are
missing one, rather hard to implement, feature. Any other deviations
from the standard are bugs rather than deliberate omissions.

The key difference, which weakens your comparison is most C++ compiler
vendors have attempted to implement the standard. Unfortunately several
large C compiler vendors have chosen to ignore C99.
 
S

Seebs

The main problem, is rather that two *mainstream* compilers lack support
for C99.

Specifically, gcc's is incomplete.

Although frankly, I haven't cared in a long time. It supports the stuff
I'm using just fine.

-s
 
J

jacob navia

Andrew Poelstra a écrit :
I believe he means gcc.

Gcc implements most of C99 and the places where it diverges from C99 is
in places where gcc implemented features of C99 BEFORE C99. I can
understand that gcc developers are reluctant to reimplement features
that are working and produce problems to gcc's users because the C99
committee decided to implement their features differently.

gcc implements C99. Yes not 100% but then it doesn't implement C++98
to 100% either
 
M

Michael Foukarakis

Gcc has a very good C99 implementation, covring most of the standard.

Your assertion has no base in reality.

*most* being the relevant keyword. Admittedly, *most* missing features
are library issues. Some missing macro names and pragmas, or lack of
optimization for static, aren't important, but extended integer types,
IEC 60559 support, support for error treatment from math library
functions are a big deal.

So, next time you want to establish "reality", get your facts straight
first.
 
W

William Hughes

Andrew Poelstra a écrit :



Gcc implements most of C99 and the places where it diverges from C99 is
in places where gcc implemented features of C99 BEFORE C99. I can
understand that gcc developers are reluctant to reimplement features
that are working and produce problems to gcc's users because the C99
committee decided to implement their features differently.

Which features are you talking about?
gcc implements C99. Yes not 100% but then it doesn't implement C++98
to 100% either

Question, how many C++ compilers would you say
implement the C++98 standard to (the same/a greater)
degree (that/than) gcc implements C99?

- William Hughes
 
S

Seebs

Which features are you talking about?

Outside of C99 mode, gcc has different semantics for inline functions...
except that they changed so that the default is now much more like C99, but
you can still use something like -fgnu89-inline to get the old behavior.
There are/were some subtle differences, I believe, in VLAs and designated
initializers, although I don't know whether any remain. The gcc
implementation of the C99 struct hack had a surprising trait which
contradicted the wording of C99 TC1 but is consistent with the revised wording
in C99 TC3. I don't know whether gcc supports C99 varargs macros; the C99
spec is noticably different, as I recall, from GNU C's previously-existing
varargs macros.

On the other hand, if I look stuff up in C99, and try to use it, it works.
I am sure there are gaps left, I just don't care about them, apparently.

.... and note that this isn't just a matter of new development. For reasons
hard to explain, I have to care about versions of gcc which are, frankly,
ridiculously old, and all my C99-oriented code still works on them,
apparently.

-s
 
W

William Hughes

Outside of C99 mode, gcc has different semantics for inline functions...
except that they changed so that the default is now much more like C99, but
you can still use something like -fgnu89-inline to get the old behavior.
There are/were some subtle differences, I believe, in VLAs and designated
initializers, although I don't know whether any remain.  The gcc
implementation of the C99 struct hack had a surprising trait which
contradicted the wording of C99 TC1 but is consistent with the revised wording
in C99 TC3.  I don't know whether gcc supports C99 varargs macros; the C99
spec is noticably different, as I recall, from GNU C's previously-existing
varargs macros.

On the other hand, if I look stuff up in C99, and try to use it, it works..
I am sure there are gaps left, I just don't care about them, apparently.

... and note that this isn't just a matter of new development.  For reasons
hard to explain, I have to care about versions of gcc which are, frankly,
ridiculously old, and all my C99-oriented code still works on them,
apparently.



Well, I was specifically thinking about inline, macros
with a variable number of arguments, and complex
support, as I understood that gcc had extensions for all
which were not compatible with the C99 standard.
I was surprised to glance at the conformance page
and see these marked as done. At a quick glance I
could not see anything that looked like Jacob Navia's
description, a feature that was not implemented because
of conflict with a pre-existing extension.
Hence the question.

- William Hughes
 
S

Seebs

Well, I was specifically thinking about inline, macros
with a variable number of arguments, and complex
support, as I understood that gcc had extensions for all
which were not compatible with the C99 standard.
I was surprised to glance at the conformance page
and see these marked as done. At a quick glance I
could not see anything that looked like Jacob Navia's
description, a feature that was not implemented because
of conflict with a pre-existing extension.
Hence the question.

Way back in the day, I think there was more of that. During the C99
process, there was poor communication between gcc folks and the standards
team, largely for hysterical raisins. That was back when gcc's maintainers
as a group were more hostile to the standard, and the standard folks as
a group were more dismissive of gcc. (Example from back in the day; the
gcc manual documented some annoying behavior about \ in include names with
the explanation that ANSI required it, but it simply wasn't so. This
kind of thing happened, going both ways.)

I think C99 would have been much improved by the involvement of someone who
was active in the gcc project, but it didn't work out. I remember a few times
we had discussions where someone said "doesn't gcc have a version of this?"
and about all we could come up with was that someone thought it did but no
one quite remembered. Ugh.

-s
 
K

Keith Thompson

Michael Foukarakis said:
*most* being the relevant keyword. Admittedly, *most* missing features
are library issues. Some missing macro names and pragmas, or lack of
optimization for static, aren't important, but extended integer types,
IEC 60559 support, support for error treatment from math library
functions are a big deal.

So, next time you want to establish "reality", get your facts straight
first.

Both extended integer types and IEC 60559 support are optional
features; the lack of them is not a conformance issue.
 
E

Ersek, Laszlo

During the C99 process

Funny this should come up, I wanted to ask about the history of the
standardization process anyway. Perhaps this is a trivia question more
adequate for a tabloid, but I hope it's not completely uninteresting,
considering that Bjarne Stroustrup wrote a complete article in a similar
matter (>>The C++0x "Remove Concepts" Decision<<).

http://www.drdobbs.com/architect/218600111

Who were the people involved? With what (public) backgrounds? How were
they "selected"?

The wikipedia article

http://en.wikipedia.org/wiki/Herbert_Schildt

uses the expression

"Peter Seebach, a former voting member of ISO C committee"

Were there non-voting members? What did the right to vote depend on?

Were committee meetings anything like corporate dev team meetings? (I
ask this in a completely neutral tone.)

I'm not trying to provoke hostility, I'm just curious how it all went.
The rationales sometimes use language that "tells a story", like "the
committee considerd this or that", or "the standard developers came to
the conclusion that so and so", but I'd like to know more.

Thanks,
lacos
 
S

Seebs

Who were the people involved? With what (public) backgrounds? How were
they "selected"?

It gets complicated.

There are two committees, sort of. There's the US ANSI committee, and there's
the ISO committee, but it's more convenient if they have the same meetings,
so they do. The ANSI committee has membership based on paying dues and
choosing to go. Other national bodies have different ways of picking people.
Many technical decisions are decided by "straw poll", where all people
present, whether or not voting, are polled to determine the sense of the
group. Decisions that actually need to be formally made are made by a vote
of national bodies, only officially it's "consensus" of national bodies.

The voting rules for ANSI are that you have to declare intent to be a voting
member, and at any given meeting, you have to have attended two of the last
three meetings (including the current one) to vote. So if you attend every
other meeting, you can vote at the ones you're at.
Were there non-voting members? What did the right to vote depend on?

Choosing to opt for it and attending meetings. Schildt didn't opt for
a voting membership, if I recall correctly, but more significantly, he
never showed up for meetings. I actually made a bit over half the meetings
during the first 9 years or so of my membership.
Were committee meetings anything like corporate dev team meetings? (I
ask this in a completely neutral tone.)

I have no idea. I am reliably assured that $dayjob's work enviroment
is wildly atypical (in a good way).

Committee meetings were, for the large part, pretty fun. Mostly polite,
reasonable, and fairly friendly. I can recall about one instance of real
hostility, involving internal politics in a national delegation. So far
as I know, the right people won that one, although it happened right as
I was dropping out for budget reasons, so I'm not totally sure.

There were various different activities, which were resolved in different
ways. Defect processing worked by splitting into smaller groups to look
at a series of defects and come up with proposed answers, which were then
presented to the committee. People presented things like proposals for
extensions, proposals for alignment with other standards, and so on.

Generally, by the end of the week, decision making had declined in quality,
so there was an effort to schedule hard stuff early and stuff that was less
important late in the week.
I'm not trying to provoke hostility, I'm just curious how it all went.
The rationales sometimes use language that "tells a story", like "the
committee considerd this or that", or "the standard developers came to
the conclusion that so and so", but I'd like to know more.

My views are probably only semi-informed, as a great deal of the material
is social and I tend to miss a big hunk of social face-to-face stuff.

-s
 
C

Chris H

Seebs said:
Committee meetings were, for the large part, pretty fun. Mostly polite,
reasonable, and fairly friendly. I can recall about one instance of real
hostility, involving internal politics in a national delegation. So far
as I know, the right people won that one,

No the right people lost and the panel has closed... Sadly all the
industrial players will not touch the panel (if and when it restarts)
with a barge pole.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,537
Members
45,021
Latest member
AkilahJaim

Latest Threads

Top