simple question about inter modular acces

[glen herrmannsfeldt]

(snip, I wrote)

Of course you can write to flash (well, there are some microcontrollers
that make it difficult - some have all their flash on a single erase
block, or for other reasons are unable to write to flash from the
running software). My point is that you cannot write /directly/ to
flash. If a variable "foo" is in flash, you cannot change it by writing
"foo = 1234;" - you have to write "flash_write(&foo, 1234)" or something
similar.

Well, if the compiler knew which were flash it could generate the
appropriate call on assignment. But either way, it is convenient to
have the ability to keep values in flash, and not zero them each
time the program is run, often with the program stored in flash.

-- glen

 

[Tim Rentsch]

On the other hand, a small target system might not have
reasonable support for 64-bit integers, or for floating-point.
[snip elaboration]

Yes but it doesn't have to. The bar for a freestanding
implementation is very low, because there is no lower bound on
the maximum object size that must be supported. A freestanding
implementation could simply not accept any program that uses
any type larger than 16 bits, with a diagnostic indicating an
environmental limit has been exceeded. Support for underranged
types, or unusual floating-point environments, could be enabled
by using #pragma or defining a symbol like __BOGUS. The result
satisfies both criteria - it can support very small systems,
and would also be a conforming implementation.

Hmm.

I can imagine a very small system (8051 may qualify, but I'm not
sufficiently familiar with it to be sure) for which floating-point
support just doesn't make sense.

Practically speaking, I'd rather see a statement like:

This is a nearly conforming C11 freestanding implementation, with
the exceptions that integers wider than 16 bits and floating-point
types of any size are not supported.

than:

This is a fully conforming C11 freestanding implementation. (Oh,
and you're not going to be able to use floating-point because scalar
types wider than 16 bits run into an environmental limit documented
in section X.Y paragraph Z.)

(Perhaps support for floating-point and for wide integer types
should be optional for freestanding implementations, but as of
C11 I personally think the standard has too many optional features
already.)

I see little point in doing arbitrary things *that are not useful
to users* to be able to claim full C conformance.

I understand where you're coming from, and I don't disagree
exactly. However there is another point to consider here,
and IMO a more important one, which I will now try to explain.

The most important attribute of a conforming implementation is
this: if it accepts a program without issuing a diagnostic, then
the resulting executable produced will behave as specified in the
ISO C standard (not counting hardware problems, compiler bugs,
etc). This attribute is more important than supporting a wider
range of will-be-accepted programs - it is better, to give one
example, for an implementation to refuse to accept a program
that uses 'double' than to accept the program but silently
(ie, sans diagnostic) represent "doubles" using 32-bit fixed
point. (There is nothing wrong with having a compiler option
that selects this semantics provided it is not misrepresented,
eg, not described as non-conforming.)

The concerns you identify are important, but they are quality
of implementation issues, not conformance issues. The people
who originally wrote the C standard decided (and wisely so IMO)
to address questions of conformance but disregard - at least as
far as normative text goes - issues related to quallity of
implementation. Of course it would be nice, other things being
equal, to have an implementation that accepts a wider range of
source programs. But being faithful to the Standard-described
semantics must be the high order bit, even if that comes at
some cost in terms of what programs are accepted.

(Aside: perhaps part of your reeaction comes from my mentioning
a dianostic saying an environmental limit had been exceeded. Of
course the diagnostic message doesn't have to actually say that,
and presumably the actual wording would be quite different. So
please don't focus on that aspect.)

Responding to your last paragraph, I would say these things.
The actions being considered are not arbitrary but motivated by
real-world concerns related to small systems. Furthermore, the
results are useful, because of the implication mentioned above.
And last but not least, the point of doing these things is not
to /claim conformance/ but rather to /be conforming/ - to provide
the most important attribute of a conforming implementation.
This last point is often overlooked in comp.lang.c discussions
because it occurs so commonly that it's taken for granted, but
it shouldn't be - this aspect is the foundation upon which
all other benefits of following the Standard rest.

 

[glen herrmannsfeldt]

(snip regarding C conformance, or lack thereof.)

You stil haven't presented a case where the costs of achieving
conformance are high. More importantly, you are disregarding
the primary benefit of implementations being conforming, as
explained in my response elsethread.
(snip)

There was a long discussion on the intel 4004 some time ago.

I understand your thesis here, but you still haven't presented
any convincing evidence that it's correct. Any device for which
a conforming C compiler cannot be fairly easily provided is so
limited (or perhaps unorthodox) that a suitable language for
it would not be C-like except perhaps very superficially.

But even the superficial is useful. Just having the same precedence
rules makes it easier to use once you are used to the C rules.
Especially if one switches between systems it helps not to have
to remember two sets of completely inconsistent rules.

-- glen

 

[glen herrmannsfeldt]

(If not the 8051, then the 4004 should be small enough.)

I understand where you're coming from, and I don't disagree
exactly. However there is another point to consider here,
and IMO a more important one, which I will now try to explain.

The most important attribute of a conforming implementation is
this: if it accepts a program without issuing a diagnostic, then
the resulting executable produced will behave as specified in the
ISO C standard (not counting hardware problems, compiler bugs,
etc).

As I suggest in a previous post, it might be that being less
surprising and/or confusing to existing C programmers is more
important, with precedence rules as an example.

Not that C precedence rules are perfect, but having to remember
two different sets would be confusing. Even if one never ports
between two systems, consistency could be useful.

This attribute is more important than supporting a wider
range of will-be-accepted programs - it is better, to give one
example, for an implementation to refuse to accept a program
that uses 'double' than to accept the program but silently
(ie, sans diagnostic) represent "doubles" using 32-bit fixed
point. (There is nothing wrong with having a compiler option
that selects this semantics provided it is not misrepresented,
eg, not described as non-conforming.)

How about one that has 16 bit float and 32 bit double?
Non-conforming, but a simple rule to remember when programming.

(snip)

Responding to your last paragraph, I would say these things.
The actions being considered are not arbitrary but motivated by
real-world concerns related to small systems. Furthermore, the
results are useful, because of the implication mentioned above.
And last but not least, the point of doing these things is not
to /claim conformance/ but rather to /be conforming/ - to provide
the most important attribute of a conforming implementation.
This last point is often overlooked in comp.lang.c discussions
because it occurs so commonly that it's taken for granted, but
it shouldn't be - this aspect is the foundation upon which
all other benefits of following the Standard rest.

For a smaler system, it might be that smaller data types and
otherwise smaller things would be more useful.

But even superficial conforming can be easier for some to use.

-- glen

 

[Keith Thompson]

I understand your thesis here, but you still haven't presented
any convincing evidence that it's correct. Any device for which
a conforming C compiler cannot be fairly easily provided is so
limited (or perhaps unorthodox) that a suitable language for
it would not be C-like except perhaps very superficially.

I think this may be the fundamental point on which we disagree.

I haven't worked on very small embedded systems, but I can imagine a
system (again, an 8051 or 4004 might qualify) where it makes perfectly
good sense to implement all C syntax and semantics *except* that, say,
floating-point types and integers wider than 16 bits are not supported.
I'm assuming, not that implementing such types would be unacceptably
difficult (though it might be), but that programmers of such systems
have no interest in using them.

There's not much point in implementing software floating-point if the
routines take up more space than is available on the target system.

For such a system, I think it would make sense to provide a *nearly*
conforming C implementation, specifically acknowledging the lack of
conformance but still leveraging C programmers' knowledge of the
language. A language that "would not be C-like except perhaps very
superficially" would lose that very real advantage (and of course would
not be conforming anyway).

 

[Stephen Sprunk]

I haven't worked on very small embedded systems, but I can imagine a
system (again, an 8051 or 4004 might qualify) where it makes
perfectly good sense to implement all C syntax and semantics *except*
that, say, floating-point types and integers wider than 16 bits are
not supported.

I'm not sure if it's what you meant, but if the system does not support
a 32-bit integer type, for instance, IMHO it should not provide "long"
at all, rather than provide a 16-bit "long". The former makes potential
problems obvious at compile time, whereas the latter will likely lead to
mysterious runtime problems.

S

 

[James Kuyper]

I'm not sure if it's what you meant, but if the system does not support
a 32-bit integer type, for instance, IMHO it should not provide "long"
at all, rather than provide a 16-bit "long". The former makes potential
problems obvious at compile time, whereas the latter will likely lead to
mysterious runtime problems.

Agree, but it has some inobvious implications. For instance,
ftell()/fseek() would have to use an int, rather than a long - which
might not matter if the system is also incapable of implementing <stdio.h>.

 

[Keith Thompson]

I'm not sure if it's what you meant, but if the system does not support
a 32-bit integer type, for instance, IMHO it should not provide "long"
at all, rather than provide a 16-bit "long". The former makes potential
problems obvious at compile time, whereas the latter will likely lead to
mysterious runtime problems.

Exactly.

 

[Keith Thompson]

Agree, but it has some inobvious implications. For instance,
ftell()/fseek() would have to use an int, rather than a long - which
might not matter if the system is also incapable of implementing <stdio.h>.

Right, but we're talking mostly about very small embedded systems,
which presumably would little if any of the standard library beyond
what's required for freestanding implementations.

It does have some implications for preprocessor arithmetic, which
should be carefully documented. (For not-quite-so-tiny systems, it
may be worth the extra effort to implement 32-bit integer arithmetic
in software.)

 

[Stephen Sprunk]

Agree, but it has some inobvious implications. For instance,
ftell()/fseek() would have to use an int, rather than a long - which
might not matter if the system is also incapable of implementing
<stdio.h>.

Again IMHO, if the system does not support a 32-bit "long", then it must
not support any Standard (ISO C or, for that matter, POSIX) interface
that requires a "long" argument/return.

If supporting such interfaces is critical to that system's market, then
the vendor needs provide a 32-bit "long" via software emulation. Aside
from multiplication and division, which are fairly rare in practice
thanks to strength reduction, it's not that expensive.

S

 

[Stephen Sprunk]

....
It does have some implications for preprocessor arithmetic, which
should be carefully documented. (For not-quite-so-tiny systems, it
may be worth the extra effort to implement 32-bit integer arithmetic
in software.)

Aren't programs for such systems typically cross-compiled? If so, it
may not be necessary for the preprocessor to be so restricted, just the
execution environment.

S

 

[James Kuyper]

Again IMHO, if the system does not support a 32-bit "long", then it must
not support any Standard (ISO C or, for that matter, POSIX) interface
that requires a "long" argument/return.

I would agree with that as a general recommendation; most of the other
functions that use 'long' don't make sense on a platform where 'long' is
too expensive to justify supporting it - but I think this particular
case is more debatable.
If such a platform can support a limited subset of <stdio.h>, for which
16-bit file offsets are sufficient, I don't think it would cause too
much trouble to support an ftell() that returns an int and an fseek()
that accepts an int, and I would expect that doing so would to cause a
marginal increase the ease of porting code to that platform from more
standard-conforming platforms.

 

[Keith Thompson]

Aren't programs for such systems typically cross-compiled? If so, it
may not be necessary for the preprocessor to be so restricted, just the
execution environment.

Good point.

The standard calls for integer types in preprocessor expressions
to be treated as intmax_t or uintmax_t, which are the widest types
available on the target. But for the kind of not-quite-conforming
implementation we're talking about, it might make sense to support,
say, 64-bit integers in the preprocessor even if the target only
has 16-bit or 32-bit integers.

 

[Stephen Sprunk]

"Stephen Sprunk" wrote in message


Mr. Thompson mentioned the 8051. I did a lot of programming in C on
some of these. I use the word "C" a bit loosely here. The language
I used had both extensions to support 8051 architectural features
(such as hardware support for single bit Booleans) and subtractions
to accommodate the processor (memory, speed, etc.). One of the
specific implementation features was that, by default, you'd get a
warning if you used the long data type. The warning basically said
that it was expensive in both clocks and memory to use longs. A
warning that could be suppressed from either the command line or with
a #pragma.

That seems like a perfectly reasonable solution.

S

 

[Tim Rentsch]

But even the superficial is useful. Just having the same
precedence rules makes it easier to use once you are used to the
C rules. Especially if one switches between systems it helps not
to have to remember two sets of completely inconsistent rules.

You misunderstand what I mean by "very superficially". A
language that shares a good fraction of C's operators (and more
or less the same semantics) is much more C-like than "very
superficially". Any processor that would benefit from such
a language could have a conforming C implementation without
too much difficulty.

 

[Tim Rentsch]

For a smaler system, it might be that smaller data types and
otherwise smaller things would be more useful.

You are confusing two distinct aspects here:

1. The language that developers think in, and
normally work in, when they write programs using
that implementation;

2. Whether the implementation is conforming.

It is perfectly possible and reasonable to accommodate both
aspects at the same time. Indeed that is the key point -
given that we _can_ provide these things in a conforming
implementation, and without any significant burden, it is
far better to restrict the set of implementations being
considered to conforming implementations.

 

[Tim Rentsch]

I think this may be the fundamental point on which we disagree.

I haven't worked on very small embedded systems, but I can imagine a
system (again, an 8051 or 4004 might qualify) where it makes
perfectly good sense to implement all C syntax and semantics
*except* that, say, floating-point types and integers wider than 16
bits are not supported.

This can be done in a conforming implementation, as I have
already explained.

I'm assuming, not that implementing such types would be unacceptably
difficult (though it might be), but that programmers of such systems
have no interest in using them.

There's not much point in implementing software floating-point if
the routines take up more space than is available on the target
system.

Perhaps so, but beside the point because it isn't necessary to do
so to achieve conformance.

For such a system, I think it would make sense to provide a *nearly*
conforming C implementation, specifically acknowledging the lack of
conformance but still leveraging C programmers' knowledge of the
language.

None of the limitations you mention prevent conformance, nor is
it difficult to achieve. If the cost of making an implementation
be conforming is essentially zero, and still can be restricted in
the ways you describe, isn't it better for it to be conforming
than not? It's hard to imagine a cost/benefits analysis
coming down on the side of throwing away benefits when the
cost is negligible.

A language that "would not be C-like except perhaps very
superficially" would lose that very real advantage (and of
course would not be conforming anyway).

I don't disagree, but this has no bearing on the above discussion
because here the language under discussion resembles C more than
superficially, and also can be supplied by an implementation that
is conforming.

 

[Keith Thompson]

This can be done in a conforming implementation, as I have
already explained.

[...]

An implementation that has no support for floating-point, for a
target system on which such support would not be useful, can be
"conforming" only in some sense that is practically indistinguishable
from non-conformance.

There are over 100 articles in this thread, but I think this is
what you're referring to:

) Yes but it doesn't have to. The bar for a freestanding
) implementation is very low, because there is no lower bound on
) the maximum object size that must be supported. A freestanding
) implementation could simply not accept any program that uses
) any type larger than 16 bits, with a diagnostic indicating an
) environmental limit has been exceeded. Support for underranged
) types, or unusual floating-point environments, could be enabled
) by using #pragma or defining a symbol like __BOGUS. The result
) satisfies both criteria - it can support very small systems,
) and would also be a conforming implementation.

You later said that any error message needn't specifically refer
to an environmental limit. But the real limit on the hypothetical
system has nothing to do with size; it might support 32-bit integers,
but not 32-bit floating-point, for example, and will almost certainly
support 32-bit and larger arrays and structures. Sure, you could
have a different limit for floating-point types vs. other types,
but I don't think that's the right approach.

I *think* you're suggesting justifying the lack of support for
floating-point by citing (directly or indirectly) an environmental
limit rather than by acknowledging that floating-point (which is
not an optional feature) is not supported.

What is the difference between a "conforming" implementation that
rejects all use floating-point due to an environmental limit and a
"non-conforming" implementation that does so because it just doesn't
support floating-point?

 

[Tim Rentsch]

[...]
I understand your thesis here, but you still haven't presented
any convincing evidence that it's correct. Any device for which
a conforming C compiler cannot be fairly easily provided is so
limited (or perhaps unorthodox) that a suitable language for
it would not be C-like except perhaps very superficially.

I think this may be the fundamental point on which we disagree.

I haven't worked on very small embedded systems, but I can imagine a
system (again, an 8051 or 4004 might qualify) where it makes
perfectly good sense to implement all C syntax and semantics
*except* that, say, floating-point types and integers wider than 16
bits are not supported.

This can be done in a conforming implementation, as I have
already explained.

[...]

An implementation that has no support for floating-point, for a
target system on which such support would not be useful, can be
"conforming" only in some sense that is practically
indistinguishable from non-conformance.

I'm not sure why you put quotes around the word conforming, since
I am using the word in the same sense that the Standard defines
it. More importantly the phrasing used disguises the distinction
I am trying to highlight: the key question is not whether an
implmentation is conforming -- which might be true purely by
accident -- but whether its implementtors are committed to
delivering a conforming implementation. Continued below...

There are over 100 articles in this thread, but I think this is
what you're referring to:

) Yes but it doesn't have to. The bar for a freestanding
) implementation is very low, because there is no lower bound on
) the maximum object size that must be supported. A freestanding
) implementation could simply not accept any program that uses
) any type larger than 16 bits, with a diagnostic indicating an
) environmental limit has been exceeded. Support for underranged
) types, or unusual floating-point environments, could be enabled
) by using #pragma or defining a symbol like __BOGUS. The result
) satisfies both criteria - it can support very small systems,
) and would also be a conforming implementation.

You later said that any error message needn't specifically refer
to an environmental limit. But the real limit on the hypothetical
system has nothing to do with size; it might support 32-bit
integers, but not 32-bit floating-point, for example, and will
almost certainly support 32-bit and larger arrays and structures.
Sure, you could have a different limit for floating-point types
vs. other types, but I don't think that's the right approach.

The only relevant question on this point is whether the Standard
allows such behavior in a conforming implementation. Do you
agree that it does? If not, why not? Obviously how diagnostics
are worded is important in terms of user reaction, but has no
bearing on conformance -- the message might be "sorry, charlie,
take your floating point somewhere else", and that wouldn't
change anything (ie, as regards the conformance question).

I *think* you're suggesting justifying the lack of support for
floating-point by citing (directly or indirectly) an environmental
limit rather than by acknowledging that floating-point (which is
not an optional feature) is not supported.

I'm not making any statement about any particular implementation,
either justifying or (non-)acknowledging. My intention is to
explain and support the thesis that a freestanding implementation
may refuse to accept programs that use floating-point operations
and yet still be conforming.

What is the difference between a "conforming" implementation that
rejects all use floating-point due to an environmental limit and a
"non-conforming" implementation that does so because it just
doesn't support floating-point?

The way the question is asked it's impossible to answer, but
let's consider a related scenario.

Suppose we have two groups of implementors, A and B. Group A has
decided to do a conforming implementation. Group B has decided
to implement "C-", which is most of C but leaves out some things
that they feel would impact the implementation too much, such as
floating point and 'long long'. The implementation of group A is
conforming working under the assumption of the thesis posited
above. The implementation of group B might or might not be
conforming under the same conditions.

Given this state of affairs, what do we know? About the
implementation done by group A, we know two things:

1. The implementation will issue a diagnostic for any
program that contains a constraint violation, and

2. Any program that is accepted without a diagnostic will
behave as specified by the relevant ISO standard.

About the implementation done by group B, we know essentially
nothing. Probably it will behave like ISO C in most cases, but
there's no way to be sure without a careful reading of the
documentation done for implementation B, and even then we might
not know. Furthermore, when the next release arrives things
might be different, because group B has decided on their own what
language to implement. Granted, group B's language(s) will be a
lot like standard C, but just how much is up to them - having
abandoned the principle of conformance in one area, we may
reasonably expect they may be lax about conformance in another
area.

The single statement that an implementation is conforming (and
that its implementors are committed to having it be conforming)
conveys by itself a tremendous amount of information, even
under the assumption that it may, eg, refuse to accept programs
that use floating point (or 'long long', etc). It is for this
reason that there is a big difference between "conforming" and
"non-conforming" implementations, as I understand what you take
the quoted terms to mean.

 

[Keith Thompson]

[...]
I understand your thesis here, but you still haven't presented
any convincing evidence that it's correct. Any device for which
a conforming C compiler cannot be fairly easily provided is so
limited (or perhaps unorthodox) that a suitable language for
it would not be C-like except perhaps very superficially.

I think this may be the fundamental point on which we disagree.

I haven't worked on very small embedded systems, but I can imagine a
system (again, an 8051 or 4004 might qualify) where it makes
perfectly good sense to implement all C syntax and semantics
*except* that, say, floating-point types and integers wider than 16
bits are not supported.

This can be done in a conforming implementation, as I have
already explained.

[...]

An implementation that has no support for floating-point, for a
target system on which such support would not be useful, can be
"conforming" only in some sense that is practically
indistinguishable from non-conformance.

I'm not sure why you put quotes around the word conforming, since
I am using the word in the same sense that the Standard defines
it. More importantly the phrasing used disguises the distinction
I am trying to highlight: the key question is not whether an
implmentation is conforming -- which might be true purely by
accident -- but whether its implementtors are committed to
delivering a conforming implementation. Continued below...

The only references to implementation-specific capacity limits that
I can find in N1570 are:

Section 1, paragraph 2:

This International Standard does not specify
[...]
- the size or complexity of a program and its data that will
exceed the capacity of any specific data-processing system
or the capacity of a particular processor

and section 5.2.4.1, which discusses translation limits and has
the long list of things like "127 nesting levels of blocks".

What you're suggesting, if I understand correctly, is that an
implementation could accept a declaration of a structure containing
function pointers, bit fields, and 42 levels of nested unions, but
reject a declaration "float x;" because it exceeds its capacity,
and claim conformance to the standard. Is my understanding of your
position correct?

I suppose that's true in the most literal sense, but I don't believe
the standard as written is *intended* to make floating-point an
optional feature. By your reasoning, a compiler could refuse to
accept *any* arbitrary language feature as long as it issues a
diagnostic and justifies that rejection as a capacity limitation
(regardless of how the diagnostic is phrased).

I don't believe the permission to impose capacity limits is intended
to permit omitting entire non-optional features.

To take things just a little further, I could construct a single C
program that precisely hits every one of the translation limits in
5.2.4.1 and produces no output or other visible behavior. I could
then write a "compiler" that recognizes that single program and
creates an executable that does nothing, while rejecting every other
C source file. I would then have a conforming C implementation
according to the letter of the standard -- but it would be utterly
useless.

(I believe the intent of 5.2.4.1 is that any *reasonable* compiler
that accepts that "one program" will also accept most real-world
code; the easiest way to satisfy 5.2.4.1 while implementing a useful
compiler is to avoid imposing any fixed limits at all, which is what
most vendors have actually done.)

[...]

The only relevant question on this point is whether the Standard
allows such behavior in a conforming implementation. Do you
agree that it does? If not, why not? Obviously how diagnostics
are worded is important in terms of user reaction, but has no
bearing on conformance -- the message might be "sorry, charlie,
take your floating point somewhere else", and that wouldn't
change anything (ie, as regards the conformance question).

Yes, I *think* the Standard allows such behavior, but I hardly
think that's the only *relevant* question. And I'm not completely
convinced that the Standard actually allows it. The counterargument
would be that failing to implement floating-point does not constitute
a *capacity* limitation as permitted by 1p2.

[...]

The way the question is asked it's impossible to answer, but
let's consider a related scenario.

How is it impossible to answer? I believe a single compiler could
simultaneously meet either description, with the only difference being
how it's described.

Suppose we have two groups of implementors, A and B. Group A has
decided to do a conforming implementation. Group B has decided
to implement "C-", which is most of C but leaves out some things
that they feel would impact the implementation too much, such as
floating point and 'long long'. The implementation of group A is
conforming working under the assumption of the thesis posited
above. The implementation of group B might or might not be
conforming under the same conditions.

Given this state of affairs, what do we know? About the
implementation done by group A, we know two things:

1. The implementation will issue a diagnostic for any
program that contains a constraint violation, and

2. Any program that is accepted without a diagnostic will
behave as specified by the relevant ISO standard.

About the implementation done by group B, we know essentially
nothing. Probably it will behave like ISO C in most cases, but
there's no way to be sure without a careful reading of the
documentation done for implementation B, and even then we might
not know. Furthermore, when the next release arrives things
might be different, because group B has decided on their own what
language to implement. Granted, group B's language(s) will be a
lot like standard C, but just how much is up to them - having
abandoned the principle of conformance in one area, we may
reasonably expect they may be lax about conformance in another
area.

Suppose Group B makes the following guarantees:

1. Our implementation fully conforms to the 2011 C standard as a
freestanding implementation *except* that floating-point and types
"long long" and "unsigned long long" are not supported, and the
widest integer types are 32 bits. (A few additional paragraphs
would be needed to cover the ramifications, such as the types used
for intmax_t and the behavior of preprocessor expressions.)

2. Our implementation will issue a diagnostic for any program that
contains a constraint violation (and for any program that violates
the restrictions stated in (1)).

3. Any program that is accepted without a diagnostic will behave
as specified by the 2011 ISO C standard.

The single statement that an implementation is conforming (and
that its implementors are committed to having it be conforming)
conveys by itself a tremendous amount of information, even
under the assumption that it may, eg, refuse to accept programs
that use floating point (or 'long long', etc). It is for this
reason that there is a big difference between "conforming" and
"non-conforming" implementations, as I understand what you take
the quoted terms to mean.

I think you're stretching the meaning of a "conforming
implementation", not necessarily beyond the Standard's definition
of that term, but beyond what is reasonable. I think that a typical
user would think of a compiler that rejects any use of floating-point
as non-conforming. The fact that it can be justified by citing the
standard would be at best an interesting but obscure curiosity.
(That's pretty much how I think of it, and I'm far more pedantic
than a typical user.)