Storgae durations
jrda...@gmail.com
durations(static,automatic and dynamic) in C?
Richard Heathfield
> what is the difference between the tree storage
> durations(static,automatic and dynamic) in C?
Firstly, there are only two:
++++++++++++++++++++++++++++++++++++++++++++++++++
3.1.2.4 Storage durations of objects
An object has a storage duration that determines its lifetime.
There are two storage durations: static and automatic.
++++++++++++++++++++++++++++++++++++++++++++++++++
So, what's the difference between them?
++++++++++++++++++++++++++++++++++++++++++++++++++
An object declared with external or internal linkage, or with the
storage-class specifier static has static storage duration. For such
an object, storage is reserved and its stored value is initialized
only once, prior to program startup. The object exists and retains
its last-stored value throughout the execution of the entire
program./12/
An object declared with no linkage and without the storage-class
specifier static has automatic storage duration. Storage is guaranteed
to be reserved for a new instance of such an object on each normal
entry into the block in which it is declared, or on a jump from
outside the block to a label in the block or in an enclosed block.
++++++++++++++++++++++++++++++++++++++++++++++++++
--
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
> jrda...@gmail.com said:
>
>> what is the difference between the tree storage
>> durations(static,automatic and dynamic) in C?
>
> Firstly, there are only two:
Correction: there _were_ only two.
> ++++++++++++++++++++++++++++++++++++++++++++++++++
> 3.1.2.4 Storage durations of objects
>
> An object has a storage duration that determines its lifetime.
> There are two storage durations: static and automatic.
6.2.4 "Storage durations of objects" now says:
An object has a storage duration that determines its lifetime. There
are three storage durations: static, automatic, and
allocated. Allocated storage is described in 7.20.3.
How did C90 square there being only two with malloc?
--
Ben.
Richard Heathfield
> Richard Heathfield <r...@see.sig.invalid> writes:
>
>> jrda...@gmail.com said:
>>
>>> what is the difference between the tree storage
>>> durations(static,automatic and dynamic) in C?
>>
>> Firstly, there are only two:
>
> Correction: there _were_ only two.
Ah, okay - once more we've hit the limbo between de jure and de facto. (And
yes, I accept the correction.)
<snip>
> How did C90 square there being only two with malloc?
"The pointer returned if the allocation succeeds is suitably aligned so
that it may be assigned to a pointer to any type of object and then used
to access such an object in the space allocated (until the space is
explicitly freed or reallocated)."
That's neither static nor auto, and therefore (in C90 terms) it isn't a
storage duration. :-)
jacob navia
> jrda...@gmail.com said:
>
>> what is the difference between the tree storage
>> durations(static,automatic and dynamic) in C?
>
> Firstly, there are only two:
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++
> 3.1.2.4 Storage durations of objects
>
> An object has a storage duration that determines its lifetime.
> There are two storage durations: static and automatic.
> ++++++++++++++++++++++++++++++++++++++++++++++++++
>
This is wrong. Heathfield lives in the past so it is using a
standard that is no longer current. The correct place to
quote is the C standard 6.2.4 Storage durations of objects:
An object has a storage duration that determines its lifetime. There are
three storage durations: static, automatic, and allocated. Allocated
storage is described in 7.20.3.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Richard Heathfield
<snip>
> This is wrong. Heathfield lives in the past so it is using a
> standard that is no longer current.
No, Heathfield lives in the real world where almost no conforming C99
implementations exist, but where almost every platform in existence is
targetted by at least one of the very many conforming C90 implementations.
Heathfield refuses to live in a fantasy land in which the pretence is made
that non-portable constructs will work everywhere just because ISO says
that they are "standard".
s0s...@gmail.com
> jacob navia said:
>
> <snip>
>
> > This is wrong. Heathfield lives in the past so it is using a
> > standard that is no longer current.
>
> No, Heathfield lives in the real world where almost no conforming C99
> implementations exist, but where almost every platform in existence is
> targetted by at least one of the very many conforming C90 implementations.
> Heathfield refuses to live in a fantasy land in which the pretence is made
> that non-portable constructs will work everywhere just because ISO says
> that they are "standard".
>
How is that relevant in regard to what jacob said? He said the
standard you referred to is no longer current. Whether C99 is portable
is another matter, which is rather pointless to discuss with you, but
let's give it a try:
You say there are a lot more C90 implementations than there are C99
implementations, so C90 is more portable. That's true. But whether C99
is portable in *general* is something different, which is subject to
each person's definition and standards of portability. For people not
trying to run programs on toasters, C99 is surely portable enough.
Sebastian
Antoninus Twink
> jacob navia said:
>> This is wrong. Heathfield lives in the past so it is using a
>> standard that is no longer current.
>
> No, Heathfield lives in the real world where almost no conforming C99
> implementations exist, but where almost every platform in existence is
> targetted by at least one of the very many conforming C90 implementations.
This is a lie. For example, (as you well know) your interlocutor above
has written a C99 implementation for Win32.
> Heathfield refuses to live in a fantasy land in which the pretence is
> made that non-portable constructs will work everywhere just because
> ISO says that they are "standard".
You'd rather pretend that the current standard doesn't exist, and
deliberately give false out information to people, all to satisfy your
nostalgia for a standard that came in at the time of the first gulf war.
James Kuyper
> jrda...@gmail.com said:
>
>> what is the difference between the tree storage
>> durations(static,automatic and dynamic) in C?
>
> Firstly, there are only two:
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++
> 3.1.2.4 Storage durations of objects
>
> An object has a storage duration that determines its lifetime.
> There are two storage durations: static and automatic.
> ++++++++++++++++++++++++++++++++++++++++++++++++++
It may say that in the C90 standard (I don't have a copy) but C99 has
three - the third one is "allocated", which corresponds to the OP's
"dynamic". I'll admit that C90 is more widely supported than C99, but if
you are sincerely sorry that adoption of C99 has gone as slowly as it
has, you should at least mention it's features when answering questions
like this one which do not specify a specific version of the standard.
If C90 didn't have "allocated" storage duration, how were the
corresponding concepts described in C90?
Antoninus Twink
> How is that relevant in regard to what jacob said?
He knows full well that it isn't. In case you haven't worked it out, his
only aim in this thread is to further his nasty campaign against Jacob.
He's not interested in addressing Jacob's valid and well-made points. In
fact, his isn't interested in much at all except preening his vast ego -
surely one of the reasons he despises Jacob so much is that Jacob has a
knack of pricking Heathfield's vanity and getting to the heart of his
bluster and nonsense.
Huibert Bol
> If C90 didn't have "allocated" storage duration, how were the corresponding
> concepts described in C90?
This was addressed in DR138, the real question is: does this make it part
of the offical standard.
--
Huibert
"Okay... really not something I needed to see." --Raven
Barry Schwarz
>what is the difference between the tree storage
>durations(static,automatic and dynamic) in C?
google for n1256 and read the reference yourself rather than depend on
others quoting or paraphrasing the standard, perhaps erroneously. Keep
it around to answer your next homework question also.
Then if you have a question about the meaning of a particular section,
ask here and many will be glad to describe what it means to them.
--
Remove del for email
Richard Heathfield
> On Aug 16, 11:55 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>> jacob navia said:
>>
>> <snip>
>>
>> > This is wrong. Heathfield lives in the past so it is using a
>> > standard that is no longer current.
>>
>> No, Heathfield lives in the real world where almost no conforming C99
>> implementations exist, but where almost every platform in existence is
>> targetted by at least one of the very many conforming C90
>> implementations. Heathfield refuses to live in a fantasy land in which
>> the pretence is made that non-portable constructs will work everywhere
>> just because ISO says that they are "standard".
>>
>
> How is that relevant in regard to what jacob said?
He claimed I was living in the past. I'm not. I'm living in the present.
He, on the other hand, appears to be living in hope.
> 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.
> Whether C99 is portable
> is another matter, which is rather pointless to discuss with you,
I suppose it depends on what you mean by "portable". If by "portable" you
mean "implementations exist for four or five platforms", 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.
> but let's give it a try:
>
> You say there are a lot more C90 implementations than there are C99
> implementations, so C90 is more portable. That's true. But whether C99
> is portable in *general* is something different, which is subject to
> each person's definition and standards of portability. 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.
Richard Heathfield
> Richard Heathfield wrote:
>> jrda...@gmail.com said:
>>
>>> what is the difference between the tree storage
>>> durations(static,automatic and dynamic) in C?
>>
>> Firstly, there are only two:
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++
>> 3.1.2.4 Storage durations of objects
>>
>> An object has a storage duration that determines its lifetime.
>> There are two storage durations: static and automatic.
>> ++++++++++++++++++++++++++++++++++++++++++++++++++
>
> It may say that in the C90 standard (I don't have a copy) but C99 has
> three - the third one is "allocated",
Yes. I have already accepted that correction elsethread.
<snip>
> If C90 didn't have "allocated" storage duration, how were the
> corresponding concepts described in C90?
See my other reply.
s0s...@gmail.com
> s0s...@gmail.com said:
>
>
>
> > On Aug 16, 11:55 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> jacob navia said:
>
> >> <snip>
>
> >> > This is wrong. Heathfield lives in the past so it is using a
> >> > standard that is no longer current.
>
> >> No, Heathfield lives in the real world where almost no conforming C99
> >> implementations exist, but where almost every platform in existence is
> >> targetted by at least one of the very many conforming C90
> >> implementations. Heathfield refuses to live in a fantasy land in which
> >> the pretence is made that non-portable constructs will work everywhere
> >> just because ISO says that they are "standard".
>
> > How is that relevant in regard to what jacob said?
>
> He claimed I was living in the past. I'm not. I'm living in the present.
> He, on the other hand, appears to be living in hope.
>
In hope of what?
> > 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. What do you mean by "de
facto"?
> > Whether C99 is portable
> > is another matter, which is rather pointless to discuss with you,
>
> I suppose it depends on what you mean by "portable". If by "portable" you
> mean "implementations exist for four or five platforms",
I don't know exactly which platforms are supported by C99
implementations, 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 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.
> > but let's give it a try:
>
> > You say there are a lot more C90 implementations than there are C99
> > implementations, so C90 is more portable. That's true. But whether C99
> > is portable in *general* is something different, which is subject to
> > each person's definition and standards of portability. 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. But the important thing is not so much the conformance
level, 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. In contrast, the other day there was a discussion on
another group where someone said that, because of undefined behavior,
a program could erase all files in the hard disk. So a compiler could
generate instructions to erase all files in the hard disk whenever the
program it is compiling makes a construct that invokes undefined
behavior, and that compiler would still conform to the standard! So
you see, "conforming" != "perfect".
Sebastian
Richard Heathfield
> Richard Heathfield wrote:
>> s0s...@gmail.com said:
>> > Richard Heathfield wrote:
>> >> jacob navia said:
>> >> <snip>
>> >> > This is wrong. Heathfield lives in the past so it is using a
>> >> > standard that is no longer current.
>>
>> >> No, Heathfield lives in the real world where almost no conforming C99
>> >> implementations exist, but where almost every platform in existence
>> >> is targetted by at least one of the very many conforming C90
>> >> implementations. Heathfield refuses to live in a fantasy land in
>> >> which the pretence is made that non-portable constructs will work
>> >> everywhere just because ISO says that they are "standard".
>>
>> > How is that relevant in regard to what jacob said?
>>
>> He claimed I was living in the past. I'm not. I'm living in the present.
>> He, on the other hand, appears to be living in hope.
>>
>
> In hope of what?
C99, presumably.
>> > 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.
> 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. De jure, C99
is the C Standard. De facto, C90 is the C Standard.
>> > Whether C99 is portable
>> > is another matter, which is rather pointless to discuss with you,
>>
>> I suppose it depends on what you mean by "portable". If by "portable"
>> you mean "implementations exist for four or five platforms",
>
> 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.
>> 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. I would also include the more powerful
DSPs, the kind you find in home entertainment hardware (set-top boxes, DVD
players, etc). It is easy to dismiss these, but they are powerful enough
to run email clients, Web browsers, all kinds of cool stuff. Not a market
one ought to dismiss too easily.
>> > but let's give it a try:
>>
>> > You say there are a lot more C90 implementations than there are C99
>> > implementations, so C90 is more portable. That's true. But whether C99
>> > is portable in *general* is something different, which is subject to
>> > each person's definition and standards of portability. 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.
> 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.
> 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.
> In contrast, the other day there was a discussion on
> another group where someone said that, because of undefined behavior,
> a program could erase all files in the hard disk.
Yes, that is one legal outcome of undefined behaviour.
> So a compiler could
> generate instructions to erase all files in the hard disk whenever the
> program it is compiling makes a construct that invokes undefined
> behavior, and that compiler would still conform to the standard!
Yes.
> 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.
James Kuyper
> James Kuyper wrote:
>
>> If C90 didn't have "allocated" storage duration, how were the corresponding
>> concepts described in C90?
>
> This was addressed in DR138, the real question is: does this make it part
> of the offical standard.
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."
It's arguably the case that C99 is not the de facto standard, but it is
most certainly the official standard.
Harald van Dijk
> s0s...@gmail.com said:
>> 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.
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.
santosh
But how often is it the case that a single application needs to be
portable across mainframes, desktops, and DSPs? Subroutines could
easily port across all these (depending of course on what exactly the
routine does), but I have yet to encounter a complete, real world,
application that ports without modification to all these diverse
systems.
>> 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.
Actually to me, both you and Sebastian seem to be arguing for the
utility of non-ISO C. :-)
<snip>
s0s...@gmail.com
How can someone be right in a meaningless way? Again, either someone
is right, or not. It's *that* simple.
> > 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.
> 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; is
that so hard to understand for you? Maybe, like Twink said, you'd
rather ignore the current standard. In any case, your above statement
makes no sense whatsoever.
> >> > Whether C99 is portable
> >> > is another matter, which is rather pointless to discuss with you,
>
> >> I suppose it depends on what you mean by "portable". If by "portable"
> >> you mean "implementations exist for four or five platforms",
>
> > 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.
> > 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.
> 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.
> >> 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.
> I would also include the more powerful
> DSPs, the kind you find in home entertainment hardware (set-top boxes, DVD
> players, etc). It is easy to dismiss these, but they are powerful enough
> to run email clients, Web browsers, all kinds of cool stuff. Not a market
> one ought to dismiss too easily.
>
> >> > but let's give it a try:
>
> >> > You say there are a lot more C90 implementations than there are C99
> >> > implementations, so C90 is more portable. That's true. But whether C99
> >> > is portable in *general* is something different, which is subject to
> >> > each person's definition and standards of portability. 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. Where do you get that "C99 isn't even
portable to my desktop"?
> > 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." I'm stating that the important
thing is not so much the conformance level, but the compiler's
usability.
> > 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).
> > In contrast, the other day there was a discussion on
> > another group where someone said that, because of undefined behavior,
> > a program could erase all files in the hard disk.
>
> Yes, that is one legal outcome of undefined behaviour.
>
> > So a compiler could
> > generate instructions to erase all files in the hard disk whenever the
> > program it is compiling makes a construct that invokes undefined
> > behavior, and that compiler would still conform to the standard!
>
> Yes.
>
> > 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. 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.
Sebastian
jacob navia
>> 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.
Heathfield is again speaking pure nonsense.
C99 is available for the z/VM operating system
(IBM Mainframes).
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
The fact that Heathfield doesn't know what he is speaking about
doesn't mean that there isn't any C99 compiler for that platform.
Ian Collins
> s0s...@gmail.com said:
>> 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.
>
How do you know that?
>> 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.
>
How do you know that? How do you know he doesn't use one of the 5
platforms he mentions, but prefers gcc?
>> 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.
>
Which is why I prefer to use 'c99' on my platform of choice.
If I'm developing code for a small embedded target or updating a library
component, I'll stick with 'c89'. Portability is relative, most code I
write these days is portable within POSIX systems, so C99 if a fair choice.
--
Ian Collins.
jacob navia
>> 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.
>
Yes, sure.
But with ISO C you do not mean ISO C, but an
obsolete version of ISO C that suits your tastes.
So, here, you say, "we" discuss whatever
"you" like.
GREAT Heathfield.
Antoninus Twink
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.
jacob navia
He said that C99 wasn't available for IBM mainframes, what
is a lie. See:
http://www-306.ibm.com/software/awdtools/czvm/
<quote>
Supports the ISO/IEC 9899:1999 international standard (C99)
<end quote>
--
Antoninus Twink
> But how often is it the case that a single application needs to be
> portable across mainframes, desktops, and DSPs? Subroutines could
> easily port across all these (depending of course on what exactly the
> routine does), but I have yet to encounter a complete, real world,
> application that ports without modification to all these diverse
> systems.
An extremely sensible and well-made point, and one that flies in the
face of the clc "regulars'" main dogma.
Antoninus Twink
> The fact that Heathfield doesn't know what he is speaking about
> doesn't mean that there isn't any C99 compiler for that platform.
If Heathfield really didn't know, then that wouldn't be so bad.
As it is, he knows perfectly well what the situation is, but
deliberately chooses to tell lies. He is not ignorant, but deceitful and
untrustworthy.
Antoninus Twink
> Richard Heathfield wrote:
>> The important thing to you, maybe - but here, we discuss ISO C, not
>> notquiteISO C.
>
> Yes, sure.
>
>
> GREAT Heathfield.
This is the same Heathfield who said earlier in this thread that he
lives in the real world.
This is not a private web forum. It is not a moderated newsgroup. There
is nothing Heathfield can do to stop "us" discussing whatever "we" like.
Or to adopt Heathfield's pompous way of putting things: "de jure" this
group may ISO C, but "de facto" it discusses all C and plenty of other
things besides.
santosh
> On Aug 16, 2:54 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> s0s...@gmail.com said:
>> > Richard Heathfield wrote:
<snip>
>> >> 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. Where do you get that "C99 isn't even
> portable to my desktop"?
Presumably from your statement above that you use GCC's non-conforming
C99 implementation.
Richard does have a point, IMO. Even some WG14 Committee members have
mentioned in this group (or in comp.std.c) that C99 has been
implemented completely by a dramatically smaller number of vendors than
the Committee had anticipated prior to the Standard's release. This
observation has resulted in the Manifesto for C1x to explicitly
discourge so-called Committee inventions unless there exist a
reasonable number of existing implementations.
Most C compilers seem to have implement *parts* of C99 but only a few
have implemented it in it's entirety. This means that you have to be
far more circumspect when trying to write a maximally portable C99
program than a C90 one, so much so, that you might find yourself coding
in the subset of C99 that corresponds almost exactly to C90.
Obviously not everyone needs to write "maximally" portable code. If
you're only targeting desktops, then you can use C99 with far more
assurance, though the fact that MS refuse to implement it is quite an
irritating thorn in the side.
>> > 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." I'm stating that the important
> thing is not so much the conformance level, but the compiler's
> usability.
When you are writing for only one compiler then it's extensions and
value-added features are great, but when you are writing code meant to
compile under several compilers then the Standard starts to be quite
valuable with regards to how much common functionality you can depend
upon, and how much of your code needs to include multiple
compiler/system specific conditionally compiled code. Rewriting the
whole application for each targeted compiler is an enormous waste,
while sticking solely to what C90/C99 guarantees may also not be
feasible. The trick is in using Standard code where it will suffice and
extensions elsewhere.
Fully conformant compilers facilitate this process of producing
semi-portable code while non-conformant compilers make the job more
complicated.
<snip>
Huibert Bol
>> This was addressed in DR138, the real question is: does this make it part
>> of the offical standard.
>
> 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, which, in
this case, never happened.
s0s...@gmail.com
> s0s...@gmail.com wrote:
> > On Aug 16, 2:54 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> s0s...@gmail.com said:
> >> > Richard Heathfield wrote:
>
> <snip>
>
> >> >> 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. Where do you get that "C99 isn't even
> > portable to my desktop"?
>
> Presumably from your statement above that you use GCC's non-conforming
> C99 implementation.
>
The question remains: Where does he get that "C99 isn't even portable
to my desktop"?
> Richard does have a point, IMO. Even some WG14 Committee members have
> mentioned in this group (or in comp.std.c) that C99 has been
> implemented completely by a dramatically smaller number of vendors than
> the Committee had anticipated prior to the Standard's release. This
> observation has resulted in the Manifesto for C1x to explicitly
> discourge so-called Committee inventions unless there exist a
> reasonable number of existing implementations.
>
I've been wondering, if C99 has been implemented only by a small
number of vendors so far, the reason seeming to be that they're not
interested in C anymore, *who* is going to implement C1X?
> Most C compilers seem to have implement *parts* of C99 but only a few
> have implemented it in it's entirety. This means that you have to be
> far more circumspect when trying to write a maximally portable C99
> program than a C90 one, so much so, that you might find yourself coding
> in the subset of C99 that corresponds almost exactly to C90.
>
Not if your code needs to portable among OSs where there are C99
implementations, which I would expect to be the case of most people.
Isn't that your case too?
<snip>
Sebastian
santosh
> James Kuyper wrote:
>
>>> This was addressed in DR138, the real question is: does this make it
>>> part of the offical standard.
>>
>> 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, which, in this case, never happened.
I believe that the RRs that are published can be taken
as "clarifications" to the current Standard, but they are not
normative.
santosh
> On Aug 16, 3:47 pm, santosh <santo...@gmail.com> wrote:
>> s0s...@gmail.com wrote:
>> > On Aug 16, 2:54 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> >> s0s...@gmail.com said:
>> >> > Richard Heathfield wrote:
>>
>> <snip>
>>
>> >> >> 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. Where do you get that "C99 isn't even
>> > portable to my desktop"?
>>
>> Presumably from your statement above that you use GCC's
>> non-conforming C99 implementation.
>
> The question remains: Where does he get that "C99 isn't even portable
> to my desktop"?
Okay, let's leave this point.
>> Richard does have a point, IMO. Even some WG14 Committee members have
>> mentioned in this group (or in comp.std.c) that C99 has been
>> implemented completely by a dramatically smaller number of vendors
>> than the Committee had anticipated prior to the Standard's release.
>> This observation has resulted in the Manifesto for C1x to explicitly
>> discourge so-called Committee inventions unless there exist a
>> reasonable number of existing implementations.
>
> I've been wondering, if C99 has been implemented only by a small
> number of vendors so far, the reason seeming to be that they're not
> interested in C anymore, *who* is going to implement C1X?
This is a fair question, and something I think that many programmers
might well wonder about, given C99's adoption rate. To the Committee's
credit, they do seem to be aware of this and seem determined to
minimise changes and additions.
Personally, I think an important determinant of C1x's success will be
it's extent of compatibility with C++0x. Apparently WG14 and WG21
collaborate closely in areas where their activities will affect the
other. A Standard that is highly compatible with C++0x will probably be
implemented fairly enthusiastically.
>> Most C compilers seem to have implement *parts* of C99 but only a few
>> have implemented it in it's entirety. This means that you have to be
>> far more circumspect when trying to write a maximally portable C99
>> program than a C90 one, so much so, that you might find yourself
>> coding in the subset of C99 that corresponds almost exactly to C90.
>
> Not if your code needs to portable among OSs where there are C99
> implementations, which I would expect to be the case of most people.
> Isn't that your case too?
>
> <snip>
Yes, but there *are* a lot of developers working in the embedded arena
where C99 is not implemented as well as C90.
Ian Collins
>
> I've been wondering, if C99 has been implemented only by a small
> number of vendors so far, the reason seeming to be that they're not
> interested in C anymore, *who* is going to implement C1X?
>
is written for embedded platforms that have no use for many C99 features
(_Complex on an 8 bit micro anyone?). I'd wager a decent quantity of
beer on the percentage of C programmers who have used <complex.h> or
<tgmath.h> in production code is vanishingly small.
--
Ian Collins.
pete
> 6.2.4 "Storage durations of objects" now says:
>
> An object has a storage duration that determines its lifetime. There
> are three storage durations: static, automatic, and
> allocated. Allocated storage is described in 7.20.3.
>
> How did C90 square there being only two with malloc?
In C89, allocated duration is just a feature of the library.
Most features of the library don't need to be described
in the language section of the standard.
In C99, the only thing about allocated duration
that is a feature of the C language proper,
is the existence of allocated duration.
Everything else about allocated duration,
is described in the library section of the standard.
--
pete
Keith Thompson
[...]
> He said that C99 wasn't available for IBM mainframes, what
> is a lie.
(referring to Richard Heathfield)
> See:
>
> http://www-306.ibm.com/software/awdtools/czvm/
>
> <quote>
> Supports the ISO/IEC 9899:1999 international standard (C99)
> <end quote>
Assuming you're referring to what Richard wrote in this thread, I
suggest you read it again. He *didn't say* that C99 isn't available
for IBM mainframes.
And even if he had, apparently it didn't occur to you that he might
not have known about that web page.
I am sick and tired of the way you throw the words "lie" and "liar"
around.
Grow up.
--
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"
santosh
Then I wonder why the Committee standardised them in the first place? It
seemingly flies against their own charter for C99.
On a related note, I note that the Committee is considering the
possibility of sectioning the Standard for it's next incarnation. If
it's embraced then the maths and scientific functions could be included
in a "Scientific C" subset.
Richard Heathfield
> 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.
Richard Heathfield
<snip>
> But how often is it the case that a single application needs to be
> portable across mainframes, desktops, and DSPs?
Rarely, I should imagine, and I've never worked on such a project - but it
is quite common for a single application to need to work on
mainframe-and-desktop, and quite common for an application to need to work
on desktop-and-DSP. I have worked on several reasonably heavy projects of
each of those two kinds.
It is far *more* common, in any case, for a C *library* to need to be
portable across mainframes, desktops, DSPs, etc.
Whilst it is possible to write an entire application in ISO C, it is pretty
rare, because people /do/ like to use their extensions - graphics,
networking, filesystem stuff, and so on (me included, when I can get away
with it - but most of the C I do is library-based). The wise will put the
portable stuff in one module (or group thereof) and the non-portable stuff
(as little as possible) in another, so that when the unexpected yet
inevitable day comes when they are asked to port their stuff, they can do
so in reasonably short order.
In any case, libraries are ported with much greater frequency than
applications, so the fact that we don't port entire applications all that
often is neither here nor there. Library portability is a fundamental
requirement for many of us.
> Subroutines could
> easily port across all these (depending of course on what exactly the
> routine does),
Yes, but only if a conforming implementation is available for it -
otherwise you might as well kiss that platform goodbye.
> but I have yet to encounter a complete, real world,
> application that ports without modification to all these diverse
> systems.
My argument doesn't depend on it, but I have certainly written or helped to
write several applications that /could/ have qualified if anyone had ever
wanted, say, to do insurance and banking quotations or flight scheduling
on their set-top box. :-)
>
>>> 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.
>
> Actually to me, both you and Sebastian seem to be arguing for the
> utility of non-ISO C. :-)
Nobody with any sense denies the usefulness of extensions - but there are
other newsgroups for discussing those.
jacob navia
> 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
Richard Heathfield
> Richard Heathfield wrote:
>> s0s...@gmail.com said:
>> > Richard Heathfield wrote:
<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...
> 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, 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.
*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!
>> 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.
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? 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?
<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.
>> > 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.
>
>> >> 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.
<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.
> 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.
>> > 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.
> 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. 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.
>> > 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.
<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?
> 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.
Richard Heathfield
> Richard Heathfield wrote:
>> s0s...@gmail.com said:
>>> Richard Heathfield wrote:
>>>> s0s...@gmail.com said:
>>> 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.
>
> Heathfield is again speaking pure nonsense.
Perhaps you'd care to explain that.
> C99 is available for the z/VM operating system
> (IBM Mainframes).
Firstly, I was talking about VM/CMS and OS390 - I didn't even mention z/VM.
Secondly, I didn't claim that no C99 compiler was available for them.
Rather, I was pointing out that Sebastian was ignoring mainframes in his
consideration of what constitutes "very portable".
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.
> The fact that Heathfield doesn't know what he is speaking about
> doesn't mean that there isn't any C99 compiler for that platform.
The fact that you can't read doesn't mean I've made the claims you imagine
I've made.
Richard Heathfield
> Richard Heathfield wrote:
>> s0s...@gmail.com said:
>
>>> I don't know exactly which platforms are supported by C99
>>> implementations,
>>
<snip>
>>
>> [...] But since you don't actually know whether the
>> platforms you name have C99 implementations available for them, your
>> point lacks force.
>>
> How do you know that?
Because he said he didn't (see above).
>>> 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.
>>
> How do you know that?
Because he says he's using a non-C99 implementation. Incidentally, I did
mean *his* desktop quite literally, which is why I picked it out in
asterisks. Presumably, as someone who values C99 highly, he would actually
use a C99 compiler if he had one, from which I deduce that he hasn't got
one.
> How do you know he doesn't use one of the 5
> platforms he mentions, but prefers gcc?
If he has a C99 compiler but is using gcc instead, C99 isn't as important
to him as he seems to think. If he hasn't got a C99 compiler, then my
point stands.
<snip>
Richard Heathfield
> Richard Heathfield wrote:
>>> 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.
>>
>
> Yes, sure.
>
> But with ISO C you do not mean ISO C, but an
> obsolete version of ISO C that suits your tastes.
No, I mean ISO C. That certainly includes C99. It also includes C90.
> So, here, you say, "we" discuss whatever "you" like.
No, in late 2007 this was debated at length, and the group decided
*against* extending topicality, despite the opinions of those who, like
me, feel we could perhaps be a little more relaxed about it.
> GREAT Heathfield.
Your continual misunderstandings do nothing to enhance your stature.
Antoninus Twink
> *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!
Once again, *THIS IS NONSENSE*.
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?
The clear fact is that C99 is now the default C standard adopted by most
C compilers, and only legalistic nitpickers too blind to see what's in
front of their eyes could think that C90 is the current standard.
> 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?
Yeah, right, how can it ever work if his implementation "doesn't
conform"?
> I don't count non-conforming implementations, since they don't
> implement C99.
I think what you really mean is
"I don't count non-conforming implementations, for the same reason that
I don't walk on cracks in the pavement."
Antoninus Twink
> jacob navia said:
>
> No, in late 2007 this was debated at length, and the group decided
> *against* extending topicality,
If a tree falls in a forest, with no one to hear it, does it make a
sound? If a small group of busybodies try to impose their own view of
topicality on the rest of the world, with no way of enforcing it, does
that mean a thing?
> despite the opinions of those who, like me, feel we could perhaps be a
> little more relaxed about it.
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.
Richard Heathfield
> 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.
No, I did not. Here is the relevant message ID:
<UuOdnVmoccDGsjrV...@bt.com>
in which I make no such claim.
Learn to read, please. It would help to stop you from looking such a fool
in the eyes of those who /can/ read.
Ian Collins
> Ian Collins wrote:
>
>> s0s...@gmail.com wrote:
>>> I've been wondering, if C99 has been implemented only by a small
>>> number of vendors so far, the reason seeming to be that they're not
>>> interested in C anymore, *who* is going to implement C1X?
>>>
>> Oh there's plenty of interest in C, but don't forget the majority of C
>> is written for embedded platforms that have no use for many C99
>> features (_Complex on an 8 bit micro anyone?). I'd wager a decent
>> quantity of beer on the percentage of C programmers who have used
>> <complex.h> or <tgmath.h> in production code is vanishingly small.
>
> Then I wonder why the Committee standardised them in the first place?
>
--
Ian Collins.
Harald van Dijk
> jacob navia said:
>>
>> <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'm not so sure of that. "Supports C99" can have different meanings than
"conforms to C99", but they seem to mean the same thing here. In either
case, the "conforms to C99" part is clearer in "a standards-conforming C
compiler", from the same page.
jacob navia
Well, this is just playing with words, seeking
legalese to hide the plain fact that R.H. was
wrong, that's all.
jacob navia
> jacob navia said:
>
>
>
>> 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.
This white paper of IBM says in:
http://www-1.ibm.com/support/docview.wss?uid=swg27007322&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>
Happy now?
Joachim Schmitz
<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
santosh
> 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.
Antoninus Twink
> 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.
santosh
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.
Jean-Marc Bourguet
Coincidence or the desire to standardize some usefull and common features?
Yours,
--
Jean-Marc
santosh
It is that too, but since GCC representatives were not among the
participants of the C99 standardisation committee(?), any similarities
must be coincidence.
Jean-Marc Bourguet
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
Ben Bacarisse
> 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.
Malcolm McLean
"Antoninus Twink" <nos...@nospam.invalid> wrote 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.
>
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
Richard Heathfield
> 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.
santosh
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.)
Kenny McCormack
Keith Thompson <ks...@mib.org> wrote:
...
> 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.
jacob navia
> 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.wss?uid=swg27007322&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!
Richard Heathfield
> 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.
James Kuyper
> 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.
Barry Schwarz
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
Barry Schwarz
<r...@see.sig.invalid> 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.
>
>> 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.
Richard Heathfield
> On Sun, 17 Aug 2008 07:32:45 +0000, Richard Heathfield
> <r...@see.sig.invalid> wrote:
>
<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.)
Antoninus Twink
> Barry Schwarz said:
>> On page 561 they state:
>>
>> 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?
s0s...@gmail.com
> s0s...@gmail.com said:
>
> > Richard Heathfield wrote:
> >> s0s...@gmail.com said:
> >> > Richard Heathfield wrote:
> >> >> s0s...@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
Keith Thompson
> 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>
>>
>
> "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"
Keith Thompson
> 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.)
jacob navia
> jacob navia <ja...@nospam.com> writes:
>> 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,
s0s...@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.
Keith Thompson
> 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.)
jacob navia
> jacob navia <ja...@nospam.com> writes:
>> 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.
Keith Thompson
[...]
>>> 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]
Andrew Poelstra
>
> 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 apoe...@wpsoftware.com
To email me, use the above email addresss with .com set to .net
jacob navia
>
> 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
> On 2008-08-17, jacob navia <ja...@nospam.com> wrote:
>> 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?
vipp...@gmail.com
<snip>
> How many times do I have to prove Heathfield wrong?
Before what? Before you stop acting like a lunatic?
jacob navia
Your answer is typical mr. If I prove heathfield wrong
I am a lunatic OF COURSE!
Your logic is as clear as heathfield's.
Andrew Poelstra
>
> 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.
Ian Collins
> vipp...@gmail.com wrote:
>> On Aug 18, 2:13 am, jacob navia <ja...@nospam.com> wrote:
>>
>> <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!
>
backs up.
--
Ian Collins.
Ben Bacarisse
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.
Keith Thompson
> 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
<UuOdnVmoccDGsjrV...@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".
James Kuyper
> Richard Heathfield wrote:
>> jacob navia said:
>>> He said that C99 wasn't available for IBM mainframes,
>>
>> No, I didn't. Learn to read, please.
>>
>
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.
>
> 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?
Ben Bacarisse
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.
Ben Bacarisse
> jacob navia <ja...@nospam.com> writes:
>> 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
> <UuOdnVmoccDGsjrV...@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.
Richard Heathfield
> On Aug 17, 3:07 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>> s0s...@gmail.com said:
>>
>> > Richard Heathfield wrote:
>> >> s0s...@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
> Richard Heathfield <r...@see.sig.invalid> writes:
<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
> Andrew Poelstra wrote:
>> On 2008-08-17, jacob navia <ja...@nospam.com> wrote:
>>> 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?
Keith Thompson
Ok, let's look at the article yet again; this is Richard Heathfield
replying to s0s...@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.
--
Richard Heathfield
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
<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>
Keith Thompson
> 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.
santosh
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.
Richard Heathfield
<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.
Nick Keighley
> James Kuyper <jameskuy...@verizon.net> writes:
> > 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
Nick Keighley
> 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