«

On 2011-01-04, Chris H <> wrote:
>>The problem is, some C99 features require a pretty intimate
>>relationship between the compiler (including the preprocessor) and the
>>library, which does not sit well with the traditional GCC's "library is
>>someone else's problem" model; math_errhandling and the standard
>>pragmas are good examples.

> Yes which is why for most targets gcc is a poor choice.

Well, I'm obviously biased, since we do embedded Linux, but we've not found
this to be a problem in practice. It generates code, the code usually works,
and people seem happy with it.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Keith Thompson wrote:

> Walter Banks <> writes:
>
> > What PJP did propose was to identify the core features of C. The context of the
> > comments was important. This was at a time that ISO/IEC 18037 and the decimal
> > math standards were becoming standards. It was clear to everyone at WG14 that
> > these two TR's were not needed by everyone. The real question was if the TR's
> > were optional, what were the core features of C?
> [...]
>
> Are there any documents available online that discuss
> the rationale for this? Probably something under
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/, but there are a
> lot of documents there.

I talked to PJP in Markham about the core components of C.
There are two short documents that PJP wrote on standard subsetting.
N1443 and N1460 These are the conditional defines that other have
mentioned.

Regards,

w..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

Walter Banks <> writes:
> Keith Thompson wrote:
>> Walter Banks <> writes:
>> > What PJP did propose was to identify the core features of
>> > C. The context of the comments was important. This was at a
>> > time that ISO/IEC 18037 and the decimal math standards were
>> > becoming standards. It was clear to everyone at WG14 that
>> > these two TR's were not needed by everyone. The real question
>> > was if the TR's were optional, what were the core features of C?
>> [...]
>>
>> Are there any documents available online that discuss
>> the rationale for this? Probably something under
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/, but there are a
>> lot of documents there.
>
> I talked to PJP in Markham about the core components of C.
> There are two short documents that PJP wrote on standard subsetting.
> N1443 and N1460 These are the conditional defines that other have
> mentioned.

N1460 appears to be an updated version of N1443.

N1471, mentioned here previously, proposes three additional optional
features; it hasn't been adopted in the latest draft. The author
is S. J. Montgomery, apparently from the MISRA C WG.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson wrote:

> > I talked to PJP in Markham about the core components of C.
> > There are two short documents that PJP wrote on standard subsetting.
> > N1443 and N1460 These are the conditional defines that other have
> > mentioned.
>
> N1460 appears to be an updated version of N1443.

> N1471, mentioned here previously, proposes three additional optional
> features; it hasn't been adopted in the latest draft. The author
> is S. J. Montgomery, apparently from the MISRA C WG.

Steve Montgomery who has a lot to say about coding standards
and feature sets. He represented misra at WG14


N1460 was updated for a later meeting. There was a lot of break time
discussions over language subsetting at a few meetings. The
conversations we had in Markham all agreed that it was a good idea,
the hard part was trying to find realistic subsets. I went away from the
Markham meeting determined to find some voice for the needs of
embedded systems applications that could be identified so the
development costs of tools could be lowered and more important
tool developers could focus on core requirements. The problem is
in the details, every set I looked had more complexity than the full
standard being replaced.

It was clear that the TR's were optional right from the beginning.

What next?
Drop floating point from embedded systems?

What about integer sizes? This was a battle won and lost creating
size specific integers in C99.

You can look at the language core and start from that side with
the essential C features.

Basic syntax.
Operator precedence
. . .
after the obvious list, again it is a series of tough choices.


There are a lot of C users here.

What is the core of the language that must be available, remembering that C is used in many contexts?

Regards,

w..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

Le 04/01/11 22:31, Walter Banks a écrit :
>
> What next?
> Drop floating point from embedded systems?
>
> What about integer sizes? This was a battle won and lost creating
> size specific integers in C99.
>
> You can look at the language core and start from that side with
> the essential C features.
>
> Basic syntax.
> Operator precedence
> . . .
> after the obvious list, again it is a series of tough choices.
>
>
> There are a lot of C users here.
>
> What is the core of the language that must be available, remembering that C is used in many contexts?
>
> Regards,
>


Why not do what the so often cited n1395 proposed?
Define a subset of C that is a new language subset
in a new document, called CSI as they propose
(Conforming Subset Implementation) without
floating point.

That would mean dropping complex and tgmath.h and most math functions
from the math library, dropping some formats from the printf
specifications and other library changes probably.

THAT was the proposal from the Netherlands committee, NOT to change
the whole language dropping most of C99 and dooming C to just a
niche language for micro controllers.

OK, your company makes money with that kind of stuff. It is OK.

But maybe you acknowledge that there are OTHER companies that
make money in OTHER kinds of environments?

Why do you want to ignore any other uses of C?

Why coudn't you propose a subset of C consisting of:

Standard language except the types

float, double, long double

and all associated stuff: math.h and stdio that use double,
complex, and tgmath.h, etc.

THAT would be a REAL progress, i.e. define a non-floating point
subset of C for micro-controllers and very small machines that
does not use floating point. The long long type would be optional,
with short 16, int 16 or 32, and long 32.

That is a feasible language where you can do a LOT of stuff.

But WHY PUT ALL OTHER users of C out of the loop?

Why destroy the C99 standard?

Just think about it for a while. You feel that the standard did not
follow your needs. Why should NOW everyone else follow YOUR needs?

In message <>, Keith Thompson <kst-
> writes
>Walter Banks <> writes:
>> Keith Thompson wrote:
>>> Walter Banks <> writes:
>>> > What PJP did propose was to identify the core features of
>>> > C. The context of the comments was important. This was at a
>>> > time that ISO/IEC 18037 and the decimal math standards were
>>> > becoming standards. It was clear to everyone at WG14 that
>>> > these two TR's were not needed by everyone. The real question
>>> > was if the TR's were optional, what were the core features of C?
>>> [...]
>>>
>>> Are there any documents available online that discuss
>>> the rationale for this? Probably something under
>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/, but there are a
>>> lot of documents there.
>>
>> I talked to PJP in Markham about the core components of C.
>> There are two short documents that PJP wrote on standard subsetting.
>> N1443 and N1460 These are the conditional defines that other have
>> mentioned.
>
>N1460 appears to be an updated version of N1443.
>
>N1471, mentioned here previously, proposes three additional optional
>features; it hasn't been adopted in the latest draft. The author
>is S. J. Montgomery, apparently from the MISRA C WG.

Steve is the Chair of the MISRA-C WG. MISRA-C now has CAT-C liaison
with ISO-C WG

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message <ig05tu$fhi$>, jacob navia
<> writes
>THAT was the proposal from the Netherlands committee, NOT to change
>the whole language dropping most of C99 and dooming C to just a
>niche language for micro controllers.

They are the main group of users for C. On the PC and other non embedded
and hosted systems people have tended to C++ and other languages.

>But WHY PUT ALL OTHER users of C out of the loop?

They are not out of the loop. The additional features are optional.

>Why destroy the C99 standard?

The C99 standard is a standard in name only as already discussed that 12
years on no serious mainstream compilers have fully implemented it.

Many have a C94/5 compiler with C99 bits added. What is suggested is to
revise the Standard so that the core language is the one everyone uses
and the additional bit that some use is optional. That way the majority
of compilers will be C1* compliant and the standard will actually mean
something again.

>Just think about it for a while. You feel that the standard did not
>follow your needs. Why should NOW everyone else follow YOUR needs?

What is needed is a subset that will work for *everyone*. All
additional things would be optional thus it will meet everyone's needs.
You can still add extensions to your compiler.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

jacob navia wrote:

> Le 04/01/11 22:31, Walter Banks a écrit :
> >
> > What next?
> > Drop floating point from embedded systems?
> >
> > What about integer sizes? This was a battle won and lost creating
> > size specific integers in C99.
> >
> > You can look at the language core and start from that side with
> > the essential C features.
> >
> > Basic syntax.
> > Operator precedence
> > . . .
> > after the obvious list, again it is a series of tough choices.
> >
> >
> > There are a lot of C users here.
> >
> > What is the core of the language that must be available, remembering that C is used in many contexts?
>
>
> Why not do what the so often cited n1395 proposed?
> Define a subset of C that is a new language subset
> in a new document, called CSI as they propose
> (Conforming Subset Implementation) without
> floating point.
>
> That would mean dropping complex and tgmath.h and most math functions
> from the math library, dropping some formats from the printf
> specifications and other library changes probably.
>
> THAT was the proposal from the Netherlands committee, NOT to change
> the whole language dropping most of C99 and dooming C to just a
> niche language for micro controllers.

The proposal was to identify core language details. Lots of the
embedded systems use a small subset of the language and at the
same time require as a norm some of the best optimization

> OK, your company makes money with that kind of stuff. It is OK.
>
> But maybe you acknowledge that there are OTHER companies that
> make money in OTHER kinds of environments?

There are plenty of C user communities. Part of the tone in my post
comes from the limited representation that embedded systems has
at WG-14. In that sense I am typically one of a few people representing
embedded systems interests.

> Why coudn't you propose a subset of C consisting of:
>
> Standard language except the types
>
> float, double, long double
>
> and all associated stuff: math.h and stdio that use double,
> complex, and tgmath.h, etc.
>
> THAT would be a REAL progress, i.e. define a non-floating point
> subset of C for micro-controllers and very small machines that
> does not use floating point. The long long type would be optional,
> with short 16, int 16 or 32, and long 32.
>
> That is a feasible language where you can do a LOT of stuff.

That defines how most small embedded systems are implemented.
A compiler for small embedded systems compilers would be defined
as the core plus ISO/IEC 18037.

> Why destroy the C99 standard?

I don't think it would destroy the C99 standard.

Yesterday I was looking at some of the WG14 papers that
led up to the release of C99 and it was clear that C89/C90
was a reference document of standard practice and the
discussions that led to C99 was dealing with everything
that was wrong with C as defined by C90.

The core language suggestions might want to look at these
papers that deal with C90 issues and not the extensions.

Regards,

w..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com