c99 on Microsoft Visual Studio
xuan...@gmail.com
Studio. Anyone know whether Microsoft has any plan to support c99 on
Visual Studio?
Thanks,
Xuan
Jonathan Burd
I haven't come across any compiler completely compliant with the
C'99 standard. Secondly, your question is about whether a particular
implementation supports standard C'99. You should visit the
manufacturer's Website for more information on this. AFAIK, it doesn't.
Regards,
Jonathan.
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
C Library: http://www.dinkumware.com/refxc.html
C99 Standard Draft: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/
"I'm learning to program because then I can write
programs to do my homework faster." - Andy Anfilofieff
BRG
The current version of the Microsoft compiler (v7.1) does not support
many C99 features. As far as I can tell this won't change in v8 (it has
not changed in the v8 beta).
On the other hand the Intel v8 compiler, which can be fully integrated
into Visual Studio, does support many C99 features using the /Qc99 option:
Restricted pointers
Variable-length Arrays
Flexible array members
Complex number support (_Complex keyword)
Hexadecimal floating-point constants
Compound literals
Designated initializers
Mixed declarations and code
Macros with a variable number of arguments
Inline functions (use inline keyword)
Boolean type (_Bool keyword)
These C99 features are NOT supported:
#pragma STDC FP_CONTRACT
#pragma STDC FENV_ACCESS
#pragma STDC CX_LIMITED_RANGE
Brian Gladman
Eltee
> xuan...@gmail.com wrote:
>
>> I want to know the current support status of c99 on Microsoft Visual
>> Studio. Anyone know whether Microsoft has any plan to support c99 on
>> Visual Studio?
>>
>> Thanks,
>>
>> Xuan
>>
>
> I haven't come across any compiler completely compliant with the
> C'99 standard.
Do you mean in general or just for MS Visual Studio?
Lawrence Kirby
> xuan...@gmail.com wrote:
>> I want to know the current support status of c99 on Microsoft Visual
>> Studio. Anyone know whether Microsoft has any plan to support c99 on
>> Visual Studio?
>>
>> Thanks,
>>
>> Xuan
>>
>
> I haven't come across any compiler completely compliant with the
> C'99 standard.
There is no way to verify that a compiler is *completely* compliant with a
standard like C's. It is likely that any piece of software as complex as
a C compiler will contain bugs. What you have in practice is a matter of
support - does the vendor support the full standard?
Lawrence
James McIninch
last year. I don't know what their current plans are.
<posted & mailed>
xuan...@gmail.com wrote:
--
Remove '.nospam' from e-mail address to reply by e-mail
Keith Thompson
> Microsoft had pledged 75% compatiblity with the C standard by 2007. That was
> last year. I don't know what their current plans are.
So CHAR_BIT will be at least 6?
--
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.
Eltee
May I conclude from the "silence" that there is, in fact, no compiler completely
compliant with the C'99 standard?
Michael Wojcik
In article <35c8gfF...@individual.net>, Eltee <el...@hotmail.com> writes:
> Eltee wrote:
> > Jonathan Burd wrote:
> >> xuan...@gmail.com wrote:
> >>
> >>> I want to know the current support status of c99 on Microsoft Visual
> >>> Studio. Anyone know whether Microsoft has any plan to support c99 on
> >>> Visual Studio?
> >>>
> >>
> >> C'99 standard.
> >
> > Do you mean in general or just for MS Visual Studio?
>
> May I conclude from the "silence" that there is, in fact, no compiler
> completely compliant with the C'99 standard?
I don't believe we can stop you.
Whether that's a smart conclusion is another question entirely.
Should you read some of the many past threads in comp.lang.c on this
question (if the question is "compilers in general", and not
"compilers for MS Visual Studio" - a qualification you yourself
raised, but did not clarify in your most recent post), you'd see that
people have identified some implementations that claim to conform to
C99.
Since it is difficult to prove that an implementation is "completely
compliant", I don't expect you'll ever have a definitive answer.
Perhaps it would be better to ask what motivates the question. If I
were to tell you that the utterly obscure Foo compiler for the Bar
system complies with every word of the C99 standard, what good would
that do you? Or, conversely, if I were to say that I have found at
least one instance of non-compliance in every single existing
implementation?
For me, what's useful to know is that five years after the standard
was published, very few implementations comply with it completely;
even more importantly *for me*, implementations I have to use do not
provide the new features of C99, and therefore the C99 standard is
largely irrelevant to the C I write and maintain. I'll be stuck with
C90 for the foreseeable future.
(Actually, it's even worse than that, for some older products I
sometimes do maintenance work on; we have customer support agreements
for those which require that we continue to support *pre-standard*
implementations, so for example the code still has abominable
conditional compilation to suppress generating prototypes when
building for those archaic implementations. Simply ghastly.)
--
Michael Wojcik michael...@microfocus.com
Americans have five disadvantages which you should take into account
before giving us too hard a time:
- We're landlocked
- We're monolingual
- We have poor math and geography skills -- Lucas MacBride
Jonathan Burd
> James McIninch <james.mcin...@comcast.net> writes:
<Snip>
>
> So CHAR_BIT will be at least 6?
>
LOL!
--
Eltee
> In article <35c8gfF...@individual.net>, Eltee <el...@hotmail.com> writes:
>
>>Eltee wrote:
>>
>>>Jonathan Burd wrote:
>>>
>>>>xuan...@gmail.com wrote:
>>>>
>>>>
>>>>>I want to know the current support status of c99 on Microsoft Visual
>>>>>Studio. Anyone know whether Microsoft has any plan to support c99 on
>>>>>Visual Studio?
>>>>>
>>>>
>>>>I haven't come across any compiler completely compliant with the
>>>>C'99 standard.
>>>
>>>Do you mean in general or just for MS Visual Studio?
>>
>>May I conclude from the "silence" that there is, in fact, no compiler
>>completely compliant with the C'99 standard?
>
>
> I don't believe we can stop you.
Stopping me would be easy. Just post a list of C99 compliant compilers. I'm not
demanding any hard proof. A word from an author/implementor/producer would be fine.
> Whether that's a smart conclusion is another question entirely.
?!?
> Should you read some of the many past threads in comp.lang.c on this
> question (if the question is "compilers in general", and not
> "compilers for MS Visual Studio" - a qualification you yourself
> raised, but did not clarify in your most recent post), you'd see that
> people have identified some implementations that claim to conform to
> C99.
>
> Since it is difficult to prove that an implementation is "completely
> compliant", I don't expect you'll ever have a definitive answer.
Like I said: I don't need a proof. For now at least. For now I'd be happy with a
reference implementation that merely claims full compliance.
> Perhaps it would be better to ask what motivates the question.
How about this: software reliability. I write something in C99 relying on some
C99\C90 feature and then I naively think that the running program executes
accordingly.
Could also be something else: if there are no C99 compilers out there ;-) then
the whole C99 "business", including the combined clc expertise so far, is just
academic.
It would be nice to know that all the C99 theorizing has some hard foundation in
practice also.
> If I
> were to tell you that the utterly obscure Foo compiler for the Bar
> system complies with every word of the C99 standard, what good would
> that do you?
I'd at least have hope that someday a C99 compiler could exist even for generaly
used, wide spread, systems.
> Or, conversely, if I were to say that I have found at
> least one instance of non-compliance in every single existing
> implementation?
At least we'd know where we stand.
> For me, what's useful to know is that five years after the standard
> was published, very few implementations comply with it completely;
> even more importantly *for me*, implementations I have to use do not
> provide the new features of C99, and therefore the C99 standard is
> largely irrelevant to the C I write and maintain. I'll be stuck with
> C90 for the foreseeable future.
>
> (Actually, it's even worse than that, for some older products I
> sometimes do maintenance work on; we have customer support agreements
> for those which require that we continue to support *pre-standard*
> implementations, so for example the code still has abominable
> conditional compilation to suppress generating prototypes when
> building for those archaic implementations. Simply ghastly.)
Yup. Ghastly.
Lawrence Kirby
> Michael Wojcik wrote:
...
> Stopping me would be easy. Just post a list of C99 compliant compilers.
Define what you mean by "compliant". Are there any C90 compliant
compilers out there, provably?
> I'm not
> demanding any hard proof. A word from an author/implementor/producer would be fine.
Comeau's C compiler may well qualify for a reasonable definition of
"compliant".
>> Whether that's a smart conclusion is another question entirely.
>
> ?!?
>
>> Should you read some of the many past threads in comp.lang.c on this
>> question (if the question is "compilers in general", and not "compilers
>> for MS Visual Studio" - a qualification you yourself raised, but did
>> not clarify in your most recent post), you'd see that people have
>> identified some implementations that claim to conform to C99.
>>
>> Since it is difficult to prove that an implementation is "completely
>> compliant", I don't expect you'll ever have a definitive answer.
>
> Like I said: I don't need a proof. For now at least. For now I'd be
> happy with a reference implementation that merely claims full
> compliance.
>
>> Perhaps it would be better to ask what motivates the question.
>
> How about this: software reliability. I write something in C99 relying
> on some C99\C90 feature and then I naively think that the running
> program executes accordingly.
>
> Could also be something else: if there are no C99 compilers out there
> ;-) then the whole C99 "business", including the combined clc expertise
> so far, is just academic.
You don't need 100% "compliance" for C99 to be useful. Compilers like gcc
with an appropriate library claim compliance except for some documented
features and situations. It isn't a perfect situation from a code
portability perspective, but it is certainly possible to use new C99
features in current developments.
Lawrence
Randy Howard
lkn...@netactive.co.uk says...
> You don't need 100% "compliance" for C99 to be useful.
You need something closer to it than what is currently available
if you need to write portable code that takes advantage of C99
features. If someone could publish a subset of C99 that is
commonly implemented on say 5 different C compilers that would
be useful. I haven't seen anything like a general trend to
implement any common subset, but I haven't searched for such
a trend either.
With C89/90, the "compliance" is such that it is rare that you
can't get portable code to work on all of them.
> Compilers like gcc with an appropriate library claim compliance
> except for some documented features and situations.
That's fairly vague and weasel-word infected, surely?
> It isn't a perfect situation from a code portability perspective,
> but it is certainly possible to use new C99 features in current
> developments.
Which can be safely used if cross-platform portability (including
those for which gcc is unavailable) is important?
--
Randy Howard (2reply remove FOOBAR)
Eltee
> On Mon, 24 Jan 2005 09:21:11 +0100, Eltee wrote:
>
>
>>Michael Wojcik wrote:
>
>
> ...
>
>
>>Stopping me would be easy. Just post a list of C99 compliant compilers.
>
>
> Define what you mean by "compliant". Are there any C90 compliant
> compilers out there, provably?
I certainly haven't proved it. Then again, seems like no one even claims C99
compliance for their implementations.
>>I'm not
>>demanding any hard proof. A word from an author/implementor/producer would be fine.
>
>
> Comeau's C compiler may well qualify for a reasonable definition of
> "compliant".
Pretty impressive, yes. Founding fa..., that is, members, heh? So now we have
"as close as you can get to full compliance" as our best candidate. Anybody else?
>>>Whether that's a smart conclusion is another question entirely.
>>
>>?!?
>>
>>
>>>Should you read some of the many past threads in comp.lang.c on this
>>>question (if the question is "compilers in general", and not "compilers
>>>for MS Visual Studio" - a qualification you yourself raised, but did
>>>not clarify in your most recent post), you'd see that people have
>>>identified some implementations that claim to conform to C99.
>>>
>>>Since it is difficult to prove that an implementation is "completely
>>>compliant", I don't expect you'll ever have a definitive answer.
>>
>>Like I said: I don't need a proof. For now at least. For now I'd be
>>happy with a reference implementation that merely claims full
>>compliance.
>>
>>
>>>Perhaps it would be better to ask what motivates the question.
>>
>>How about this: software reliability. I write something in C99 relying
>>on some C99\C90 feature and then I naively think that the running
>>program executes accordingly.
>>
>>Could also be something else: if there are no C99 compilers out there
>>;-) then the whole C99 "business", including the combined clc expertise
>>so far, is just academic.
>
>
> You don't need 100% "compliance" for C99 to be useful.
Certainly. It would be nice to know, however, that there's some fully compliant
compiler out there. Might even be slow, producing slow executables, whatever.
Just for comparison.
In mathematics one can define almost anything. Whether one can prove the defined
thing's existence or not, well, that's another matter. Generaly, things without
proven existence aren't very useful in developing further theories, nor regarded
very highly. Analogously, if we take ISO C99 standard as a definition, it'd be
nice to have a reference implementation, thus giving the definition (standard)
some level of consistency. In fact, I'd go even one step further: I'd deny a
specification a title of a standard without a reference implementation. But hey,
that's just me. ;-)
p...@plauger.com
Eltee wrote:
>> Define what you mean by "compliant". Are there any C90 compliant
>> compilers out there, provably?
>
> I certainly haven't proved it. Then again, seems like no one even
claims
> C99 compliance for their implementations.
Uh, the EDG front end plus the Dinkum C Library has been C99 compliant
for several years now. And Perennial, Inc. -- an independent purveyor
of C validation suites -- certified our compliance over two years ago.
(See http://www.peren.com/index.htm.) We have quite a number of joint
customers who are in a position to claim C99 conformance when it suits
them, but each of these has its own release schedule and its own
priorities for what it emphasizes. Meanwhile, you can easily license
the Comeau packaging of the EDG front end, plus our library, and
have a conforming C99 implementation in the comfort of your own home.
(FWIW, this combo is also the only fully compliant C++ compiler I
know of.)
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Eltee
I stand corrected. Fortunately. ;-)
Michael Wojcik
In article <35mr1tF...@individual.net>, Eltee <el...@hotmail.com> writes:
> p...@plauger.com wrote:
> > Eltee wrote:
> >
> >>I certainly haven't proved it. Then again, seems like no one even claims
> >>C99 compliance for their implementations.
> >
> > Uh, the EDG front end plus the Dinkum C Library has been C99 compliant
>
> I stand corrected. Fortunately. ;-)
You stood corrected much earlier in the discussion. I already pointed
out that various people - including myself - had noted conformance
claims from assorted implementors in other threads. Had you simply
searched for them you would have found them.
For example, not long ago I noted that HP claims that the OpenVMS C
compiler conforms to C99.
Of course, if you fail to look for conformance claims, and you ignore
suggestions to do so, then it's not odd that it will appear to you that
no one makes them.
--
Michael Wojcik michael...@microfocus.com
The way things were, were the way things were, and they stayed that way
because they had always been that way. -- Jon Osborne
Greg Comeau
<xuan...@gmail.com> wrote:
>I want to know the current support status of c99 on Microsoft Visual
>Studio.
Current VC has no purposeful support of C99, only of C90.
>Anyone know whether Microsoft has any plan to support c99 on
>Visual Studio?
To the best of my knowledge, their plan is a wait and see plan:
Wait and see if customer demand for it increases,
and wait and see which c99isms make their way into C++0x.
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Greg Comeau
James McIninch <james.mcin...@comcast.net> wrote:
>xuan...@gmail.com wrote:
>> I want to know the current support status of c99 on Microsoft Visual
>> Studio. Anyone know whether Microsoft has any plan to support c99 on
>> Visual Studio?
>
>That was last year. I don't know what their current plans are.
I am unclear what the means. C90 itself is probably 75%
compatible with C99 (that is, C99 is derived from C90,
and so some 75% of C99 already looks exactly the same as C90)??
Do you have the URL where that pledge is made?
Greg Comeau
Michael Wojcik <mwo...@newsguy.com> wrote:
>In article <35c8gfF...@individual.net>, Eltee <el...@hotmail.com> writes:
>> Eltee wrote:
>> > Jonathan Burd wrote:
>> >> xuan...@gmail.com wrote:
>> >>> I want to know the current support status of c99 on Microsoft Visual
>> >>> Studio. Anyone know whether Microsoft has any plan to support c99 on
>> >>> Visual Studio?
>> >>
>> >> I haven't come across any compiler completely compliant with the
>> >> C'99 standard.
>> >
>> > Do you mean in general or just for MS Visual Studio?
>>
>> May I conclude from the "silence" that there is, in fact, no compiler
>> completely compliant with the C'99 standard?
>
>I don't believe we can stop you.
>
>Whether that's a smart conclusion is another question entirely.
>Should you read some of the many past threads in comp.lang.c on this
>question (if the question is "compilers in general", and not
>"compilers for MS Visual Studio" - a qualification you yourself
>raised, but did not clarify in your most recent post), you'd see that
>people have identified some implementations that claim to conform to
>C99.
Indeed.
>Since it is difficult to prove that an implementation is "completely
>compliant", I don't expect you'll ever have a definitive answer.
Which is true of say C90 too then.
>Perhaps it would be better to ask what motivates the question. If I
>were to tell you that the utterly obscure Foo compiler for the Bar
>system complies with every word of the C99 standard, what good would
>that do you?
Conformance in a vaccuum is clearly only of of many issues which
should be considered, agreed.
>Or, conversely, if I were to say that I have found at
>least one instance of non-compliance in every single existing
>implementation?
Probably you can.
>For me, what's useful to know is that five years after the standard
>was published, very few implementations comply with it completely;
>even more importantly *for me*, implementations I have to use do not
>provide the new features of C99, and therefore the C99 standard is
>largely irrelevant to the C I write and maintain. I'll be stuck with
>C90 for the foreseeable future.
Some feel that's a good thing, but yes, some aspects to C99
are circular. I've pointed out previously that I feel it
will be C++ to bring about C99 popularity, but that's still
up in the air too.
>(Actually, it's even worse than that, for some older products I
>sometimes do maintenance work on; we have customer support agreements
>for those which require that we continue to support *pre-standard*
>implementations, so for example the code still has abominable
>conditional compilation to suppress generating prototypes when
>building for those archaic implementations. Simply ghastly.)
But often practical for those projects.
Greg Comeau
>Michael Wojcik wrote:
>> In article <35c8gfF...@individual.net>, Eltee <el...@hotmail.com> writes:
>>>Eltee wrote:
>>>>Jonathan Burd wrote:
>>>>>xuan...@gmail.com wrote:
>>>>>>I want to know the current support status of c99 on Microsoft Visual
>>>>>>Studio. Anyone know whether Microsoft has any plan to support c99 on
>>>>>>Visual Studio?
>>>>>I haven't come across any compiler completely compliant with the
>>>>>C'99 standard.
>>>>Do you mean in general or just for MS Visual Studio?
>>>May I conclude from the "silence" that there is, in fact, no compiler
>>>completely compliant with the C'99 standard?
>> I don't believe we can stop you.
>
>Stopping me would be easy. Just post a list of C99 compliant compilers.
>I'm not demanding any hard proof. A word from an author/implementor/
>producer would be fine.
Here's one: Comeau + Dinkumware. Will even give you the proof! :) :
See the thread tied to http://tinyurl.com/5wmxa
Greg Comeau
Randy Howard <randy...@FOOverizonBAR.net> wrote:
>In article <pan.2005.01.24....@netactive.co.uk>,
>lkn...@netactive.co.uk says...
>> You don't need 100% "compliance" for C99 to be useful.
>
>You need something closer to it than what is currently available
>if you need to write portable code that takes advantage of C99
>features. If someone could publish a subset of C99 that is
>commonly implemented on say 5 different C compilers that would
>be useful. I haven't seen anything like a general trend to
>implement any common subset, but I haven't searched for such
>a trend either.
Comeau, gcc, and Dinkware are available across the most popular
platforms, and that covers at least a reasonable subset.
To increase to 5 compiles, toss in Intel, IBM, Compaq, etc.
>With C89/90, the "compliance" is such that it is rare that you
>can't get portable code to work on all of them.
That's because efforts were made by vendors to target
full C90 compliance. And it happened quicker.
Greg Comeau
>Lawrence Kirby wrote:
>> On Mon, 24 Jan 2005 09:21:11 +0100, Eltee wrote:
>>>Michael Wojcik wrote:
>> ...
>>>Stopping me would be easy. Just post a list of C99 compliant compilers.
>>
>> Define what you mean by "compliant". Are there any C90 compliant
>> compilers out there, provably?
>
>I certainly haven't proved it. Then again, seems like no one even claims C99
>compliance for their implementations.
>
>>>I'm not demanding any hard proof. A word from an
>>>author/implementor/producer would be fine.
>>
>> Comeau's C compiler may well qualify for a reasonable definition of
>> "compliant".
>
>Pretty impressive, yes. Founding fa..., that is, members, heh?
What???
>So now we have
>"as close as you can get to full compliance" as our best candidate.
>Anybody else?
We do believe it is as close as you can get, to C90, to C99,
to C++98, and C++03 (and tons of dialects and compatibility
modes too). For all practical purposes, we are there.
As has been pointed out, 100% conformance is a slippery slope.
Not to mention that even the standards themselves have defects.
Randy Howard
> Comeau, gcc, and Dinkware are available across the most popular
> platforms, and that covers at least a reasonable subset.
gcc (even with the c99 command line options) is not a c99 compiler.
It's "part" of one perhaps, but that's it.
> To increase to 5 compiles, toss in Intel, IBM, Compaq, etc.
Do they implement ALL of C99?
> >With C89/90, the "compliance" is such that it is rare that you
> >can't get portable code to work on all of them.
>
> That's because efforts were made by vendors to target
> full C90 compliance. And it happened quicker.
Exactly the point.
E. Robert Tisdale
> xuanbai98 wrote:
>
>>I want to know the current support status
>>of c99 on Microsoft Visual Studio.
>
> Current VC has no purposeful support of C99, only of C90.
>
>>Anyone know whether Microsoft has any plan
>>to support c99 on Visual Studio?
>
> To the best of my knowledge, their plan is a wait and see plan:
> Wait and see if customer demand for it increases,
> and wait and see which c99isms make their way into C++0x.
Why should C programmers confine themselves
to the capabilities of and inferior product
like Microsoft Visual Studio?
Why don't they just dump it?
An switch to a C99 compliant implementation?
Michael Mair
> Greg Comeau wrote:
>
>> xuanbai98 wrote:
>>
>>> I want to know the current support status
>>> of c99 on Microsoft Visual Studio.
>>
>>
>> Current VC has no purposeful support of C99, only of C90.
>>
>>> Anyone know whether Microsoft has any plan
>>> to support c99 on Visual Studio?
>>
>>
>> To the best of my knowledge, their plan is a wait and see plan:
>> Wait and see if customer demand for it increases,
>> and wait and see which c99isms make their way into C++0x.
>
> Why should C programmers confine themselves
> to the capabilities of and inferior product
> like Microsoft Visual Studio?
Because their company provides it and says this or nothing.
> Why don't they just dump it?
> An switch to a C99 compliant implementation?
Oh, so you did buy the Comeau compiler and the Dinkumware
library on your own and dropped non-conforming gcc?
Maybe we now will more often see quality posts from you.
-Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Eltee
> In article <35mr1tF...@individual.net>, Eltee <el...@hotmail.com> writes:
>
>>p...@plauger.com wrote:
>>
>>>Eltee wrote:
>>>
>>>
>>>>I certainly haven't proved it. Then again, seems like no one even claims
>>>>C99 compliance for their implementations.
>>>
>>>Uh, the EDG front end plus the Dinkum C Library has been C99 compliant
>>>for several years now. ...
>>
>>I stand corrected. Fortunately. ;-)
>
>
> You stood corrected much earlier in the discussion. I already pointed
> out that various people - including myself - had noted conformance
> claims from assorted implementors in other threads.
You failed to specify them, though.
> Had you simply
> searched for them you would have found them.
That's typical for this NG: people are using ZKPs. The quasy-versions, to be
exact. In this case you (personaly) knew (or so you say now) who those
implementors were, yet the only thing you were prepared to
<drumroll>share</drumroll> was the fact that you knew them. Wouldn't it have
been much easyer if you had just listed them? Because, you see, I have been in
too many situations where "somebody knew somebody", if you know what I mean.
> For example, not long ago I noted that HP claims that the OpenVMS C
> compiler conforms to C99.
Not in this thread, though. BTW: why didn't you say that in your first post in
this thread?
Eltee
> In article <35mdjjF...@individual.net>, Eltee <el...@hotmail.com> wrote:
>
>>Lawrence Kirby wrote:
>>
>>>On Mon, 24 Jan 2005 09:21:11 +0100, Eltee wrote:
>>>
>>>>Michael Wojcik wrote:
>>>
>>>...
>>>
>>>>Stopping me would be easy. Just post a list of C99 compliant compilers.
>>>
>>>Define what you mean by "compliant". Are there any C90 compliant
>>>compilers out there, provably?
>>
>>I certainly haven't proved it. Then again, seems like no one even claims C99
>>compliance for their implementations.
>>
>>
>>>>I'm not demanding any hard proof. A word from an
>>>>author/implementor/producer would be fine.
>>>
>>>Comeau's C compiler may well qualify for a reasonable definition of
>>>"compliant".
>>
>>Pretty impressive, yes. Founding fa..., that is, members, heh?
>
>
> What???
http://www.comeaucomputing.com/ : Who is Comeau computing: "We are founding
members of the ANSI/ISO C++ committee".
I was trying to be funny. I guess I failed. Come to think of it: I mentioned the
no-no "word" again. Sorry.
>>So now we have
>>"as close as you can get to full compliance" as our best candidate.
>>Anybody else?
>
>
> We do believe it is as close as you can get, to C90, to C99,
> to C++98, and C++03 (and tons of dialects and compatibility
> modes too). For all practical purposes, we are there.
> As has been pointed out, 100% conformance is a slippery slope.
> Not to mention that even the standards themselves have defects.
I'm particularly interested in ISO C99 standard defects. Would you care to
elaborate?
Chris Croughton
<randy...@FOOverizonBAR.net> wrote:
> In article <ct73u0$a17$1...@panix2.panix.com>, com...@panix.com says...
>> Comeau, gcc, and Dinkware are available across the most popular
>> platforms, and that covers at least a reasonable subset.
>
> gcc (even with the c99 command line options) is not a c99 compiler.
> It's "part" of one perhaps, but that's it.
And doesn't provide the library, which is a large part of the
specification. GLIBC2 is a lot of the way there but still has some
deficiencies.
>> To increase to 5 compiles, toss in Intel, IBM, Compaq, etc.
>
> Do they implement ALL of C99?
Do Compaq have their own compiler?
>> >With C89/90, the "compliance" is such that it is rare that you
>> >can't get portable code to work on all of them.
>>
>> That's because efforts were made by vendors to target
>> full C90 compliance. And it happened quicker.
>
> Exactly the point.
Unless anyone who might want to use my code can use it with their
existing compiler and library, there is no point in my code using any
form of extension to C89. I do, for instance, use some gcc extensions
in code which I know is only intended for use on Unix-like platforms
where gcc is available, but that code is typically unessential things or
ones which can be implemented easily on a compiler which doesn't support
them[1]. There is no point in my using features which require the
instalation of a proprietary compiler and library (it's like web pages
which insist that they can be viewed only with MSIE), unless I can
provide replacements and autoconfiguration to use my versions if the C99
ones are absent (like the types int stdint.h).
[1] Examples: gcc's __PRETTY_FUNCTION__ for tracing code, detecting the
maximum integer size, detecting whether gcc or C99 variable length
arrays are supported...
Chris C
Alan Balmer
>That's typical for this NG: people are using ZKPs. The quasy-versions, to be
>exact. In this case you (personaly) knew (or so you say now) who those
>implementors were, yet the only thing you were prepared to
><drumroll>share</drumroll> was the fact that you knew them. Wouldn't it have
>been much easyer if you had just listed them? Because, you see, I have been in
>too many situations where "somebody knew somebody", if you know what I mean.
Then how could you possibly accept the word of an unknown who thinks
he might remember something? Or should we assume that you are
incapable of doing your own search, even when given the newsgroup to
search in?
You can expect guidance here, but you can't expect people to do all
the work for you.
--
Al Balmer
Balmer Consulting
removebalmerc...@att.net
Michael Wojcik
In article <35p1cbF...@individual.net>, Eltee <el...@hotmail.com> writes:
> Michael Wojcik wrote:
> > In article <35mr1tF...@individual.net>, Eltee <el...@hotmail.com> writes:
> >>I stand corrected. Fortunately. ;-)
> >
> > You stood corrected much earlier in the discussion. I already pointed
> > out that various people - including myself - had noted conformance
> > claims from assorted implementors in other threads.
>
> You failed to specify them, though.
It's not my job to do your research for you. You were wrong; I
pointed out that you were wrong, and noted where you could find the
necessary evidence. Your laziness does not refute my argument.
> > Had you simply searched for them you would have found them.
>
> That's typical for this NG: people are using ZKPs. The quasy-versions, to be
> exact. In this case you (personaly) knew (or so you say now) who those
> implementors were, yet the only thing you were prepared to
> <drumroll>share</drumroll> was the fact that you knew them.
Try reading for comprehension. I told you that *I had posted at
least one example disproving your thesis* in a previous thread, in
this group. That's what you needed, and failed, to search for.
The necessary information had already been shared.
And if you think any of this has anything to do with zero-knowledge
proofs, you're sadly mistaken.
> Wouldn't it have been much easyer if you had just listed them?
Easier for you, perhaps. I don't have any particular motive to make
things easy for you.
> > For example, not long ago I noted that HP claims that the OpenVMS C
> > compiler conforms to C99.
>
> Not in this thread, though.
Yes, that's what I meant by "in other threads".
> BTW: why didn't you say that in your first post in this thread?
Because it should have been sufficient, for any moderately capable
and reasonable reader, to note simply that the relevant information
was available in the archives. And that is what I did.
--
Michael Wojcik michael...@microfocus.com
As always, great patience and a clean work area are required for fulfillment
of this diversion, and it should not be attempted if either are compromised.
-- Chris Ware
Michael Wojcik
In article <ct724b$smm$1...@panix2.panix.com>, com...@panix.com (Greg Comeau) writes:
> In article <csrra...@news1.newsguy.com>,
> Michael Wojcik <mwo...@newsguy.com> wrote:
> >
> >Since it is difficult to prove that an implementation is "completely
> >compliant", I don't expect you'll ever have a definitive answer.
>
> Which is true of say C90 too then.
Agreed. IMO it's not very useful to ask about proof of compliance;
what's useful is to ask whether the vendor has committed to a
compliant implementation, how far they should be trusted to have
provided one, and how likely they are to deal promptly with problems.
> >Or, conversely, if I were to say that I have found at
> >least one instance of non-compliance in every single existing
> >implementation?
>
> Probably you can.
Not me - I'm too lazy. :-)
> >(Actually, it's even worse than that, for some older products I
> >sometimes do maintenance work on; we have customer support agreements
> >for those which require that we continue to support *pre-standard*
> >implementations, so for example the code still has abominable
> >conditional compilation to suppress generating prototypes when
> >building for those archaic implementations. Simply ghastly.)
>
> But often practical for those projects.
True, it's practical, in the sense that we can support those customers
and collect revenue from them. I think it probably makes business
sense; even if the revenue from those platforms isn't sufficient to
recoup the costs of supporting them (and I really have no idea whether
it is), there's value in a reputation for providing long-term support.
It's just ugly, and of course there are some risks (due to argument
promotions) if build errors lead to a mix of prototyped and non-
prototyped modules.
--
Michael Wojcik michael...@microfocus.com
Let's say the conservative is the quiet green grin of the crocodile ...
an' the liberal is the SNAP! -- Walt Kelly
lawrenc...@ugs.com
>
> If someone could publish a subset of C99 that is
> commonly implemented on say 5 different C compilers that would
> be useful.
Inline functions, C++ style comments, and long long?
-Larry Jones
Apparently I was misinformed. -- Calvin
lawrenc...@ugs.com
>
> That's because efforts were made by vendors to target
> full C90 compliance. And it happened quicker.
It certainly started quicker, but I'm not sure that it finished any
quicker. Nearly every implementation touted "ANSI Compatibility" before
the ANSI standard was even finalized, which left them between a rock and
a hard place once the final standard was approved and turned out to be
slightly different from what they had implemented and their user base
now depended on (sound familiar?). Although most implentations were
mostly conforming (if such a thing is possible) fairly quickly, it took
a long time for all of them to get to the point where they were supposed
to be fully conforming. And there were a few that took a long time to
even get started, mostly implementations that were entrenched monopolies
with little or no competition to spur them on (which describes most
extant implementations). There were also some memorable bloopers, like
the implementation whose sole ANSI feature was that it defined __STDC__
as 1!
-Larry Jones
In short, open revolt and exile is the only hope for change? -- Calvin
Greg Comeau
Randy Howard <randy...@FOOverizonBAR.net> wrote:
>In article <ct73u0$a17$1...@panix2.panix.com>, com...@panix.com says...
>> Comeau, gcc, and Dinkware are available across the most popular
>> platforms, and that covers at least a reasonable subset.
>
>gcc (even with the c99 command line options) is not a c99 compiler.
>It's "part" of one perhaps, but that's it.
I feel like I've been tricked. Maybe I misunderstood,
but I thought somebody was asking for a subset of C99 that
could be used across multiple compilers and on multiple
platforms. gcc is definitely not a full c99 compiler,
but I think can meet the _substandard_ 5 features or whatever
that was being requested.
>> To increase to 5 compiles, toss in Intel, IBM, Compaq, etc.
>
>Do they implement ALL of C99?
It's my understanding that those 3 do, or bugs notwithstanding,
at least intend do (which is different than the case of gcc).
>> >With C89/90, the "compliance" is such that it is rare that you
>> >can't get portable code to work on all of them.
>>
>> That's because efforts were made by vendors to target
>> full C90 compliance. And it happened quicker.
>
>Exactly the point.
I'm not convined it's exactly the point, even though I said it,
I just thing it's one aspect of many that leaps out as being
more true than false.
Greg Comeau
E. Robert Tisdale <E.Robert...@jpl.nasa.gov> wrote:
>Greg Comeau wrote:
>> xuanbai98 wrote:
>>>I want to know the current support status
>>>of c99 on Microsoft Visual Studio.
>>
>> Current VC has no purposeful support of C99, only of C90.
>>
>>>Anyone know whether Microsoft has any plan
>>>to support c99 on Visual Studio?
>>
>> To the best of my knowledge, their plan is a wait and see plan:
>> Wait and see if customer demand for it increases,
>> and wait and see which c99isms make their way into C++0x.
>
>Why should C programmers confine themselves
>to the capabilities of and inferior product
>like Microsoft Visual Studio?
Many reasons.
>Why don't they just dump it?
Many people don't have that choice.
>An switch to a C99 compliant implementation?
For many people, C99 doesn't offer the umph that
other "releases of C" have been able to provide,
even when not using an MS C compiler.
I'm trying to be the messager above, so I'm trying
to stay neutral on the provacative aspects of your post.
Greg Comeau
>Greg Comeau wrote:
>> In article <35mdjjF...@individual.net>, Eltee <el...@hotmail.com> wrote:
>>>Lawrence Kirby wrote:
>>>>On Mon, 24 Jan 2005 09:21:11 +0100, Eltee wrote:
>>>>>Michael Wojcik wrote:
>>>>...
>>>>>Stopping me would be easy. Just post a list of C99 compliant compilers.
>>>>Define what you mean by "compliant". Are there any C90 compliant
>>>>compilers out there, provably?
>>>I certainly haven't proved it. Then again, seems like no one
>>>even claims C99 compliance for their implementations.
>>>>>I'm not demanding any hard proof. A word from an
>>>>>author/implementor/producer would be fine.
>>>>
>>>>Comeau's C compiler may well qualify for a reasonable definition of
>>>>"compliant".
>>>
>>>Pretty impressive, yes. Founding fa..., that is, members, heh?
>>
>> What???
>
>http://www.comeaucomputing.com/ : Who is Comeau computing: "We are
>founding members of the ANSI/ISO C++ committee".
We are.
>I was trying to be funny. I guess I failed.
Maybe I'm too biased, but I don't see it.
Fail free to explain, or equally let's just move on.
Greg Comeau
>> In article <35mdjjF...@individual.net>, Eltee <el...@hotmail.com> wrote:
>>>Lawrence Kirby wrote:
>>>>On Mon, 24 Jan 2005 09:21:11 +0100, Eltee wrote:
>>>>>Michael Wojcik wrote:
>>>>Comeau's C compiler may well qualify for a reasonable definition of
>>>>"compliant".
>>>"as close as you can get to full compliance" as our best candidate.
>>>Anybody else?
>>
>> We do believe it is as close as you can get, to C90, to C99,
>> to C++98, and C++03 (and tons of dialects and compatibility
>> modes too). For all practical purposes, we are there.
>> As has been pointed out, 100% conformance is a slippery slope.
>> Not to mention that even the standards themselves have defects.
>
>I'm particularly interested in ISO C99 standard defects.
>Would you care to elaborate?
I'm not sure what you're asking. Generally speaking,
all Standards have conflicting statments, ambiguities,
typos, missed intention, outright errors, etc. C90
had them as does C99. If this is not what you're asking,
elaborate on what your interest in the defects is/are,
and what you would like elaborated, and I'm sure folks
here will chime in appropriately.
Greg Comeau
Chris Croughton <ch...@keristor.net> wrote:
>On Wed, 26 Jan 2005 04:48:37 GMT, Randy Howard
> <randy...@FOOverizonBAR.net> wrote:
>> In article <ct73u0$a17$1...@panix2.panix.com>, com...@panix.com says...
>>> Comeau, gcc, and Dinkware are available across the most popular
>>> platforms, and that covers at least a reasonable subset.
>>
>> gcc (even with the c99 command line options) is not a c99 compiler.
>> It's "part" of one perhaps, but that's it.
>
>And doesn't provide the library, which is a large part of the
>specification. GLIBC2 is a lot of the way there but still has some
>deficiencies.
This suggestion is not intended to change the above fact,
but it's worth pointing out that in addition to use with
Comeau on various platforms, that Dinkumware's C99 library
is available for use with gcc too on various platforms.
E. Robert Tisdale
> I'm trying to be the messager above, so I'm trying
> to stay neutral on the provacative aspects of your post.
You are *not* neutral.
You promote a product that competes with Microsoft Visual Studio.
You might claim to be "objective"
but you are obliged to divulge your biases and self interest.
Eltee
> In article <35p2c7F...@individual.net>, Eltee <el...@hotmail.com> wrote:
>
>>Greg Comeau wrote:
>>
>>>In article <35mdjjF...@individual.net>, Eltee <el...@hotmail.com> wrote:
>>>
>>>>Lawrence Kirby wrote:
>>>>
>>>>>On Mon, 24 Jan 2005 09:21:11 +0100, Eltee wrote:
>>>>>
>>>>>>Michael Wojcik wrote:
>>>>>
>>>>>Comeau's C compiler may well qualify for a reasonable definition of
>>>>>"compliant".
>>>>
>>>>So now we have
>>>>"as close as you can get to full compliance" as our best candidate.
>>>>Anybody else?
>>>
>>>We do believe it is as close as you can get, to C90, to C99,
>>>to C++98, and C++03 (and tons of dialects and compatibility
>>>modes too). For all practical purposes, we are there.
>>>As has been pointed out, 100% conformance is a slippery slope.
>>>Not to mention that even the standards themselves have defects.
>>
>>I'm particularly interested in ISO C99 standard defects.
>>Would you care to elaborate?
>
>
> I'm not sure what you're asking.
I was wondering if you knew any defects in ISO C99 standard. If you do (you
should, since you implemented a compliant compiler), please tell us.
Eltee
> In article <35p1cbF...@individual.net>, Eltee <el...@hotmail.com> writes:
>
>>Michael Wojcik wrote:
>>
>>>In article <35mr1tF...@individual.net>, Eltee <el...@hotmail.com> writes:
>>>
>>>>I stand corrected. Fortunately. ;-)
>>>
>>>You stood corrected much earlier in the discussion. I already pointed
>>>out that various people - including myself - had noted conformance
>>>claims from assorted implementors in other threads.
>>
>>You failed to specify them, though.
>
>
> It's not my job to do your research for you.
Of course not. Just like it's not your job to point out that I was wrong.
Neither is noting where I can find the "necessary evidence". Yet you chose to do
that. Instead of a couple of words (names, urls, whatever) that could resolve
the "issue" in a second, you chose to lecture me about lazyness, incomprehension
and whatnot. Are you always so friendly or just in this case?
> You were wrong; I
> pointed out that you were wrong, and noted where you could find the
> necessary evidence. Your laziness does not refute my argument.
>
>
>>>Had you simply searched for them you would have found them.
>>
>>That's typical for this NG: people are using ZKPs. The quasy-versions, to be
>>exact. In this case you (personaly) knew (or so you say now) who those
>>implementors were, yet the only thing you were prepared to
>><drumroll>share</drumroll> was the fact that you knew them.
>
>
> Try reading for comprehension. I told you that *I had posted at
> least one example disproving your thesis*
My _thesis_? That's a bit strong of a word, don't you find?
> in a previous thread, in
> this group. That's what you needed, and failed, to search for.
>
> The necessary information had already been shared.
>
> And if you think any of this has anything to do with zero-knowledge
> proofs, you're sadly mistaken.
>
>
>>Wouldn't it have been much easyer if you had just listed them?
>
>
> Easier for you, perhaps. I don't have any particular motive to make
> things easy for you.
Thanks a million, Michael.
>>>For example, not long ago I noted that HP claims that the OpenVMS C
>>>compiler conforms to C99.
>>
>>Not in this thread, though.
>
>
> Yes, that's what I meant by "in other threads".
>
>
>>BTW: why didn't you say that in your first post in this thread?
>
>
> Because it should have been sufficient, for any moderately capable
> and reasonable reader, to note simply that the relevant information
> was available in the archives. And that is what I did.
Thanks again, your Michaelness. I'm forever in your debt. Not.
Eltee
All the work? If this wasn't funny it'd be tragical. This is comp.lang._C_,
isn't it? People in here should know something about C, shouldn't they? Well, if
this whole business wasn't just academic they should know about compilers, too.
Especially those that adhere to the standard. I never realized that listing some
of those would be such an unthinkable thing to ask.
BRG
> Greg Comeau wrote:
>
>> xuanbai98 wrote:
>>
>>> I want to know the current support status
>>> of c99 on Microsoft Visual Studio.
>>
>>
>> Current VC has no purposeful support of C99, only of C90.
>>
>>> Anyone know whether Microsoft has any plan
>>> to support c99 on Visual Studio?
>>
>>
>> To the best of my knowledge, their plan is a wait and see plan:
>> Wait and see if customer demand for it increases,
>> and wait and see which c99isms make their way into C++0x.
>
>
> Why should C programmers confine themselves
> to the capabilities of and inferior product
> like Microsoft Visual Studio?
They might not get to make the choice. Or they might not share your
view of VC++.
Brian Gladman
CBFalconer
> Alan Balmer wrote:
>
... snip ...
>>
>> You can expect guidance here, but you can't expect people to do
>> all the work for you.
>
> All the work? If this wasn't funny it'd be tragical. This is
> comp.lang._C_, isn't it? People in here should know something
> about C, shouldn't they? Well, if this whole business wasn't just
> academic they should know about compilers, too. Especially those
> that adhere to the standard. I never realized that listing some
> of those would be such an unthinkable thing to ask.
Because specific compilers are not the subject of the group. If
you had taken the trouble to lurk for a short time you would have
both known that and have seen various references to compilers. You
have another chance by looking through the references in my sig
below.
--
Some useful references:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99)
<http://www.dinkumware.com/refxc.html> C-library
Chris Croughton
<com...@panix.com> wrote:
> In article <slrncvf4s3...@ccserver.keris.net>,
> Chris Croughton <ch...@keristor.net> wrote:
>>On Wed, 26 Jan 2005 04:48:37 GMT, Randy Howard
>> <randy...@FOOverizonBAR.net> wrote:
>>> In article <ct73u0$a17$1...@panix2.panix.com>, com...@panix.com says...
>>>> Comeau, gcc, and Dinkware are available across the most popular
>>>> platforms, and that covers at least a reasonable subset.
>>>
>>> gcc (even with the c99 command line options) is not a c99 compiler.
>>> It's "part" of one perhaps, but that's it.
>>
>>And doesn't provide the library, which is a large part of the
>>specification. GLIBC2 is a lot of the way there but still has some
>>deficiencies.
>
> This suggestion is not intended to change the above fact,
> but it's worth pointing out that in addition to use with
> Comeau on various platforms, that Dinkumware's C99 library
> is available for use with gcc too on various platforms.
Where is it stated which versions of gcc and which platforms? I can
find the price ($135 per user for the "Single User License" -- which I
can't find stated on their site) and a vague statement that the
libraries can be configured for "several compilers on Windows, Unix,
Linux, and Mac OS/X" but not which ones (Debian 'stable'? Gentoo?
Cygwin?). Or there's the source licence for $600 which presumably will
compile on any C89 and later compiler (but presumably also needs to know
about system 'hooks'). Whether the users of applications compiled with
those libraries also need to buy the libraries I can't find (it's
probably in the licence which I can't find on that site).
Plus a lot of programmers in the Real World(tm) have to work with the
library supplied by the customer, they can't just use another library
which might not be compatible with the customer's other software and
bought-in 3rd-party libraries.
Chris C
S.Tobias
> >>I'm particularly interested in ISO C99 standard defects.
> >>Would you care to elaborate?
Why particularly? What's so interesting in the defects? You had better
get yourself seriously interested in the Standard in the first place.
If you did, you wouldn't ask such idiotic questions here.
> I was wondering if you knew any defects in ISO C99 standard. If you do (you
> should, since you implemented a compliant compiler), please tell us.
Were you born this Christmas? If you're so "particularly" interested,
haven't you heard of TC1 and 2 at least? Google not working? Don't you
read c.s.c.? Is WG14 page down or is it too hard for you to find any
DRs there?
--
Stan Tobias
mailx `echo si...@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`
Eltee
> Eltee <el...@hotmail.com> wrote:
>
>>>>I'm particularly interested in ISO C99 standard defects.
>>>>Would you care to elaborate?
>
>
> Why particularly? What's so interesting in the defects?
Why indeed. Why are people interested in having defects corrected? Why are we
interested in having bugs fixed? Heck if I know. It's probably in our nature.
Not that I care too much but if you want to keep using faulty software /
machinery, be my guest. Just don't cry later on when something goes ... well,
not quite as expected.
> You had better
> get yourself seriously interested in the Standard in the first place.
This is a good start, isn't it? Getting to know the defects.
> If you did, you wouldn't ask such idiotic questions here.
Yeah, right.
So I'm only allowed to ask quesions to which I know the answers already (after a
looooooooong study of the standard in this case)? I think that having the
(alleged) defects (of the ISO C standard) exposed is quite on-topic in this NG.
Besides, I wasn't even aware that there were any (defects). I learned that fact
in this NG. In this particular thread, for that matter.
Are those defects a c.l.c-taboo or something?
>>I was wondering if you knew any defects in ISO C99 standard. If you do (you
>>should, since you implemented a compliant compiler), please tell us.
>
>
> Were you born this Christmas?
What's a Christmas? I bet it's off topic in here.
> If you're so "particularly" interested,
> haven't you heard of TC1 and 2 at least? Google not working?
Google working good, thank you very much. In fact, I don't know if this NG even
deserves to be alive anymore. Google outdoes it in every aspect. Oh, well, maybe
it can serve as a meeting point for those ol'-c-geeks who want to avoid going
through too many cold turkeys.
> Don't you
> read c.s.c.? Is WG14 page down or is it too hard for you to find any
> DRs there?
64
Greg Comeau
When push comes to shove, none of us are neutral,
though perhaps not all equally.
I was answering this particular point in general, as a legacy code
or management issue, not as an MS question in and of itself
because we could probably plug in each vendor for some definition
of why people doing this or that, and hence said divulgance didn't
need to come into play, this time around. Or so I though.
Generally though, I agree with you, and I do often go out
of my way for that, and in fact, find myself not even posting
sometimes because of perceived twistings that otherwise would
not have any special significance.
Anyway, we're getting _pretty far_ away from C...
Greg Comeau
>Greg Comeau wrote:
>> In article <35p2c7F...@individual.net>, Eltee <el...@hotmail.com> wrote:
>>>Greg Comeau wrote:
>>>>In article <35mdjjF...@individual.net>, Eltee <el...@hotmail.com> wrote:
>>>>>Lawrence Kirby wrote:
>>>>>>On Mon, 24 Jan 2005 09:21:11 +0100, Eltee wrote:
>>>>>>>Michael Wojcik wrote:
>>>>>>Comeau's C compiler may well qualify for a reasonable definition of
>>>>>>"compliant".
>>>>>So now we have
>>>>>"as close as you can get to full compliance" as our best candidate.
>>>>>Anybody else?
>>>>We do believe it is as close as you can get, to C90, to C99,
>>>>to C++98, and C++03 (and tons of dialects and compatibility
>>>>modes too). For all practical purposes, we are there.
>>>>As has been pointed out, 100% conformance is a slippery slope.
>>>>Not to mention that even the standards themselves have defects.
>>>
>>>I'm particularly interested in ISO C99 standard defects.
>>>Would you care to elaborate?
>>
>> I'm not sure what you're asking.
>
>I was wondering if you knew any defects in ISO C99 standard.
Sure.
>If you do (you should, since you implemented a compliant compiler),
>please tell us.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm
Greg Comeau
>Alan Balmer wrote:
>All the work? If this wasn't funny it'd be tragical. This is comp.lang._C_,
>isn't it? People in here should know something about C, shouldn't they?
>Well, if this whole business wasn't just academic they should know about
>compilers, too. Especially those that adhere to the standard.
>I never realized that listing some
>of those would be such an unthinkable thing to ask.
I'll side step the above and provide this (which I has posted
Aug 26, 2003 at 12:18PM) and believe that it is still accurate:
"To the best of my understanding, at least the following
is the situation as regards C99 implementations:
* Full: Comeau C/C++ (compiler) + Dinkumware (lib)
For: many platforms
* Full: IBM C for AIX version 6
For: AIX
* Intel C (at least compiler)
For: x86
* Full: Compaq/HP/Dec C (this has had various flavors)
For: Unsure
* Full: SGI C
For: SGI platforms (MIPS IRIX I guess)
* Full: Lund Multiprocessor Compiler Company
For: PowerPC LINUX on Apple G4
* Unsure: SAS/C
For: IBM mainframes
* Partial: gcc
For: Many platforms
* Partial: lcc-win32
For: MS-Windows
Only the latter two have "free" possibilities.
As an aside, there is now a small number of books where C99 is
discussed. Search for C99 at http://www.comeaucomputing.com/booklist "
Eltee
Thank you, thank you, thank you. Now my heart is full. ;-)
Greg Comeau
This seems a good summary http://www.dinkumware.com/libdual.html
>Plus a lot of programmers in the Real World(tm) have to work with the
>library supplied by the customer, they can't just use another library
>which might not be compatible with the customer's other software and
>bought-in 3rd-party libraries.
As usual, that can be said of any compiler/lib.
And it also goes as well that if a lot do, then
a lot don't, both in the real world and not in it.
One needs to start somewhere. Your implication is that
say Dinkumware can't be involved in the lib supplied by
the customer. Of course it can. And often is.
There is no escaping issues depending upon the choice,
so are generally neutral although they are different.
If not, I suspect we're talking about different things.
Michael Wojcik
In article <ctavl0$t6n$1...@panix1.panix.com>, com...@panix.com (Greg Comeau) writes:
>
> I'll side step the above and provide this (which I has posted
> Aug 26, 2003 at 12:18PM) and believe that it is still accurate:
>
> "To the best of my understanding, at least the following
> is the situation as regards C99 implementations:
Of course it's still important to check the conformance claims for
the particular release you're using (as I'm sure Greg would agree).
Case in point:
> * Full: Compaq/HP/Dec C (this has had various flavors)
> For: Unsure
I know HP claims that its current OpenVMS C implementation is fully-
conforming, and it may be that its other implementations (which may
be largely the same implementation, for different platforms, under
different names) now conform as well. But the (relatively recent) HP
C compilers we're using on HP-UX and Tru64 do not conform completely
to C99, in a particularly annoying fashion: they have the old, broken
snprintf return semantics.
That might seem unimportant to some, but snprintf is very useful for
avoiding buffer overflows - more useful than, say, strncpy, since
it's not trivial to do the same length checks manually. And the old
return semantics for snprintf (-1 is returned both for overflow and
for formatting error) not only make it more cumbersome to, say,
reallocate the destination buffer until it's sufficiently large;
they make it impossible to distinguish among simply needing a
larger destination, needing a destination that the program would
consider *too* large, and a formatting error which no size of
destination will ever correct.
Consequently, code using snprintf and expecting the C99 semantics
will likely be unpleasantly broken under these nonconforming HP
implementations. (And for that reason I wrote and ran a little
snprintf test program on all of the platforms we're currently
supporting. Microsoft Visual C 6 and the two HP platforms were
the only ones which still had the old semantics, I think.)
So while Greg's list is a useful starting point, and a handy thing to
have for the general discussion of C99 uptake, I wouldn't rely on it
(except for the case of Comeau/Dinkumware) when you're looking at
writing C99 code for some particular implementation.
--
Michael Wojcik michael...@microfocus.com
Pocket #9: A complete "artificial glen" with rocks, and artificial moon,
and forester's station. Excellent for achieving the effect of the
sublime without going out-of-doors. -- Joe Green
S.Tobias
> >>>>I'm particularly interested in ISO C99 standard defects.
> >>>>Would you care to elaborate?
[snip]
> > You had better
> > get yourself seriously interested in the Standard in the first place.
Take it as my good-will advice.
> This is a good start, isn't it? Getting to know the defects.
Absolutely. As good as building a house and starting with the smoke
from the chimney.
Studying the defects is very educating, but first you have to well
understand what they are for.
[snip]
> So I'm only allowed to ask quesions to which I know the answers already (after a
> looooooooong study of the standard in this case)?
No. But it's considered a good behaviour to do some *basic* research
yourself. By not doing so you show your disrespect towards those who
answer your questions. It's not that someone has to read your posts,
because nobody has to and it doesn't cost a lot to kill entire thread;
its your _attitude_ that annoys others. When I ask a question I often
prepare myself for the discussion first. Sometimes it takes days;
sometimes minutes, when I discover the answer is obvious.
> I think that having the
> (alleged) defects (of the ISO C standard) exposed is quite on-topic in this NG.
Yes, and even more so in c.s.c. What have you exposed?
> Besides, I wasn't even aware that there were any (defects). I learned that fact
> in this NG. In this particular thread, for that matter.
You sound very naive.
> Are those defects a c.l.c-taboo or something?
Not in the least, it's just they're a few clicks away from you. If only
you just cared to have a look at the proper place...
[snip]
I beg you to grow up. "Plonk" is usually the last word you hear from
a person here, and it means you lost. If anybody is still speaking to
you, he's a friendly soul, even if he's giving you a reprimand. If you
want to learn C, you're invited, but try to be nice to others and don't
try to fight existing customs or invent your own. If you just want to
annoy others (you have done so recently), please go away.
> Google working good, thank you very much. In fact, I don't know if this NG even
> deserves to be alive anymore. Google outdoes it in every aspect.
It's your opinion. Some believe giraffes can't exist.
> Oh, well, maybe
> it can serve as a meeting point for those ol'-c-geeks who want to avoid going
> through too many cold turkeys.
Many newbies, who perhaps know C less than you, come here and obtain
very good answers. Wonder where the problem lies...
> > Don't you
> > read c.s.c.? Is WG14 page down or is it too hard for you to find any
> > DRs there?
> 64
Well, you've found them youself, good! Is that too few?
Greg Comeau
Michael Wojcik <mwo...@newsguy.com> wrote:
>
>In article <ctavl0$t6n$1...@panix1.panix.com>, com...@panix.com (Greg Comeau) writes:
>> I'll side step the above and provide this (which I has posted
>> Aug 26, 2003 at 12:18PM) and believe that it is still accurate:
>>
>> "To the best of my understanding, at least the following
>> is the situation as regards C99 implementations:
>
>Of course it's still important to check the conformance claims for
>the particular release you're using (as I'm sure Greg would agree).
I do agree. That said...
....I think at the time I wrote the original post i was
considering the compiler aspect not the libs. I believe
you are correct that the libs are still across the baord,
though I have not done any additional major investigations
since the Aug 2003 post. Probably even the compilers are
across the board. As I think Larry wrote about C89,
vendors were claiming conformance even before the standard
was finished. The same thing happened before C++98,
if I recall years before it, so it wouldm't surprise me if
there are even major issues with some of the claims.
So sure, don't take the list as authoritive, it was mainly
to show progress was occuring, not a compliance survey.
Randy Howard
> In article <MPG.1c60dd1a5...@news.verizon.net>,
> Randy Howard <randy...@FOOverizonBAR.net> wrote:
> >In article <ct73u0$a17$1...@panix2.panix.com>, com...@panix.com says...
> >> Comeau, gcc, and Dinkware are available across the most popular
> >> platforms, and that covers at least a reasonable subset.
> >
> >gcc (even with the c99 command line options) is not a c99 compiler.
> >It's "part" of one perhaps, but that's it.
>
> I feel like I've been tricked. Maybe I misunderstood,
> but I thought somebody was asking for a subset of C99 that
> could be used across multiple compilers and on multiple
> platforms. gcc is definitely not a full c99 compiler,
> but I think can meet the _substandard_ 5 features or whatever
> that was being requested.
Ahh, I guess I misunderstood you, no "trick" intended. Are you
saying that whatever gcc -std=c99 provides is the "common"
subset that the other compilers you mentioned (Intel, IBM,
Compaq and a vague "etc.") support? If true, it seems like
a reasonable way to approach the problem.
--
Randy Howard (2reply remove FOOBAR)
"For some reason most people seem to be born without the part
of the brain that understands pointers." -- Joel Spolsky
Eltee
> Eltee <el...@hotmail.com> wrote:
>
>>S.Tobias wrote:
>>
>>>Eltee <el...@hotmail.com> wrote:
>
>
>>>>>>I'm particularly interested in ISO C99 standard defects.
>>>>>>Would you care to elaborate?
>
>
> [snip]
>
>
>> > You had better
>>
>>>get yourself seriously interested in the Standard in the first place.
>
>
> Take it as my good-will advice.
>
>
>>This is a good start, isn't it? Getting to know the defects.
>
>
> Absolutely. As good as building a house and starting with the smoke
> from the chimney.
I don't know about you, but I wouldn't even consider building the house if I
learned beforehand that the smoke is going to backfire on me, in the first
place. It's no use blinding yourself with "we're going to cross that bridge when
we get to it" when you can easily find out right at the begining that the gap
you're supposed to cross has interplanetary "dimensions" and would, in fact,
demand a space ship. I'm not saying that this is the case with C99 defects, but
I don't think that learning what they are, before you familiarize yourself with
all the intricacies of the language itself, is a bad thing.
> Studying the defects is very educating, but first you have to well
> understand what they are for.
Understand what the defects are for?!? Even before you go studying them?!? This
is a joke, right? No, wait, those are _two_ separate jokes.
> [snip]
>
>
>>So I'm only allowed to ask quesions to which I know the answers already (after a
>>looooooooong study of the standard in this case)?
>
>
> No. But it's considered a good behaviour to do some *basic* research
> yourself.
But this _is_ what I'm doing.
> By not doing so you show your disrespect towards those who
> answer your questions.
That's the point. They aren't answering them. Not at first, that is. I have to
drag every word out of their "mouths". This whole thread would have been
unnecessary if that first someone simply had posted a few links (_one_ even)
instead of saying that this has been answered before someplace.
> It's not that someone has to read your posts,
> because nobody has to and it doesn't cost a lot to kill entire thread;
> its your _attitude_ that annoys others. When I ask a question I often
> prepare myself for the discussion first. Sometimes it takes days;
> sometimes minutes, when I discover the answer is obvious.
>
>
>>I think that having the
>>(alleged) defects (of the ISO C standard) exposed is quite on-topic in this NG.
>
>
> Yes, and even more so in c.s.c. What have you exposed?
Not me. But others have. Still others are trying to ban such discussions from
clc. I can't understand such behaviour.
>>Besides, I wasn't even aware that there were any (defects). I learned that fact
>>in this NG. In this particular thread, for that matter.
>
>
> You sound very naive.
Maybe. But, what would you say of a man who tells you that before you study the
defects you first have to understand them?
>>Are those defects a c.l.c-taboo or something?
>
>
> Not in the least, it's just they're a few clicks away from you. If only
> you just cared to have a look at the proper place...
There we go again. Proper place. We all know where that's at, don't we. For all
the cases, for all the situations. Why, oh, why do we need clc then, if there's
some other proper place for everything?
> [snip]
>
>
> I beg you to grow up. "Plonk" is usually the last word you hear from
> a person here, and it means you lost. If anybody is still speaking to
> you, he's a friendly soul, even if he's giving you a reprimand. If you
> want to learn C, you're invited, but try to be nice to others and don't
> try to fight existing customs or invent your own. If you just want to
> annoy others (you have done so recently), please go away.
>
>
>
>>Google working good, thank you very much. In fact, I don't know if this NG even
>>deserves to be alive anymore. Google outdoes it in every aspect.
>
>
> It's your opinion.
But of course!
> Some believe giraffes can't exist.
You among them, I take it.
>>Oh, well, maybe
>>it can serve as a meeting point for those ol'-c-geeks who want to avoid going
>>through too many cold turkeys.
>
>
> Many newbies, who perhaps know C less than you, come here and obtain
> very good answers.
In spite of all the proper places out there?
> Wonder where the problem lies...
Me too, me too. Have been wondering right from the first non-answer I got in
this NG.
>> > Don't you
>>
>>>read c.s.c.? Is WG14 page down or is it too hard for you to find any
>>>DRs there?
>
>
>>64
>
>
> Well, you've found them youself, good! Is that too few?
Samoa.
Greg Comeau
Randy Howard <randy...@FOOverizonBAR.net> wrote:
>In article <ct9deb$flb$1...@panix2.panix.com>, com...@panix.com says...
>> In article <MPG.1c60dd1a5...@news.verizon.net>,
>> Randy Howard <randy...@FOOverizonBAR.net> wrote:
>> >In article <ct73u0$a17$1...@panix2.panix.com>, com...@panix.com says...
>> >> Comeau, gcc, and Dinkware are available across the most popular
>> >> platforms, and that covers at least a reasonable subset.
>> >
>> >gcc (even with the c99 command line options) is not a c99 compiler.
>> >It's "part" of one perhaps, but that's it.
>>
>> I feel like I've been tricked. Maybe I misunderstood,
>> but I thought somebody was asking for a subset of C99 that
>> could be used across multiple compilers and on multiple
>> platforms. gcc is definitely not a full c99 compiler,
>> but I think can meet the _substandard_ 5 features or whatever
>> that was being requested.
>
>Ahh, I guess I misunderstood you, no "trick" intended. Are you
>saying that whatever gcc -std=c99 provides is the "common"
>subset that the other compilers you mentioned (Intel, IBM,
>Compaq and a vague "etc.") support?
Probably.
BTW gcc's features is no secret, or should not be, see here:
http://gcc.gnu.org/c99status.html
>If true, it seems like
>a reasonable way to approach the problem.
I don't know if it's reasonable, but at least it is a start.
No doubt for every project where that's ok, there's
another where it is completely insufficient.... assuming
compilation across 5 compilers (assuming on 5 different OSs)
is/was the goal.
S.Tobias
> S.Tobias wrote:
[cut the crap]
> > Studying the defects is very educating, but first you have to well
> > understand what they are for.
> Understand what the defects are for?!? Even before you go studying them?!? This
> is a joke, right? No, wait, those are _two_ separate jokes.
In case I didn't express myself clearly, I meant there's no point in
studying the Standard defects if you don't know the Standard in the first
place; it was just a piece of advice. But this is not my business,
now you know where to look for them, go figure yourself. It's not
what my argument is about anyway.
> >>So I'm only allowed to ask quesions to which I know the answers already (after a
> >>looooooooong study of the standard in this case)?
> >
> >
> > No. But it's considered a good behaviour to do some *basic* research
> > yourself.
> But this _is_ what I'm doing.
No, this is exactly what you are expected to do, but not doing it at all.
I have pointed out to you, in this particular case you had plenty of
sources to answer your particular question, you just had to reach out
for them. In the clc FAQ you have "11. ANSI/ISO Standard C" where you
can find more than you asked for, and links for specific information.
(Of course, you have read the FAQ, haven't you?) If you at least new
what the latest ISO C standard version was, you'd realize how idiotic
your question was.
(I hope you don't start asking now what the current version is.)
> > By not doing so you show your disrespect towards those who
> > answer your questions.
> That's the point. They aren't answering them. Not at first, that is. I have to
> drag every word out of their "mouths". This whole thread would have been
> unnecessary if that first someone simply had posted a few links (_one_ even)
> instead of saying that this has been answered before someplace.
Because Usenet was not created specially for you. If someone gives you
a *friendly response* that something has been already discussed before,
it roughly means: "I can't answer your question, but I remember this topic
appeared here before, you can easily find it there and get comprehensive
answer". What do you think, that anybody remembers by heart all you
ask about? No, those people often would have to get to their keyboards
and first find and check the answers themselves. If you can't make
any effort, why can you expect others to do it for you? Nobody is your
servant.
[snip]
> > Some believe giraffes can't exist.
> You among them, I take it.
If you look for friends, you'll find many in c.[ls].c. If you look
for enemies, don't bother, you'll find none; those people are really
serious here.
Eltee
> Eltee <el...@hotmail.com> wrote:
>
>>S.Tobias wrote:
>
>
> [cut the crap]
>
>
>>>Studying the defects is very educating, but first you have to well
>>>understand what they are for.
>
>
>>Understand what the defects are for?!? Even before you go studying them?!? This
>>is a joke, right? No, wait, those are _two_ separate jokes.
>
>
> In case I didn't express myself clearly, I meant there's no point in
> studying the Standard defects if you don't know the Standard in the first
> place;
Well, I see it this way. Why study the standard if I can get to know the defects
from someone else who already studied it in great detail and knows it so much
better than me? If that someone is prepared to give me that information or to
show me where I can find it myself (thanks, Greg!) then it saves me a lot of
time. Idealy everybody should study everything, get to know everything,
(re)verify all the proofs of all the theorems (I think that R. Feynman said
something like that once). Unfortunately we don't live in an ideal world. In our
(_real_) world time plays an important role, you see. Like most people, I'm
frequently delegating my time and - most importantly - trust to people more
knowledgeable (in some particular field of knowledge) than me. Having never
written a serious compiler (let alone C99 compliant one) and not having any
aspirations to do so in the future, I clearly don't have other choice but to
trust other people, like Greg, who did. Call it naive if you want, but I don't
think that in this particular case I'm in much danger of being doublecrossed.
No, not at all. But the question of compiler compliancy is, in my view at least,
of utmost importance, if someone is seriously involved in C, as I would
absolutely expect the people (well, the experts at least) of c.l.c to be. Ergo,
I would expect that people would have no trouble listing the major compliant
compilers if someone asked. Don't misunderstand me: I don't believe my
expectations were misplaced. Not then, not now. I'm certain that people do know,
yet they are somewhat reluctant to tell. I'm still figuring out the reason
behind that reluctancy.
> No, those people often would have to get to their keyboards
> and first find and check the answers themselves. If you can't make
> any effort, why can you expect others to do it for you? Nobody is your
> servant.
>
> [snip]
>
>
>
>> > Some believe giraffes can't exist.
>
>
>>You among them, I take it.
>
>
> If you look for friends, you'll find many in c.[ls].c. If you look
> for enemies, don't bother, you'll find none; those people are really
> serious here.
OK. We friends now? ;-)
S.Tobias
> S.Tobias wrote:
[snip]
> > Because Usenet was not created specially for you. If someone gives you
> > a *friendly response* that something has been already discussed before,
> > it roughly means: "I can't answer your question, but I remember this topic
> > appeared here before, you can easily find it there and get comprehensive
> > answer". What do you think, that anybody remembers by heart all you
> > ask about?
> No, not at all. But the question of compiler compliancy is, in my view at least,
> of utmost importance, if someone is seriously involved in C, as I would
> absolutely expect the people (well, the experts at least) of c.l.c to be.
Yes, it is important, but there's no need to exaggerate here. We all
work with broken compilers of broken languages and broken tools on
broken OS-s with broken protocols on broken hardware. And we
still live.
> Ergo,
> I would expect that people would have no trouble listing the major compliant
> compilers if someone asked. Don't misunderstand me: I don't believe my
> expectations were misplaced. Not then, not now.
Sometimes it's impossible to give a single and unambiguous answer
to a simple question. For any Yes-es there may be as many No-s.
If you trust people more knowledgeable than you, as you say
(snipped away), why haven't you trusted Michael Wojcik? He gave you
a long and over-broad explanation why such an answer in not possible.
He has been extremely kind to you. You really _were_ to look first
into the past discussions, and then come back again if you _needed_
more answers. If you hadn't done that, you weren't even aware what
you were asking about.
> I'm certain that people do know,
> yet they are somewhat reluctant to tell.
People here are not automatic machines for answering questions.
They are here to *help* other people. It means that you have to
treat them as humans, and you have to be human too. They have their
feelings, too. If someone doesn't want to answer you question,
you have to respect him. Don't treat clc as a private chat room.
The answers that you get here are serious. Patience and humility
are good companions here.
> I'm still figuring out the reason
> behind that reluctancy.
There're many reasons why certain questions are not and should not
be answered. Stay here a longer time, you'll learn why.
> > If you look for friends, you'll find many in c.[ls].c. If you look
> > for enemies, don't bother, you'll find none; those people are really
> > serious here.
> OK. We friends now? ;-)
Yes, with pleasure. After you learn how to behave here.
Keith Thompson
> S.Tobias wrote:
[snip]
>> In case I didn't express myself clearly, I meant there's no point in
>> studying the Standard defects if you don't know the Standard in the first
>> place;
>
> Well, I see it this way. Why study the standard if I can get to know
> the defects from someone else who already studied it in great detail
> and knows it so much better than me?
Knowing about the defects in the standard is a very small part of
understanding the standard, and it's probably not the first thing you
should worry about.
It's up to you, of course, but I don't see the point of studying, for
example, a defect in the wording that describes the conversion of an
imaginary type to _Bool (DR 285) without first understanding
conversions, imaginary types, and _Bool.
Why do you want to focus on the defects rather than on understanding
the standard as a whole?
--
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.
Eltee
> Eltee <el...@hotmail.com> wrote:
>
>>S.Tobias wrote:
>
>
> [snip]
>
>
>>>Because Usenet was not created specially for you. If someone gives you
>>>a *friendly response* that something has been already discussed before,
>>>it roughly means: "I can't answer your question, but I remember this topic
>>>appeared here before, you can easily find it there and get comprehensive
>>>answer". What do you think, that anybody remembers by heart all you
>>>ask about?
>
>
>>No, not at all. But the question of compiler compliancy is, in my view at least,
>>of utmost importance, if someone is seriously involved in C, as I would
>>absolutely expect the people (well, the experts at least) of c.l.c to be.
>
>
> Yes, it is important, but there's no need to exaggerate here. We all
> work with broken compilers of broken languages and broken tools on
> broken OS-s with broken protocols on broken hardware. And we
> still live.
Right. Me, I use gcc in spite of it not being compliant. But, from what I've
learned in this discussion, I might have to change that.
>>Ergo,
>>I would expect that people would have no trouble listing the major compliant
>>compilers if someone asked. Don't misunderstand me: I don't believe my
>>expectations were misplaced. Not then, not now.
>
>
> Sometimes it's impossible to give a single and unambiguous answer
> to a simple question. For any Yes-es there may be as many No-s.
> If you trust people more knowledgeable than you, as you say
> (snipped away), why haven't you trusted Michael Wojcik?
Hm. Let me see. I asked for a list of compliant compilers. I would have been
happy with a very short list: one entry would've been enough. He gave me nothing
of the sort. There was actually nothing to put my trust into. Greg, on the other
hand, gave me what I wanted.
> He gave you
> a long and over-broad explanation why such an answer in not possible.
> He has been extremely kind to you. You really _were_ to look first
> into the past discussions, and then come back again if you _needed_
> more answers. If you hadn't done that, you weren't even aware what
> you were asking about.
>
>
>>I'm certain that people do know,
>>yet they are somewhat reluctant to tell.
>
>
> People here are not automatic machines for answering questions.
> They are here to *help* other people. It means that you have to
> treat them as humans, and you have to be human too. They have their
> feelings, too. If someone doesn't want to answer you question,
> you have to respect him.
Right. I could live with no answers. What I don't understand is the answers
saying "I don't know the answer to your question, but here's something else if
you like". Well, sorry folks, no offence meant but ... me no like.
> Don't treat clc as a private chat room.
> The answers that you get here are serious. Patience and humility
> are good companions here.
>
>
>>I'm still figuring out the reason
>>behind that reluctancy.
>
>
> There're many reasons why certain questions are not and should not
> be answered. Stay here a longer time, you'll learn why.
>
>
>
>>>If you look for friends, you'll find many in c.[ls].c. If you look
>>>for enemies, don't bother, you'll find none; those people are really
>>>serious here.
>
>
>>OK. We friends now? ;-)
>
>
> Yes, with pleasure. After you learn how to behave here.
Doing my best to learn. Just give me some time, OK?
Eltee
> Eltee <el...@hotmail.com> writes:
>
>>S.Tobias wrote:
>
> [snip]
>
>>>In case I didn't express myself clearly, I meant there's no point in
>>>studying the Standard defects if you don't know the Standard in the first
>>>place;
>>
>>Well, I see it this way. Why study the standard if I can get to know
>>the defects from someone else who already studied it in great detail
>>and knows it so much better than me?
>
>
> Knowing about the defects in the standard is a very small part of
> understanding the standard, and it's probably not the first thing you
> should worry about.
>
> It's up to you, of course, but I don't see the point of studying, for
> example, a defect in the wording that describes the conversion of an
> imaginary type to _Bool (DR 285) without first understanding
> conversions, imaginary types, and _Bool.
>
> Why do you want to focus on the defects rather than on understanding
> the standard as a whole?
I just recently became aware of those defects. Feeling more than a little
surprised by their existence I wanted to learn what they were. Not knowing the
standard I thought my "learned colleagues" could tell me more about them.
Secondly, I don't have any real aspirations in knowing the standard itself. My
interest lies more within the field of the language the standard "describes". So ...
...thirdly, I'm worried that the language inherited those defects from the standard.
S.Tobias
> S.Tobias wrote:
> > Sometimes it's impossible to give a single and unambiguous answer
> > to a simple question. For any Yes-es there may be as many No-s.
> > If you trust people more knowledgeable than you, as you say
> > (snipped away), why haven't you trusted Michael Wojcik?
> Hm. Let me see. I asked for a list of compliant compilers. I would have been
> happy with a very short list: one entry would've been enough.
You can't impose limits on your interlocutor. This is not a quiz.
> He gave me nothing
> of the sort.
He gave you a fishing rod.
> There was actually nothing to put my trust into.
Stay here longer, you'll get the Tao.
> Greg, on the other
> hand, gave me what I wanted.
Yes. The world is not all black-and-white only.
[snip]
> Right. I could live with no answers. What I don't understand is the answers
> saying "I don't know the answer to your question, but here's something else if
> you like". Well, sorry folks, no offence meant but ... me no like.
Then look into "something else" and tell why you're not satisfied with it.
I'm sure everybody will be happy to answer you, and you'll be happy
with the answers you obtain.
Look, I don't want to convince you any more, I think I have said enough.
Life is not easy at clc, but staying here can be very rewarding. Just
go with what people tell you, and do it _for your own sake_. Otherwise
people will just ignore you.
Bye, and good luck getting your answers!