"Bruce McFarling" <agila61@[EMAIL PROTECTED]
> wrote in message
news:2a170d1b-3366-4af5-828f-eaaf5222098a@[EMAIL PROTECTED]
> On Apr 1, 12:00 am, "Ed" <nos...@[EMAIL PROTECTED]
> wrote:
> > "Bruce McFarling" <agil...@[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.
>
> I think there is static on the line here. I meant, the main pitfall
> in the existing _status quo_, without the value of MAX-FLOAT-DIGITS
> available as an environment query.
>
> The argument of the proposal being, I took it, that lacking
> ``MAX-FLOAT-DIGITS'' and with the range of permitted Forth-94
> semantics for ``REPRESENT'', the effort to write a portable app
> is subject to a range of pitfalls.
>
> > 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.
>
> That was not from an implementers perspective, and not referring
> to patching MAX-FLOAT-DIGITS. It was referring to source that
> is written without the proposed system, and applying a patch with
> a prelude file that is written using the information provided by
> the proposal, including the information returned by
> MAX-FLOAT-DIGITS.
Ok. I take it such a prelude would redefine REPRESENT and
include it's own local buffer etc? It sounds do-able.
My own feeling is that such measures won't be needed. I
surveyed as much code as I could find which used REPRESENT.
What usage I saw (and there wasn't much) had REPRESENT
work with buffers of at least 18 chars. If that applies generally,
then there should be no issues. To date only one application
has been reported that could fail and it is readily fixable.
|
