By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,078 Members | 2,164 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,078 IT Pros & Developers. It's quick & easy.

Storgae durations

P: n/a
what is the difference between the tree storage
durations(static,automatic and dynamic) in C?
Aug 16 '08 #1
Share this Question
Share on Google+
241 Replies


P: n/a
jr******@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.
++++++++++++++++++++++++++++++++++++++++++++++++++

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
Aug 16 '08 #2

P: n/a
Richard Heathfield <rj*@see.sig.invalidwrites:
jr******@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.
Aug 16 '08 #3

P: n/a
Ben Bacarisse said:
Richard Heathfield <rj*@see.sig.invalidwrites:
>jr******@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. :-)

--
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
Aug 16 '08 #4

P: n/a
Richard Heathfield wrote:
jr******@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
Aug 16 '08 #5

P: n/a
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".

--
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
Aug 16 '08 #6

P: n/a
On Aug 16, 11:55*am, Richard Heathfield <r...@see.sig.invalidwrote:
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

Aug 16 '08 #7

P: n/a
On 16 Aug 2008 at 16:55, Richard Heathfield wrote:
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.

Aug 16 '08 #8

P: n/a
Richard Heathfield wrote:
jr******@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?
Aug 16 '08 #9

P: n/a
On 16 Aug 2008 at 17:32, s0****@gmail.com wrote:
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.

Aug 16 '08 #10

P: n/a
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.

--
Huibert
"Okay... really not something I needed to see." --Raven
Aug 16 '08 #11

P: n/a
On Sat, 16 Aug 2008 09:02:11 -0700 (PDT), jr******@gmail.com wrote:
>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
Aug 16 '08 #12

P: n/a
s0****@gmail.com said:
On Aug 16, 11:55 am, Richard Heathfield <r...@see.sig.invalidwrote:
>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 <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
Aug 16 '08 #13

P: n/a
James Kuyper said:
Richard Heathfield wrote:
>jr******@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.

--
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
Aug 16 '08 #14

P: n/a
On Aug 16, 1:55*pm, Richard Heathfield <rj*@see.sig.invalidwrote:
s0****@gmail.com said:
On Aug 16, 11:55 am, Richard Heathfield <rj*@see.sig.invalidwrote:
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

Aug 16 '08 #15

P: n/a
s0****@gmail.com said:
Richard Heathfield wrote:
>s0****@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.

--
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
Aug 16 '08 #16

P: n/a
Huibert Bol wrote:
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.
Aug 16 '08 #17

P: n/a
On Sat, 16 Aug 2008 19:54:07 +0000, Richard Heathfield wrote:
s0****@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.
Aug 16 '08 #18

P: n/a
Richard Heathfield wrote:
s0****@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.
>>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 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>

Aug 16 '08 #19

P: n/a
On Aug 16, 2:54*pm, Richard Heathfield <rj*@see.sig.invalidwrote:
s0****@gmail.com said:
Richard Heathfield wrote:
s0****@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.
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

Aug 16 '08 #20

P: n/a
Richard Heathfield wrote:
s0****@gmail.com said:
>Richard Heathfield wrote:
>>s0****@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.

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.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Aug 16 '08 #21

P: n/a
Richard Heathfield wrote:
s0****@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.
Aug 16 '08 #22

P: n/a
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.

So, here, you say, "we" discuss whatever
"you" like.

GREAT Heathfield.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Aug 16 '08 #23

P: n/a
On 16 Aug 2008 at 20:06, Harald van Dijk 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.

Aug 16 '08 #24

P: n/a
Antoninus Twink wrote:
On 16 Aug 2008 at 20:06, Harald van Dijk 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, 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>

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Aug 16 '08 #25

P: n/a
On 16 Aug 2008 at 20:25, santosh wrote:
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.

Aug 16 '08 #26

P: n/a
On 16 Aug 2008 at 20:29, jacob navia wrote:
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.

Aug 16 '08 #27

P: n/a
On 16 Aug 2008 at 20:35, jacob navia wrote:
Richard Heathfield wrote:
>The important thing to you, maybe - but here, we discuss ISO C, not
notquiteISO C.

Yes, sure.

So, here, you say, "we" discuss whatever "you" like.

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.

Aug 16 '08 #28

P: n/a
s0****@gmail.com wrote:
On Aug 16, 2:54*pm, Richard Heathfield <rj*@see.sig.invalidwrote:
>s0****@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>

Aug 16 '08 #29

P: n/a
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.

--
Huibert
"Okay... really not something I needed to see." --Raven
Aug 16 '08 #30

P: n/a
On Aug 16, 3:47 pm, santosh <sa*********@gmail.comwrote:
s0****@gmail.com wrote:
On Aug 16, 2:54 pm, Richard Heathfield <rj*@see.sig.invalidwrote:
s0****@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

Aug 16 '08 #31

P: n/a
Huibert Bol wrote:
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.

Aug 16 '08 #32

P: n/a
s0****@gmail.com wrote:
On Aug 16, 3:47 pm, santosh <sa*********@gmail.comwrote:
>s0****@gmail.com wrote:
On Aug 16, 2:54 pm, Richard Heathfield <rj*@see.sig.invalidwrote:
s0****@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.

Aug 16 '08 #33

P: n/a
s0****@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.hor
<tgmath.hin production code is vanishingly small.

--
Ian Collins.
Aug 16 '08 #34

P: n/a
Ben Bacarisse wrote:
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
Aug 17 '08 #35

P: n/a
jacob navia <ja***@nospam.comwrites:
[...]
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"
Aug 17 '08 #36

P: n/a
Ian Collins wrote:
s0****@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.hor <tgmath.hin production code is vanishingly small.
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.

Aug 17 '08 #37

P: n/a
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.

--
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
Aug 17 '08 #38

P: n/a
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
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Aug 17 '08 #39

P: n/a
s0****@gmail.com said:
Richard Heathfield wrote:
>s0****@gmail.com said:
Richard Heathfield wrote:
s0****@gmail.com said:
<snip>
>>
He said the
standard you referred to is no longer current.
>Yes, he did, and yes, he's de jure right. But he's de facto wrong.
Either he's right (which he is), or he's not.

He's right only in a completely useless and almost meaningless way.

How can someone be right in a meaningless way?
It's not difficult, but someone can also be wrong in meaningless ways...
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 <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
Aug 17 '08 #40

P: n/a
jacob navia said:
Richard Heathfield wrote:
>s0****@gmail.com said:
>>Richard Heathfield wrote:
s0****@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 <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
Aug 17 '08 #41

P: n/a
Ian Collins said:
Richard Heathfield wrote:
>s0****@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 <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
Aug 17 '08 #42

P: n/a
jacob navia said:
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.

--
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
Aug 17 '08 #43

P: n/a
On 17 Aug 2008 at 8:07, Richard Heathfield wrote:
*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."

Aug 17 '08 #44

P: n/a
On 17 Aug 2008 at 8:20, Richard Heathfield wrote:
jacob navia said:
>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,
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.

Aug 17 '08 #45

P: n/a
jacob navia said:
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:
<Uu******************************@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.

--
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
Aug 17 '08 #46

P: n/a
santosh wrote:
Ian Collins wrote:
>s0****@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.hor <tgmath.hin production code is vanishingly small.

Then I wonder why the Committee standardised them in the first place?
You're certainly not alone there!

--
Ian Collins.
Aug 17 '08 #47

P: n/a
On Sun, 17 Aug 2008 08:12:42 +0000, Richard Heathfield wrote:
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.
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.
Aug 17 '08 #48

P: n/a
Harald van Dijk wrote:
On Sun, 17 Aug 2008 08:12:42 +0000, Richard Heathfield wrote:
>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.

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.
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 at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Aug 17 '08 #49

P: n/a
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.

This white paper of IBM says in:

http://www-1.ibm.com/support/docview...27007322&aid=1

<quote>
IBM compilers strive to maximize the performance of scientific,
technical, and commercial applications on server platforms. Multiple
operating system availability ensures cross-platform portability,
augmented by standards compliance. IBM XL compilers conform with:

IBM XL C compiler conforms with ISO C90 and C99 standards.
[snipped rest of conformace statements]
<end quote>

Happy now?

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Aug 17 '08 #50

241 Replies

This discussion thread is closed

Replies have been disabled for this discussion.