Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Ruvim Newsgroups: comp.lang.forth Subject: Re: portable or not? Volatile strings Date: Mon, 12 Aug 2024 15:00:53 +0400 Organization: A noiseless patient Spider Lines: 106 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 12 Aug 2024 13:00:55 +0200 (CEST) Injection-Info: dont-email.me; posting-host="f6b7ac0d41814a48556029f556ee937f"; logging-data="3346903"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/XcUz2Tpu1EQe6Am3KRtQI" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:dCazgBbK4+YsXtFBCcARBpXrkpg= In-Reply-To: Content-Language: en-US Bytes: 4262 On 2024-08-12 13:01, albert@spenarnc.xs4all.nl wrote: > In article , > Ruvim wrote: >> On 2024-08-11 17:35, albert@spenarnc.xs4all.nl wrote: [...] >>> I made S" " such that it ALLOT's the string at HERE, to >>> prevent problems with going out of scope, even in interpret mode. >>> (Only 256,000,000,000 -10 bytes left). >>> >>> This doesn't sit well with the definition of BRICK1 , >>> that sees its data area grabbed. >>> You are probably not surprised that tetris doesn't work. >>> >>> The question is, is it legal to store these temporary strings >>> in the dictionary in this way? >> >> >> Strings that are stored relatively to the HERE address 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. >> — as "3.3.3.6 Other transient regions" > > Not relevant. My "transient" region is permanent. That I have > permission to invalidate doesn't affect me. Yes, this is not relevant to your case, but this is correct by itself. Then I realized irrelevance and made another post. > >> says. >> >> All affected transition regions shall be listed. If a region is not >> listed as affected, than it is not affected by allocating data space memory. > > My regions are not affected. So again this is not relevant. There is no need to repeat this. [...] >> In the same time, a Forth system is allowed to limit the buffer >> lifetime (for example, till the next memory allocation), and >> document it as an environmental restriction. [...] > I can't make out what you think. A possible implementation for the interpretation semantics for `S"` is to keep data somewhere in the memory region that returns by "here unused", and declare the lifetime restriction for the returned string. For example: 128 constant _sbufsize 0 value _sn 4 value _snlimit : _sbuf-next ( -- c-addr u ) here aligned 4096 + _sbufsize _sn * + _sbufsize ( c-addr.buf u.buf-len ) 2dup + here unused + u> if -8 throw then \ "dictionary overflow" _sn 1+ _snlimit mod to _sn ; : _memorize-string ( c-addr1 u -- c-addr2 u ) >r _sbuf-next r@ u< ( c-addr c-addr.buf flag ) if -18 throw then \ "parsed string overflow" r@ over >r chars move r> r> ; : s" ( -- c-addr u | ) '"' parse compilation if slit, exit then _memorize-string ; immediate At first I thought you were asking about this approach. This approach implies an environmental restriction. > >>> >>> [ It was sufficient to replace S" with S"' in order to make it run: >>> : S"' &" PARSE ; >>> ] > > Okay let's say it out loud. Classic Forth is not fit for handling strings. > A denotation that generates a constant string "blablabla" that has > a status as a number is long overdue. > The mindset of formulating standards is so 70's. > Why not prepare a proposal? -- Ruvim