[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Meeting the Scope and Purpose of P754
This is rather off-group, but I am including it because C99 is used
as a claim that some programming languages have included more-or-less
complete support for IEEE 754. My assertion is that it has not, I have
not heard of any that have, the reasons are NOT due to their reluctance
to move forward but to fundamental mismatches of concept, and that
IEEE 754R is no better. Sorry, but IEEE 754R absolutely MUST move
towards the languages' models if it is to do much better.
The following problems are NOT with IEEE 754R, but attempt to describe
how the main attempt to shoehorn IEEE 754 into an existing language
falls foul of some existing ambiguities and inconsistencies, and turns
them from a relatively minor problem into a major one.
I shall not follow up on this C99 arcana further.
Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
C99 says "semantic type". See also 6.3.1.8#2 and its note about cast
and assignment operators.
And where does it define semantic type? Remember that the C90 (and,
much more so, C99) introduced the concept of two types that are
syntactically different but semantically identical. It is perfectly
reasonable to say that the semantic type has nothing to do with the
actual values of a datum.
AFAIK, C99 defines only one concept of type for an expression (6.2.5),
so I don't see any ambiguity.
That's THE ambiguity :-( I am sorry to be blunt, but you haven't
thought that aspect through. Here is the issue.
C has the concept of syntactically different types that have the same
semantics in all respects - and one may even be derived from the other
behind the scenes. The char type and its signed/unsigned equivalent
and (typically) size_t and unsigned long are examples. That is meaning
one.
It also has the concept of two types that differ in semantics. Two
lengths of integer or floating-point are examples. That is meaning
two.
But it also introduces the concept of two values being held in ways
that are not syntactically visible (the issue here). Now, the only
useful definition is 3.17, which says a value is "precise meaning of
the contents of an object when interpreted as having a specific type".
That makes it pretty clear that such ways are types of a sort. That
is meaning three.
Yes, I know and you know what the intent of all that wording is, and
there isn't much dissent on this matter in SC22WG14. But that's not
the point - an implementor reading the standard has not seen any of
the discussions and ISO (and VENDOR) rules require them to interpret
the words as written.
Which of meanings two and three is "semantic type"?
Also, according to ISO rules, 6.3.1.8#2 is normative, but its footnote
is merely informative.
Yes, but it allows to say whether an interpretation can be correct or
not.
That is not what I was told. But I have not read the rules, and you
may be right.
6.3.1.8#2 does not mention any exceptions, [...]
There doesn't need to be an exception if some other part of the
standard gives more detail. The standard says that a conversion
is required when there is an explicit conversion (6.3.1.5), but
I agree that you need informative parts of the standard to guess
what an explicit conversion is exactly. After this conversion,
6.3.1.8#2 still holds.
No, there doesn't. But note what YOU said. There doesn't NEED to
be an exception. That isn't the issue, which is whether there MAY
BE one. Where does it say that an implementation is non-conforming
if it takes the other interpretation?
The problem is that the whole standard (and this area of the standard)
is riddled with places which can be read in the way you describe, or
in the way that I say is possible. Nowhere in that whole **** document
does it say how this problem is to be resolved, and I can witness that
it has caused extended Email flame wars in SC22WG14.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1@xxxxxxxxx
Tel.: +44 1223 334761 Fax: +44 1223 334679