what is the difference between the tree storage
durations(static,automatic and dynamic) in C?
Aug 16 '08
241  6727 
Antoninus Twink wrote:
<snip>
How many people do you know who, when they fire up their C compiler
with its default settings (not carefully picking a hundred different
switches and command line options to make it emulate a 20-year old
standards mode) find that their compiler rejects // comments? Or
rejects mixed definitions and code? Or won't accept long long ints?
Everyone working in C on NonStop, as that Platform provides C89 compiler
only, and without extra switches you don't get _any_ extension _enabled_, so
this compiler is by default conforming (to C89/C90).
To allow for // comments e.g. the switch is -Walow_cplusplus_comments
The clear fact is that C99 is now the default C standard adopted by
most C compilers,
s/most/some very few/
Bye, Jojo
Joachim Schmitz wrote:
Antoninus Twink wrote:
[ ... ]
>The clear fact is that C99 is now the default C standard adopted by
most C compilers,
s/most/some very few/
I also note that the default C dialect for gcc is "gnu89" which is
essentially C89 + some GNU extensions. IME most compiler default to a
non-conforming mode.
On 17 Aug 2008 at 11:03, santosh wrote:
I also note that the default C dialect for gcc is "gnu89" which is
essentially C89 + some GNU extensions.
Actually it's C89 + some C99 features + some GNU extensions.
Antoninus Twink wrote:
On 17 Aug 2008 at 11:03, santosh wrote:
>I also note that the default C dialect for gcc is "gnu89" which is
essentially C89 + some GNU extensions.
Actually it's C89 + some C99 features + some GNU extensions.
I was under the impression that it was ISO C90 plus some GNU extensions
some of which happen to be identical to some C99 features.
Also gnu89 was implemented before C99 came out so it's merely
coincidence that some GNU extensions happen to have been standardised
by C99.
santosh <sa*********@gmail.comwrites:
Antoninus Twink wrote:
>On 17 Aug 2008 at 11:03, santosh wrote:
>>I also note that the default C dialect for gcc is "gnu89" which is
essentially C89 + some GNU extensions.
Actually it's C89 + some C99 features + some GNU extensions.
I was under the impression that it was ISO C90 plus some GNU extensions
some of which happen to be identical to some C99 features.
Also gnu89 was implemented before C99 came out so it's merely
coincidence that some GNU extensions happen to have been standardised
by C99.
Coincidence or the desire to standardize some usefull and common features?
Yours,
--
Jean-Marc
Jean-Marc Bourguet wrote:
santosh <sa*********@gmail.comwrites:
>Antoninus Twink wrote:
>>On 17 Aug 2008 at 11:03, santosh wrote:
I also note that the default C dialect for gcc is "gnu89" which is
essentially C89 + some GNU extensions.
Actually it's C89 + some C99 features + some GNU extensions.
I was under the impression that it was ISO C90 plus some GNU
extensions some of which happen to be identical to some C99 features.
Also gnu89 was implemented before C99 came out so it's merely
coincidence that some GNU extensions happen to have been standardised
by C99.
Coincidence or the desire to standardize some usefull and common
features?
It is that too, but since GCC representatives were not among the
participants of the C99 standardisation committee(?), any similarities
must be coincidence.
santosh <sa*********@gmail.comwrites:
Jean-Marc Bourguet wrote:
>santosh <sa*********@gmail.comwrites:
>>Antoninus Twink wrote:
On 17 Aug 2008 at 11:03, santosh wrote:
I also note that the default C dialect for gcc is "gnu89" which is
essentially C89 + some GNU extensions.
Actually it's C89 + some C99 features + some GNU extensions.
I was under the impression that it was ISO C90 plus some GNU
extensions some of which happen to be identical to some C99 features.
Also gnu89 was implemented before C99 came out so it's merely
coincidence that some GNU extensions happen to have been standardised
by C99.
Coincidence or the desire to standardize some usefull and common
features?
It is that too, but since GCC representatives were not among the
participants of the C99 standardisation committee(?), any similarities
must be coincidence.
I don't follow the reasonning leading to the "MUST". I can think of
several plausible ways for the absence of coincidence (gcc copied the
extension from another compiler which inspired the comittee, another
compiler which inspired the comittee copied the extension from gcc and
someone on the comittee but not working on gcc was inspired by an
extension).
--
Jean-Marc
santosh <sa*********@gmail.comwrites:
Antoninus Twink wrote:
>On 17 Aug 2008 at 11:03, santosh wrote:
>>I also note that the default C dialect for gcc is "gnu89" which is
essentially C89 + some GNU extensions.
Actually it's C89 + some C99 features + some GNU extensions.
I was under the impression that it was ISO C90 plus some GNU extensions
some of which happen to be identical to some C99 features.
That is taking nit-picking to an extraordinary level. Would you say
the same if all GNU extensions had become C99 features, and all C99
features had happened to be extensions in gcc? You would then have to
say the gcc only supports C90 + GNU extensions despite that being
exactly equal to C99.
Also gnu89 was implemented before C99 came out so it's merely
coincidence that some GNU extensions happen to have been standardised
by C99.
It is hardly a coincidence.
--
Ben.
"Antoninus Twink" <no****@nospam.invalidwrote in message
This whole "my topicality house is liberty hall, it's just these other
nasty people who want to restrict it" shtick is wearing a bit thin now
Heathfield. Your behavior in this thread exposes it as a blatant lie.
Personally I'd like a newgroup that discusses portable C programming, MPI,
Fortran 77, protein folding algorithms, little video games under Windows and
Basic interpreters. Oh and the atheism / Christianity debate. Those happen
to be my main interests.
Unfortunately there are only a very few people in the world who will have an
identical list. So we need to compromise. Which means not, obviously,
discussing atheism on comp.lang.c. But it also means not insisting on a
personal intepretation of where the bounds of "C programming" end and
"Windows programming" begins.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
jacob navia said:
Richard Heathfield wrote:
>jacob navia said:
[snip]
>>
>>http://www-306.ibm.com/software/awdtools/czvm/
<quote>
Supports the ISO/IEC 9899:1999 international standard (C99)
<end quote>
IBM supports C99 in all its mainline compilers
"supports C99" and "conforms to C99" have different meanings.
You are just trying to play with words to hide the
fact that you are wrong heathfield.
When you have learned to read, we might take up this conversation again.
Until then, I see little point.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Malcolm McLean wrote:
>
"Antoninus Twink" <no****@nospam.invalidwrote in message
>This whole "my topicality house is liberty hall, it's just these
other nasty people who want to restrict it" shtick is wearing a bit
thin now Heathfield. Your behavior in this thread exposes it as a
blatant lie.
Personally I'd like a newgroup that discusses portable C programming,
MPI, Fortran 77, protein folding algorithms, little video games under
Windows and Basic interpreters. Oh and the atheism / Christianity
debate. Those happen to be my main interests.
Unfortunately there are only a very few people in the world who will
have an identical list. So we need to compromise. Which means not,
obviously, discussing atheism on comp.lang.c. But it also means not
insisting on a personal intepretation of where the bounds of "C
programming" end and "Windows programming" begins.
The problem is that while "standard C" is clearly defined and well
demarcated, the same is not true of "nearly standard C", "non-standard
C", "language closely compatible with C", "C-like language", and so on.
Discussing anything "C like" or "somehow related with C" will broaden
the topicality too much and thus reduce the usefullness of the group.
However adopting an overly pedantic position by refusing to discuss
anything not literally appearing in the C Standard is also likely to be
very unhelpful to beginners (who don't start out with ISO C, but
whatever their instructor/class teaches them.)
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
....
blah, blah, blah
I am sick and tired of the way you throw the words "lie" and "liar"
around.
We are sick and tired of the way Heathfield (and others) continually lie
(and show themselves to be liars)
>Grow up.
Heal thyself.
Richard Heathfield wrote:
jacob navia said:
>Richard Heathfield wrote:
>>jacob navia said:
[snip]
>>>
http://www-306.ibm.com/software/awdtools/czvm/
<quote>
Supports the ISO/IEC 9899:1999 international standard (C99)
<end quote>
IBM supports C99 in all its mainline compilers
"supports C99" and "conforms to C99" have different meanings.
You are just trying to play with words to hide the
fact that you are wrong heathfield.
When you have learned to read, we might take up this conversation again.
Until then, I see little point.
And... he snips the place where I PROVED him wrong OF COURSE:
This white paper of IBM says in: http://www-1.ibm.com/support/docview...27007322&aid=1
<quote>
IBM compilers strive to maximize the performance of scientific,
technical, and commercial applications on server platforms. Multiple
operating system availability ensures cross-platform portability,
augmented by standards compliance. IBM XL compilers conform with:
IBM XL C compiler conforms with ISO C90 and C99 standards.
[snipped rest of conformace statements]
<end quote>
IBM EXPLICITLY states "conforms" to C99. Not just "support",
as Heathfield was arguing.
Being proved wrong he has nothing more to say than
just accusing me of not reading correctly!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia said:
Richard Heathfield wrote:
>jacob navia said:
>>Richard Heathfield wrote:
jacob navia said:
[snip]
http://www-306.ibm.com/software/awdtools/czvm/
>
<quote>
Supports the ISO/IEC 9899:1999 international standard (C99)
<end quote>
>
IBM supports C99 in all its mainline compilers
"supports C99" and "conforms to C99" have different meanings.
You are just trying to play with words to hide the
fact that you are wrong heathfield.
When you have learned to read, we might take up this conversation again.
Until then, I see little point.
And... he snips the place where I PROVED him wrong OF COURSE:
No, I didn't, because you didn't prove me wrong. You only demonstrated that
you *still* haven't understood what I actually said. You jumped, as you so
often jump, to an incorrect conclusion, based on what you thought I said.
Like I said - learn to read.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Huibert Bol wrote:
James Kuyper wrote:
....
>What do you mean by that question? It most certainly already is a part of the
official standard: 6.2.4p1: "There are three storage durations: static,
automatic, and allocated."
Sorry, I meant what was the status with regard to the (then, 1994) standard?
RRs seem to live in a sort of limbo until the standard gets updated,
I'm not sure where to find the RR; it's wording should clarify that
issue. Do you know where I can find it?
... which, in
this case, never happened.
Um - once again, you've confused me. I was able to find the DR. The
standard did indeed get updated, in 1999, as indicated above, with
precisely the changes that were proposed in that DR.
On Sun, 17 Aug 2008 09:58:35 +0200, jacob navia <ja***@nospam.com>
wrote:
>Richard Heathfield wrote:
>jacob navia said:
>>Antoninus Twink wrote:
On 16 Aug 2008 at 20:06, Harald van D?k wrote:
On Sat, 16 Aug 2008 19:54:07 +0000, Richard Heathfield wrote:
>But since you don't actually know whether the platforms you name have
>C99 implementations available for them, your point lacks force.
Intel's compiler is available for Windows and Linux, and the other
three conform to SUSv3. In other words, the platforms all have
conforming C99 implementations.
I don't believe for a second that Heathfield wasn't fully aware of that.
He's a proven liar who chooses to spread FUD about the current C
standards for his own reasons.
He said that C99 wasn't available for IBM mainframes,
No, I didn't. Learn to read, please.
You said that there was no C99 for S390.
IBM renamed S390 to z Series systems
Datsun was renamed to Nissan. Saigon was renamed to Ho Chi Minh City.
Computer Associates changed their name to CA. The same entity
continued to exist with a new name.
No System/390 product was renamed to z anything. Existing System/390
products are still System/390 products. What IBM elected to do was
terminate the System/390 product line and start a new one.
--
Remove del for email
On Sun, 17 Aug 2008 07:32:45 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:
>jacob navia said:
>Antoninus Twink wrote:
>>On 16 Aug 2008 at 20:06, Harald van D?k wrote:
On Sat, 16 Aug 2008 19:54:07 +0000, Richard Heathfield wrote:
But since you don't actually know whether the platforms you name have
C99 implementations available for them, your point lacks force.
Intel's compiler is available for Windows and Linux, and the other
three conform to SUSv3. In other words, the platforms all have
conforming C99 implementations.
I don't believe for a second that Heathfield wasn't fully aware of that.
He's a proven liar who chooses to spread FUD about the current C
standards for his own reasons.
He said that C99 wasn't available for IBM mainframes,
No, I didn't. Learn to read, please.
>what is a lie.
It is especially important to learn to read if it will help you to avoid
hurling silly insults around. What I said was no lie. Read it again.
Since Keith has already made both those points, however, let's move on and
make a third one, shall we?
>See:
http://www-306.ibm.com/software/awdtools/czvm/
<quote>
Supports the ISO/IEC 9899:1999 international standard (C99)
<end quote>
Yes, there are lots of implementations that "support" C99 to a greater or
lesser extent. I see no hard evidence that the implementation you mention
even *claims* C99 conformance, however. Perhaps I missed it, in which case
no doubt you can point out where the conformance claim is made.
Hardly surprising since that page is a marketing puff piece. If you
follow the links to documentation, you can find IBM document
SC09-4767-06, "z/OS XL C/C++ User’s Guide". On page 561 they state:
c89 ... Use this invocation for strict conformance to the ISO/IEC
9899:1990 standard.
c99 ... Use this invocation for strict conformance to the ISO/IEC
9899:1999 standard.
--
Remove del for email
Barry Schwarz said:
On Sun, 17 Aug 2008 07:32:45 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:
<snip>
>>Yes, there are lots of implementations that "support" C99 to a greater or
lesser extent. I see no hard evidence that the implementation you mention
even *claims* C99 conformance, however. Perhaps I missed it, in which
case no doubt you can point out where the conformance claim is made.
Hardly surprising since that page is a marketing puff piece. If you
follow the links to documentation, you can find IBM document
SC09-4767-06, "z/OS XL C/C++ User’s Guide". On page 561 they state:
c89 ... Use this invocation for strict conformance to the ISO/IEC
9899:1990 standard.
c99 ... Use this invocation for strict conformance to the ISO/IEC
9899:1999 standard.
Thank you, Barry. (I did actually know about the XL compiler, because it's
one of the implementations listed on Bruce Perens's C99 conformance page,
but I didn't recall which OSs it had been tested on.)
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
On 17 Aug 2008 at 19:04, Richard Heathfield wrote:
Barry Schwarz said:
>On page 561 they state:
c99 ... Use this invocation for strict conformance to the ISO/IEC
9899:1999 standard.
Thank you, Barry.
Why are you thanking someone for providing documentary proof that you
lied to try to get one over on Jacob?
On Aug 17, 3:07*am, Richard Heathfield <rj*@see.sig.invalidwrote:
s0****@gmail.com said:
Richard Heathfield wrote:
s0****@gmail.com said:
Richard Heathfield wrote:
s0****@gmail.com said:
<snip>
He said the
standard you referred to is no longer current.
Yes, he did, and yes, he's de jure right. But he's de facto wrong.
Either he's right (which he is), or he's not.
He's right only in a completely useless and almost meaningless way.
How can someone be right in a meaningless way?
It's not difficult, but someone can also be wrong in meaningless ways...
No. Either someone is wrong, or not. It's *that* simple.
Again, either someone is right, or not. It's *that* simple.
...and that's a good example.
What do you mean by "de facto"?
"de jure": in law.
"de facto": in reality.
A government passes a law that as of now, nobody may breathe. De jure,
people no longer breathe. De facto, however, they still do.
In other words, they are committing a crime. I fail to see how that
relates to what we're discussing here.
Look, I feel like I'm arguing with a complete idiot,
Finally, something we have in common.
and you're going to
have to work pretty hard to change my mind. You *ASKED* for an explanation
of "de facto", and I gave you one, complete with an illustration. What's
more, it is clear that the distinction is highly relevant.
Yes, you gave me an explanation, and I understood. What I mean is that
the words "de jure" and "de facto," in the way you used them to
describe the government law, is different from the way you used them
to describe the two standards, and makes no sense.
*IN LAW*, C99 is the current Standard. *IN PRACTICE*, here you are,
advocating C99 and saying that C90 is obsolete, but according to your last
article you don't even have a conforming C99 implementation on your
desktop machine!
Looks like it's hard for you to understand simple facts. What makes
you think there can only be *one* standard? Like I said, they're
*both* C standards. C99 is the *current* standard. And no, I never
said C89 was obsolete. In fact, I'd recommend using it for
applications that need more portability than C99 offers, or to
maintain legacy code that uses it. And how do you know I don't have a
conforming C99 implementation in my desktop machine? The fact that I
use GCC doesn't mean I must *only* have GCC on my machine. I simply
don't think that "conforming" == "perfect", as you seem to think.
De jure, C99
is the C Standard. De facto, C90 is the C Standard.
They're both C standards; the latter is the *current* standard;
De jure, C99 is the C Standard. De facto, C90 is the C Standard.
For the third time: They're *both* C standards. C99 is the *current*
standard.
Is that so hard to understand for you? I mean, I know you struggled with
the terminology, but I have now explained that. Do you *have* to struggle
with the common sense, too?
It seems to me your common sense and my common sense are very
different.
Are you really so foolish as to believe
there's any point in trying to write code that adheres to a Standard to
which not even your own implementation conforms?
What makes you think I can only have *one* implementation? Besides,
while GCC doesn't strictly conform to the standard, they've clearly
marked what features are supported and which aren't, and the failures
are minor. So I wouldn't be "foolish" even if I had *only* GCC
available to me.
<snip>
I don't know exactly which platforms are supported by C99
implementations,
Then you are in no position to make an argument about C99's portability
or otherwise.
I am if my standards of portability comprise an implementation being
portable among a number of fairly popular and widely used OSs, and if
there are implementations for C99 that target those platforms.
That's a lot of ifs.
It proves the point.
>
but let's name five (random) platforms for
illustration:
- Windows
- Linux
- Mac OS X
- Solaris
- HP-UX
By what I'd call "common standards," something that is portable among
that much platforms is very portable.
I think the OS390 and VM/CMS folks might cough and splutter a bit if
they heard you say that.
Surely, they probably have different opinions on portability.
The ones I've worked with are red-hot on portability. I've done a lot of
work on OS390 projects, and normal practice is to write it on the PC, get
it working, then put it straight up on the mainframe for testing. The
ideal is for no code changes to be required on the mainframe - this is
rarely attained, but any such changes that do turn out to be necessary are
made *ON THE PC*, tested there, and then ported up.
But since you don't actually know whether the
platforms you name have C99 implementations available for them, your
point lacks force.
Again:
Not if my standards of portability comprise an implementation being
portable among a number of fairly popular and widely used OSs, and if
there are implementations for C99 that target those platforms.
Again, that's a lot of ifs. You're talking through your nose and hoping
that the facts support you, instead of checking and presenting the facts.
What facts are you referring to? I stated that I don't necessarily
need to know exactly on which platforms I can compile code, depending
on my portability needs. That's the fact.
>
then yes, of
course C99 is portable. But if you mean "implementations exist for
the vast majority of platforms", then I would argue that it isn't.
That in turn depends on what you mean by "the vast majority of
platforms." Do you mean "from microchips to supercomputers"? Or do you
mean "any popular OS"? I would expect most people in general to mean
the second.
I would certainly include mainframes and mid-range computers, which you
seem to have ignored completely.
Yes, because they are of no interest to me.
Well, there's a shock. Nevertheless, there's a lot more to life than Vista.
I don't use Vista. Anyway, not everyone has the same interests as you.
<snip>
For people not trying to run programs on toasters, C99 is surely
portable enough.
Do *you* use a conforming C99 implementation? You probably don't -
but maybe, just maybe, you do. Most people, however, don't.
Like I've told you before, I use GCC's non-conforming C99
implementation.
So no, then. If C99 isn't even portable to *your* desktop, it is hard to
see how you can sustain a claim to general portability.
I use C99 for my desktop.
That's a change from your last article, where you claimed you did not use
C99 for your desktop. I don't count non-conforming implementations, since
they don't implement C99.
They do implement C99, just not completely. Hence the "non-conforming
implementation" phrase. Thus, I do use C99 for my desktop, despite
your extreme misinterpretation of my post.
Where do you get that "C99 isn't even portable to my desktop"?
From your own claim that you don't use a C99 implementation.
I do use one. Where do you get that "you don't use a C99
implementation"?
But the important thing is not so much the conformance
level,
The important thing to you, maybe - but here, we discuss ISO C, not
notquiteISO C.
I'm not discussing "notquiteISO C."
That's exactly what you're discussing, when you talk about non-conformiong
implementations.
No. In fact, we're even discussing C here. We're discussing
implementations. So we're discussing neither "ISO C," nor "notquiteISO
C."
I'm stating that the important
thing is not so much the conformance level, but the compiler's
usability.
Usability is important, but rarely an issue.
It is for me.
Compilers are normally pretty
easy to use. But if the implementation *doesn't conform*, then you can't
trust it to run code that wasn't tailored specifically for it.
You can trust it if the implementation has clearly marked the features
it has implemented, and the ones it hasn't, as is the case for GCC.
It's a similar case for conforming implementations: if it claims to
conform, you can safely use everything the standard defines and as it
defines it. If it doesn't conform, you have to see the documentation
to find out what you can use safely and what not.
but the compiler's usability. For example, lcc-win doesn't
conform, but it has the most useful set of extensions I've ever seen
on any compiler.
If it doesn't implement the language correctly, the extensions are a
moot point.
That's your opinion (and apparently only yours).
I think you'll find a wide body of support for the opinion that compilers
ought to be able to translate programs according to spec, if only you're
prepared to take your blinkers off.
Likewise, many people will agree that compiler-specific extensions are
generally useful. Also, I forgot to mention on the previous post: "non-
conforming" != "incorrect".
<snip>
So you see, "conforming" != "perfect".
You seem to be arguing that it's the compiler's fault if the program is
incorrectly written. I don't agree.
It's the compiler's decision what to do when a has something in it
invokes undefined behavior.
Actually, very often the compiler *doesn't* make that decision. For
example, consider the following code:
void foo(unsigned int *a, unsigned int *b)
{
* *a += ++*b;
}
This code is standalone, in the sense that one could legally compile it as
a separate translation unit. Do you see any reason why a compiler should
decide to insert extra instructions into this function's translated code
to guard against undefined behaviour, especially when the compiler has no
reason to believe that the function will ever be invoked incorrectly?
But let's look at a more obvious example of undefined behavior:
int i;
int *p = &i;
p++;
In this case, it's obvious to the compiler that the code invokes
undefined behavior, and the compiler is faced with the decision of
what to do: Should it not increment p? Should it increment it and hope
for the best? Should it generate instructions to erase all files in
the hard disk? I'm not sure about the first two, but the third is
legal according to the standard (as you already agreed).
If a compiler does what I mentioned above
in a case where a program does something that invokes undefined
behavior, I'd deem that compiler useless.
At the very least, it would be a valuable teaching tool.
But not everyone's on the learning phase, and some people need
productivity. And a compiler like that would be nothing but useless to
a serious programmer.
Sebastian
Richard Heathfield <rj*@see.sig.invalidwrites:
jacob navia said:
[...]
Thirdly, the page you cite doesn't actually claim C99 conformance as far as
I can see.
I *do* wish you'd think before posting.
>http://www-306.ibm.com/software/awdtools/czvm/
<quote>
Supports the ISO/IEC 9899:1999 international standard (C99)
<end quote>
IBM supports C99 in all its mainline compilers
"supports C99" and "conforms to C99" have different meanings.
I suppose so, but the statement that it "Supports" the C99 standard
strongly implies that it conforms to it. If I were a potential
customer, and I found that IBM's marketing department had told me that
their compiler "supports" C99 but in fact did not fully conform to it,
I would conclude that they had attempted to deceive me.
But there appears to be no such conflict, since
<http://www-306.ibm.com/software/awdtools/xlcpp/says
They comply with the latest C/C++ international standards and
industry specifications and support a large array of common
language features.
(I think we can assume that "C/C++" means "C *and* C++".)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
jacob navia <ja***@nospam.comwrites:
Richard Heathfield wrote:
>jacob navia said:
[snip]
>>
>>http://www-306.ibm.com/software/awdtools/czvm/
<quote>
Supports the ISO/IEC 9899:1999 international standard (C99)
<end quote>
IBM supports C99 in all its mainline compilers
"supports C99" and "conforms to C99" have different meanings.
You are just trying to play with words to hide the
fact that you are wrong heathfield.
Wrong about what?
This white paper of IBM says in:
[snip]
IBM XL C compiler conforms with ISO C90 and C99 standards.
[snip]
That's nice.
For the Nth time, Richard Heathfield *did not say* that C99 is not
available for IBM mainframes. Re-read what he wrote in this very
thread. I can understand that you might have reached that conclusion
on a quick reading, but I find it difficult to believe that, after
being told several times that he did not make that claim, you're
incapable of going back, re-reading the article, and concluding that
he didn't actually say what you claim he said.
(I would applaud the fact that you've backed off from calling him a
liar and are now merely saything that he's wrong, but you haven't
demonstrated that you understand the difference.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:
>Richard Heathfield wrote:
>>jacob navia said:
[snip]
>>>http://www-306.ibm.com/software/awdtools/czvm/
<quote>
Supports the ISO/IEC 9899:1999 international standard (C99)
<end quote>
IBM supports C99 in all its mainline compilers
"supports C99" and "conforms to C99" have different meanings.
You are just trying to play with words to hide the
fact that you are wrong heathfield.
Wrong about what?
>This white paper of IBM says in:
[snip]
>IBM XL C compiler conforms with ISO C90 and C99 standards.
[snip]
That's nice.
For the Nth time, Richard Heathfield *did not say* that C99 is not
available for IBM mainframes.
There was a conversation, aboutr "storage durations", and Heathfield
brought a quote from the obsoleted standard C89 saying that there are two
types of them.
I (and several others) corrected that blunder since the current standard
(C99) specifies three types.
Heathfield was forced to recognize his error, but then he started
the usual campaign against standard C (not portable, not implemented
etc etc)
Then, s0****@gmail.com said:
[snip]
but let's name five (random) platforms for
illustration:
- Windows
- Linux
- Mac OS X
- Solaris
- HP-UX
By what I'd call "common standards," something that is portable among
that much platforms is very portable.
Then Heathfield answered:
<quote>
I think the OS390 and VM/CMS folks might cough and splutter a bit if they
heard you say that.
<end quote>
OS390 was obsoleted by IBM in 2000 and replaced by the z/VM
system, that is the main system used by IBM mainframes.
Obviously I think Heathfield was speaking about that system
(OS390 later z/VM).
I am not an expert in Heathfield psychology of course.
When he speaks about OS390 he is maybe talking about
CP/M or maybe about Apple pascal. Who knows.
I assumed however, that he is speaking about IBM's mainframe
system.
Obviously he did not say that IBM's mainframes do not have
C99, but in his wording it was obviously IMPLIED.
Later, when proved WRONG, he started arguing his word
games (as he always does with your support).
You and Mr Heathfield always resort to those games when PROVED
WRONG.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia <ja***@nospam.comwrites:
Keith Thompson wrote:
[...]
>For the Nth time, Richard Heathfield *did not say* that C99 is not
available for IBM mainframes.
There was a conversation, aboutr "storage durations", and Heathfield
brought a quote from the obsoleted standard C89 saying that there are two
types of them.
I (and several others) corrected that blunder since the current standard
(C99) specifies three types.
Yes. He made a mistake, it was pointed out, and he graciously
accepted the correction. You might try it some time.
[snip]
Obviously he did not say that IBM's mainframes do not have
C99, but
[snip]
Correct, he did not. Thank you for admitting your error.
(Yes, I snipped relevant context.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:
>Keith Thompson wrote:
[...]
>>For the Nth time, Richard Heathfield *did not say* that C99 is not
available for IBM mainframes.
There was a conversation, aboutr "storage durations", and Heathfield
brought a quote from the obsoleted standard C89 saying that there are two
types of them.
I (and several others) corrected that blunder since the current standard
(C99) specifies three types.
Yes. He made a mistake, it was pointed out, and he graciously
accepted the correction. You might try it some time.
"graciously accepted the correction" but not for my message.
[snip]
>Obviously he did not say that IBM's mainframes do not have
C99, but
[snip]
Correct, he did not. Thank you for admitting your error.
I did not admit any error. You snipped my argumentation since
you are just trying to defend your buddy against all
evidence.
>
(Yes, I snipped relevant context.)
Yes you did, since neither you nor heathfield have any
arguments. Both of you have been proved wrong and
can't admit it.
You are waging a war against standard C in this group.
"It is just de jure standard", but "de facto" it is C89,
etc etc. And each time I prove you WRONG you go into
your word games to save the face.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia <ja***@nospam.comwrites:
Keith Thompson wrote:
>jacob navia <ja***@nospam.comwrites:
[...]
>>Obviously he did not say that IBM's mainframes do not have
C99, but
[snip]
Correct, he did not. Thank you for admitting your error.
I did not admit any error.
You should have.
You snipped my argumentation since
you are just trying to defend your buddy against all
evidence.
>(Yes, I snipped relevant context.)
Yes you did, since neither you nor heathfield have any
arguments. Both of you have been proved wrong and
can't admit it.
Sigh.
Fact: Richard did not claim that IBM mainframes do not have C99.
Fact: You claimed that he had made that claim.
Fact: You called him a liar because of it.
And you still will not admit that you were wrong.
You are waging a war against standard C in this group.
Wrong.
[snip]
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
On 2008-08-17, jacob navia <ja***@nospam.comwrote:
>
Heathfield was forced to recognize his error, but then he started
the usual campaign against standard C (not portable, not implemented
etc etc)
He accepted his error, but pointed out that reliance on C99 restricts
portability compared with C89, since it is not implemented on nearly
as many platforms. This is a statement of fact, not a "campaign
against standard C".
Talk about word games.
>
OS390 was obsoleted by IBM in 2000 and replaced by the z/VM
system, that is the main system used by IBM mainframes.
Obviously I think Heathfield was speaking about that system
(OS390 later z/VM).
How is this obvious? If he said OS390, he meant OS390. Its
obsolescence does not change what its name refers to.
>
When he speaks about OS390 he is maybe talking about
CP/M or maybe about Apple pascal. Who knows.
Maybe OS390?
And yes, I snipped a lot.
--
Andrew Poelstra ap*******@wpsoftware.com
To email me, use the above email addresss with .com set to .net
Keith Thompson wrote:
>
Fact: Richard did not claim that IBM mainframes do not have C99.
OK. I assumed that he was speaking of the z/VM system, as OS390
is called today.
But even if we take it at face value, the compiler for OS390
is z/OS XL C/C++, that supports C99, so he was telling a
misleading statement when he said that C99 is NOT available for OS390.
IT IS AVAILABLE for OS390. The compiler that was marketed with
that system is no longer available since it was discontinued in 2004.
The replacement product for OS390 according to IBM's documentation
is the z/OS XL C/C++. This is obvious for anyone.
You see how far you go with your "facts" ?
Just LIES.
Fact: You claimed that he had made that claim.
Even if I would accept he was talking about OS390 is is WRONG
ANYWAY (and you with him of course)
Fact: You called him a liar because of it.
Yes, and the "fact" that OS390 has no C99 is a LIE since
there is a compiler for OS390 that supports C99.
And you still will not admit that you were wrong.
And I have presented all necessary facts to prove I am not!
>You are waging a war against standard C in this group.
Wrong.
Yes. Each time you speak about a significant platform
WITHOUT C99 I prove you wrong!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Andrew Poelstra wrote:
On 2008-08-17, jacob navia <ja***@nospam.comwrote:
>Heathfield was forced to recognize his error, but then he started
the usual campaign against standard C (not portable, not implemented
etc etc)
He accepted his error, but pointed out that reliance on C99 restricts
portability compared with C89, since it is not implemented on nearly
as many platforms. This is a statement of fact, not a "campaign
against standard C".
Talk about word games.
>OS390 was obsoleted by IBM in 2000 and replaced by the z/VM
system, that is the main system used by IBM mainframes.
Obviously I think Heathfield was speaking about that system
(OS390 later z/VM).
How is this obvious? If he said OS390, he meant OS390. Its
obsolescence does not change what its name refers to.
>When he speaks about OS390 he is maybe talking about
CP/M or maybe about Apple pascal. Who knows.
Maybe OS390?
And yes, I snipped a lot.
Even if I accept that he was speaking about ONLY OS390
HE IS STILL WRONG since the z/OS XL C/C++ runs in OS390 and
fully supports C99.
So he was lying again. Please look in: http://www-306.ibm.com/software/awdtools/c390/
There in that page you will find that OS/390 C/C++
is no longer sold. AND
<quote>
No longer in marketing - current replacement product is z/OS XL C/C++
<end quote>
This means that the current compiler for OS390 fully supports
C99.
How many times do I have to prove Heathfield wrong?
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
On Aug 18, 2:13 am, jacob navia <ja...@nospam.comwrote:
<snip>
How many times do I have to prove Heathfield wrong?
Before what? Before you stop acting like a lunatic? vi******@gmail.com wrote:
On Aug 18, 2:13 am, jacob navia <ja...@nospam.comwrote:
<snip>
>How many times do I have to prove Heathfield wrong?
Before what? Before you stop acting like a lunatic?
Your answer is typical mr. If I prove heathfield wrong
I am a lunatic OF COURSE!
Your logic is as clear as heathfield's.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
On 2008-08-17, jacob navia <ja***@nospam.comwrote:
>
Even if I accept that he was speaking about ONLY OS390
HE IS STILL WRONG since the z/OS XL C/C++ runs in OS390 and
fully supports C99.
So he was lying again. Please look in:
http://www-306.ibm.com/software/awdtools/c390/
There in that page you will find that OS/390 C/C++
is no longer sold. AND
It says nothing about C99 on that page. It does however,
mention C89 and C90 a few times.
><quote>
No longer in marketing - current replacement product is z/OS XL C/C++
<end quote>
Okay, but the compiler for z/OS does not run on OS390.
This means that the current compiler for OS390 fully supports
C99.
No, it doesn't.
--
Andrew Poelstra ap*******@wpsoftware.com
To email me, use the above email addresss with .com set to .net
jacob navia wrote:
vi******@gmail.com wrote:
>On Aug 18, 2:13 am, jacob navia <ja...@nospam.comwrote:
<snip>
>>How many times do I have to prove Heathfield wrong?
Before what? Before you stop acting like a lunatic?
Your answer is typical mr. If I prove heathfield wrong
I am a lunatic OF COURSE!
The proof is irrelevant, it's the incessant ranting that puts people's
backs up.
--
Ian Collins.
Antoninus Twink <no****@nospam.invalidwrites:
On 17 Aug 2008 at 19:04, Richard Heathfield wrote:
>Barry Schwarz said:
>>On page 561 they state:
c99 ... Use this invocation for strict conformance to the ISO/IEC
9899:1999 standard.
Thank you, Barry.
Why are you thanking someone for providing documentary proof that you
lied to try to get one over on Jacob?
What is the statement that is in dispute here? Jacob's post pointed
to a document that seems to be about IBM's XL compilers for AIX and
Linux systems. I have not seen anyone dispute the availability of C99
for such systems.
--
Ben.
jacob navia <ja***@nospam.comwrites:
Keith Thompson wrote:
>Fact: Richard did not claim that IBM mainframes do not have C99.
OK. I assumed that he was speaking of the z/VM system, as OS390
is called today.
But even if we take it at face value, the compiler for OS390
is z/OS XL C/C++, that supports C99, so he was telling a
misleading statement when he said that C99 is NOT available for OS390.
In the article with Message-ID
<Uu******************************@bt.com>, available
at<http://groups.google.com/group/comp.lang.c/msg/d070c346d8105ca8>,
he DID NOT SAY that C99 is not available for OS390.
Read the article again, and pay attention this time. Believe it or
not, I don't enjoy seeing you make a fool of yourself like this.
[snip]
You see how far you go with your "facts" ?
Just LIES.
Are you calling me a liar as well? If so, please quote one statement
I've made that is a lie (i.e., a deliberate falsehood).
>Fact: You claimed that he had made that claim.
Even if I would accept he was talking about OS390 is is WRONG
ANYWAY (and you with him of course)
You seem to think that this is about the distinction between OS390 and
z/OS. It isn't.
>Fact: You called him a liar because of it.
Yes, and the "fact" that OS390 has no C99 is a LIE since
there is a compiler for OS390 that supports C99.
He never said otherwise.
>And you still will not admit that you were wrong.
And I have presented all necessary facts to prove I am not!
One more time, you called Richard Heathfield a liar for a statement
that he never made.
>>You are waging a war against standard C in this group.
Wrong.
Yes. Each time you speak about a significant platform
WITHOUT C99 I prove you wrong!
Wrong about what? I am not "waging a war against standard C".
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
jacob navia wrote:
Richard Heathfield wrote:
>jacob navia said:
....
>>He said that C99 wasn't available for IBM mainframes,
No, I didn't. Learn to read, please.
You said that there was no C99 for S390.
Could you give me a citation for that, please? I can't find any such
comment from Richard Heathfield, so I'm probably looking in the wrong
place. The only previous comment I could find from him mentioning S390
is the following (and it mentions OS390, not S390):
Richard Heathfield wrote:
s0****@gmail.com said:
....
>but let's name five (random) platforms for
illustration:
- Windows
- Linux
- Mac OS X
- Solaris
- HP-UX
By what I'd call "common standards," something that is portable among
that much platforms is very portable.
I think the OS390 and VM/CMS folks might cough and splutter a bit if
they
heard you say that
You obviously can't be referring to that message, because it is only a
a comment about how the mainframe people might consider that definition
of "portable" to be absurdly restricted. They would be right, of course
- a definition of "portable" that excludes the most of the machines for
which C code is written nowadays is pretty ridiculous.
So, where was it that Richard Heathfield claimed that C99 was not
available on S390?
James Kuyper <ja*********@verizon.netwrites:
jacob navia wrote:
>Richard Heathfield wrote:
>>jacob navia said:
...
>>>He said that C99 wasn't available for IBM mainframes,
No, I didn't. Learn to read, please.
You said that there was no C99 for S390.
Could you give me a citation for that, please? I can't find any such
comment from Richard Heathfield, so I'm probably looking in the wrong
place. The only previous comment I could find from him mentioning S390
is the following (and it mentions OS390, not S390):
Richard Heathfield wrote:
>s0****@gmail.com said:
...
>>but let's name five (random) platforms for
illustration:
- Windows
- Linux
- Mac OS X
- Solaris
- HP-UX
By what I'd call "common standards," something that is portable among
that much platforms is very portable.
I think the OS390 and VM/CMS folks might cough and splutter a bit if
they
>heard you say that
You obviously can't be referring to that message, because it is only a
a comment about how the mainframe people might consider that
definition of "portable" to be absurdly restricted. They would be
right, of course - a definition of "portable" that excludes the most
of the machines for which C code is written nowadays is pretty
ridiculous.
I am used to some pretty adroit verbal gymnastics in c.l.c but is that
really how you read that remark? In an exchange about C99
portability, after a list of some systems that were claimed (rightly
or wrongly) to have C99 support a reference to OS/390 was made just to
make a remark about other, more general, portability issues?
If that was the intent (and I trust Richard Heathfield will tell us the
intent) then it was a first-class trap into which Jacob fell. As I've
said before, I don't like the term, but I might just have to call it a
first-class troll.
--
Ben.
Keith Thompson <ks***@mib.orgwrites:
jacob navia <ja***@nospam.comwrites:
>Keith Thompson wrote:
>>Fact: Richard did not claim that IBM mainframes do not have C99.
OK. I assumed that he was speaking of the z/VM system, as OS390
is called today.
But even if we take it at face value, the compiler for OS390
is z/OS XL C/C++, that supports C99, so he was telling a
misleading statement when he said that C99 is NOT available for OS390.
In the article with Message-ID
<Uu******************************@bt.com>, available
at<http://groups.google.com/group/comp.lang.c/msg/d070c346d8105ca8>,
he DID NOT SAY that C99 is not available for OS390.
I agree that he did not, but I am now a bit confused. I though, right
up until your message, that I was following all this.
The remark: "I think the OS390 and VM/CMS folks might cough and
splutter a bit if they heard you say that" certainly suggested to me
that it was the narrowness of the proffered list of C99 supported
platforms that would cause the spluttering, i.e. that OS/390 VM/CMS
could not be on the list.
Now I /can/ put a meaning to it that has nothing to do with C99
availability for OS/390 VM/CMS, but it feels like quite a stretch to
do so, and makes the remark seem out of place.
If there /is/ a C99 compiler for OS/390 (something I can't comment on
but which does not yet appear to have been documented by any of the
posted links) it seems a misleading example to pick in the middle of
an exchange about systems to which C99 code is portable.
How did you read it?
By the way, in case you are in any doubt, I am not supporting any of Jacob
Navia's wild claims about what Richard Heathfield said -- they are as
over the top as I have come to expect -- I am just confused about the
reference to OS/390 if it is not about C99 availability.
--
Ben. s0****@gmail.com said:
On Aug 17, 3:07 am, Richard Heathfield <rj*@see.sig.invalidwrote:
>s0****@gmail.com said:
Richard Heathfield wrote:
s0****@gmail.com said:
<snip>
Either he's right (which he is), or he's not.
>He's right only in a completely useless and almost meaningless way.
How can someone be right in a meaningless way?
It's not difficult, but someone can also be wrong in meaningless ways...
No. Either someone is wrong, or not. It's *that* simple.
You're wrong. It's that simple.
<snip>
>*IN LAW*, C99 is the current Standard. *IN PRACTICE*, here you are,
advocating C99 and saying that C90 is obsolete, but according to your
last article you don't even have a conforming C99 implementation on your
desktop machine!
Looks like it's hard for you to understand simple facts. What makes
you think there can only be *one* standard?
I'm well aware that the number of Standards exceeds one.
Like I said, they're
*both* C standards. C99 is the *current* standard.
Whether that is true depends on what you mean by the word "current". In
theory ("in law", if you like), you're right - C99 /is/ the current
Standard. In practice, you're wrong - C90 is the current Standard, because
that's the one which is conformed to by the implementations that people
actually use.
I'm sure I have already explained this to you at least twice.
And no, I never said C89 was obsolete.
Neither did I claim that you had said that.
In fact, I'd recommend using it for
applications that need more portability than C99 offers, or to
maintain legacy code that uses it.
So would I. So we are, after all, in agreement. Good.
And how do you know I don't have a
conforming C99 implementation in my desktop machine?
Logic. You are advocating C99. You claim to use gcc, which is not a C99
compiler. Either you have a C99 implementation on your desktop machine or
you don't. To have such an implementation on your desktop and yet not even
mention it, let alone claim to use it, even at such a late stage in a
debate on C99, would be very strange behaviour. I deduce that the balance
of probability is that you don't have a conforming C99 implementation on
your desktop. I can only think of two other options, neither of which is
very complimentary to you, so I'd rather avoid them if I can.
The fact that I
use GCC doesn't mean I must *only* have GCC on my machine. I simply
don't think that "conforming" == "perfect", as you seem to think.
That's precisely what "conforming" means.
"6 The two forms of conforming implementation are hosted and
freestanding. A conforming hosted implementation shall accept any strictly
conforming program. A conforming freestanding implementation shall accept
any strictly conforming program that does not use complex types and in
which the use of the features specified in the library clause (clause 7)
is confined to the contents of the standard headers <float.h>, <iso646.h>,
<limits.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>. A
conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any
strictly conforming program."
There's no room in there for imperfection. Either an implementation
conforms or it doesn't.
>De jure, C99
is the C Standard. De facto, C90 is the C Standard.
They're both C standards; the latter is the *current* standard;
De jure, C99 is the C Standard. De facto, C90 is the C Standard.
For the third time: They're *both* C standards. C99 is the *current*
standard.
It depends on what you mean by "current".
>Is that so hard to understand for you? I mean, I know you struggled with
the terminology, but I have now explained that. Do you *have* to
struggle with the common sense, too?
It seems to me your common sense and my common sense are very
different.
On that, we can agree.
>Are you really so foolish as to believe
there's any point in trying to write code that adheres to a Standard to
which not even your own implementation conforms?
What makes you think I can only have *one* implementation?
I have seen no evidence so far that you have *even* one (C99-conforming)
implementation.
Besides,
while GCC doesn't strictly conform to the standard, they've clearly
marked what features are supported and which aren't, and the failures
are minor. So I wouldn't be "foolish" even if I had *only* GCC
available to me.
If your code doesn't need to be portable, I agree. But if your code doesn't
need to be portable, why do you care in the first place?
><snip>
I don't know exactly which platforms are supported by C99
implementations,
>Then you are in no position to make an argument about C99's
portability or otherwise.
I am if my standards of portability comprise an implementation being
portable among a number of fairly popular and widely used OSs, and if
there are implementations for C99 that target those platforms.
That's a lot of ifs.
It proves the point.
No, it's a lot of ifs. It doesn't prove anything at all. Your "proof",
so-called, says that you don't know what you're talking about and you
consider yourself free to re-define your terms as you go along, therefore
you must be right. Sorry, but it doesn't convince me.
<snip>
>But since you don't actually know whether the
platforms you name have C99 implementations available for them, your
point lacks force.
Again:
Not if my standards of portability comprise an implementation being
portable among a number of fairly popular and widely used OSs, and if
there are implementations for C99 that target those platforms.
Again, that's a lot of ifs. You're talking through your nose and hoping
that the facts support you, instead of checking and presenting the
facts.
What facts are you referring to?
The availability and installation of C99 implementations on your targets.
I stated that I don't necessarily
need to know exactly on which platforms I can compile code, depending
on my portability needs. That's the fact.
Provided your portability needs are very modest and provided that you don't
need to port to platforms where those needs are not met, yes. That's a
little like saying you have a brand-new widget that is really useful, and
okay, you know it needs a special kind of power source, but you can use
your widget ANYWHERE that this special power source is available. True
enough, but it doesn't actually say much.
Those who program in the common subset of C90 and C99 genuinely don't need
to know on which platforms their code will be compiled, because any
platform that can support C code at all is going to have a C90
implementation available for it, and by sticking to the common subset they
avoid the risk of the code /not/ compiling because someone out there
actually happened to have a C99 implementation.
<snip>
>I would certainly include mainframes and mid-range computers, which
you seem to have ignored completely.
Yes, because they are of no interest to me.
Well, there's a shock. Nevertheless, there's a lot more to life than
Vista.
I don't use Vista.
Well, I suppose I should thank heaven for small mercies.
Anyway, not everyone has the same interests as you.
Very true. But I'm not concerned with those who have the /same/ interests
as me. I can be absolutely sure that they will be able to compile my code,
because they'll have the same system as me. I'm far more concerned with
those who have /different/ interests to me. If they can't compile my code
too, that's a big problem.
<snip>
Like I've told you before, I use GCC's non-conforming C99
implementation.
>So no, then. If C99 isn't even portable to *your* desktop, it is hard
to see how you can sustain a claim to general portability.
I use C99 for my desktop.
That's a change from your last article, where you claimed you did not
use C99 for your desktop. I don't count non-conforming implementations,
since they don't implement C99.
They do implement C99,
No, they don't.
just not completely.
You can't be a little bit pregnant. Either you're pregnant or you're not.
>Compilers are normally pretty
easy to use. But if the implementation *doesn't conform*, then you can't
trust it to run code that wasn't tailored specifically for it.
You can trust it if the implementation has clearly marked the features
it has implemented, and the ones it hasn't, as is the case for GCC.
The more I read this, the more I think you've never actually ported code in
your life.
It's a similar case for conforming implementations: if it claims to
conform, you can safely use everything the standard defines and as it
defines it. If it doesn't conform, you have to see the documentation
to find out what you can use safely and what not.
No, you can't, because the bits of C99 that *your* implementation
implements correctly might not be the same as the bits of C99 that the
other guy's implementation implements correctly. The issue here is
portability. A program is (minimally) portable if it can be compiled and
executed correctly (without source code changes) on at least two
implementations. If those two implementations disagree about the semantics
or legality of a construct used by the program, then the program is *not*
portable (without source code changes) between those two implementations.
The more implementations that translate the program correctly and with
identical semantics (without source code changes), the more portable the
program. There are those for whom portability is really, really, really
important, and for them, perfection in conformance - whilst admittedly an
unattainable ideal - is nevertheless vastly important, and "misses out
whole chunks of the Standard" doesn't count as being even remotely close
to what is required. The conformance of gcc, Visual Studio, Borland C,
Intel C, Digital Mars C, C/370, LE370, XL C, Norcroft C, CodeWarrior - and
plenty of other compilers - to C90 is astoundingly good, making C90 the
Standard of choice when writing code intended to be portable.
but the compiler's usability. For example, lcc-win doesn't
conform, but it has the most useful set of extensions I've ever
seen on any compiler.
>If it doesn't implement the language correctly, the extensions are a
moot point.
That's your opinion (and apparently only yours).
I think you'll find a wide body of support for the opinion that
compilers ought to be able to translate programs according to spec, if
only you're prepared to take your blinkers off.
Likewise, many people will agree that compiler-specific extensions are
generally useful.
Sure, and nobody has claimed otherwise as far as I'm aware - but
compiler-specific extensions are not topical here. Similarly, I have on my
desk a fret brush. It's in a tube marked "ghs Fast-Fret" ("Glides on,
wipes off, cleans strings, lets you play faster, brightens sound, prolongs
fingerboard life, long-lasting, won't damage finish, won't soil or stain,
can't spill or break".) Very useful indeed, and I use it regularly. But
it's hardly relevant in comp.lang.c, is it? Same applies to
compiler-specific extensions.
Also, I forgot to mention on the previous post: "non-
conforming" != "incorrect".
If it isn't conforming, it isn't a C compiler. If it conforms to C90 but
not to C99, it's a C90 compiler but not a C99 compiler. gcc currently
falls into that category.
It's the compiler's decision what to do when a has something in it
invokes undefined behavior.
Actually, very often the compiler *doesn't* make that decision. For
example, consider the following code:
void foo(unsigned int *a, unsigned int *b)
{
*a += ++*b;
}
This code is standalone, in the sense that one could legally compile it
as a separate translation unit. Do you see any reason why a compiler
should decide to insert extra instructions into this function's
translated code to guard against undefined behaviour, especially when
the compiler has no reason to believe that the function will ever be
invoked incorrectly?
But let's look at a more obvious example of undefined behavior:
You avoided the question. Why did you avoid the question?
>
int i;
int *p = &i;
p++;
In this case, it's obvious to the compiler that the code invokes
undefined behavior,
But it doesn't. It's on the edge of doing so in two ways, but it doesn't
*actually* invoke undefined behaviour.
and the compiler is faced with the decision of
what to do: Should it not increment p?
It is required to increment p. The code is strictly conforming.
Should it increment it and hope
for the best?
It must increment the pointer. What it hopes is its own affair.
Should it generate instructions to erase all files in
the hard disk?
No, because the code is strictly conforming and doesn't have any "erase all
files" semantics.
I'm not sure about the first two, but the third is
legal according to the standard (as you already agreed).
I agreed no such thing, since the code is strictly conforming.
If a compiler does what I mentioned above
in a case where a program does something that invokes undefined
behavior, I'd deem that compiler useless.
At the very least, it would be a valuable teaching tool.
But not everyone's on the learning phase, and some people need
productivity.
Their productivity will increase if they have learned to avoid invoking
undefined behaviour unintentionally.
And a compiler like that would be nothing but useless to
a serious programmer.
Presumably you define "serious programmer" as "programmer who
unintentionally invokes undefined behaviour on a regular basis".
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Keith Thompson said:
Richard Heathfield <rj*@see.sig.invalidwrites:
<snip>
>>
"supports C99" and "conforms to C99" have different meanings.
I suppose so, but the statement that it "Supports" the C99 standard
strongly implies that it conforms to it.
Well, there /is/ a distinction. If I recall correctly (which I might not),
it was Greg Comeau who started out by advertising that Comeau C "conforms
to C99", but later adapted the claim to "supports C99" because he'd found
a sticking-point that he hadn't (at that point in time) been able to fix.
Perhaps Greg could comment on that, as I don't wish to misrepresent him. (I
am not aware of Comeau C's current status w.r.t. C99.)
If I were a potential
customer, and I found that IBM's marketing department had told me that
their compiler "supports" C99 but in fact did not fully conform to it,
I would conclude that they had attempted to deceive me.
I, on the other hand, would conclude that I hadn't asked them enough
questions. :-)
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
jacob navia said:
Andrew Poelstra wrote:
>On 2008-08-17, jacob navia <ja***@nospam.comwrote:
>>Heathfield was forced to recognize his error, but then he started
the usual campaign against standard C (not portable, not implemented
etc etc)
He accepted his error, but pointed out that reliance on C99 restricts
portability compared with C89, since it is not implemented on nearly
as many platforms. This is a statement of fact, not a "campaign
against standard C".
Talk about word games.
>>OS390 was obsoleted by IBM in 2000 and replaced by the z/VM
system, that is the main system used by IBM mainframes.
Obviously I think Heathfield was speaking about that system
(OS390 later z/VM).
How is this obvious? If he said OS390, he meant OS390. Its
obsolescence does not change what its name refers to.
>>When he speaks about OS390 he is maybe talking about
CP/M or maybe about Apple pascal. Who knows.
Maybe OS390?
And yes, I snipped a lot.
Even if I accept that he was speaking about ONLY OS390
HE IS STILL WRONG since the z/OS XL C/C++ runs in OS390 and
fully supports C99.
If you would be so kind as to learn to read, and then to read my original
statement, you will find that I didn't make any claims about the
availability *or otherwise* of C99 implementations on mainframe operating
systems. Rather, I made a statement about Sebastian's attitude towards
portability.
Until you realise this, you will continue to make an idiot of yourself with
these ludicrous "liar" claims. You really, really should learn to read. It
would do you a lot of good.
So he was lying again.
For example, you'd stop saying stupid things like this. Well, you might.
How many times do I have to prove Heathfield wrong?
Once would be a good start, but I don't think it's happened yet. (Yeah,
it's possible, obviously, that it has happened and I've forgotten because
it was so long ago.)
More to the point, how many times do people have to ask you to read what I
actually wrote instead of making silly claims about what you thought I
wrote?
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Ben Bacarisse <be********@bsb.me.ukwrites:
Keith Thompson <ks***@mib.orgwrites:
>jacob navia <ja***@nospam.comwrites:
>>Keith Thompson wrote:
Fact: Richard did not claim that IBM mainframes do not have C99.
OK. I assumed that he was speaking of the z/VM system, as OS390
is called today.
But even if we take it at face value, the compiler for OS390
is z/OS XL C/C++, that supports C99, so he was telling a
misleading statement when he said that C99 is NOT available for OS390.
In the article with Message-ID
<Uu******************************@bt.com>, available
at<http://groups.google.com/group/comp.lang.c/msg/d070c346d8105ca8>,
he DID NOT SAY that C99 is not available for OS390.
I agree that he did not, but I am now a bit confused. I though, right
up until your message, that I was following all this.
The remark: "I think the OS390 and VM/CMS folks might cough and
splutter a bit if they heard you say that" certainly suggested to me
that it was the narrowness of the proffered list of C99 supported
platforms that would cause the spluttering, i.e. that OS/390 VM/CMS
could not be on the list.
Now I /can/ put a meaning to it that has nothing to do with C99
availability for OS/390 VM/CMS, but it feels like quite a stretch to
do so, and makes the remark seem out of place.
If there /is/ a C99 compiler for OS/390 (something I can't comment on
but which does not yet appear to have been documented by any of the
posted links) it seems a misleading example to pick in the middle of
an exchange about systems to which C99 code is portable.
How did you read it?
Ok, let's look at the article yet again; this is Richard Heathfield
replying to s0****@gmail.com.
| I don't know exactly which platforms are supported by C99
| implementations,
|
| Then you are in no position to make an argument about C99's portability or
| otherwise.
|
| but let's name five (random) platforms for
| illustration:
|
| - Windows
| - Linux
| - Mac OS X
| - Solaris
| - HP-UX
|
| By what I'd call "common standards," something that is portable among
| that much platforms is very portable.
|
| I think the OS390 and VM/CMS folks might cough and splutter a bit if they
| heard you say that. But since you don't actually know whether the
| platforms you name have C99 implementations available for them, your point
| lacks force.
I read it as s0suk3 saying that anything portable to Windows, Linux,
Mac OS X, Solaris, and HP-UX is "very portable", and Richard offering
OS390 and VM/CMS as counterexamples. The surrounding context was
about C99, but the immediate point was about portability. s0suk3 made
a point *about portability*, and Richard responded to it. And it's
being blown completely out of proportion because of jacob's fixation.
By the way, in case you are in any doubt, I am not supporting any of Jacob
Navia's wild claims about what Richard Heathfield said -- they are as
over the top as I have come to expect -- I am just confused about the
reference to OS/390 if it is not about C99 availability.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Ben Bacarisse said:
James Kuyper <ja*********@verizon.netwrites:
>jacob navia wrote:
>>Richard Heathfield wrote:
jacob navia said:
...
>>>>He said that C99 wasn't available for IBM mainframes,
No, I didn't. Learn to read, please.
You said that there was no C99 for S390.
Could you give me a citation for that, please? I can't find any such
comment from Richard Heathfield, so I'm probably looking in the wrong
place. The only previous comment I could find from him mentioning S390
is the following (and it mentions OS390, not S390):
Richard Heathfield wrote:
>>s0****@gmail.com said:
...
>>>but let's name five (random) platforms for
illustration:
- Windows
- Linux
- Mac OS X
- Solaris
- HP-UX
By what I'd call "common standards," something that is portable among
that much platforms is very portable.
I think the OS390 and VM/CMS folks might cough and splutter a bit if
they
>>heard you say that
You obviously can't be referring to that message, because it is only a
a comment about how the mainframe people might consider that
definition of "portable" to be absurdly restricted. They would be
right, of course - a definition of "portable" that excludes the most
of the machines for which C code is written nowadays is pretty
ridiculous.
I am used to some pretty adroit verbal gymnastics in c.l.c but is that
really how you read that remark?
It is really how I wrote it, and no gymnastics were intended. That you
(i.e. a reasonable person) inferred any is something I find astonishing.
In an exchange about C99
portability, after a list of some systems that were claimed (rightly
or wrongly) to have C99 support a reference to OS/390 was made just to
make a remark about other, more general, portability issues?
Let me paraphrase the claim as I understood it: "Anything that's portable
to Windows, Linux, Mac OS X, Solaris, and HP-UX is very portable", to
which my reply was intended to convey the meaning "the mainframe guys
might consider your list to be somewhat parochial".
>
If that was the intent (and I trust Richard Heathfield will tell us the
intent) then it was a first-class trap into which Jacob fell. As I've
said before, I don't like the term, but I might just have to call it a
first-class troll.
IIRC Jacob Navia was not even involved in the discussion at that point, and
I had no reason to believe he would even read the article, let alone reply
to it. No, it wasn't a troll. It was a rebuttal to Sebastian's parochial
"I'm all right Jack" attitude to portability.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Keith Thompson said:
<snip>
I read it as s0suk3 saying that anything portable to Windows, Linux,
Mac OS X, Solaris, and HP-UX is "very portable", and Richard offering
OS390 and VM/CMS as counterexamples. The surrounding context was
about C99, but the immediate point was about portability. s0suk3 made
a point *about portability*, and Richard responded to it.
Precisely so. Nevertheless, if someone as bright as Ben can misinterpret
it, I am beginning to wonder whether I was as clear as I should have been
in my original statement.
The balance (in the general case) is a tricky one. Spelling out every
single nuance of every thought is (a) too time-consuming, and (b)
insulting to my readership, and (c) probably impossible anyway. But my
more usual strategy of leaving people to make what *I* consider to be
obvious and trivial leaps of logic appears to run the risk of being
misunderstood even by bright people.
It never occurred to me, when I was writing a reply to Sebastian's
eyebrow-raising claim that we might paraphrase as "if it works on this
handful of tiny systems, well, that's portable enough for rock n' roll",
that my reply about parochialism might be taken as a claim about C99's
availability or otherwise on mainframe systems. I must have re-read it a
dozen times now, and I still can't see how it could be interpreted that
way. Nevertheless, I recognise that Ben isn't stupid, so I suppose there
must be some way of looking at the wording that completely changes the
meaning. Perhaps Ben could explain how he arrives at that interpretation.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard Heathfield <rj*@see.sig.invalidwrites:
Keith Thompson said:
[...]
>If I were a potential customer, and I found that IBM's marketing
department had told me that their compiler "supports" C99 but in
fact did not fully conform to it, I would conclude that they had
attempted to deceive me.
I, on the other hand, would conclude that I hadn't asked them enough
questions. :-)
Well, that too.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson wrote:
Ben Bacarisse <be********@bsb.me.ukwrites:
>Keith Thompson <ks***@mib.orgwrites:
>>jacob navia <ja***@nospam.comwrites:
Keith Thompson wrote:
Fact: Richard did not claim that IBM mainframes do not have C99.
OK. I assumed that he was speaking of the z/VM system, as OS390
is called today.
But even if we take it at face value, the compiler for OS390
is z/OS XL C/C++, that supports C99, so he was telling a
misleading statement when he said that C99 is NOT available for
OS390.
In the article with Message-ID
<Uu******************************@bt.com>, available
at<http://groups.google.com/group/comp.lang.c/msg/d070c346d8105ca8>,
he DID NOT SAY that C99 is not available for OS390.
I agree that he did not, but I am now a bit confused. I though,
right up until your message, that I was following all this.
The remark: "I think the OS390 and VM/CMS folks might cough and
splutter a bit if they heard you say that" certainly suggested to me
that it was the narrowness of the proffered list of C99 supported
platforms that would cause the spluttering, i.e. that OS/390 VM/CMS
could not be on the list.
Now I /can/ put a meaning to it that has nothing to do with C99
availability for OS/390 VM/CMS, but it feels like quite a stretch to
do so, and makes the remark seem out of place.
If there /is/ a C99 compiler for OS/390 (something I can't comment on
but which does not yet appear to have been documented by any of the
posted links) it seems a misleading example to pick in the middle of
an exchange about systems to which C99 code is portable.
How did you read it?
Ok, let's look at the article yet again; this is Richard Heathfield
replying to s0****@gmail.com.
| I don't know exactly which platforms are supported by C99
| implementations,
|
| Then you are in no position to make an argument about C99's
| portability or otherwise.
|
| but let's name five (random) platforms for
| illustration:
|
| - Windows
| - Linux
| - Mac OS X
| - Solaris
| - HP-UX
|
| By what I'd call "common standards," something that is portable
| among that much platforms is very portable.
|
| I think the OS390 and VM/CMS folks might cough and splutter a bit if
| they heard you say that. But since you don't actually know whether
| the platforms you name have C99 implementations available for them,
| your point lacks force.
I read it as s0suk3 saying that anything portable to Windows, Linux,
Mac OS X, Solaris, and HP-UX is "very portable", and Richard offering
OS390 and VM/CMS as counterexamples. The surrounding context was
about C99, but the immediate point was about portability. s0suk3 made
a point *about portability*, and Richard responded to it. And it's
being blown completely out of proportion because of jacob's fixation.
>By the way, in case you are in any doubt, I am not supporting any of
Jacob Navia's wild claims about what Richard Heathfield said -- they
are as over the top as I have come to expect -- I am just confused
about the reference to OS/390 if it is not about C99 availability.
No. The list that Sebastian made up was intended to serve as a made up
list of C99 supported platforms. Richard's first comment in the quote
above intersects a statement by Sebastian which is *continuing* his
point about C99, not switching from C99 to general portability.
Sebastian is saying that he considers C99 to be pretty reasonably
portable if it supports a list of platforms similar to the hypothetical
list that he gave. Richard responded by saying that the OS390 and
VM/CMS people will be surprised about this comment, which directly
suggests that that is because C99 is not available for them. This is
the most reasonable interpretation of the exchange you have quoted
above. Obviously others will interpret it differently. However this
doesn't excuse jacob's hysterical tirade. If C99 is indeed available on
OS390 it simply means that Richard made a mistake -- perhaps his
information was outdated. Accusations of deliberate falsehood are quite
over the top.
santosh said:
<snip>
No. The list that Sebastian made up was intended to serve as a made up
list of C99 supported platforms.
That was not how I read it. I read it as a list of platforms such that any
program that was portable across all of them could be considered "very
portable". This list was woefully inadequate. For example, on every single
platform on the list, the following construct:
if(ch >= 65 && ch <= 90)
{
printf("%c is an upper case letter\n", ch);
}
will work just fine - and yet that code will always produce the wrong
results on EBCDIC-based platforms. Now, that wasn't the point I had
specifically in mind when composing my reply - I merely use it as an
illustration that the list is inadequate for general use. I think what
Sebastian meant to say (or what he ought to have meant to say?!?) is that
such a list was adequate for *his* purposes, which is fine - but what he
actually said was that the list was adequate by what he referred to as
"common standards". In other words, he was dismissing any platform not on
the list as being "uncommon".
Richard's first comment in the quote
above intersects a statement by Sebastian which is *continuing* his
point about C99, not switching from C99 to general portability.
Yes, I agree with the text of what you say, but I suspect that I disagree
with the reasoning behind it.
Sebastian is saying that he considers C99 to be pretty reasonably
portable if it supports a list of platforms similar to the hypothetical
list that he gave.
Yes.
Richard responded by saying that the OS390 and
VM/CMS people will be surprised about this comment, which directly
suggests that that is because C99 is not available for them.
No, it doesn't. It directly suggests that they would be surprised to see
that the list of platforms that Sebastian gives excludes their own
platforms, which support a vast amount of business processing in the real
world. Whether C99 is or is not available to mainframe systems is
completely beyond this particular point (although I agree that it is not
beyond the wider point of how portable C99 actually is). That is, I was
suggesting that mainframe people would be surprised at Sebastian's
parochialism; I was *not* suggesting that they would be surprised at the
availability or otherwise of C99 on their platform.
This is
the most reasonable interpretation of the exchange you have quoted
above.
Not to me it isn't! :-)
Obviously others will interpret it differently. However this
doesn't excuse jacob's hysterical tirade. If C99 is indeed available on
OS390 it simply means that Richard made a mistake
No, it doesn't mean that at all, because it's completely beside the point
that I was making, which was about Sebastian's rather limited world view.
-- perhaps his information was outdated.
It is certainly the case that I've never encountered a C99 mainframe
implementation in the real world, but that is very different from claiming
that no such implementations exist, and I made no such claim.
Accusations of deliberate falsehood are quite over the top.
Right - especially when they are based on a misinterpretation of what I
actually wrote.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
On 18 Aug, 05:02, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
James Kuyper <jameskuy...@verizon.netwrites:
jacob navia wrote:
Richard Heathfield wrote:
jacob navia said:
>>He said that C99 wasn't available for IBM mainframes,
>No, I didn't. Learn to read, please.
You said that there was no C99 for S390.
Could you give me a citation for that, please? I can't find any such
comment from Richard Heathfield, so I'm probably looking in the wrong
place. The only previous comment I could find from him mentioning S390
is the following (and it mentions OS390, not S390):
Richard Heathfield wrote:
s0s...@gmail.com said:
...
>but let's name five (random) platforms for
illustration:
> - Windows
- Linux
- Mac OS X
- Solaris
- HP-UX
>By what I'd call "common standards," something that is portable among
that much platforms is very portable.
this is his definition of "very portable". Note he didn't say there
was a C99 implementation for them.
I think the OS390 and VM/CMS folks might cough and splutter a bit if
they heard you say that
ie. he's missed some widely used platforms. Note He didn't
say a C99 compiler was *not* available for these platforms.
You obviously can't be referring to that message, because it is only a
a comment about how the mainframe people might consider that
definition of "portable" to be absurdly restricted. They would be
right, of course - a definition of "portable" that excludes the most
of the machines for which C code is written nowadays is pretty
ridiculous.
yes, that's what I read it to say
I am used to some pretty adroit verbal gymnastics in c.l.c but is that
really how you read that remark? In an exchange about C99
portability, after a list of some systems that were claimed (rightly
or wrongly) to have C99 support
I did not see that explicitly claimed (I suspect he doesn't know)
a reference to OS/390 was made just to
make a remark about other, more general, portability issues?
yes
If that was the intent (and I trust Richard Heathfield will tell us the
intent) then it was a first-class trap into which Jacob fell. As I've
said before, I don't like the term, but I might just have to call it a
first-class troll.
Jacob doesn't read what is written.
--
Nick Keighley
in comp.lang.c, the very people most capable of making the inference
are those least likely to make it. This newsgroup considers pedantry
to be an art form.
Richard Heathfield
On 18 Aug, 00:09, jacob navia <ja...@nospam.comwrote:
Keith Thompson wrote:
Fact: Richard did not claim that IBM mainframes do not have C99.
OK. I assumed that he was speaking of the z/VM system, as OS390
is called today.
you are *still* mirading what people are saying. Richard *was*
talking about mainframes. He DID NOT SAY OS390 (z/VM) DID NOT HAVE
A CONFORMING C99 COMPILER. He initially listed OS390 as being an
important platform that should be considered when listing major
platforms. And nothing sbout compilers available or not available.
At a later point someone (you?) found a statement that IBM's compiler
"supported" C99. Richard argued that this didn't say "conforms to"
C99. He still didn't say the compiler was not conforming. Then someone
found a site that stated that IBM's compiler did "conform to" C99.
Richard thanked them for providing the information.
Learn to read.
But even if we take it at face value, the compiler for OS390
is z/OS XL C/C++, that supports C99, so he was telling a
misleading statement when he said that C99 is NOT available for OS390.
he didn't say that
IT IS AVAILABLE for OS390. The compiler that was marketed with
that system is no longer available since it was discontinued in 2004.
The replacement product for OS390 according to IBM's documentation
is the z/OS XL C/C++. This is obvious for anyone.
You see how far you go with your "facts" ?
Just LIES.
no. Gat a dictionary.
Fact: You claimed that he had made that claim.
Even if I would accept he was talking about OS390 is is WRONG
ANYWAY (and you with him of course)
Fact: You called him a liar because of it.
Yes, and the "fact" that OS390 has no C99 is a LIE since
there is a compiler for OS390 that supports C99.
And you still will not admit that you were wrong.
And I have presented all necessary facts to prove I am not!
you have presented no facts
You are waging a war against standard C in this group.
no
Wrong.
Yes. Each time you speak about a significant platform
WITHOUT C99 I prove you wrong!
no
--
Nick Keighley
On Aug 17, 11:43 pm, Richard Heathfield <rj*@see.sig.invalidwrote:
s0****@gmail.com said:
On Aug 17, 3:07 am, Richard Heathfield <rj*@see.sig.invalidwrote:
s0****@gmail.com said:
Richard Heathfield wrote:
s0****@gmail.com said:
<snip>
Either he's right (which he is), or he's not.
He's right only in a completely useless and almost meaningless way.
How can someone be right in a meaningless way?
It's not difficult, but someone can also be wrong in meaningless ways...
No. Either someone is wrong, or not. It's *that* simple.
You're wrong. It's that simple.
So you're implying that someone can be right /and/ wrong at the same
time, regarding the same subject? I don't share your reasoning.
<snip>
*IN LAW*, C99 is the current Standard. *IN PRACTICE*, here you are,
advocating C99 and saying that C90 is obsolete, but according to your
last article you don't even have a conforming C99 implementation on your
desktop machine!
Looks like it's hard for you to understand simple facts. What makes
you think there can only be *one* standard?
I'm well aware that the number of Standards exceeds one.
Finally.
Like I said, they're
*both* C standards. C99 is the *current* standard.
Whether that is true depends on what you mean by the word "current". In
theory ("in law", if you like), you're right - C99 /is/ the current
Standard. In practice, you're wrong - C90 is the current Standard, because
that's the one which is conformed to by the implementations that people
actually use.
What people would those be? I've seen more people use C99 than C90.
So, even though I don't agree with the "de jure," "de facto," "in
theory" and "in practice" stuff, C99 would be the current standard
even in the way you mean it.
I'm sure I have already explained this to you at least twice.
And no, I never said C89 was obsolete.
Neither did I claim that you had said that.
Well, you said
"*IN PRACTICE*, here you are, advocating C99 and saying that C90 is
obsolete, ..."
I was regarding C89 as interchangeable with C90 in this context.
In fact, I'd recommend using it for
applications that need more portability than C99 offers, or to
maintain legacy code that uses it.
So would I. So we are, after all, in agreement. Good.
And how do you know I don't have a
conforming C99 implementation in my desktop machine?
Logic. You are advocating C99. You claim to use gcc, which is not a C99
compiler.
It is.
Either you have a C99 implementation on your desktop machine or
you don't.
I do.
To have such an implementation on your desktop and yet not even
mention it, let alone claim to use it, even at such a late stage in a
debate on C99, would be very strange behaviour. I deduce that the balance
of probability is that you don't have a conforming C99 implementation on
your desktop. I can only think of two other options, neither of which is
very complimentary to you, so I'd rather avoid them if I can.
I don't think mentioning the programs installed on my computer is
relevant to this discussion. If you think it's relevant in the sense
that I need to prove that I have a C99-conforming implementation
available in my machine: you can see my headers; I'm on Linux. There
are C99-conforming implementations for Linux. There, was that so hard?
But the point is that you did not have a valid reason to believe I
didn't.
The fact that I
use GCC doesn't mean I must *only* have GCC on my machine. I simply
don't think that "conforming" == "perfect", as you seem to think.
That's precisely what "conforming" means.
"6 The two forms of conforming implementation are hosted and
freestanding. A conforming hosted implementation shall accept any strictly
conforming program. A conforming freestanding implementation shall accept
any strictly conforming program that does not use complex types and in
which the use of the features specified in the library clause (clause 7)
is confined to the contents of the standard headers <float.h>, <iso646.h>,
<limits.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>. A
conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any
strictly conforming program."
I don't see the word "perfect" in there.
There's no room in there for imperfection. Either an implementation
conforms or it doesn't.
Of course. Saying "this implementation conforms, but it doesn't," is a
null statement. And I've never said anything like that. BTW, what does
that have to do with an implementation being or not being perfect?
De jure, C99
is the C Standard. De facto, C90 is the C Standard.
They're both C standards; the latter is the *current* standard;
De jure, C99 is the C Standard. De facto, C90 is the C Standard.
For the third time: They're *both* C standards. C99 is the *current*
standard.
It depends on what you mean by "current".
Apparently we're never going to agree on what "current" means.
Is that so hard to understand for you? I mean, I know you struggled with
the terminology, but I have now explained that. Do you *have* to
struggle with the common sense, too?
It seems to me your common sense and my common sense are very
different.
On that, we can agree.
Are you really so foolish as to believe
there's any point in trying to write code that adheres to a Standard to
which not even your own implementation conforms?
What makes you think I can only have *one* implementation?
I have seen no evidence so far that you have *even* one (C99-conforming)
implementation.
Like I mentioned above, I'm currently on Linux. You can find out for
yourself which conforming implementations there are if you are so
interested.
Besides,
while GCC doesn't strictly conform to the standard, they've clearly
marked what features are supported and which aren't, and the failures
are minor. So I wouldn't be "foolish" even if I had *only* GCC
available to me.
If your code doesn't need to be portable, I agree. But if your code doesn't
need to be portable, why do you care in the first place?
That depends on what you mean by portable. Do you mean "from
microchips to supercomputers"? Or do you mean "any popular OS"? I
think I shouldn't have to mention any further that your standards of
portability are radically different from mine.
Also, in the case of GCC, they implement it closely enough that I've
never even had to read their site about C99. So I've been writing
standard C without worrying about what GCC supports or not, which
proves that using GCC doesn't limit the code to be compiled only under
GCC. So the code's portability is not reduced at all.
<snip>
I don't know exactly which platforms are supported by C99
implementations,
Then you are in no position to make an argument about C99's
portability or otherwise.
I am if my standards of portability comprise an implementation being
portable among a number of fairly popular and widely used OSs, and if
there are implementations for C99 that target those platforms.
That's a lot of ifs.
It proves the point.
No, it's a lot of ifs. It doesn't prove anything at all. Your "proof",
so-called, says that you don't know what you're talking about and you
consider yourself free to re-define your terms as you go along, therefore
you must be right.
No. The fact that my standards for something are different from yours
doesn't mean I'm re-defining anything.
Sorry, but it doesn't convince me.
But it proves you wrong.
<snip>
But since you don't actually know whether the
platforms you name have C99 implementations available for them, your
point lacks force.
Again:
Not if my standards of portability comprise an implementation being
portable among a number of fairly popular and widely used OSs, and if
there are implementations for C99 that target those platforms.
Again, that's a lot of ifs. You're talking through your nose and hoping
that the facts support you, instead of checking and presenting the
facts.
What facts are you referring to?
The availability and installation of C99 implementations on your targets.
I stated that I don't necessarily
need to know exactly on which platforms I can compile code, depending
on my portability needs. That's the fact.
Provided your portability needs are very modest and provided that you don't
need to port to platforms where those needs are not met, yes. That's a
little like saying you have a brand-new widget that is really useful, and
okay, you know it needs a special kind of power source, but you can use
your widget ANYWHERE that this special power source is available. True
enough, but it doesn't actually say much.
Those who program in the common subset of C90 and C99 genuinely don't need
to know on which platforms their code will be compiled,
What people would those be? We're discussing the portability of C89/
C90/C99 here, but we both know that out there in the real world this
isn't as relevant as it may sound here. I hardly can think of any
serious program that has the fortune of being able to restrict itself
to pure standard C. Want to hit the net? Want to flow through more
than one thread of control? Want to draw a window on the screen? Want
to start another process? Want to handle directories? There you go
your (completely) non-portable code. I at least have never had the
chance to write a (serious) program in standard C. Have /you/? Have
you ever developed production code in which you only write to a few
streams, do some math operations, do some text processing, and finally
display a nice "exiting" message?
because any
platform that can support C code at all is going to have a C90
implementation available for it, and by sticking to the common subset they
avoid the risk of the code /not/ compiling because someone out there
actually happened to have a C99 implementation.
<snip>
I would certainly include mainframes and mid-range computers, which
you seem to have ignored completely.
Yes, because they are of no interest to me.
Well, there's a shock. Nevertheless, there's a lot more to life than
Vista.
I don't use Vista.
Well, I suppose I should thank heaven for small mercies.
Anyway, not everyone has the same interests as you.
Very true. But I'm not concerned with those who have the /same/ interests
as me. I can be absolutely sure that they will be able to compile my code,
because they'll have the same system as me. I'm far more concerned with
those who have /different/ interests to me. If they can't compile my code
too, that's a big problem.
<snip>
Like I've told you before, I use GCC's non-conforming C99
implementation.
So no, then. If C99 isn't even portable to *your* desktop, it is hard
to see how you can sustain a claim to general portability.
I use C99 for my desktop.
That's a change from your last article, where you claimed you did not
use C99 for your desktop. I don't count non-conforming implementations,
since they don't implement C99.
They do implement C99,
No, they don't.
Yes, they do.
just not completely.
You can't be a little bit pregnant. Either you're pregnant or you're not.
But a glass of water can be a little full. I'd say my analogy applies
better than yours, but that's something we're never going to agree on,
are we?
Compilers are normally pretty
easy to use. But if the implementation *doesn't conform*, then you can't
trust it to run code that wasn't tailored specifically for it.
You can trust it if the implementation has clearly marked the features
it has implemented, and the ones it hasn't, as is the case for GCC.
The more I read this, the more I think you've never actually ported code in
your life.
I have, just not in the same way as you.
It's a similar case for conforming implementations: if it claims to
conform, you can safely use everything the standard defines and as it
defines it. If it doesn't conform, you have to see the documentation
to find out what you can use safely and what not.
No, you can't, because the bits of C99 that *your* implementation
implements correctly might not be the same as the bits of C99 that the
other guy's implementation implements correctly.
But that wasn't my point. My point was, again: you can use safely the
subset of the language that the implementation implements; you just
have to know what you can use and what not. And *that* isn't going to
make the code any less portable, since it will later be compilable
under any conforming implementation. If you use extensions, then sure,
you're limiting the code to be compilable only under that specific
compiler, but that's not what I mentioned.
The issue here is
portability. A program is (minimally) portable if it can be compiled and
executed correctly (without source code changes) on at least two
implementations. If those two implementations disagree about the semantics
or legality of a construct used by the program, then the program is *not*
portable (without source code changes) between those two implementations.
You're talking as if I said anything about extensions.
The more implementations that translate the program correctly and with
identical semantics (without source code changes), the more portable the
program. There are those for whom portability is really, really, really
important, and for them, perfection in conformance - whilst admittedly an
unattainable ideal - is nevertheless vastly important, and "misses out
whole chunks of the Standard" doesn't count as being even remotely close
to what is required. The conformance of gcc, Visual Studio, Borland C,
Intel C, Digital Mars C, C/370, LE370, XL C, Norcroft C, CodeWarrior - and
plenty of other compilers - to C90 is astoundingly good, making C90 the
Standard of choice when writing code intended to be portable.
but the compiler's usability. For example, lcc-win doesn't
conform, but it has the most useful set of extensions I've ever
seen on any compiler.
If it doesn't implement the language correctly, the extensions are a
moot point.
That's your opinion (and apparently only yours).
I think you'll find a wide body of support for the opinion that
compilers ought to be able to translate programs according to spec, if
only you're prepared to take your blinkers off.
Likewise, many people will agree that compiler-specific extensions are
generally useful.
Sure, and nobody has claimed otherwise as far as I'm aware - but
compiler-specific extensions are not topical here. Similarly, I have on my
desk a fret brush. It's in a tube marked "ghs Fast-Fret" ("Glides on,
wipes off, cleans strings, lets you play faster, brightens sound, prolongs
fingerboard life, long-lasting, won't damage finish, won't soil or stain,
can't spill or break".) Very useful indeed, and I use it regularly. But
it's hardly relevant in comp.lang.c, is it? Same applies to
compiler-specific extensions.
You went more off-topic in that paragraph than I went on mentioning
the words "compiler-specific extensions." So I have to ask: Why do you
talk about your toy on comp.lang.c? :-)
And actually, the standard talks about compiler-specific extensions.
So it *is* relevant to comp.lang.c. It's simply not appropriate to
discuss them in detail, which I didn't. The standard, however, doesn't
mention anything about objects hanging around on your desk.
Also, I forgot to mention on the previous post: "non-
conforming" != "incorrect".
If it isn't conforming, it isn't a C compiler.
Yes, it is. It simply isn't conforming. Hence the phrase "non-
conforming C implementation."
If it conforms to C90 but
not to C99, it's a C90 compiler but not a C99 compiler. gcc currently
falls into that category.
GCC is both a C90 and C99 implementation. It conforms to C90, but it
doesn't conform to C99.
It's the compiler's decision what to do when a has something in it
invokes undefined behavior.
Actually, very often the compiler *doesn't* make that decision. For
example, consider the following code:
void foo(unsigned int *a, unsigned int *b)
{
*a += ++*b;
}
This code is standalone, in the sense that one could legally compile it
as a separate translation unit. Do you see any reason why a compiler
should decide to insert extra instructions into this function's
translated code to guard against undefined behaviour, especially when
the compiler has no reason to believe that the function will ever be
invoked incorrectly?
But let's look at a more obvious example of undefined behavior:
You avoided the question. Why did you avoid the question?
The function won't always invoke undefined behavior, so I thought I'd
bring up a more relevant and illustrative example. But anyway, what if
we modified the function so that it did something that would *always*
invoke undefined behavior? What do you think the compiler should do
then? Do you think I'd be OK for it to erase all files in the hard
disk?
>
int i;
int *p = &i;
p++;
In this case, it's obvious to the compiler that the code invokes
undefined behavior,
But it doesn't. It's on the edge of doing so in two ways, but it doesn't
*actually* invoke undefined behaviour.
and the compiler is faced with the decision of
what to do: Should it not increment p?
It is required to increment p. The code is strictly conforming.
Should it increment it and hope
for the best?
It must increment the pointer. What it hopes is its own affair.
Should it generate instructions to erase all files in
the hard disk?
No, because the code is strictly conforming and doesn't have any "erase all
files" semantics.
I'm not sure about the first two, but the third is
legal according to the standard (as you already agreed).
I agreed no such thing, since the code is strictly conforming.
Sorry; I thought it would undoubtedly invoke undefined behavior.
If a compiler does what I mentioned above
in a case where a program does something that invokes undefined
behavior, I'd deem that compiler useless.
At the very least, it would be a valuable teaching tool.
But not everyone's on the learning phase, and some people need
productivity.
Their productivity will increase if they have learned to avoid invoking
undefined behaviour unintentionally.
The world isn't perfect. Even the most experienced programmer will
make mistakes and invoke undefined bahavior.
And a compiler like that would be nothing but useless to
a serious programmer.
Presumably you define "serious programmer" as "programmer who
unintentionally invokes undefined behaviour on a regular basis".
No. In this context, I meant it more as "a programmer that needs to be
as productive as possible, and thus needs the best possible tools
available, and a compiler that doesn't erase all files in the hard
disk at the first sign of undefined behavior is the very minimum
requirement."
Sebastian This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Robert |
last post by:
Is there a way to determine why the Textdata field has "NULL" for a value.
The trace shows multiple "NULL" value records with the longest durations;
many greater than 50,000ms. The {} indicate the...
|
by: Ant |
last post by:
Hi, I need to find out what data types I need to work with time durations &
how to add/subtract them from clock time. For example:
A customer logs in at 7:30 in the morning. I need notification...
|
by: John Bailo |
last post by:
I'm doing a profile on my SQL Server to see if I can eliminate any long
running statements, and periodically, I see an entry for ".NET SqlClient
Data Provider". The durations for it are very...
|
by: PWS |
last post by:
Hi all,
I developed an online learning website where each student has his own
username/password and they can view course materials and take tests
online. I did that in PHP and PostgreSQL.
...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
