C89 Standard for Britons

[Richard Heathfield]

Chris Hills said:

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]

Chris Hills said:

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.

 

[Chris Hills]

Chris Hills said:


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.

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]

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]

Chris Hills said:


My work here is done.


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

 

[Richard Heathfield]

Chris Hills said:

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.

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]

Chris Hills said:

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>

 

[Chris Hills]

Chris Hills said:


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.

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.

 

[Richard Heathfield]

Chris Hills said:

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>

 

[Eric Sosman]

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.

 

[Chris Hills]

Chris Hills wrote On 06/21/07 08:46,:

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.

 

[Eric Sosman]

Chris Hills wrote On 06/21/07 12:25,:

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?

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?

 

[Chris Hills]

Chris Hills wrote On 06/21/07 12:25,:

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?


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 .

 

[Al Balmer]

See private email


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]

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.

 

[Ian Collins]

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.

 

[Chris Hills]

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]

[...]
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.

 

[P.J. Plauger]

.....

What else depends on it?


That is the point. The vast majority of compilers have not implemented
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

 

[Ian Collins]

What else depends on it?


That is the point. The vast majority of compilers have not implemented 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.