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

C89 Standard for Britons

P: n/a
It was reported in another group that people with an address in the UK
can join Manchester Central Library on line, and when you've received
your card, you can read and/or download any BSI Standard for free, as a
PDF. The relevance of this to comp.lang.c is that one of these BSI
Standards is BS EN 29899:1993*, a.k.a. ISO/IEC 9899:1990/Amendment 1.
This is a useful way to pick up the previous ISO C Standard, which isn't
always easy to get in another way.

Richard
Jun 14 '07 #1
Share this Question
Share on Google+
51 Replies


P: n/a
In article <46**************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nlwrote:
>It was reported in another group that people with an address in the UK
can join Manchester Central Library on line, and when you've received
your card, you can read and/or download any BSI Standard for free, as a
PDF. The relevance of this to comp.lang.c is that one of these BSI
Standards is BS EN 29899:1993*, a.k.a. ISO/IEC 9899:1990/Amendment 1.
This is a useful way to pick up the previous ISO C Standard, which isn't
always easy to get in another way.
C99 is also available as a BSI standard, BS ISO/IEC 9899:1999.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jun 14 '07 #2

P: n/a
ri*****@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <46**************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nlwrote:
It was reported in another group that people with an address in the UK
can join Manchester Central Library on line, and when you've received
your card, you can read and/or download any BSI Standard for free, as a
PDF. The relevance of this to comp.lang.c is that one of these BSI
Standards is BS EN 29899:1993*, a.k.a. ISO/IEC 9899:1990/Amendment 1.
This is a useful way to pick up the previous ISO C Standard, which isn't
always easy to get in another way.

C99 is also available as a BSI standard, BS ISO/IEC 9899:1999.
True, but that's more easily available from any other country as well,
as n1124.pdf. C89 is rarer.

Richard
Jun 14 '07 #3

P: n/a
Richard Bos wrote:
ri*****@cogsci.ed.ac.uk (Richard Tobin) wrote:
>In article <46**************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nlwrote:
>>It was reported in another group that people with an address in the UK
can join Manchester Central Library on line, and when you've received
your card, you can read and/or download any BSI Standard for free, as a
PDF. The relevance of this to comp.lang.c is that one of these BSI
Standards is BS EN 29899:1993*, a.k.a. ISO/IEC 9899:1990/Amendment 1.
This is a useful way to pick up the previous ISO C Standard, which isn't
always easy to get in another way.
C99 is also available as a BSI standard, BS ISO/IEC 9899:1999.

True, but that's more easily available from any other country as well,
as n1124.pdf. C89 is rarer.
Which led immediately to:

http://www.open-std.org/JTC1/SC22/WG...docs/n1124.pdf

Thanks!

David Mathog
Jun 14 '07 #4

P: n/a
In article <46**************@news.xs4all.nl>, Richard Bos
<rl*@hoekstra-uitgeverij.nlwrites
>It was reported in another group that people with an address in the UK
can join Manchester Central Library on line, and when you've received
your card, you can read and/or download any BSI Standard for free, as a
PDF. The relevance of this to comp.lang.c is that one of these BSI
Standards is BS EN 29899:1993*, a.k.a. ISO/IEC 9899:1990/Amendment 1.
This is a useful way to pick up the previous ISO C Standard, which isn't
always easy to get in another way.

Richard
Your subject and message don't match

C89 is ANSI C that is the US c standard.

C90 is the ISO 9899:1990

The C90/93 standard you mention has been very easily available in the UK
for a long time, In fact my company used to supply it in a bundle with
MISRA-C 1 or 2 for the last 6 years.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 14 '07 #5

P: n/a
On Jun 15, 8:27 am, Chris Hills <c...@phaedsys.orgwrote:
C89 is ANSI C that is the US c standard.
C90 is the ISO 9899:1990
ISO/IEC 9899:1990 is the same as ANSI X3.159-1989
except the sections are numbered differently (AFAIK).

I have also heard that ANSI subsequently ratified
ISO/IEC 9899:1990 so the latter is also an
"ANSI C standard".

Jun 15 '07 #6

P: n/a
Old Wolf <ol*****@inspire.net.nzwrote:
>
ISO/IEC 9899:1990 is the same as ANSI X3.159-1989
except the sections are numbered differently (AFAIK).
And it doesn't include the Rationale.

-Larry Jones

I've got to start listening to those quiet, nagging doubts. -- Calvin
Jun 15 '07 #7

P: n/a
In article <f4***********@pc-news.cogsci.ed.ac.uk>, Richard Tobin
<ri*****@cogsci.ed.ac.ukwrites
>In article <46**************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nlwrote:
>>It was reported in another group that people with an address in the UK
can join Manchester Central Library on line, and when you've received
your card, you can read and/or download any BSI Standard for free, as a
PDF. The relevance of this to comp.lang.c is that one of these BSI
Standards is BS EN 29899:1993*, a.k.a. ISO/IEC 9899:1990/Amendment 1.
This is a useful way to pick up the previous ISO C Standard, which isn't
always easy to get in another way.

C99 is also available as a BSI standard, BS ISO/IEC 9899:1999.

-- Richard

However the better way to buy it is the Wiley book "The C standard"
ISBN 0-470-84573-2 which contains C99 and the ANSI Rational

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 19 '07 #8

P: n/a
Chris Hills <ch***@phaedsys.orgwrote:
However the better way to buy it is the Wiley book "The C standard"
ISBN 0-470-84573-2 which contains C99 and the ANSI Rational
each to his own (you can't grep paper).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Jun 20 '07 #9

P: n/a
In article <13*************@corp.supernews.com>, Thomas Dickey
<di****@saltmine.radix.netwrites
>Chris Hills <ch***@phaedsys.orgwrote:
>However the better way to buy it is the Wiley book "The C standard"
ISBN 0-470-84573-2 which contains C99 and the ANSI Rational

each to his own (you can't grep paper).
And you can't grip a PDF :-)

BTW ISO9899:200* is likely to be smaller than 9899:1999 :-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 20 '07 #10

P: n/a
Chris Hills said:
In article <13*************@corp.supernews.com>, Thomas Dickey
<di****@saltmine.radix.netwrites
>>Chris Hills <ch***@phaedsys.orgwrote:
>>However the better way to buy it is the Wiley book "The C standard"
ISBN 0-470-84573-2 which contains C99 and the ANSI Rational

each to his own (you can't grep paper).

And you can't grip a PDF :-)

BTW ISO9899:200* is likely to be smaller than 9899:1999 :-)
Why not just photocopy C90? Then you wouldn't have to wait a decade for
implementations to catch up.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jun 20 '07 #11

P: n/a
Chris Hills <ch***@phaedsys.orgwrites:
In article <13*************@corp.supernews.com>, Thomas Dickey
<di****@saltmine.radix.netwrites
>>Chris Hills <ch***@phaedsys.orgwrote:
>>However the better way to buy it is the Wiley book "The C standard"
ISBN 0-470-84573-2 which contains C99 and the ANSI Rational

each to his own (you can't grep paper).

And you can't grip a PDF :-)

BTW ISO9899:200* is likely to be smaller than 9899:1999 :-)
I see the smiley, but is that a serious comment? Can you expand on
it?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 20 '07 #12

P: n/a
In article <X6*********************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>Chris Hills said:
>In article <13*************@corp.supernews.com>, Thomas Dickey
<di****@saltmine.radix.netwrites
>>>Chris Hills <ch***@phaedsys.orgwrote:

However the better way to buy it is the Wiley book "The C standard"
ISBN 0-470-84573-2 which contains C99 and the ANSI Rational

each to his own (you can't grep paper).

And you can't grip a PDF :-)

BTW ISO9899:200* is likely to be smaller than 9899:1999 :-)

Why not just photocopy C90? Then you wouldn't have to wait a decade for
implementations to catch up.
I don't think implementations will ever catch up with C99

I think you will find that C200* will be C99 with some big bits removed
and a few smaller bits added.

They have woken up to the fact that a lot of things were added to C99 by
pressure groups that the industry as a whole did not want. Also that
the main users of C are, and will be in the future, the embedded
community where they still use a lot of 8 and 16 bit MCU

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 21 '07 #13

P: n/a
Chris Hills <ch***@phaedsys.orgwrites:
[...]
I don't think implementations will ever catch up with C99

I think you will find that C200* will be C99 with some big bits
removed and a few smaller bits added.
Can you substantiate this claim? Has the committee considered the
fact that most or all C99 features actually have been implemented by
some compilers, and removing them from the language will break
existing code?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 21 '07 #14

P: n/a
In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>Chris Hills <ch***@phaedsys.orgwrites:
[...]
>I don't think implementations will ever catch up with C99

I think you will find that C200* will be C99 with some big bits
removed and a few smaller bits added.

Can you substantiate this claim?
See private email
>Has the committee considered the
fact that most or all C99 features actually have been implemented by
some compilers, and removing them from the language will break
existing code?
That is not a problem vitally all compilers have extensions to the
standard.

Compilers have only added the C99 parts their customers wanted. So if
some are removed from the standard it will not affect them. They will
continue to use those features. They will just not be part of the
standard.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 21 '07 #15

P: n/a
Chris Hills wrote:
In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>Chris Hills <ch***@phaedsys.orgwrites:
[...]
>>I don't think implementations will ever catch up with C99

I think you will find that C200* will be C99 with some big bits
removed and a few smaller bits added.

Can you substantiate this claim?

See private email
>Has the committee considered the
fact that most or all C99 features actually have been implemented by
some compilers, and removing them from the language will break
existing code?

That is not a problem vitally all compilers have extensions to the
standard.

Compilers have only added the C99 parts their customers wanted. So if
some are removed from the standard it will not affect them. They will
continue to use those features. They will just not be part of the standard.
So the next standard will be a list of optional features that might be
removed in a future edition? What a joke.
--
Ian Collins.
Jun 21 '07 #16

P: n/a
Keith Thompson said:

<snip>
Has the committee considered the
fact that most or all C99 features actually have been implemented by
some compilers, and removing them from the language will break
existing code?
I would like to assure the committee that, even if they remove *all* the
features added by C99, this will have no effect whatsoever on my
existing code.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jun 21 '07 #17

P: n/a
In article <5d*************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites
>Chris Hills wrote:
>In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>>Chris Hills <ch***@phaedsys.orgwrites:
[...]
I don't think implementations will ever catch up with C99

I think you will find that C200* will be C99 with some big bits
removed and a few smaller bits added.

Can you substantiate this claim?

See private email
>>Has the committee considered the
fact that most or all C99 features actually have been implemented by
some compilers, and removing them from the language will break
existing code?

That is not a problem vitally all compilers have extensions to the
standard.

Compilers have only added the C99 parts their customers wanted. So if
some are removed from the standard it will not affect them. They will
continue to use those features. They will just not be part of the standard.
So the next standard will be a list of optional features that might be
removed in a future edition? What a joke.
What is your solution....

Would you care to share your experiences from having worked on an
international standard?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 21 '07 #18

P: n/a
In article <PB**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.ukwrote:
>Compilers have only added the C99 parts their customers wanted.
It seems to me that several parts of C99 should have been published
as separate standards, to which compilers could claim conformance
if they implemented them. The floating-point environment and complex
number support are obvious examples. If this had been done, I think
the core of C99 would be much more widely supported and used.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jun 21 '07 #19

P: n/a
In article <lO******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>Keith Thompson said:

<snip>
>Has the committee considered the
fact that most or all C99 features actually have been implemented by
some compilers, and removing them from the language will break
existing code?

I would like to assure the committee that, even if they remove *all* the
features added by C99, this will have no effect whatsoever on my
existing code.
I will let them know Richard, and I am sure that this will reassure
them greatly :-)

DON'T PANIC the sort of things they were looking at are the ones that
(virtually) no one has implemented.

It still does not matter as people who do NEED those features will still
be able to use them as extensions just as virtually everybody else does.

It is either that or include ALL extensions (as used from 8 to 128 bit
in embedded compilers) along with the proposed Standard Graphics
library and file system....

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 21 '07 #20

P: n/a
Chris Hills said:
In article <5d*************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites
>>Chris Hills wrote:
<snip>
>>Compilers have only added the C99 parts their customers wanted. So
if some are removed from the standard it will not affect them. They
will continue to use those features. They will just not be part of
the standard.
So the next standard will be a list of optional features that might be
removed in a future edition? What a joke.

What is your solution....
Drop C99 completely. Give it up as a bad job, and work on something that
actually meets the needs of programmers writing portable C code.
Would you care to share your experiences from having worked on an
international standard?
What has that to do with it? Surely one doesn't have to be a carpenter
to complain about a wobbly table?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jun 21 '07 #21

P: n/a
Chris Hills said:
In article <lO******************************@bt.com>, Richard
Heathfield <rj*@see.sig.invalidwrites
<snip>
>>I would like to assure the committee that, even if they remove *all*
the features added by C99, this will have no effect whatsoever on my
existing code.

I will let them know Richard, and I am sure that this will reassure
them greatly :-)
My work here is done. :-)
DON'T PANIC the sort of things they were looking at are the ones that
(virtually) no one has implemented.
Who's panicking? I'm not even going to /start/ using /any/ features from
a new standard until they're very widely portable indeed. And anyone
who needs to write portable code is going to have the same attitude.
And anyone who doesn't need to write portable code isn't going to give
a stuff about the Standard anyway.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jun 21 '07 #22

P: n/a
In article <4P*********************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>Chris Hills said:
>In article <5d*************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites
>>>Chris Hills wrote:

<snip>
>>>Compilers have only added the C99 parts their customers wanted. So
if some are removed from the standard it will not affect them. They
will continue to use those features. They will just not be part of
the standard.

So the next standard will be a list of optional features that might be
removed in a future edition? What a joke.

What is your solution....

Drop C99 completely. Give it up as a bad job, and work on something that
actually meets the needs of programmers writing portable C code.
The majority of C programmers don't need portability. The majority of
C programmers need a small powerful language that will run on small
processors.
>Would you care to share your experiences from having worked on an
international standard?
What has that to do with it? Surely one doesn't have to be a carpenter
to complain about a wobbly table?
Your comment that it was a joke... Try working on a standard and you
will learn why these things happen.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 21 '07 #23

P: n/a
In article <f5***********@pc-news.cogsci.ed.ac.uk>, Richard Tobin
<ri*****@cogsci.ed.ac.ukwrites
>In article <PB**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.ukwrote:
>>Compilers have only added the C99 parts their customers wanted.

It seems to me that several parts of C99 should have been published
as separate standards, to which compilers could claim conformance
if they implemented them.
That was a proposal from a group in the UK some years ago. We looked at
moving back from C99 to a core language not too far from c96 with a
series of optional appendices for things like complex maths, file
systems even (god forbid) a standard graphics system) :-(
>The floating-point environment and complex
number support are obvious examples. If this had been done, I think
the core of C99 would be much more widely supported and used.
-- Richard
I agree. However...... that was not the way it went.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 21 '07 #24

P: n/a
In article <Hc******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>Chris Hills said:
>In article <lO******************************@bt.com>, Richard
Heathfield <rj*@see.sig.invalidwrites

<snip>
>>>I would like to assure the committee that, even if they remove *all*
the features added by C99, this will have no effect whatsoever on my
existing code.

I will let them know Richard, and I am sure that this will reassure
them greatly :-)

My work here is done. :-)
>DON'T PANIC the sort of things they were looking at are the ones that
(virtually) no one has implemented.

Who's panicking? I'm not even going to /start/ using /any/ features from
a new standard until they're very widely portable indeed. And anyone
who needs to write portable code is going to have the same attitude.
And anyone who doesn't need to write portable code isn't going to give
a stuff about the Standard anyway.
That is not true. You need to know how the [Standard] C works even if
you don't use all of it or have to use extensions.

I need to know exactly how the C in my program (bar the extensions)
will work so it is compatible with other tools. The extensions should be
limited to things like architecture specific parts for talking to the
HW.

Much of my code is targeted to a specific MCU and is not likely to move.
At least not without a major re-write to add in new functionality with
new HW

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 21 '07 #25

P: n/a
Chris Hills said:
In article <4P*********************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>>Chris Hills said:
>>In article <5d*************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites
<snip>
>>>>>
So the next standard will be a list of optional features that might
be
removed in a future edition? What a joke.

What is your solution....

Drop C99 completely. Give it up as a bad job, and work on something
that actually meets the needs of programmers writing portable C code.

The majority of C programmers don't need portability.
If that's true, then they don't need a standard, just an implementation.
But I don't think it's true.
The majority of C programmers need a small powerful language that will
run on small processors.
Either they're always running on the /same/ small processor, or they
need portability.
>>Would you care to share your experiences from having worked on an
international standard?
What has that to do with it? Surely one doesn't have to be a carpenter
to complain about a wobbly table?

Your comment that it was a joke... Try working on a standard and you
will learn why these things happen.
It wasn't my comment. My comment was to do with the fact that, just
because writing standards is difficult, that does *not* mean that a bad
standard is immune from criticism from those who have not themselves
written standards.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jun 21 '07 #26

P: n/a
Chris Hills said:
In article <Hc******************************@bt.com>, Richard
Heathfield <rj*@see.sig.invalidwrites
<snip>
>>And anyone who doesn't need to write portable code isn't
going to give a stuff about the Standard anyway.

That is not true. You need to know how the [Standard] C works even if
you don't use all of it or have to use extensions.
No, you don't. You only need to know how your implementation works. If
your code doesn't have to be portable, your implementation trumps the
Standard every single time.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jun 21 '07 #27

P: n/a
In article <YJ******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>Chris Hills said:
>In article <4P*********************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>>>Chris Hills said:

In article <5d*************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites
<snip>
>>>>>>
>So the next standard will be a list of optional features that might
>be
>removed in a future edition? What a joke.

What is your solution....

Drop C99 completely. Give it up as a bad job, and work on something
that actually meets the needs of programmers writing portable C code.

The majority of C programmers don't need portability.

If that's true, then they don't need a standard, just an implementation.
But I don't think it's true.
No they need the standard. Whilst they don't need portability the do
need to know how the C will behave.
>>>Would you care to share your experiences from having worked on an
international standard?
What has that to do with it? Surely one doesn't have to be a carpenter
to complain about a wobbly table?

Your comment that it was a joke... Try working on a standard and you
will learn why these things happen.

It wasn't my comment. My comment was to do with the fact that, just
because writing standards is difficult, that does *not* mean that a bad
standard is immune from criticism from those who have not themselves
written standards.
I agree.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 21 '07 #28

P: n/a
Chris Hills said:
In article <YJ******************************@bt.com>, Richard
Heathfield <rj*@see.sig.invalidwrites
>>Chris Hills said:
<snip>
>>The majority of C programmers don't need portability.

If that's true, then they don't need a standard, just an
implementation. But I don't think it's true.

No they need the standard. Whilst they don't need portability the do
need to know how the C will behave.
They can get that from their implementation's documentation.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jun 21 '07 #29

P: n/a
Chris Hills wrote On 06/21/07 08:46,:
>
The majority of C programmers don't need portability. The majority of
C programmers need a small powerful language that will run on small
processors.
This sounds like an argument for abandoning the standards
altogether.

Chris, I remember those days. They were not good days.

--
Er*********@sun.com
Jun 21 '07 #30

P: n/a
In article <1182437721.64774@news1nwk>, Eric Sosman
<Er*********@sun.comwrites
>Chris Hills wrote On 06/21/07 08:46,:
>>
The majority of C programmers don't need portability. The majority of
C programmers need a small powerful language that will run on small
processors.

This sounds like an argument for abandoning the standards
altogether.
Not at all. Back to C95 and then move forward carefully.
Chris, I remember those days. They were not good days.
Agreed.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 21 '07 #31

P: n/a
Chris Hills wrote On 06/21/07 12:25,:
In article <1182437721.64774@news1nwk>, Eric Sosman
<Er*********@sun.comwrites
>>Chris Hills wrote On 06/21/07 08:46,:
>>>The majority of C programmers don't need portability. The majority of
C programmers need a small powerful language that will run on small
processors.

This sounds like an argument for abandoning the standards
altogether.


Not at all. Back to C95 and then move forward carefully.
Maybe I'm even denser than usual today, but I don't see
what this has to do with "don't need portability." It's a
comment/complaint/opinion about the "feature set" of C, as
far as I can tell.

So, my question again: If in truth "the majority of C
programmers don't need portability," it means that the
majority of C programmers don't need a standard. They
don't need to know how this or that feature of the language
works on the ideal, abstract C platform, but only how it
behaves on the specific machine they're working with today.
Tomorrow's machine, or their neighbors' machine, or any
other machine is just plain irrelevant, because they "don't
need portability" and their code will never need to run on
those machines. So, why go to the bother of a standard?
Just to please the minority?
> Chris, I remember those days. They were not good days.

Agreed.
Well, naturally I agree with myself. I just don't
understand why you do, if you think portability has no
significant value. The difficulty in the pre-Standard
days was that each C implementation was a law unto itself,
and they disagreed in subtle and unsubtle ways. But if
programmers don't need portability, they don't encounter
the disagreements and aren't discommoded by them -- so
why do you think those days were ungood?

--
Er*********@sun.com

Jun 21 '07 #32

P: n/a
In article <1182445878.934238@news1nwk>, Eric Sosman
<Er*********@sun.comwrites
>Chris Hills wrote On 06/21/07 12:25,:
>In article <1182437721.64774@news1nwk>, Eric Sosman
<Er*********@sun.comwrites
>>>Chris Hills wrote On 06/21/07 08:46,:

The majority of C programmers don't need portability. The majority of
C programmers need a small powerful language that will run on small
processors.

This sounds like an argument for abandoning the standards
altogether.


Not at all. Back to C95 and then move forward carefully.

Maybe I'm even denser than usual today, but I don't see
what this has to do with "don't need portability." It's a
comment/complaint/opinion about the "feature set" of C, as
far as I can tell.

So, my question again: If in truth "the majority of C
programmers don't need portability," it means that the
majority of C programmers don't need a standard. They
don't need to know how this or that feature of the language
works on the ideal, abstract C platform, but only how it
behaves on the specific machine they're working with today.
Tomorrow's machine, or their neighbors' machine, or any
other machine is just plain irrelevant, because they "don't
need portability" and their code will never need to run on
those machines. So, why go to the bother of a standard?
Just to please the minority?
>> Chris, I remember those days. They were not good days.

Agreed.

Well, naturally I agree with myself. I just don't
understand why you do, if you think portability has no
significant value. The difficulty in the pre-Standard
days was that each C implementation was a law unto itself,
and they disagreed in subtle and unsubtle ways. But if
programmers don't need portability, they don't encounter
the disagreements and aren't discommoded by them -- so
why do you think those days were ungood?
We have been around this several times.

It's quite simple I write a lot of specialised embedded software for
specific processors. You need the SW to be as small and fast as
possible. You don't have the luxury of adding more memory.

Therefore you have to interact with the hardware directly no OS. One
MCU I use has directly addressable bit memory. So you use 1 bit flags.
These are not standard C.

For the serial IO you directly address the UART registers the same for
CAN or USB. That is all with non standard C.

However the rest off the App will be in standard C which you would like
the be have as per the standard. Ie the if, while, switch etc .

However there is no way I will port 8051 code to a 68040 It would be
better two re-write it in standard C in a way that takes advantage of
the underlying MCU architecture.

It is the model or algorithms which are portable. Not the C a lot of the
time .

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 21 '07 #33

P: n/a
On Thu, 21 Jun 2007 10:30:18 +0100, Chris Hills <ch***@phaedsys.org>
wrote:
>In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>>Chris Hills <ch***@phaedsys.orgwrites:
[...]
>>I don't think implementations will ever catch up with C99

I think you will find that C200* will be C99 with some big bits
removed and a few smaller bits added.

Can you substantiate this claim?

See private email
>>Has the committee considered the
fact that most or all C99 features actually have been implemented by
some compilers, and removing them from the language will break
existing code?

That is not a problem vitally all compilers have extensions to the
standard.

Compilers have only added the C99 parts their customers wanted. So if
some are removed from the standard it will not affect them. They will
continue to use those features. They will just not be part of the
standard.
But why remove them? Those that do not want those features can
continue to not use them.

--
Al Balmer
Sun City, AZ
Jun 21 '07 #34

P: n/a
On 21 Jun 2007 11:07:44 GMT, ri*****@cogsci.ed.ac.uk (Richard Tobin)
wrote:
>In article <PB**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.ukwrote:
>>Compilers have only added the C99 parts their customers wanted.

It seems to me that several parts of C99 should have been published
as separate standards, to which compilers could claim conformance
if they implemented them. The floating-point environment and complex
number support are obvious examples. If this had been done, I think
the core of C99 would be much more widely supported and used.
That approach seems to be accepted in POSIX.

--
Al Balmer
Sun City, AZ
Jun 21 '07 #35

P: n/a
Chris Hills wrote:
In article <5d*************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites
>Chris Hills wrote:
>>In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites

Has the committee considered the
fact that most or all C99 features actually have been implemented by
some compilers, and removing them from the language will break
existing code?

That is not a problem vitally all compilers have extensions to the
standard.

Compilers have only added the C99 parts their customers wanted. So if
some are removed from the standard it will not affect them. They will
continue to use those features. They will just not be part of the
standard.
So the next standard will be a list of optional features that might be
removed in a future edition? What a joke.

What is your solution....
I made that comment because a document like the C standard does not
stand in isolation. Not only do compiler writers invest time and effort
implementing it, but other standards are based on or include it. So
removing features has the potential to knock the legs out from under
other standards.

--
Ian Collins.
Jun 21 '07 #36

P: n/a
In article <5e*************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites
>Chris Hills wrote:
>In article <5d*************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites
>>Chris Hills wrote:
In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites

Has the committee considered the
fact that most or all C99 features actually have been implemented by
some compilers, and removing them from the language will break
existing code?

That is not a problem vitally all compilers have extensions to the
standard.

Compilers have only added the C99 parts their customers wanted. So if
some are removed from the standard it will not affect them. They will
continue to use those features. They will just not be part of the
standard.

So the next standard will be a list of optional features that might be
removed in a future edition? What a joke.

What is your solution....
I made that comment because a document like the C standard does not
stand in isolation.
What else depends on it?
Not only do compiler writers invest time and effort
implementing it,
That is the point. The vast majority of compilers have not implemented
it.
but other standards are based on or include it.
Such as?
So
removing features has the potential to knock the legs out from under
other standards.
Which?
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 21 '07 #37

P: n/a
In article <gu********************************@4ax.com>, Al Balmer
<al******@att.netwrites
>On Thu, 21 Jun 2007 10:30:18 +0100, Chris Hills <ch***@phaedsys.org>
wrote:
>>In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>>>Chris Hills <ch***@phaedsys.orgwrites:
[...]
I don't think implementations will ever catch up with C99

I think you will find that C200* will be C99 with some big bits
removed and a few smaller bits added.

Can you substantiate this claim?

See private email
>>>Has the committee considered the
fact that most or all C99 features actually have been implemented by
some compilers, and removing them from the language will break
existing code?

That is not a problem vitally all compilers have extensions to the
standard.

Compilers have only added the C99 parts their customers wanted. So if
some are removed from the standard it will not affect them. They will
continue to use those features. They will just not be part of the
standard.

But why remove them? Those that do not want those features can
continue to not use them.
Because you will never again have a conforming C compiler.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 21 '07 #38

P: n/a
"Chris Hills" <ch***@phaedsys.orgwrote in message
news:fZ**************@phaedsys.demon.co.uk...
In article <5e*************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites
.....
>>I made that comment because a document like the C standard does not
stand in isolation.

What else depends on it?
>Not only do compiler writers invest time and effort
implementing it,

That is the point. The vast majority of compilers have not implemented
it.
>but other standards are based on or include it.

Such as?
Posix requires C99. The next revision of the C++ Standard will
require the entire C99 library and a preprocessor that matches
C99, plus other bits.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jun 21 '07 #39

P: n/a
Chris Hills wrote:
In article <5e*************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites:
>>
I made that comment because a document like the C standard does not
stand in isolation.

What else depends on it?
>Not only do compiler writers invest time and effort
implementing it,

That is the point. The vast majority of compilers have not implemented it.
>but other standards are based on or include it.

Such as?
That question is almost an answer in its self. I'm aware of C++ and
Posix, but there may be others. That's the problem with dropping
features from a key standard, one can never be sure the change won't
break something down stream.

--
Ian Collins.
Jun 21 '07 #40

P: n/a
Chris Hills <ch***@phaedsys.orgwrites:
[...]
> Well, naturally I agree with myself. I just don't
understand why you do, if you think portability has no
significant value. The difficulty in the pre-Standard
days was that each C implementation was a law unto itself,
and they disagreed in subtle and unsubtle ways. But if
programmers don't need portability, they don't encounter
the disagreements and aren't discommoded by them -- so
why do you think those days were ungood?

We have been around this several times.

It's quite simple I write a lot of specialised embedded software for
specific processors. You need the SW to be as small and fast as
possible. You don't have the luxury of adding more memory.

Therefore you have to interact with the hardware directly no OS. One
MCU I use has directly addressable bit memory. So you use 1 bit
flags. These are not standard C.

For the serial IO you directly address the UART registers the same for
CAN or USB. That is all with non standard C.

However the rest off the App will be in standard C which you would
like the be have as per the standard. Ie the if, while, switch etc .

However there is no way I will port 8051 code to a 68040 It would be
better two re-write it in standard C in a way that takes advantage of
the underlying MCU architecture.

It is the model or algorithms which are portable. Not the C a lot of
the time .
That's *your* application domain. Portability may not be important to
you, but it's very important to a lot of C programmers. And if you're
talking about going back to the C95, then portability is entirely
possible.

One of C's greatest strengths is that it allows you write non-portable
system-specific code when you have to. Another of its greatest
strengths is that it allows you to write *portable* code when
system-specificity isn't necessary. Ignoring either aspect of the
language is foolish.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 21 '07 #41

P: n/a
Chris Hills <ch***@phaedsys.orgwrites:
In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>>Chris Hills <ch***@phaedsys.orgwrites:
[...]
>>I don't think implementations will ever catch up with C99

I think you will find that C200* will be C99 with some big bits
removed and a few smaller bits added.

Can you substantiate this claim?

See private email
[...]

To repeat what I wrote in my e-mail response:

| Thanks for the information, but why send it to just me? I'm sure it
| would be of great interest to a lot of people. If it's confidential,
| why tell me?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 21 '07 #42

P: n/a
Chris Hills <ch***@phaedsys.orgwrites:
In article <lO******************************@bt.com>, Richard
Heathfield <rj*@see.sig.invalidwrites
>>Keith Thompson said:

<snip>
>>Has the committee considered the
fact that most or all C99 features actually have been implemented by
some compilers, and removing them from the language will break
existing code?

I would like to assure the committee that, even if they remove *all* the
features added by C99, this will have no effect whatsoever on my
existing code.

I will let them know Richard, and I am sure that this will reassure
them greatly :-)

DON'T PANIC the sort of things they were looking at are the ones that
(virtually) no one has implemented.
Please be more specific.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 21 '07 #43

P: n/a
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>| Thanks for the information, but why send it to just me? I'm sure it
| would be of great interest to a lot of people. If it's confidential,
| why tell me?
Because you're a model of discretion?

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jun 21 '07 #44

P: n/a
Keith Thompson wrote:
>
.... snip ...
>
One of C's greatest strengths is that it allows you write non-
portable system-specific code when you have to. Another of its
greatest strengths is that it allows you to write *portable* code
when system-specificity isn't necessary. Ignoring either aspect
of the language is foolish.
Oh, nicely put.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 22 '07 #45

P: n/a
In article <8Y******************************@giganews.com>, P.J. Plauger
<pj*@dinkumware.comwrites
>"Chris Hills" <ch***@phaedsys.orgwrote in message
news:fZ**************@phaedsys.demon.co.uk...
>In article <5e*************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites
>.....
>>>I made that comment because a document like the C standard does not
stand in isolation.

What else depends on it?
>>Not only do compiler writers invest time and effort
implementing it,

That is the point. The vast majority of compilers have not implemented
it.
>>but other standards are based on or include it.

Such as?

Posix requires C99. The next revision of the C++ Standard will
require the entire C99 library and a preprocessor that matches
C99, plus other bits.
POSIX will be a problem as it is published though it can still refer
back to a specific version of the C standard.

As for C++ "The next revision"... well if it is not published yet then
they can be for warned that the C standard will change.

Do we really want a C++ that is merged with the C library? That idea
seems a bit of a mess to me. We end up with the infamous "C/C+" language
:-(
Regards
Chris

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 22 '07 #46

P: n/a
Chris Hills wrote:
In article <8Y******************************@giganews.com>, P.J. Plauger
<pj*@dinkumware.comwrites
>"Chris Hills" <ch***@phaedsys.orgwrote in message
news:fZ**************@phaedsys.demon.co.uk...
>>In article <5e*************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites
>>.....
I made that comment because a document like the C standard does not
stand in isolation.

What else depends on it?

Not only do compiler writers invest time and effort
implementing it,

That is the point. The vast majority of compilers have not implemented
it.

but other standards are based on or include it.

Such as?

Posix requires C99. The next revision of the C++ Standard will
require the entire C99 library and a preprocessor that matches
C99, plus other bits.

POSIX will be a problem as it is published though it can still refer
back to a specific version of the C standard.

As for C++ "The next revision"... well if it is not published yet then
they can be for warned that the C standard will change.

Do we really want a C++ that is merged with the C library? That idea
seems a bit of a mess to me. We end up with the infamous "C/C+" language
:-(
The current C++ standard includes the previous C standard library (with
a few modifications), so it makes sense for the next standard to include
the current C standard library and preprocessor changes.

--
Ian Collins.
Jun 22 '07 #47

P: n/a
[snips]

On Thu, 21 Jun 2007 22:01:12 +0100, Chris Hills wrote:
>>>>Has the committee considered the
fact that most or all C99 features actually have been implemented by
some compilers
>>But why remove them? Those that do not want those features can
continue to not use them.
Because you will never again have a conforming C compiler.

If, as noted above, some compilers have actually implemented all the
features, then there are conforming compilers - and presumably will
continue to be as new features are added. If other compilers don't
support the standard, it's a QoI issue. "You'll never again have a
conforming C compiler" doesn't work.

That said, if QoI is consistently poor over a wide variety of compilers as
pertains to a particular feature, it might argue that the specific feature
is simply unreasonably difficult to implement.
Jun 29 '07 #48

P: n/a
In article <vd************@spanky.localhost.net>, Kelsey Bjarnason
<kb********@gmail.comwrites
>[snips]

On Thu, 21 Jun 2007 22:01:12 +0100, Chris Hills wrote:
>>>>>Has the committee considered the
>fact that most or all C99 features actually have been implemented by
>some compilers
>>>But why remove them? Those that do not want those features can
continue to not use them.
>Because you will never again have a conforming C compiler.


If, as noted above, some compilers have actually implemented all the
features, then there are conforming compilers
Very few and not main steam compilers.
- and presumably will
continue to be as new features are added. If other compilers don't
support the standard, it's a QoI issue. "You'll never again have a
conforming C compiler" doesn't work.
It does work in practice.
>That said, if QoI is consistently poor over a wide variety of compilers as
pertains to a particular feature, it might argue that the specific feature
is simply unreasonably difficult to implement.
Or the market just does not want them.

You have a standard that is at variance with what the users want.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jul 1 '07 #49

P: n/a
Chris Hills said:
In article <vd************@spanky.localhost.net>, Kelsey Bjarnason
<kb********@gmail.comwrites
<snip>
>>If, as noted above, some compilers have actually implemented all the
features, then there are conforming compilers

Very few and not main steam compilers.
True, but irrelevant, since most compilers have already been converted
to Diesel.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jul 1 '07 #50

51 Replies

This discussion thread is closed

Replies have been disabled for this discussion.