On Apr 11, 1:49 pm, m_l_g3 <m_l...@[EMAIL PROTECTED]
> wrote:
> 1a. The buffer is transient, its addresses and contents may
> become invalid after any of the conditions mentioned
> in 3.3.3.6 Other transient regions.
This is, OTOH, fine. For reference, the way the Forth-94 describes
this kind of scenario:
QUOTE
The data space regions identified by PAD, WORD, and #> (the pictured
numeric output string buffer) may be transient. Their addresses and
contents may become invalid after:
- a definition is created via a defining word;
- definitions are compiled with : or :NONAME;
- data space is allocated using ALLOT, , (comma), C, (c-comma), or
ALIGN.
The previous contents of the regions identified by WORD and #> may be
invalid after each use of these words. Further, the regions returned
by WORD and #> may overlap in memory. Consequently, use of one of
these words can corrupt a region returned earlier by a different word.
The other words that construct pictured numeric output strings (<#, #,
#S, and HOLD) may also modify the contents of these regions.
Words that display numbers may be implemented using pictured numeric
output words. Consequently, . (dot), .R, .S, ?, D., D.R, U., and U.R
could also corrupt the regions.
The size of the scratch area whose address is returned by PAD shall be
at least 84 characters. The contents of the region addressed by PAD
are intended to be under the complete control of the user: no words
defined in this Standard place anything in the region, although
changing data-space allocations as described in 3.3.3.2 Contiguous
regions may change the address returned by PAD. Non-standard words
provided by an implementation may use PAD, but such use shall be
documented. The size of the region identified by WORD shall be at
least 33 characters.
The size of the pictured numeric output string buffer shall be at
least (2*n) + 2 characters, where n is the number of bits in a cell.
Programs that consider it a fixed area with unchanging access
parameters have an environmental dependency
UNQUOTE
The data space region identified by ANCHORED and LIB-ANCHORED may be
transient. Their addresses and contents may become invalid after:
- a definition is created via a defining word;
- definitions are compiled with : or :NONAME;
- data space is allocated using ALLOT, , (comma), C, (c-comma), or
ALIGN.
ANCHORED and LIB-ANCHORED may be implemented to use a common absolute
file reference buffer. Consequently, any use of one may corrupt the
region used by the other.
The absolute file reference buffer used by ANCHORED shall be at least
large enough to contain the absolute file reference for the minimum
relative file reference (see below) contained in a file contained in
the implementation default filesystem location used by INCLUDED. If
the file referred to exists, the absolute file reference must support
the ``R/O'' file-access-method. If relative to a file-system location
that supports the ``R/W'' file-access method, the absolute file
reference provided by ANCHORED should refer to a location that also
support the ``R/W'' file-access-method.
The absolute file reference buffer used by LIB-ANCHORED shall be at
least large enough to contain the absolute file reference for the
minimum relative file reference (see below) relative to the library
locations in the implementation default library search path. If the
file referred to exists, the absolute file reference must support the
``R/O'' file-access-method.
The minimum relative file reference that ANCHORED and LIB-ANCHORED
must support, relative to the specified locations in the file-system,
may:
(a) optionally includes up to two levels of subdirectory, with
subdirectory names of up to eight ASCII7 characters
(b) include a filename consisting of up to eight ASCII7 characters,
and an option of at least one type suffix consisting of a ``.'' and up
to three ASCII7 characters.
> > 2. No, there is no sharing between the LIB-ANCHORED and ANCHORED
> > absolute file reference buffer and any buffer provided for a command-
> > line ``S"''.
>
> Personally I do not see any problem with that the S" buffer may not
> exist. There is even no need to define a word for that buffer, it may
> be just PAD /PAD +
But normally these kind of "may re-use" conditions are a concession to
small systems. Permitting re-use of the buffer handed to ANCHORED and
LIB-ANCHORED is a concession to big systems, who don't especially need
it, while making life harder for small systems.
Its not whether the buffer needs to be created, its the fact that the
question of where to buffer the absolute file reference only becomes
tricky for small systems. Just ALLOCATE a space that should be big
enough, remember how much space you allocated, if you need more,
``RESIZE''. If you have megabytes of RAM and don't have enough to save
*one* absolute file reference, you've got a serious memory leak
somewhere.
If each source solves for itself the problem of where to buffer the
file reference, then in porting in code written in big systems, that
problem will often be solved in a way that must be rewritten for a
small system.
By contrast, make ANCHORED and LIB-ANCHORED black boxes that hold the
absolute file reference in their own buffer, which might be the same
buffer, and the problem only has to be solved for the small system
once and for all.
> I would prefer to assume that ANCHORED always rewrite the interpreted
> S" buffer. These buffers are anyway transient, no problem if they are
> *one* transient buffer.
The reason that PAD can not be used by S" is because there is, indeed,
all sorts of opportunities for problems when porting code that assumes
buffers are separate to implementations where in fact that they are
shared.
The simplest solution is to set it up front so that the absolute file
reference buffer is always separate.
Further, in every *actual* implementation where I will be testing
whether this allows writing code in the big box and compiling it in
the little one, it is strictly impossible that that both ANCHORED and
LIB-ANCHORED can be implemented as:
: ANCHORED ;
: LIB-ANCHORED ;
.... because:
* for gforth in Linux, the LIB-ANCHORED will in fact have an
implementation defined search path to search, and absolute file
references in a Unixy system can get very big, very quickly, with the
tendency to have long-form subdirectory names that include full
version and revision information
* for CP/M hForth, the ANCHORED will map subdirectory names to user
areas, while LIB-ANCHORED will refer to a specific library file user
area, set by the user (oddly enough), and the subdirectories will
be .LBR files (which of course may easily be nested in other .LBR
files to whatever depth is required).
* for DOS hForth, both ANCHORED and LIB-ANCHORED will swap to the ``
\'' subdirectory separator (so that the absolute file reference can be
built into a shell command), and LIB-ANCHORED will use the library
path in an environment variable.
* for the current C64 Volksforth, the whole filesystem will be a span
of blocks containing lines of text. The prefix ``./'' will be treated
as relative to a "file" containing a file word, the prefix ``$/'' will
be treated as relative to the library hierarchy and the prefix ``//''
will be treated as relative to the root directory listing the base
block of the filesystem. A single span of blocks is a whole directory
of text files, which are packed by the individual line rather than the
block.
|
