Re: Sine code for ANSI C
From: Dan Pop (Dan.Pop_at_cern.ch)
Date: 05/14/04
- Next message: Guruz: "Program without main"
- Previous message: Svein E. Seldal: "GCC structure initialization"
- In reply to: Sam Dennis: "Re: Sine code for ANSI C"
- Next in thread: Dan Pop: "Re: Sine code for ANSI C"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 14 May 2004 11:27:27 GMT
In <slrnca7h8o.5gr.sam@ID-227112.user.uni-berlin.de> Sam Dennis <sam@malfunction.screaming.net> writes:
>Dan Pop wrote:
>> If you're looking for loopholes in the C standard, it contains one so
>> large as to make even a *completely* useless implementation (a two line
>> shell script) fully conforming.
>>
>> 1 The implementation shall be able to translate and execute at
>> least one program that contains at least one instance of every
>> one of the following limits:
>
>I've decided that that was probably a political decision to allow buggy
>compilers to claim conformance.
It's actually a pragmatic decision: for any given implementation, it is
possible to construct a strictly conforming program exceeding the
implementation's resources, while still staying within the translation
limits mentioned in the standard.
One year or so ago I explored the ways of avoiding this wording by
adding a few more translation limits. Then, the standard could reasonably
require the translation and execution of *any* program staying within the
translation limits.
>Specifying accuracy for floating-point
>operations such that enough current implementations can conform, on the
>other hand, is a genuinely hellish task.
I don't think so. If the standard could specify minimal accuracy
requirements for the floating point types, it could also specify
minimal accuracy requirements for the floating point operations. I have
already debated this issue in comp.std.c and my opponents came with bogus
counterarguments (like the unfeasibility of documenting the accuracy of
all the <math.h> functions, although I was strictly and explicitly
talking about the floating point operations).
>> [A conforming implementation, once documentation is attached]
>> echo "Program accepted."
>> cp /bin/true a.out
>
>(The extension below can be ignored if you don't consider `accepted' to
>require even an appropriate diagnostic from a one line file that starts
>with `#error'.)
Who says that the one and only correctly translated program has to
contain the #error pragma?
>> This illustrates the importance of a factor that is not even mentioned
>> in the C standard: the quality of implementation.
>
>Oh, but it would be a perfectly good implementation in most other ways.
I.e. for people with no need for floating point. This is actually the
case with certain implementations for embedded control applications:
floating point support is too expensive and irrelevant to the typical
application domain of the processor, yet the standard says that it must
be provided. A much better solution would have been to make floating
point support optional for freestanding implementations.
In the case of hosted implementations, people would choose the ones
providing proper support for floating point even if they don't need it.
OTOH, considering that practically every hosted implementation in current
use today is for systems with native floating point support, the issue is
moot: the implementation delivers whatever the hardware delivers.
Dan
-- Dan Pop DESY Zeuthen, RZ group Email: Dan.Pop@ifh.de
- Next message: Guruz: "Program without main"
- Previous message: Svein E. Seldal: "GCC structure initialization"
- In reply to: Sam Dennis: "Re: Sine code for ANSI C"
- Next in thread: Dan Pop: "Re: Sine code for ANSI C"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
