C 99 compiler access
E. Robert Tisdale
and they all have pretty good C 99 compilers.
Some people claim that they have not moved to the new standard
because of the lack of C 99 compliant compilers.
Is this just a lame excuse for back-sliding?
Richard Tobin
E. Robert Tisdale <E.Robert...@jpl.nasa.gov> wrote:
>I have access to a wide variety of different platforms here at JPL
>and they all have pretty good C 99 compilers.
If JPL pays me to write some C code for them, I'll bear it in mind.
-- Richard
Eric Sosman
Yes; see Section 1.42.8 paragraph 9. It is permitted
to back-slide to any valid array element or to one element
before the start of the array, provided the element is not
actually referenced. Back-sliding by an amount greater than
the number of padding bits is undefined; "lame" refers to the
condition of the user after blistering his gluteal muscles
by back-sliding with insufficient padding.
However, "excuse" is used only as a synonym for "rationale,"
and as we all know the Rationale is non-normative.
Mac
As I understand it, the argument against moving to C99 rests on the
premise that there is a lack of conforming implementations.
It sounds like you are claiming that there are actually a wide variety
of conforming implementations at your disposal. If this is the case,
then maybe your point is a good one. And it would seem that there is
nothing holding you back from using C99 features in your code.
But just to confirm, do the authors or vendors of the compilers and
libraries you are referring to actually claim C99 conformance for them?
And are they widely available to other people on other platforms?
--Mac
E. Robert Tisdale
I don't even know of *any* implementation
that actually claims C 89/90 compliance (conformance)
let alone C 99 compliance.
That doesn't prevent people from writing C 89/90 code.
So far, the closest to compliance are the Comeau compilers:
http://www.comeaucomputing.com/
I have GNU, MIPSPro and Intel C compilers
that support all of the C99 features that I have found useful so far.
CBFalconer
> E. Robert Tisdale <E.Robert...@jpl.nasa.gov> wrote:
>
>> I have access to a wide variety of different platforms here at
>> JPL and they all have pretty good C 99 compilers.
>
> If JPL pays me to write some C code for them, I'll bear it in
> mind.
Considering the normal accuracy of his comments, I have grave
doubts. You will note he fails to specify the compilers involved,
which makes this just another Trollsdale troll.
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Mike Wahler
news:cgo9lq$m35$1...@nntp1.jpl.nasa.gov...
Why do you believe JPL's 'wide variety' of platforms contains
all those used by everyone else?
-Mike
E. Robert Tisdale
> E. Robert Tisdale wrote:
>
>>I have access to a wide variety of different platforms here at JPL
>>and they all have pretty good C 99 compilers.
>>
>>Some people claim that they have not moved to the new standard
>>because of the lack of C 99 compliant compilers.
>>Is this just a lame excuse for back-sliding?
>
> Why do you believe JPL's 'wide variety' of platforms
> contains all those used by everyone else?
I didn't say that it does.
We might have one of every platform here at JPL
but I'm not sure that we do.
But I'm pretty sure that we have most viable platforms
and I've used C 99 compilers on most of them.
Mike Wahler
> Mike Wahler wrote:
>
> > E. Robert Tisdale wrote:
> >
> >>I have access to a wide variety of different platforms here at JPL
> >>and they all have pretty good C 99 compilers.
> >>
> >>Some people claim that they have not moved to the new standard
> >>because of the lack of C 99 compliant compilers.
> >>Is this just a lame excuse for back-sliding?
> >
> > Why do you believe JPL's 'wide variety' of platforms
> > contains all those used by everyone else?
>
> I didn't say that it does.
> We might have one of every platform here at JPL
> but I'm not sure that we do.
> But I'm pretty sure
Why are you pretty sure?
> that we have most viable platforms
'Viable'? That's subject to context.
> and I've used C 99 compilers on most of them.
So, what's your point? From your original post:
"Some people claim that they have not moved to the new standard
because of the lack of C 99 compliant compilers.
Is this just a lame excuse for back-sliding?"
Who cares if or why someone does or does not use new C99
features? And for some platforms, yes, lack of an implementation
(or at least one of 'acceptable' quality) is indeed a legitimate
reason. But that needn't be the *only* reason. Perhaps
a developer's target platform does have a good C99 implementation
available. Why would someone switch when c90 is still sufficient?
You're implying that not using the 'latest and greatest'
tools, simply because they exist, is somehow 'backsliding'.
That's utter nonsense.
-Mike
Malcolm
"Mike Wahler" <mkwa...@mkwahler.net> wrote
>
> You're implying that not using the 'latest and greatest'
> tools, simply because they exist, is somehow 'backsliding'.
> That's utter nonsense.
>
point in having a "standard" that is not widely implemented. So the present
situation is very undesireable, but it is largely ANSI's fault, because the
extensions were neither so minimal that they could be trivially implemented
(a #define for bool, a vnsprintf() function, etc) nor were like the C++
extensions, very far reaching and offering greatly enhanced functionality.
Instead we had a lot of feature of dubious use which require rewrites of the
compiler. For instance variables can now be declared anywhere, which seems
to be just a way of making code less organised and harder to read, and
variable arrays are allowed. Since a variable length array cannot fail, and
the programmer won't know the array length at run time, this is asking for a
security exploit.
E. Robert Tisdale
> Mike Wahler wrote:
>
>>You're implying that not using the 'latest and greatest'
>>tools, simply because they exist, is somehow 'backsliding'.
>>That's utter nonsense.
>>
> The difference is that C99 was designed by a standards body.
> There is no point in having a "standard" that is not widely implemented.
Which begs the question,
"Is the ANSI/ISO C 99 standard 'widely implemented'?"
It appears to me to be widely implemented now.
> So the present situation is very undesireable but it is largely ANSI's fault
> because the extensions were neither so minimal that they could be trivially implemented
> (a #define for bool, a vnsprintf() function, etc.) nor were like the C++ extensions,
> very far reaching and offering greatly enhanced functionality. Instead,
> we had a lot of feature of dubious use which require rewrites of the compiler.
> For instance, variables can now be declared anywhere,
> which seems to be just a way of making code less organised
> and harder to read, and variable arrays are allowed.
> Since a variable length array cannot fail,
> and the programmer won't know the array length at run time,
> this is asking for a security exploit.
I suppose you would describe yourself as a backslider. :-)
Malcolm
>
under no obligation to defend its actions nor to see that its decisions are
implemented.
The situation is that very few C99 compilers are in existence, five years
after the standard was proposed. I am not going to use what influence I have
to encourage vendors to ship C99-compliant compilers, but on the other hand
if the standard did take off and customers started asking for C99-conforming
code, then I would oblige.
E. Robert Tisdale
> I wasn't on the C99 committee, nor did I make any suggestions to it.
> So I am under no obligation to defend its actions
> nor to see that its decisions are implemented.
> The situation is that very few C99 compilers are in existence
> five years after the standard was proposed.
What do you mean by "very few".
There aren't many C compilers that comply with C 89
fifteen years after the standard was proposed.
> I am not going to use what influence I have
> to encourage vendors to ship C99-compliant compilers
> but, on the other hand, if the standard did take off
> and customers started asking for C99-conforming code,
> then I would oblige.
I think that the C 99 standard is
"backward compatible" with the C 89 standard
so C 89 code is. by definition, "C99-conforming code".
How will you know when the [C 99] standard does "take off"?
What evidence are you looking for?
Maybe it has already "taken off" and you just didn't notice.
Jens.T...@physik.fu-berlin.de
> Malcolm wrote:
>> I wasn't on the C99 committee, nor did I make any suggestions to it.
>> So I am under no obligation to defend its actions
>> nor to see that its decisions are implemented.
>> The situation is that very few C99 compilers are in existence
>> five years after the standard was proposed.
> What do you mean by "very few".
> There aren't many C compilers that comply with C 89
> fifteen years after the standard was proposed.
Can you name just a few commonly used ones that don't?
My impression is that basically all are C89 compliant.
Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.T...@physik.fu-berlin.de
\__________________________ http://www.toerring.de
E. Robert Tisdale
> E. Robert Tisdale wrote:
>
>>What do you mean by "very few".
>>There aren't many C compilers that comply with C 89
>>fifteen years after the standard was proposed.
>
> Can you name just a few commonly used ones that don't?
> My impression is that basically all are C89 compliant.
To my knowledge,
there are no C compilers that claim to be fully compliant
with the ANSI/ISO C 89/90 language standard.
The only C compiler that comes close is the Comeau compiler:
http://www.comeaucomputing.com/
All C compilers come with a disclaimer
something like the one that came with my GNU C compiler:
GCC is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
Do you know of any C compiler that *does* claim to comply
with the ANSI/ISO C 89/90 standard?
Robert Wessel
> I don't even know of *any* implementation
> that actually claims C 89/90 compliance (conformance)
> let alone C 99 compliance.
OK, from page xii of the "C Language Reference" from the MS VC7.0
(circa 1991) package (it was handy):
"ANSI Conformance: Microsoft C version 7.0 conforms to the standard
for the C language as set forth in the American National Standard
(hereinafter referred to as the ANSI C standard). Microsoft
extensions to the ANSI C standard are noted in the text and syntax of
this manual as well as in the online references. Because the
extensions are not a part of the ANSI C standard, their use may
restrict portability of programs between systems. By default the
Microsoft extensions are enabled. To disable the extensions, specify
/Za on the command line. With /Za, all non-ANSI code generates errors
or warnings." (Retyped from the original hardcopy by RW, apologies in
advance for any transcription errors).
Essentially the identical paragraph is included in the online doc of
several of the newer versions of the compiler.
While one might quibble about the degree to which the MS compilers
actual meet that claim, the claim of C89/90 compliance is clearly
made.
Robert Gamble
Can you point out where gcc does not support full c90 compliance? The
documentation implies full conformance to c90:
"GCC supports three versions of the C standard, although support for the
most recent version is not yet complete."
Where the 3 versions are c89/c90, c94/c95, and c99 respectively.
Rob Gamble
Mike Wahler
news:cgqri9$46l$1...@nntp1.jpl.nasa.gov...
>
> I think that the C 99 standard is
> "backward compatible" with the C 89 standard
Nope.
> so C 89 code is. by definition, "C99-conforming code".
The following conforms to C89 but not C99:
main()
{
return 0;
}
-Mike
E. Robert Tisdale
> "GCC supports three versions of the C standard,
> although support for the most recent version is not yet complete."
Can you give us a pointer (URL) for this quote?
Keith Thompson
It's in the documentation provided along with gcc; "info gcc"
and search ('s') for "gcc supports".
See also <http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/Standards.html>.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Flash Gordon
http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/Standards.html#Standards
Also
http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/C-Implementation.html#C%20Implementation
for required documentation on implementation defined behaviour.
For information about the library read
http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/Standard-Libraries.html#Standard%20Libraries
Taking these three things together you have a claim for C89 compliance
on Linux and C95 compliance on Linux.
From the man page of the compiler that is part of the development system
for SCO (spit) Openserver 5.0.7 we have "For example, to request the
complete and strict ANSI C environment, you can use the option
combination -Xc -a ansi". I can't be bothered to track down the full
documentation.
The C compiler by Texas Instruments I used a few years ago for the
TMS320C25 also claimed C89 conformance, obviously as a freestanding
implementation. It mentions ANSI compliance for the latest tools in
http://focus.ti.com/lit/ug/spru376a/spru376a.pdf I don't have the full
documentation as I no longer do embedded development.
I could probably go on finding C compilers claiming ANSI/ISO compliance
either from memory or hunting the web, but I've made the point.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.
Richard Tobin
E. Robert Tisdale <E.Robert...@jpl.nasa.gov> wrote:
>>>There aren't many C compilers that comply with C 89
>>>fifteen years after the standard was proposed.
>> Can you name just a few commonly used ones that don't?
>To my knowledge,
>
> there are no C compilers that claim to be fully compliant
> with the ANSI/ISO C 89/90 language standard.
The question was about whether they comply, not whether they claim to
comply.
-- Richard
Rouben Rostamian
Malcolm <mal...@55bank.freeserve.co.uk> wrote:
[about features introduced in C99]
>Instead we had a lot of feature of dubious use which require rewrites
>of the compiler. For instance variables can now be declared anywhere,
>which seems to be just a way of making code less organised and harder
>to read,
I agree with your statement in general -- declaration of variables
in the middle of a function block can make the code less organized
and harder to follow.
There is one exception, however. The new feature that allows local
declaration of loop indices, as in:
for (int i=0; i<n; i++)
is a positive change. It makes the code easier to read and reduces
name pollution within the body of a function.
--
rr
Ben Pfaff
> Instead we had a lot of feature of dubious use which require rewrites of the
> compiler. For instance variables can now be declared anywhere, which seems
> to be just a way of making code less organised and harder to read, [...]
I disagree. Declaring a variable in mid-block is a valuable way
to reduce the scope of that variable, giving the programmer less
time to screw it up. Furthermore, a variable declared in
mid-block can usually be initialized in the declaration, which
means there's a bigger chance it can be marked `const', which in
turn gives the programmer less to screw up.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
Malcolm
>
> there are no C compilers that claim to be fully compliant
> with the ANSI/ISO C 89/90 language standard.
>
> The only C compiler that comes close is the Comeau compiler:
>
> http://www.comeaucomputing.com/
>
> All C compilers come with a disclaimer
> something like the one that came with my GNU C compiler:
>
> GCC is distributed in the hope that it will be useful,
> but WITHOUT ANY WARRANTY; without even the implied warranty
> of MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> See the GNU General Public License for more details.
>
> Do you know of any C compiler that *does* claim to comply
> with the ANSI/ISO C 89/90 standard?
>
in one particular little area, but for some reason this causes consequential
losses, you can be sued for millions. So the custom has grown up in software
circles of disclaiming fitness "for any particular purpose".
Of course if a program wasn't fit for a particular purpose, then no-one
would buy it. On the other hand I can quite understand Microsoft not wanting
to compensate me for the inconvenience when Windows crashes taking with it
half a day's work.
CBFalconer
> "Malcolm" <mal...@55bank.freeserve.co.uk> writes:
>
>> Instead we had a lot of feature of dubious use which require
>> rewrites of the compiler. For instance variables can now be
>> declared anywhere, which seems to be just a way of making code
>> less organised and harder to read, [...]
>
> I disagree. Declaring a variable in mid-block is a valuable way
> to reduce the scope of that variable, giving the programmer less
> time to screw it up. Furthermore, a variable declared in
> mid-block can usually be initialized in the declaration, which
> means there's a bigger chance it can be marked `const', which in
> turn gives the programmer less to screw up.
To me it is completely unnecessary. The proper answer is to saw
off the block in question and create a new function. Once in a
blue moon you will run into efficiency considerations, but we are
not supposed to be worrying about that here.
Keith Thompson
> Ben Pfaff wrote:
> > "Malcolm" <mal...@55bank.freeserve.co.uk> writes:
> >> Instead we had a lot of feature of dubious use which require
> >> rewrites of the compiler. For instance variables can now be
> >> declared anywhere, which seems to be just a way of making code
> >> less organised and harder to read, [...]
> >
> > I disagree. Declaring a variable in mid-block is a valuable way
> > to reduce the scope of that variable, giving the programmer less
> > time to screw it up. Furthermore, a variable declared in
> > mid-block can usually be initialized in the declaration, which
> > means there's a bigger chance it can be marked `const', which in
> > turn gives the programmer less to screw up.
>
> To me it is completely unnecessary. The proper answer is to saw
> off the block in question and create a new function. Once in a
> blue moon you will run into efficiency considerations, but we are
> not supposed to be worrying about that here.
A much more lightweight approach is to create a new block, not a new
function.
For example:
void foo(void)
{
int x;
statement;
int y;
statement;
}
is equivalent to:
void foo(void)
{
int x;
some_statements;
{
int y;
more_statements;
E. Robert Tisdale
No. If there are any other C compilers
which make ANSI/ISO C 89/90 compliance claims,
other subscribers will let us know.
> but I've made the point.
You have made your point. I agree that
"provides support for" can be interpreted by a reasonable person
as a claim of "compliance with" the ANSI/ISO standards.
I should also point out that it is a *vacuous* claim
when accompanied by a disclaimer
like the one that comes with your GNU C compiler.
I have never heard of a case where the ANSI or ISO
has accused a compiler vendor of claiming compliance
with the ANSI/ISO C 89/90 standard without actually complying.
Minti
"Arthur J. O'Dwyer" <a...@nospam.andrew.cmu.edu> wrote in message
news:Pine.LNX.4.60-041....@unix48.andrew.cmu.edu...
>
> On Sun, 29 Aug 2004, Ben Pfaff wrote:
> >
> > "Malcolm" <mal...@55bank.freeserve.co.uk> writes:
> >> Instead we had a lot of feature of dubious use which require rewrites
of the
> >> compiler. For instance variables can now be declared anywhere, which
seems
> >> to be just a way of making code less organised and harder to read,
[...]
> >
> > I disagree. Declaring a variable in mid-block is a valuable way
> > to reduce the scope of that variable, giving the programmer less
> > time to screw it up. Furthermore, a variable declared in
> > mid-block can usually be initialized in the declaration, which
> > means there's a bigger chance it can be marked `const', which in
> > turn gives the programmer less to screw up.
>
> in C99 for /closing/ the scope of a variable with a minimum of clutter.
> That is, a lot of the time I want to write the equivalent of:
>
> int foo, baz;
> process(foo, baz);
> { /* scope opens */
> int bar = 2*foo+1;
> process2(bar);
> } /* scope closes */
> process(baz, foo);
>
> The above code is valid C90 and C99, but it's ugly (IMHO) because
> the braces and indentation don't actually represent any control
> structure.
> C99 fixes /half/ of the problem by letting me write
>
> int foo, baz;
> process(foo, baz);
> int bar = 2*foo+1; /* scope opens */
> process2(bar);
> process(baz, foo);
>
> but now, as I said, the problem is that there's no way to "close" the
> scope of 'bar' where I intend. 'bar' can be destroyed (by the computer)
> and forgotten about (by the reader) once we get to line 5; unfortunately,
> there's no way to tell the reader that. And in a long function, the
> mental clutter of so many "scope-unclosed" temporary variables can really
> impede understanding. ("Okay, here he's defining 'bar'. And he uses it
> on the next line... and nowhere else? That can't be right... grep grep...
> okay, I guess that is right. Now where was I?")
>
> At least, that's what I find. YMMV.
>
Do you have any suggestions that this may be avoided. I really don't know if
any language does indeed provide the ability to delete/destroy "automatic"
variables. Maybe you could solve the probem using pointers. But then again
YMMV.
--
Imanpreet Singh Arora
"ISINGH AT ACM DOT ORG"
Mike Sullivan
> All C compilers come with a disclaimer
> something like the one that came with my GNU C compiler:
>
> GCC is distributed in the hope that it will be useful,
> but WITHOUT ANY WARRANTY; without even the implied warranty
> of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> See the GNU General Public License for more details.
That disclaimer is based on sections 11 and 12 of the GNU General Public
License. It is included with all GNU software, and applies to all GPL
licensed software, including the Linux kernel. It's not there because
GCC isn't C89 compliant.
Eric Sosman
And for completeness, the following conforms to
C99 but not to C89:
int main(void) {}
Eric Sosman
> "Mike Wahler" <mkwa...@mkwahler.net> wrote
>
>>You're implying that not using the 'latest and greatest'
>>tools, simply because they exist, is somehow 'backsliding'.
>>That's utter nonsense.
>>
>
> The difference is that C99 was designed by a standards body.
... and C89 was designed by ____? I'm having trouble
understanding the distinction.
> There is no
> point in having a "standard" that is not widely implemented. So the present
> situation is very undesireable, but it is largely ANSI's fault,
What did ANSI have to do with C99, other than to adopt the
already-approved ISO standard as an ANSI standard? Are you
arguing that ANSI should have rejected the ISO standard, and
perhaps developed a divergent version?
"The nice thing about standards is that there are so many
of them to choose from." -- Andrew Tanenbaum
Alan Balmer
wrote:
>Richard Tobin wrote:
>> E. Robert Tisdale <E.Robert...@jpl.nasa.gov> wrote:
>>
>>> I have access to a wide variety of different platforms here at
>>> JPL and they all have pretty good C 99 compilers.
>>
>> If JPL pays me to write some C code for them, I'll bear it in
>> mind.
I doubt that there's much danger of that happening. Although I've
never figured out what it is they do pay him for.
>
>Considering the normal accuracy of his comments, I have grave
>doubts. You will note he fails to specify the compilers involved,
>which makes this just another Trollsdale troll.
--
Al Balmer
Balmer Consulting
removebalmerc...@att.net
Dan Pop
> And for completeness, the following conforms to
>C99 but not to C89:
>
> int main(void) {}
Huh?!?
Does it require a diagnostic in C89? Chapter and verse.
Does it invoke undefined behaviour in C89? Chapter and verse.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Eric Sosman
> In <4133407B...@sun.com> Eric Sosman <Eric....@sun.com> writes:
>
>
>> And for completeness, the following conforms to
>>C99 but not to C89:
>>
>> int main(void) {}
>
>
> Huh?!?
>
> Does it require a diagnostic in C89? Chapter and verse.
No; undefined behavior does not require a diagnostic.
1.6 "Definitions of terms".
> Does it invoke undefined behaviour in C89? Chapter and verse.
Yes. 3.6.6.4 "The return statement" says that reaching
a function's closing } is equivalent to executing a return
with no value. 2.1.2.2 "Hosted environment" says that if the
initial invocation of main() executes a return with no value,
the status returned to the host environment is undefined.
1.6 "Definitions of terms" says that using an indeterminately
valued object produces undefined behavior.
If you can argue that the host environment's use of the
termination status isn't a "use," you can probably get along
well with Bill Clinton.
Mabden
news:hip6j0po7bjd01s8o...@4ax.com...
Oh boy, I get to read another "E. Robert Tisdale" is a troll message.
Q. When does pointing out a troll become trolling?
A. Last year.
Everyone knows that statements made on the Internet should be taken with a
grain of salt. M'kay. Get over it. I can find the kill button all by myself,
so STFU.
--
Mabden
Michael Wojcik
In article <2pfmf2F...@uni-berlin.de>, "Minti" <mintisp...@yahoo.com> writes:
>
> "Arthur J. O'Dwyer" <a...@nospam.andrew.cmu.edu> wrote in message
> news:Pine.LNX.4.60-041....@unix48.andrew.cmu.edu...
>
> >
> > int foo, baz;
> > process(foo, baz);
> > int bar = 2*foo+1; /* scope opens */
> > process2(bar);
> > process(baz, foo);
> >
> > but now, as I said, the problem is that there's no way to "close" the
> > scope of 'bar' where I intend. 'bar' can be destroyed (by the computer)
> > and forgotten about (by the reader) once we get to line 5; unfortunately,
> > there's no way to tell the reader that.
>
As Arthur already noted, it can be avoided in any version of C from
C89 on by creating a block. He finds that aesthetically unpleasing,
but I, for one, do not, and you can make your own decision.
> I really don't know if
> any language does indeed provide the ability to delete/destroy "automatic"
> variables.
LISP does, for one, if I understand what you're describing.
--
Michael Wojcik michael...@microfocus.com
I do not care to listen; obloquy injures my self-esteem and I am
skeptical of praise. -- Jack Vance
CBFalconer
>
... snip ...
>
> Oh boy, I get to read another "E. Robert Tisdale" is a troll
> message.
>
> Q. When does pointing out a troll become trolling?
> A. Last year.
>
> Everyone knows that statements made on the Internet should be
> taken with a grain of salt. M'kay. Get over it. I can find the
> kill button all by myself, so STFU.
Unfortunately (or fortunately) there are always newbies appearing
here. Without periodic warnings they would have no idea who
should be listened to and who should not. You may note that not
all of his postings are so marked, because he does occasionally
say something that is not in error.
--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"We have always known that heedless self-interest was bad
morals. We now know that it is bad economics" - FDR
E. Robert Tisdale
> The difference is that C99 was designed by a standards body.
> There is no point in having a "standard" that is not widely implemented.
> So the present situation is very undesireable, but it is largely ANSI's fault,
> because the extensions were neither so minimal that they could be
> trivially implemented (a #define for bool, a vnsprintf() function, etc)
> nor were like the C++ extensions,
> very far reaching and offering greatly enhanced functionality.
> Instead, we had a lot of feature of dubious use
> which require rewrites of the compiler.
> For instance, variables can now be declared anywhere which seems to be
> just a way of making code less organised and harder to read,
> and variable arrays are allowed.
> Since a variable length array cannot fail,
> and the programmer won't know the array length at run time,
> this is asking for a security exploit.
Your indictment of ANSI seems to imply that
it is taking a lot longer for C compiler developers to implement
the C99 standard than it took to implement the C89 standard
and that the blame for the delay belongs [mostly] with ANSI
and *not* with the C compiler developers.
Mabden
news:413392BD...@yahoo.com...
> Mabden wrote:
> > Everyone knows that statements made on the Internet should be
> > taken with a grain of salt. M'kay. Get over it. I can find the
> > kill button all by myself, so STFU.
>
> Unfortunately (or fortunately) there are always newbies appearing
> here. Without periodic warnings they would have no idea who
> should be listened to and who should not.
> You may note that not all of his postings are so marked,
> because he does occasionally
> say something that is not in error.
How benign. Praise you.
I have seen more garbage disposing him (to coin a phrase) than any kind of
erroneous posts and numerous harping on a slight misspelling or nuance that
does not detract from the actual point he was making - just to then add "is
a known troll" - is not helpful to the discussion so why are you "helping".
It has gotten really old, since I find no problem with the post in question,
only with the (mandatory) follow-up posts. Take a breath and google some
responses in the last 3 months. They have no content at all. Just a warning
about trolls. People understand (or come to understand) that the Internet is
an open forum and any maniac may post. Little girls will be seduced, people
will be electrocuted, dogs will be badly trained - all by following advice
from the Internet.
Sorry for the rant, but I am tired of the follow-ons and if you continue it
you will also find the tedium of my follow-ons saying please stop. Of course
there are many of you and only one of me, so I am easier to killfile.
Hmmmm... I will have to think about this.
But please stop. People are able to decide who to listen to, and one person
will not the world change. Or change the world, but it sounded cooler in my
head the other way.
--
Mabden
"Changing the world, one post at a time."
Jack Klein
<a...@nospam.andrew.cmu.edu> wrote in comp.std.c:
>
> On Sat, 28 Aug 2004, Malcolm wrote:
> [...]
> > variable arrays are allowed. Since a variable length array cannot fail,
> > and the programmer won't know the array length at run time, this is
> > asking for a security exploit. ^^^^^^^^^^^
>
> Nit: ITYM "at compile time."
>
> I just checked N869, and I don't see any provision for the failure
> of VLA allocation either. Does that mean that if the programmer writes
>
> #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);
}
Since an array of one million ints has a size greater than 65,535
bytes, no implementation is required to successfully translate and
execute it.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Douglas A. Gwyn
> int foo[atoi(argv[1])];
It's essentially like any other kind of potential
stack overflow, and what occurs upon such overflow
is beyond the scope of the standard.
Malcolm's criticisms (which I saw only embedded in
a later response) were off the mark.
Dan Pop
>Dan Pop wrote:
>> In <4133407B...@sun.com> Eric Sosman <Eric....@sun.com> writes:
>>
>>
>>> And for completeness, the following conforms to
>>>C99 but not to C89:
>>>
>>> int main(void) {}
>>
>>
>> Huh?!?
>>
>> Does it require a diagnostic in C89? Chapter and verse.
>
> No; undefined behavior does not require a diagnostic.
>1.6 "Definitions of terms".
>
>> Does it invoke undefined behaviour in C89? Chapter and verse.
>
> Yes. 3.6.6.4 "The return statement" says that reaching
>a function's closing } is equivalent to executing a return
>with no value. 2.1.2.2 "Hosted environment" says that if the
>initial invocation of main() executes a return with no value,
>the status returned to the host environment is undefined.
>1.6 "Definitions of terms" says that using an indeterminately
>valued object produces undefined behavior.
If the indeterminately valued object is used *by the C program*.
> If you can argue that the host environment's use of the
>termination status isn't a "use," you can probably get along
>well with Bill Clinton.
1. The termination status is not a C object. It's not even a value with
a C type.
2. Since this use of the termination status is outside of the execution
of the C program (the execution of the C program has terminated by
then), the text of the C standard does not apply to it: it is beyond
the scope of the C standard.
Before being sarcastic, make sure that your brain is fully engaged ;-)
Alan Balmer
wrote:
>But please stop. People are able to decide who to listen to, and one person
>will not the world change.
Yes, you are free to read or not read any post here, as are the rest
of us. If you find the writings of any particular person too obnoxious
or tedious, you can killfile them, as I have long ago killfiled Mr.
Tisdale. I am on the verge of finding your writings tedious, as well.
Michael Wojcik
In article <8RPYc.13656$e64....@newssvr27.news.prodigy.com>, "Mabden" <mabden@sbc_global.net> writes:
> "CBFalconer" <cbfal...@yahoo.com> wrote in message
> news:413392BD...@yahoo.com...
> >
> > here. Without periodic warnings they would have no idea who
> > should be listened to and who should not.
>
In this matter you appear to be in the minority of posters to c.l.c
who have expressed an opinion; that being the case, I imagine you'll
have to come up with a stronger argument than "I don't like it".
> People are able to decide who to listen to,
Yes. However, they have historically not been able to make that
decision well, absent any information about the person speaking.
Have people suddenly gained a magic ability to unerringly determine
the value of someone else's statements? I must have missed that.
Usenet is by its nature an antagonistic forum; it does not lend
itself to the gradual building of consensus. (Read some of the
academic work on discourse in this sort of environment if you're
curious why.) Public response is the only direct mechanism available
for vetting the ideas presented in unmoderated newsgroups. Asking
people to refrain from making such responses is tantamount to asking
them to reduce the information content of the group.
--
Michael Wojcik michael...@microfocus.com
_
| 1
| _______ d(cabin) = log cabin + c = houseboat
| (cabin)
_| -- Thomas Pynchon
Mabden
news:ch2hq...@news2.newsguy.com...
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.'"
"Yes it is."
"No, it isn't"
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 messages I'm objecting to have no instructive or constructive
content other than "that guy is a shithead and everyone already knows it, so
I want to be first to say it again".
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.
Now, unfortunately for me, I don't wish to killfile the posters doing it
like CBF, yourself, etc. because they tend to have good comments once in a
while and that's why I read here. But they have this one-sided fight that
seems a little unreasonable to the casual reader of this newsgroup. Perhaps
ERT has mollified (does that mean lightened-up?) in his bad behaviour but he
really hasn't said anything trollish in the last 6 months that I have been
here.
Anyone (including yours truly) can be mistaken and pedantic about a point
they believe correct, and I believe I was called troll in one thread with
another gentleman. I learned a lesson about C through the conversation,
however, and there was no trolling going on, simply extensive requests for
clarification that ended in my enlightenment. So I have felt the sting of
the troll brush, and will probably feel it again for responding to this
post. That or a sock-puppet card. 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.
Killfile me if you want, but please killfile ERT first so I don't have to
read your flames about him anymore.
--
Mabden
Allin Cottrell
[ that he does not like to see E. Robert Tisdale called a troll ]
It seems to me that you can't have been reading this newsgroup very
long, or very carefully.
Of the messages I've seen, saying "So-and-so is a troll, disregard
him", over the last year or so, most have been from ERT himself, and
mostly they have been very silly: a troll accusation issued when
somebody says something he disagrees with.
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?"
Allin Cottrell
Mabden
news:ch3h2m$30s0$1...@f1n1.spenet.wfu.edu...
> Mabden wrote:
>
> [ that he does not like to see E. Robert Tisdale called a troll ]
>
> 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.
I read how some people feel that C99 is not implemented as widely as it
should be. So what is wrong with all the C99 compiler implementations in
your view?
--
Mabden
CBFalconer
>
... snip ...
>
> as it should be. So what is wrong with all the C99 compiler
> implementations in your view?
Back when C89/90 appeared, it was preceded by the appropriate
drafts. The prime market for C (and other) compilers then was
DOS. Among the main competitors were MS, Borland, Zortech,
Watcom, selling roughly in the $200 .. $1000 range. There had
been no standard, and the users demanded standards compliance.
There was fun and profit in supplying that demand.
Today by far the majority of C is developed on either GCC or MS
VC. Only gcc is making an effort to be C99 compliant, on
principle. There is no profit in it, and no overwhelming user
demand, thus no pressure. There is a relatively small market for
embedded cross compilers, some of which still sell for exorbitant
numbers. The chips their output runs on are often incapable of
handling a fully compliant C system, so the compilers do funny and
specialized things. Again, no pressure.
A third factor is the GUI. They are inherently system specific
and have been deliberately made incompatible with standard
practice (at least in the case of MS, i.e. use of winmain, no
stdin/stdout). MS has no great interest in portable code.
15, 20, 25 years ago a good compiler, for any fairly popular
language or close approximation could earn the writer a good
living. Not so today.
Flash Gordon
The fact that they don't exist?
Seriously, only a very few of the implementations used by people other
than ERT claim C99 conformance but nearly all of them claim C89
conformance when invoked correctly.
MS have stated that they do not intend to implement C99 thus eliminating
a significant (although not necessarily the largest) part of the market.
gcc has not fully implemented the language parts of C99 (the libraries
are separate) thus eliminating another large segment.
I currently develop SW for 4 OSs and don't have even 1 C99 compliant
compiler. Admittedly 3 of those are *nix, but I am including both native
compilers and gcc on all the systems in my count.
Also, you should note that ERT has not told us what these compilers are
that he claims to have that support C99. Since he won;t tell us the
claim cannot be verified and is therefor highly suspect.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.
Dan Pop
>"Allin Cottrell" <cott...@wfu.edu> wrote in message
>news:ch3h2m$30s0$1...@f1n1.spenet.wfu.edu...
>> 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. 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).
Alan Balmer
wrote:
>"Allin Cottrell" <cott...@wfu.edu> wrote in message
>news:ch3h2m$30s0$1...@f1n1.spenet.wfu.edu...
>> 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.
>
Did he name those machines, and the C99 implementations that he claims
exist?
>I read how some people feel that C99 is not implemented as widely as it
>should be. So what is wrong with all the C99 compiler implementations in
>your view?
Mostly that with few exceptions, they don't exist. The only compiler
I'm aware of which claims C99 conformance is Comeau, though many
compilers provide support for some of the features. The probability is
that Mr. Tisdale doesn't know what he's talking about, or is simply
trolling, or both. We have seen many examples of all three cases.
Chris Hills
<E.Robert...@jpl.nasa.gov> writes
>Malcolm wrote:
>
>> The difference is that C99 was designed by a standards body.
>> There is no point in having a "standard" that is not widely implemented.
>> So the present situation is very undesireable, but it is largely ANSI's fault,
>> because the extensions were neither so minimal that they could be
>> trivially implemented (a #define for bool, a vnsprintf() function, etc)
>> nor were like the C++ extensions,
>> very far reaching and offering greatly enhanced functionality.
>> Instead, we had a lot of feature of dubious use
>> which require rewrites of the compiler.
>> For instance, variables can now be declared anywhere which seems to be
>> just a way of making code less organised and harder to read,
>> and variable arrays are allowed.
>> Since a variable length array cannot fail,
>> and the programmer won't know the array length at run time,
>> this is asking for a security exploit.
>
>Your indictment of ANSI
It was not an indictment of ANSI.... ANSI is only one of a large number
of National Bodies that make up the ISO WG14 who produce the C standard.
>seems to imply that
>it is taking a lot longer for C compiler developers to implement
>the C99 standard than it took to implement the C89 standard
>and that the blame for the delay belongs [mostly] with ANSI
>and *not* with the C compiler developers.
Well ISO have produced the standard the compiler writers have to work
to. The simpler the standard the easier it is to do.
The compiler writers are (on the whole) commercial if the world really
demanded a C99 compiler the would be more likely to do them faster.
I think it is the complexity coupled with the lack of requirement for a
C99 compiler that is the problem. If there was an industrial/commercial
requirement that we all use C99 compilers they would all be C99
compilers.
There is no black and white in this.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
E. Robert Tisdale
> IE. Robert Tisdale writes
>
>>Malcolm wrote:
>>
>>>The difference is that C99 was designed by a standards body.
>>>There is no point in having a "standard" that is not widely implemented.
>>>So the present situation is very undesireable, but it is largely ANSI's fault,
>>>because the extensions were neither so minimal that they could be
>>>trivially implemented (a #define for bool, a vnsprintf() function, etc)
>>>nor were like the C++ extensions,
>>>very far reaching and offering greatly enhanced functionality.
>>>Instead, we had a lot of feature of dubious use
>>>which require rewrites of the compiler.
>>>For instance, variables can now be declared anywhere which seems to be
>>>just a way of making code less organised and harder to read,
>>>and variable arrays are allowed.
>>>Since a variable length array cannot fail,
>>>and the programmer won't know the array length at run time,
>>>this is asking for a security exploit.
>>
>>Your indictment of ANSI
>
> It was not an indictment of ANSI....
> ANSI is only one of a large number of National Bodies
> that make up the ISO WG14 who produce the C standard.
Malcolm mentions only ANSI.
What fraction of the blame belongs to these other "National Bodies"?
And who are they?
>>seems to imply that
>>it is taking a lot longer for C compiler developers to implement
>>the C99 standard than it took to implement the C89 standard
>>and that the blame for the delay belongs [mostly] with ANSI
>>and *not* with the C compiler developers.
>
> Well, ISO [has] produced the standard
> [that] the compiler writers [must] work to.
> The simpler the standard the easier it is to do.
>
> The compiler writers are, on the whole, commercial. If the world really
> demanded a C99 compiler, they would be more likely to do them faster.
So the "world" is to blame for the delay in full compliance?
> I think it is the complexity coupled with
> the lack of requirement for a C99 compiler that is the problem.
> If there was an industrial/commercial requirement
> that we all use C99 compilers, they would all be C99 compilers.
So C99 is the standard that nobody wanted?
Dan Pop
>I think it is the complexity coupled with the lack of requirement for a
>C99 compiler that is the problem. If there was an industrial/commercial
>requirement that we all use C99 compilers they would all be C99
>compilers.
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).
James Kuyper
> Chris Hills wrote:
...
> Malcolm mentions only ANSI.
> What fraction of the blame belongs to these other "National Bodies"?
ANSI has always played a disproportionately large role in the
development of the C standard, but I don't know how to determine a hard
number describing that disproportion.
> And who are they?
The ISO C committee membership consists of representatives of various
"National Bodies" - each one is responsible for technical standards in
one nation, just as ANSI responsible for technical standards for the
United States.
...
>> The compiler writers are, on the whole, commercial. If the world really
>> demanded a C99 compiler, they would be more likely to do them faster.
>
>
> So the "world" is to blame for the delay in full compliance?
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.
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.
--
Joseph S. Myers
js...@gcc.gnu.org
Mike Wahler
news:ch51jo$jej$1...@nntp1.jpl.nasa.gov...
> >
> > The compiler writers are, on the whole, commercial. If the world really
> > demanded a C99 compiler, they would be more likely to do them faster.
>
> 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.
> > I think it is the complexity coupled with
> > the lack of requirement for a C99 compiler that is the problem.
> > If there was an industrial/commercial requirement
> > that we all use C99 compilers, they would all be C99 compilers.
>
> 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
Mabden
news:ch4eur$1k8$8...@sunnews.cern.ch...
> In <qCdZc.14002$Fn....@newssvr27.news.prodigy.com> "Mabden"
<mabden@sbc_global.net> writes:
>
> >"Allin Cottrell" <cott...@wfu.edu> wrote in message
> >news:ch3h2m$30s0$1...@f1n1.spenet.wfu.edu...
> >> 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.
--
Mabden
Mike Wahler
news:_xtZc.14287$Wd7....@newssvr27.news.prodigy.com...
> "Dan Pop" <Dan...@cern.ch> wrote in message
> news:ch4eur$1k8$8...@sunnews.cern.ch...
> > In <qCdZc.14002$Fn....@newssvr27.news.prodigy.com> "Mabden"
> <mabden@sbc_global.net> writes:
> >
> > 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?
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
CBFalconer
>
... 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.
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.
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Ben Pfaff
> 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.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
Douglas A. Gwyn
> 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.
Brian Inglis
<b...@cs.stanford.edu> wrote:
>CBFalconer <cbfal...@yahoo.com> writes:
>
>> 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.
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.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian....@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
Thomas Pornin
> 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
James Kuyper
> > 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?
No, he said it was "portable code", not "a compiler".
lawrenc...@ugs.com
>
> 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. Robert Tisdale
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.
lawrenc...@ugs.com
>
> 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
Michael Wojcik
In article <1H7Zc.13893$I%4.5...@newssvr27.news.prodigy.com>, "Mabden" <mabden@sbc_global.net> writes:
> "Michael Wojcik" <mwo...@newsguy.com> wrote in message
> news:ch2hq...@news2.newsguy.com...
> >
> > who have expressed an opinion; that being the case, I imagine you'll
> > have to come up with a stronger argument than "I don't like it".
> >
> > > People are able to decide who to listen to,
> >
> > Yes. However, they have historically not been able to make that
> >
> > Usenet is by its nature an antagonistic forum; it does not lend
> > Public response is the only direct mechanism available
> > for vetting the ideas presented in unmoderated newsgroups. Asking
> > people to refrain from making such responses is tantamount to asking
> > them to reduce the information content of the group.
>
> 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 michael...@microfocus.com
Pogo: The dogs *scarcely* ever catches the rabbit.
Bun: "Scarcely" got a very unpleasant ring of frequency to it.
-- Walt Kelly
Mabden
news:8b42afac.04090...@posting.google.com...
<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>
--
Mabden
Mabden
>
> In article <1H7Zc.13893$I%4.5...@newssvr27.news.prodigy.com>, "Mabden"
<mabden@sbc_global.net> writes:
> > "Michael Wojcik" <mwo...@newsguy.com> wrote in message
> > news:ch2hq...@news2.newsguy.com...
> > >
> > > In this matter you appear to be in the minority of posters to c.l.c
> > > who have expressed an opinion; that being the case, I imagine you'll
> > > have to come up with a stronger argument than "I don't like it".
> > >
> > > > People are able to decide who to listen to,
> > >
> > > Yes. However, they have historically not been able to make that
> > > decision well, absent any information about the person speaking....
> > >
> > > Usenet is by its nature an antagonistic forum; it does not lend
> > > itself to the gradual building of consensus....
> > > Public response is the only direct mechanism available
> > > for vetting the ideas presented in unmoderated newsgroups. Asking
> > > people to refrain from making such responses is tantamount to asking
> > > them to reduce the information content of the group.
> >
> > 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.
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.
>
> > 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.
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?!
> > 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.
Huh? I just don't want the warnings. I like reading from the posters making
the warnings, I mean when they post content.
>
> > 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.
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.
<snip>
> 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!
> > 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.)
Again, I didn't mean you. Sorry for the confusion.
--
Mabden
Alan Balmer
wrote:
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.
Kelsey Bjarnason
On Mon, 30 Aug 2004 22:39:34 -0500, Jack Klein wrote:
>> #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.
Douglas A. Gwyn
> 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).
Mabden
news:cgafj0h51ehada3oo...@4ax.com...
> On Thu, 02 Sep 2004 22:40:19 GMT, "Mabden" <mabden@sbc_global.net>
> wrote:
>
> 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.
--
Mabden
CBFalconer
>>
>> 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.
Meanwhile Trollsdale has struck again in another thread.
--
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Dan Pop
>In comp.std.c Dan Pop <Dan...@cern.ch> wrote:
>>
>> 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.
Then, please explain the lack of interest in C99 among the C programming
community at large.
>> 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.
And it was too late to change this state of facts by 1999. Those people
didn't wait for C to provide what they were missing, they simply adopted
either F90 or C++ (or simply contined to use traditional FORTRAN with the
common set of extensions) and kept doing their work.
If the commitee keeps its collective head in the sand instead of
admitting that C99 was a failure and trying to lucidly analyse the reasons
of this failure, chances are that C89 plus a set of extensions becoming a
de facto standard will be the future definition of C as far as the C
programming community at large is concerned and future ISO C standards
will be exercises in futility.
>> 2. C99 features conflicting with existing C89 extensions of many
>> implementors.
>
>Not many implementors, primarily just GCC.
And GNU C is the very last language you'd want a new C standard to
conflict with. Without these conflicts, gcc would have been a conforming
C99 translator by the time gcc 3.0 was released or shortly afterwards and
this would have created the motivation for commercial implementors to
support C99, too. End result: success instead of failure.
Dan Pop
>Granted. However, it seems to me that VLAs are sort of a "lazy man's
>malloc", but without the error handling ability.
OTOH, VLAs are invaluable as function parameters, where there are no
allocation failure issues.
Imagine that you want to write a 2-dim matrix multiplication function,
without knowing the sizes of the matrices. In C89, you have to treat
the matrices as 1-dim arrays and do all the index arithmetic yourself,
impairing the code readability. Or implement the matrices using dope
vectors, which is likely to adversely affect the code performance.
Using VLAs, the code is as straightforward as its Fortran equivalent.
Throw in "restrict" and the performance is likely to match that of the
Fortran code, too.
Joseph Myers
>And GNU C is the very last language you'd want a new C standard to
>conflict with. Without these conflicts, gcc would have been a conforming
>C99 translator by the time gcc 3.0 was released or shortly afterwards and
>this would have created the motivation for commercial implementors to
>support C99, too. End result: success instead of failure.
As I stated in my previous posting on the subject, this is not an
accurate representation of the reasons behind the status of C
standards implementation in GCC. Such conflicts are not an issue; we
are perfectly capable of conditioning choices of conflicting behavior
on command-line options, just as C compilers need to contain
appropriate conditionals for differences between C90 and C99. Examine
what C99 features (and other conformance improvements) have been
implemented when and by whom in GCC over the past four years. Outside
the preprocessor, where the work has been done by other people, you
should see the strong correlation I indicated in my previous message
with when I have been able to work on implementing them, and the lack
of any funding for C99 or conformance implementation. Only a few C99
features have been implemented by other people, who may have had
funding to do so.
You may speculate on the reasons for lack of funded implementation
effort. The most obvious would be that lack of C99 implementations
means lack of users with C99 code, so lack of demand for such
implementations.
GCC does not have a conforming C90 implementation either. I have been
working on this, but whether it is completed comes down to much the
same issues. (Plus the point that guesswork is rather involved in
ascertaining whether it is done or not, given the presumed expense of
third-party conformance testsuites and the apparent restrictions on
any developers who might have access to such disclosing their results
to any who might be working on conformance.)
CBFalconer
>
... snip ...
>
> And GNU C is the very last language you'd want a new C standard
> to conflict with. Without these conflicts, gcc would have been a
> conforming C99 translator by the time gcc 3.0 was released or
> shortly afterwards and this would have created the motivation for
> commercial implementors to support C99, too. End result: success
> instead of failure.
This may be the wrong venue in which to ask, but how many
programmers really use the GNU extensions? I know I have used
only one in one particular package in the past two years, and that
was effectively for a system component. In that case I used
variadic macros, and picked the GNU variety because it would be
more widely available.
Keith Thompson
> Dan Pop wrote:
> >
> ... snip ...
> >
> > And GNU C is the very last language you'd want a new C standard
> > to conflict with. Without these conflicts, gcc would have been a
> > conforming C99 translator by the time gcc 3.0 was released or
> > shortly afterwards and this would have created the motivation for
> > commercial implementors to support C99, too. End result: success
> > instead of failure.
>
> This may be the wrong venue in which to ask, but how many
> programmers really use the GNU extensions? I know I have used
> only one in one particular package in the past two years, and that
> was effectively for a system component. In that case I used
> variadic macros, and picked the GNU variety because it would be
> more widely available.
I rarely do, though I use gcc all the time, because the C code I work
on has be reasonably portable to other compilers.
I think the Linux kernel depends on gcc extensions.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
E. Robert Tisdale
> Then, please explain the lack of interest in C99
> among the C programming community at large.
Which begs the question,
"Is there a lack of interest in C99
among the C programming community at large?
What evidence do you have to support this assertion?
E. Robert Tisdale
Note that this is a direct contradiction of Robert Gamble's assertion:
'The documentation implies full conformance to c90:
"GCC supports three versions of the C standard, although
support for the most recent version is not yet complete."'
> I have been working on this,
> but whether it is completed comes down to much the same issues.
> (Plus the point that guesswork is rather involved
> in ascertaining whether it is done or not,
> given the presumed expense of third-party conformance testsuites
> and the apparent restrictions on any developers
> who might have access to such disclosing their results
> to any who might be working on conformance.)
Actually, Greg Comeau does *not* claim that his compilers comply
with ANSI/ISO standards but that other [authorities] make that claim.
How would you characterize the "pace" of the GNU C 99 implementation.
Is it proceeding more slowly
than the GNU C 89 implementation ten years ago?
Suppose that you got adequate funding tomorrow.
How long would it take to produce an ANSI/ISO compliant C 99 compiler?
Chris Hills
<E.Robert...@jpl.nasa.gov> writes
>Chris Hills wrote:
>
>> IE. Robert Tisdale writes
>>
>>>Malcolm wrote:
>>>
>>>>The difference is that C99 was designed by a standards body.
>>>
>>>Your indictment of ANSI
>>
>> It was not an indictment of ANSI....
>> ANSI is only one of a large number of National Bodies
>> that make up the ISO WG14 who produce the C standard.
>
>Malcolm mentions only ANSI.
>What fraction of the blame belongs to these other "National Bodies"?
>And who are they?
Most countries of the world. ANSI gets one vote like all the rest. The
C standard is an ISO standard.
>>>seems to imply that
>>>it is taking a lot longer for C compiler developers to implement
>>>the C99 standard than it took to implement the C89 standard
>>>and that the blame for the delay belongs [mostly] with ANSI
>>>and *not* with the C compiler developers.
>>
>> Well, ISO [has] produced the standard
>> [that] the compiler writers [must] work to.
>> The simpler the standard the easier it is to do.
>>
>> The compiler writers are, on the whole, commercial. If the world really
>> demanded a C99 compiler, they would be more likely to do them faster.
>
>So the "world" is to blame for the delay in full compliance?
It's a bit of everything...
The ISO committee who produced a standard that is difficult to implement
The SW Industry for not requiring ISO-C compilers.
>> I think it is the complexity coupled with
>> the lack of requirement for a C99 compiler that is the problem.
>> If there was an industrial/commercial requirement
>> that we all use C99 compilers, they would all be C99 compilers.
>
>So C99 is the standard that nobody wanted?
Not at all. It is a standard that not enough people want or have to use.
I note that most of the worlds major embedded compiler writers have
managed to implement MISRA-C compliance in their libraries over the same
period... 1999 to now. And that was from a standing start (there was no
MISRA-C before 1998).
SO it is down to commercial will as much as anything else.
If the industry required ISO-C compilers (as the ADA community require
certified compilers) then we would have them. Though I am informed by
several people who know that the C99 has some serious flaws in it.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills
writes
>In comp.std.c James Kuyper <kuy...@saicmodis.com> wrote:
>>
>> 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,
That is not true. There is a lot of competition. the problem is that
ISO-C compliance is not a high requirement. This is a pity.
However strict conformance to ISO-C would be difficult if not impossible
for a lot of C compilers.
> and that decision is almost never made based
>on which supports C99 better.
That is true. There is no requirement, or rarely any, for an ISO-C
complaint compiler. I think in time this may happen. Unfortunately I
think it will be down to the insurance companies trying to minimise risk
rather than engineering requirements.
>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.
That is not the case.
Chris Hills
writes
>In <uVzpGeA6...@phaedsys.demon.co.uk> Chris Hills <ch...@phaedsys.org>
>writes:
>
>>I think it is the complexity coupled with the lack of requirement for a
>>C99 compiler that is the problem. If there was an industrial/commercial
>>compilers.
>
>You can safely drop the complexity bit from the picture:
I am not so sure about that. I know some people with real concerns about
some parts of the C99 model. (their job is in validation)
>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.
Also the Tasking Tricore compiler.
Has anyone actually validated these two/three compilers?
>
>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).
Not even the // are supported in the same way. :-(
Chris Hills
<cbfal...@yahoo.com> writes
>Joseph Myers wrote:
>>
>... 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.
>
>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.
or even C90
:-)
Chris Hills
writes
>In comp.std.c Dan Pop <Dan...@cern.ch> wrote:
>>
>> 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.
So why aren't C programmers pushing for C99? It C99 was important to
them surely the compiler writers would be producing?
>
>> 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.
I am told there are a lot of problems with the maths in C99. this was by
a mathematician who's arguments was way beyond my ken...
Chris Hills
writes
>In <h2uj02-...@jones.homeip.net> lawrenc...@ugs.com writes:
>
>>In comp.std.c Dan Pop <Dan...@cern.ch> wrote:
>>>
>>> 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.
>
>Then, please explain the lack of interest in C99 among the C programming
>community at large.
This is one of the major problems. There is no requirement to have an
ISO-C compiler. For some reason, unlike the ADA crowd the C community
seems to be a lot less interested in standards and "SW Engineering" as
opposed to "programming"
>If the commitee keeps its collective head in the sand instead of
>admitting that C99 was a failure and trying to lucidly analyse the reasons
>of this failure, chances are that C89 plus a set of extensions becoming a
>de facto standard will be the future definition of C as far as the C
>programming community at large is concerned and future ISO C standards
>will be exercises in futility.
I have heard several C standards people express exactly that thought.
However they are generally not seen in a good light in the main ISO-C
body so I have been told.
Chris Hills
>admitting that C99 was a failure and trying to lucidly analyse the reasons
>of this failure,
> chances are that C89 plus a set of extensions becoming a
>de facto standard will be the future definition of C as far as the C
>programming community at large is concerned and future ISO C standards
>will be exercises in futility.
I know of a team that actually looked at doing that. However pressures
of business and time put a stop to it. A pity.
Chris Hills
<E.Robert...@jpl.nasa.gov> writes
That is easy... None of the compiler writers I know have been asked for
it. They get hundreds/thousands of requests for all sorts of things from
both users, other tool makers and the silicon makes. C99 is not a
requirement that gets raised.
I have talked with several on this matter specifically.
If any of them could see any commercial advantage in producing a C99
compile they would. It is for this reason that most of the worlds major
embedded compiler writers are making their compilers MISRA-C compliant
(MISRA-C was first launched in 1997) and they are eager to tp become
MISRA-C2 compliant even before the new version has been published. (on
the 13th October BTW)
Joseph Myers
E. Robert Tisdale <E.Robert...@jpl.nasa.gov> wrote:
>> GCC does not have a conforming C90 implementation either.
>
>Note that this is a direct contradiction of Robert Gamble's assertion:
>
> 'The documentation implies full conformance to c90:
>
> "GCC supports three versions of the C standard, although
> support for the most recent version is not yet complete."'
I recommend reading the whole of the relevant section of the manual
<http://gcc.gnu.org/onlinedocs/gcc/Standards.html> rather than just an
isolated extract. In particular
For each language compiled by GCC for which there is a standard,
GCC attempts to follow one or more versions of that standard,
possibly with some exceptions, and possibly with some extensions.
and
GCC aims towards being usable as a conforming freestanding
implementation, or as the compiler for a conforming hosted
implementation.
- note the "attempts to follow" and "aims towards".
Support for C99 is not feature-complete (nor fully correct for some
features where there is approximate support for the standard).
Support for C90 is not fully correct, though the language features are
there and most users who do not read comp.std.c may not notice that
constant expression constraints don't work.
>How would you characterize the "pace" of the GNU C 99 implementation.
>Is it proceeding more slowly
>than the GNU C 89 implementation ten years ago?
I do not know the pace of C89 implementation (when GCC development was
done on private mailing lists and with no bug tracking database),
though it evidently finished without getting all the fine details
right.
>Suppose that you got adequate funding tomorrow.
>How long would it take to produce an ANSI/ISO compliant C 99 compiler?
The C99 implementation could be completed in a few months. (That is
for targets with sane floating-point hardware; not 387 floating point
on x86 which makes it hard to do computations in the range and
precision of float / double or round those done in long double to the
range and precision of float / double without storing to memory.)
Ben Pfaff
> This may be the wrong venue in which to ask, but how many
> programmers really use the GNU extensions?
In portable software, I use the GNU extensions that don't hurt if
you don't have them. That's mainly the __attribute__ feature,
which you can conditionalize on __GNUC__. (Although testing
__GNUC__ may be undefined behavior, it would be foolish to claim
to be GNU C without implementing its extensions.)
Low-level system software often has to assume some compiler
anyway because e.g. it needs inline assembly. I'm more liberal
in my use of GNU extensions in such cases because I can't avoid
them anyway.
--
"To get the best out of this book, I strongly recommend that you read it."
--Richard Heathfield
Keith Thompson
[...]
> This is one of the major problems. There is no requirement to have an
> ISO-C compiler. For some reason, unlike the ADA crowd the C community
> seems to be a lot less interested in standards and "SW Engineering" as
> opposed to "programming"
A small off-topic quibble: It's Ada, not ADA. (The name isn't an
acronym.)
Douglas A. Gwyn
> Then, please explain the lack of interest in C99 among the C programming
> community at large.
How do you know there is a "lack of interest"? Have you taken
a scientifically valid poll?
Anyway, until C99 compliance is sufficiently widely available,
it is unlikely to be a project requirement. That alone would
be sufficient to explain any apparent "lack of interest".
Douglas A. Gwyn
> If any of them could see any commercial advantage in producing a C99
> compile they would. It is for this reason that most of the worlds major
> embedded compiler writers are making their compilers MISRA-C compliant
> (MISRA-C was first launched in 1997) and they are eager to tp become
> MISRA-C2 compliant even before the new version has been published. (on
> the 13th October BTW)
Last time I looked, MISRA-C was a set of programming guidelines,
not a compiler specification.
Anyway, there are several compilers that have incorporated C99
features, on a path to full compliance.
Douglas A. Gwyn
> I have heard several C standards people express exactly that thought.
I haven't heard any.