C 99 compiler access

J

Joseph Myers

2. C99 features conflicting with existing C89 extensions of many
implementors. The implementors are reluctant to break their users'
code by implementing the C99 semantics of the same feature. See an
older discussion about why GNU C people don't want to change their
compiler according to C99. gcc got quite close to C99 conformance
when version 3.0 was released (over three years ago), but didn't make
any significant progress ever since...

Such conflicts are not a significant obstruction to C99 support in
GCC. Where problems arise, compatibility with old extensions
conflicting with C99 syntax is preserved under -std=gnu89. (For
example, certain uses of compound literals not permitted by C99 are
permitted with -std=gnu89. If C99 inline is implemented, that is
another case where -std=gnu89 would preserve the old semantics.)

When C99 features or other conformance improvements have been added to
GCC over the last four years has been largely determined by when I
have been able to work on implementing them and by the lack of any
funding for C99 or conformance implementation.

To answer some of the other suggestions made about missing and
incomplete C99 support in GCC:

There are no technical difficulties in preserving compatibility with
existing documented and undocumented extensions under appropriate
options, and in maintaining support for past C standard versions under
appropriate options (-std=iso9899:1990, -std=iso9899:199409,
-std=iso9899:1999). (GCC is not following the route apparently
followed by some implementations of abandoning support for older and
more widely used standard versions, nor is it abandoning extensions
without careful individual consideration.)

There are no technical difficulties in supporting C99 through
incremental changes within the current infrastructure.

There are no political objections to supporting the actual standard
rather than drafts.

It may not always be obvious whether a particular ill-designed
extension (documented or undocumented) is something that should be
kept, for compatibility with existing code or because it supports
something that can't be done within the standard, but this is dealt
with, whether or not the extension conflicts with C99, by taking care
to understand the extensions, documented or undocumented, implemented
by compiler code before changing it, so as to avoid removing
extensions by accident, discussing appropriately before removing
extensions and normally deprecating extensions for a release before
removing them if it is thought they may have a significant number of
users. Extensions are not any longer generally liked unless they add
expressive power to the language (e.g., to do machine-dependent things
which standard C cannot do) but consideration for existing users means
we take this care to stay compatible and only remove extensions with
due warning and where they cause trouble for the implementation.
 
M

Mike Wahler

E. Robert Tisdale said:
So the "world" is to blame for the delay in full compliance?

Essentially, yes. The 'market' is to 'blame'. If there's
little or no demand for something, there's not much return for
resources expended in creating it.
So C99 is the standard that nobody wanted?

Seems that way. At least so far. If someone were to prove
unequivocably that they gained a significant increase in
productivity and/or quality as a direct result of using
C99 instead of C89, in more than a narrow application niche,
then I'd expect folks would have more interest in seeing C99
more widely implemented.

-Mike
 
M

Mabden

Dan Pop said:
In <[email protected]> "Mabden"
Allin Cottrell said:
Mabden wrote:

[ that he does not like to see E. Robert Tisdale called a troll ]

ERT's latest foray strikes me as a case of (at least mild)
trolling. Not long ago here there was a serious discussion of the
shortcomings of C99 and the fact that mainstream C compilers do not
support it and do not seem in any hurry to support it. Then ERT
comes along and says, all innocent and without reference to the
previous discussion, "Hey, on my system I have a bunch of compilers
that support C99, why isn't everyone using it? Are they just
dragging their feet?"

Yes I saw that. He claims to work at JPL and has access to many machines of
all kinds that support C99.

If you're not a patent idiot (or a troll on your own) you must be an
alternate net identity of Tisdale.

Ummm... I guess the first one? But I was never patented, so copies of my
idiocy may be reused and distributed freely. BTW, you snipped the bit where
I said someone would call me a troll and / or a sock puppet - are you trying
to appear original, because you are quite predictable.
ERT has explicitly admitted, in a
subsequent post, that none of the compilers he has access to is a
conforming C99 compiler, they merely support all the C99 features *he*
needs. This doesn't make them C99 compilers and this is far from
justifying the usage of C99 features in *portable* C code (which
happens to be the main focus of this newsgroup).

OK, so the "main focus" of this newsgroup is a compiler that doesn't exist?
And the one man who says he has one is ridiculed by all those who don't have
a C99 compiler?

If I admit I feel stupid, will you explain that to me, please?

And, please, TRY to be nicer once in a while.
 
M

Mike Wahler

Mabden said:
OK, so the "main focus" of this newsgroup is a compiler that doesn't
exist?

That's not what he said. He said the main focus is "*portable* C code."
I agree with that.
And the one man who says he has one is ridiculed by all those who don't have
a C99 compiler?

IMO the ridicule is because of his reputation here. Again, note
that he did not enumerate the 'C99 compliant' implementations he has,
so nobody can verify or disprove his claim.
If I admit I feel stupid, will you explain that to me, please?

And, please, TRY to be nicer once in a while.

Dan is Dan. He does seem to rub many folks the wrong way, but
in light of his demonstrated knowledge, I'm glad he's here.

-Mike
 
C

CBFalconer

Joseph said:
.... snip ...

When C99 features or other conformance improvements have been
added to GCC over the last four years has been largely determined
by when I have been able to work on implementing them and by the
lack of any funding for C99 or conformance implementation.
.... snip ...

Excellent. One thing that annoys me (please correct if I am
wrong) is that I understand gcc requires the gnu extensions to
compile itself. It would be a great boost to portability if it
required nothing more than C89 compliance.
 
B

Ben Pfaff

CBFalconer said:
Excellent. One thing that annoys me (please correct if I am
wrong) is that I understand gcc requires the gnu extensions to
compile itself. It would be a great boost to portability if it
required nothing more than C89 compliance.

You are partly right. From http://gcc.gnu.org/install/prerequisites.html:

Tools/packages necessary for building GCC

ISO C90 compiler

Necessary to bootstrap the GCC package, although versions of
GCC prior to 3.4 also allow bootstrapping with a traditional
(K&R) C compiler.

To make all languages in a cross-compiler or other
configuration where 3-stage bootstrap is not performed, you
need to start with an existing GCC binary (version 2.95 or
later) because source code for language frontends other than
C might use GCC extensions.

So you need GCC to compile GCC if you're cross-compiling, but not
otherwise.
 
D

Douglas A. Gwyn

E. Robert Tisdale said:
So C99 is the standard that nobody wanted?

Actually quite a lot of the new stuff in C99 was in
response to "customer" demand. But since it is
almost entirely compatible with C89, there isn't
as much a sense of urgency to get it implemented as
there was for the initial standard. There are C99
implementations (at least they purport to be; I
haven't validated them), and much of the new stuff
has been implemented in not-yet-fully-C99-compliant
implementations. We chose to reaffirm the current
standard for the next several years rather than
work on a major revision, in order to provide more
stability while the transition occurs.
 
B

Brian Inglis

You are partly right. From http://gcc.gnu.org/install/prerequisites.html:

Tools/packages necessary for building GCC

ISO C90 compiler

Necessary to bootstrap the GCC package, although versions of
GCC prior to 3.4 also allow bootstrapping with a traditional
(K&R) C compiler.

To make all languages in a cross-compiler or other ^^^
configuration where 3-stage bootstrap is not performed, you
need to start with an existing GCC binary (version 2.95 or
later) because source code for language frontends other than
^^^^^^^^^^
C might use GCC extensions.

So you need GCC to compile GCC if you're cross-compiling, but not
otherwise.

ISTM that only applies to cross-compiling languages other than C.
IIRC GNU C conditionalizes GCC extensions to allow other compilers to
bootstrap GCC: whereas GNU C may take advantage of GCC extensions if
compiled by GCC, it appears that GNU Ada, C++, Fortran, Java, Pascal
may rely on GCC extensions.
It also seems that as of GCC 3.4, K&R compilers are not supported and
ISO compilers are now required to port GCC. Providing 15 years
transition is pretty reasonable. Looks like GCC 3.3 may be a keeper
for supporting traditional platforms, and providing a transition to
newer versions.
 
T

Thomas Pornin

According to Mike Wahler said:
If someone were to prove unequivocably that they gained a significant
increase in productivity and/or quality as a direct result of using
C99 instead of C89

My company writes cryptographic-related code and my own RSA code is
made much faster by the use of the "unsigned long long" type which
C99 provides, but not C89. Several implementations had the "long
long" before C99, but C99 gives me the guarantee that ultimately, all
compilers which will provide "long long" will do it in a way which is
compatible with C99. This increases portability.


--Thomas Pornin
 
L

lawrence.jones

In comp.std.c James Kuyper said:
Yes. By "the world", what is meant is people who purchase compilers. If
those people really demanded C99 compliance, and refused to purchase
non-compliant compilers, the compiler vendors would rush to accommodate
them. Since there's been no strong demand for C99 compliance, it has
come far more slowly.

There's also essentially no competition in the C compiler market any
more. For any given platform, the choice is typically between the
vendor's compiler and GCC, and that decision is almost never made based
on which supports C99 better. When there's little competition, there's
little incentive.

Another problem is that the resources that used to be dedicated to
supporting C are now typically supporting both C and C++, so there are
fewer resources available.

-Larry Jones

Oh, now don't YOU start on me. -- Calvin
 
E

E. Robert Tisdale

Dan said:
You can safely drop the complexity bit from the picture:
two tiny businesses, Comeau and Dinkumware
have produced an implementation claiming C99 conformance since quite a while.
The bigger vendors could have done it a lot faster.

The real reasons are:

1. Lack of interest from the C community at large.
The development of C99 was mostly politically driven
and little attention was paid to what the C programmers actually needed/wanted.
GNU C extensions of proven value have been completely ignored,
but we've got plenty of Fortran features
with little relevance to the main C problem domains.

2. C99 features conflicting with existing C89 extensions of many implementors.
The implementors are reluctant to break their users' code
by implementing the C99 semantics of the same feature.
See an older discussion
about why GNU C people don't want to change their compiler according to C99.
gcc got quite close to C99 conformance
when version 3.0 was released (over three years ago),
but didn't make any significant progress ever since...
As a result, most implementations have C99 extensions,
but this doesn't help people writing portable code,
as there is no commonly supported subset of C99
(with the possible exception of // comments).

If there was "no commonly supported subset of C99",
I would think that I would be having more trouble porting C99 code
but I'm *not* experiencing any such trouble.
Evidently, I haven't tried to use any of the the features
that aren't implemented yet because they aren't useful to me --
actually, I don't understand all of the new features
and I don't know whether they would be useful to me or not.
It appears to me that there actually *is* a common subset of C99
among the compilers (GNU, Intel, SGI, etc.) that I have used.

Is it really taking much longer to implement C99
than it took to implement C89?

How much longer do you think that it will take
before implementations approach "full" compliance with C99?

Perhaps we need to shelve the C99 standard
and simply describe and document the de facto standard so that
programmers can use the C99 features that are already implemented.
 
L

lawrence.jones

In comp.std.c Dan Pop said:
1. Lack of interest from the C community at large. The development of
C99 was mostly politically driven and little attention was paid to
what the C programmers actually needed/wanted.

That is absolutely untrue.
GNU C extensions of
proven value have been completely ignored, but we've got plenty of
Fortran features with little relevance to the main C problem domains.

It is true that much of C99 was targeted at the numerical community, but
that's because they're the ones that cried loudest and did the work to
create proposals and get them adopted. Numerical programming may be a
boutique market, but it's an important one. And the main reason that C
wasn't used much by that market is because it didn't support them very
well.
2. C99 features conflicting with existing C89 extensions of many
implementors.

Not many implementors, primarily just GCC. That is unfortunate, but not
unsurprising given the historical tendancy of GCC to adopt extensions
with little or no thought given to rigorous definition or to portability
outside the mainstream architectures. Not to mention the historical
disinterest in standards by the GCC developers and user community who
couldn't be bothered to participate in the standardization effort and
even actively opposed it at one time. I hasten to note, however, that
that attitude has now changed significantly, it's just unfortunate that
it didn't happen sooner.

-Larry Jones

Can I take an ax to school tomorrow for ... um ... show and tell? -- Calvin
 
M

Michael Wojcik

Understood, but I feel like I'm in a Monty Python skit at this point.
"An argument is a connected series of statements intended to establish a
proposition. It's not just saying, 'No it isn't.'"

I have seen several responses to your previous posts, including my
own, which contained significant information and were not simply
contradiction. In fact, I don't see anywhere in my post where I
contradicted anything you wrote.
When some one makes a remark on the usenet it may be correct, it may be
false, it may be somewhere in between. You are free to correct the poster,
or ignore the error. But to just post to say, "This guy is a shithead" isn't
helpful.

The "troll alert" messages to which you're objecting alert readers
to an established history of questionable posting. That's not the
simple attack you make it out to be.
Just killfile him and YOU won't have to hear what he has to say, and the
rest of us can go on listening to whomever we choose.

I don't know why you think I don't want to read ERT's posts, or why
you believe my refraining from doing so has any effect on whom you
read.
Now, unfortunately for me, I don't wish to killfile the posters doing it
like CBF, yourself,

I'm sorry, but could you cite these anti-ERT posts of mine? I don't
recall writing them, and Google doesn't appear to have any record of
them.

Someone uncharitable might feel that you are tarring all your
opponents with the same brush. Or that you respond to posts without
reading them carefully first, or that you don't put sufficient
thought into your posts, or that you suffer from delusions.
Fortunately, I am a model of charity.[1]

In fact, I have never even specifically advocated posting such "troll
alerts", as far as I recall. The post to which you responded makes
an argument (two arguments, actually) against advocating surpressing
them, but that is hardly the same thing.
In any case, I am merely stating again,
for anyone still reading, that I don't find any recent posts by ERT to
display any trolling or inappropriate language, but I have seen such
behaviour in those following along behind him issuing harassing missives
behind his back EVERY TIME. That is a troll.

How are public posts "behind his back"?

Also, that's a rather idiosyncratic definition of trolling you're
applying there. If you were to claim, say, that they were ad
hominem arguments, you might be on stronger ground. (They are, of
course, ad hominem arguments. But while argumentum ad hominem is a
*logical* fallacy, it does not follow that all ad hominem arguments
have no value for intellectual work.)
Killfile me if you want, but please killfile ERT first so I don't have to
read your flames about him anymore.

You haven't had to read them in the past. In fact, you haven't been
able to, since they don't exist. Any "flames" I composed regarding
ERT concerned his arguments, and were directed right at him. (And
there don't appear to have been many of those, either.)


1. Note that I didn't claim to be a *working* model. Nor do I mention
at what scale.

--
Michael Wojcik (e-mail address removed)

Pogo: The dogs *scarcely* ever catches the rabbit.
Bun: "Scarcely" got a very unpleasant ring of frequency to it.
-- Walt Kelly
 
M

Mabden

James Kuyper said:
"Mabden" <mabden@sbc_global.net> wrote in message exist?

No, he said it was "portable code", not "a compiler".

<putting on the flame-retardant underwear>

OK, I see, the "code" is portable, but there are no compilers on any of the
"machines" to compile it yet. Right? It is "in theory" portable code, that
will "one day" be compilable everywhere, but not quite yet. And this is the
"main focus" of this newsgroup. Am I getting this right yet...?

....and ERT is a troll for saying he has one?

<leaving underwear on, just in case>
 
M

Mabden

Michael Wojcik said:
I have seen several responses to your previous posts, including my
own, which contained significant information and were not simply
contradiction. In fact, I don't see anywhere in my post where I
contradicted anything you wrote.


Which makes this reply so confusing. Why are you going back and making a new
thread on this old topic. I responded to your last thread, but now we're
getting circular here.
The "troll alert" messages to which you're objecting alert readers
to an established history of questionable posting. That's not the
simple attack you make it out to be.

But what I'm opbjecting to is the AUTOMATIC "troll alert". Every statement
was being followed by a no-content misive (sounds like missile, get it)
"warning". Now, I haven't seen one lately, so I thank those who are laying
off but it was getting old. And tedious. And slightly insulting to readers;
who are "you" (not you personally, but the troll alert posters) to tell me
who's a troll. Will you tell me which books and magazines to read next?!
I don't know why you think I don't want to read ERT's posts, or why
you believe my refraining from doing so has any effect on whom you
read.

Huh? I just don't want the warnings. I like reading from the posters making
the warnings, I mean when they post content.
I'm sorry, but could you cite these anti-ERT posts of mine? I don't
recall writing them, and Google doesn't appear to have any record of
them.

Of course you are right. I apologize for lumping you in with "them". You
actually respond quite respectfully to his posts. Well, mostly. I'm not sure
why we are even talking about this, since you seem to be one of the people
who _doesn't_ do what I'm talking about.

Also, that's a rather idiosyncratic definition of trolling you're
applying there. If you were to claim, say, that they were ad
hominem arguments, you might be on stronger ground. (They are, of
course, ad hominem arguments. But while argumentum ad hominem is a
*logical* fallacy, it does not follow that all ad hominem arguments
have no value for intellectual work.)

Well, I didn't have the correct term, cos I tain't that smart. But that
sounds like what I meant!

You haven't had to read them in the past. In fact, you haven't been
able to, since they don't exist. Any "flames" I composed regarding
ERT concerned his arguments, and were directed right at him. (And
there don't appear to have been many of those, either.)


Again, I didn't mean you. Sorry for the confusion.
 
A

Alan Balmer

An ever more tedious rambling about our bad treatment of poor ERT, who
is at a loss to defend himself.

Please mark this thread Off Topic.
 
K

Kelsey Bjarnason

[snips]

#include <stdlib.h>
int main(int argc, char **argv)
{
int foo[atoi(argv[1])];
}

that will simply invoke undefined behavior if the user enters, say,
'./a.out 1000000' and there's not enough memory to satisfy such a
request?

That does seem like a weird "feature" to add to C99, then, if it
can just fail randomly with no chance of recovery! :(

[xpost to c.s.c added]

Why so strange? This program can fail:

#include <stdio.h>
int main(void)
{
int foo [1000000];
foo [999999] = 42;
printf("%d\n", 42);
}

Granted. However, it seems to me that VLAs are sort of a "lazy man's
malloc", but without the error handling ability.

If we can't check to see if, say, there's 10,000 ints worth of available
memory for allocation, we can't assume we can allocate an array of 10,000
ints - so we can't use a VLA int array of size 10,000. But we can't,
AFAIAA, either check for available memory, or check the results of the
allocation.

Net result, it sems, is that we should stick to malloc: if there isn't
enough room to allocate our 10,000 int array, we'll just get a NULL back
and we can react accordingly.
 
D

Douglas A. Gwyn

Kelsey said:
Granted. However, it seems to me that VLAs are sort of a "lazy man's
malloc", but without the error handling ability.

Used with caution they're no worse than any other auto
variable. Until C gets exceptions there isn't any good
solution to the general stack overrun problem (and even
then, the exception handler might overrun the stack too).
 
M

Mabden

Alan Balmer said:
An ever more tedious rambling about our bad treatment of poor ERT, who
is at a loss to defend himself.

Please mark this thread Off Topic.

Don't worry I'm pretty much done now. Even I got bored reading my posts! ;-)
I started as just a simple request, but kinda blew up around me.
'Nuff said.
 

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

Forum statistics

Threads
474,292
Messages
2,571,494
Members
48,171
Latest member
EllaHolmwo

Latest Threads

Top