Re: Conflicts between C standard and 754-2008
754 and 1788 members
I am coming late to this discussion. It seems to me that an interval standard will provide an incentive to clear up many of the ambiguities or incompatibilities discussed in this thread. Provided, as Dan said, we make things as clear as possible at the logical and mathematical level. It will take time, but I recall a phrase in a book by E.M. Beale, one of the gurus of linear & nonlinear programming. In his experience in industry "often the first time anyone realises a constraint exists is when one propounds a solution that violates it". It's analogous but a bit the other way about here: there are many "solutions" -- e.g. current language implementations -- out there. P1788 will comprise a constraint, and it will be clear that the solutions violate it in various ways. And they will be changed over time to conform. I hope.
John Pryce
On 6 Jan 2011, at 14:54, N.M. Maclaren wrote:
> On Jan 6 2011, Hossam A. H. Fahmy wrote:
>>
>> 754 and 1788 members,
>>
>> I followed the steps of Michel and tried to see if there are any other
>> issues with the C standard that conflict with 754-2008. I used the links
>> provided by Fred Tydeman on the current versions of the standard.
>> (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf and
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1539.pdf)
>
> It depends on what you mean.
>
> If you mean conflicts where a clear requirement of C99 or C1X is flatly
> incompatible with a clear requirement of IEEE 754, there are probably
> very few. I know of none.
>
> If you mean conflicts where a conforming C99 or C1X implementation
> can set __STDC_IEC_559__ to 1 and still be incompatible with a clear
> requirement of IEEE 754, there are dozens, perhaps hundreds. I have
> mentioned a few on this mailing list in the past, but they are merely
> a small subset of the clearer ones.
>
> If you mean conflicts of a less definite nature, where the requirements
> can reasonably be interpreted incompatibly or the intents are clearly
> incompatible, it's impossible even to estimate.
>
> I don't see any major difficulty in an implementation delivering formal
> conformance with both standards, but it will be obviously be impossible
> to write portable code that uses IEEE 754 as it was intended and relies
> solely on the guaranteed properties. Whether a de facto interpretation
> will emerge that makes it possible to write semi-portable code that does
> is less clear.