"Bruce McFarling" <agila61@[EMAIL PROTECTED]
> wrote in message
news:e5b38da9-e193-4b4a-9fb3-0363cbb29cbf@[EMAIL PROTECTED]
> On Mar 30, 9:02 pm, "Ed" <nos...@[EMAIL PROTECTED]
> wrote:
>
> > It requires apps allocate a minimum buffer size of MAX-FLOAT-DIGITS.
> > In practice most apps and forths already meet that. Apps that
dynamically
> > ALLOCATE the buffer should ask for ( n ) MAX-FLOAT-DIGITS MAX chars.
>
> OK, so the main pitfall is an application that assumes that MAX-FLOAT-
> DIGITS is smaller than it actually is for the system it is running on,
> normally because the actual MAX-FLOAT-DIGITS was smaller in the
> testbed system, so that REPRESENT overflows the buffer.
MAX-FLOAT-DIGITS is a system constant and it's there to let
applications know how much buffer space to allocate. If an app
assumes a value then it isn't portable and suffers the consequences.
The sample apps in the document show how to write a function
using REPRESENT portably.
> And given an environment query for MAX-FLOAT-DIGITS, that can be
> patched, pending a rewrite of the source, by performing the REPRESENT
> in a local buffer and then copying the appropriate contents into the
> buffer handed by the application.
Patching MAX-FLOAT-DIGITS is outside the scope of spec,
however implementers who understand the consequences and
ensure REPRESENT takes into account any changes, are free
to do so.
I needed to do this myself when implementing my scheme
on a system that let users alter hardware precision on the fly.
Thus the value returned by MAX-FLOAT-DIGITS changes
according to the hardware precision selected.
|
