Digest #281 2024-09-21
Contributions
requestClarification - Clarification on what constitutes an ambiguous condition for this word.
The description for this word says: "...An ambiguous condition exists if there are less than u+2 items on the stack before PICK is executed"
In this example with 3 items on the stack: (x2 x1 x0 2 -- x2 x1 x0 x2)
This example worked in gforth - However u+2 = 4 and since 3 < 4 this is an ambiguous condition.
I might be missing something here but shouldn't this read : "An ambiguous condition exists if there are less than u+1 items on the stack before PICK is executed"
Replies
What is the behavior for words of intermediate length? Ambiguous condition (my understanding is this is the case traditionally)?
It's up to the system.
A system is allowed to support definition names longer than 31 characters. Then, the size of the region identified by WORD must be at least the maximum supported definition name length. An ambiguous condition exists if the system encounters a name that is longer than the maximum supported length, as [4.1.2 Ambiguous conditions] says:
- a definition name exceeded the maximum length allowed (3.3.1.2 Definition names);
In this case a system may truncate the name, may throw an exception, or may take other cations (see 3.4.4 Possible actions on an ambiguous condition).
In the future, systems may be required to throw an exception with a specific throw code in this case (in the frame of eliminating some ambiguous conditions).
3.3.1.2 Definition names says:
- Programs with definition names longer than 31 characters have an environmental dependency.
If I'm understanding correctly this also means that an implementation that, e.g., returns counted strings where only the region they occupy is available to the program even if this should be shorter than 33 characters is not compliant?
A don't see any statement that disallows a program to modify the region identified by WORD. If a program is allowed to do it, than yes, this region shall be at least 33 characters long, regardless how many characters are occupied.
I missed it, there is a better option in the section 4.1.2 Ambiguous conditions:
- string longer than a counted string returned by 6.1.2450
WORD;
Also, the section 4.1.1 Implementation-defined options says that a standard system shall document the size of buffer for WORD:
- size of buffer at 6.1.2450
WORD(3.3.3.6 Other transient regions);
It is worth nothing that a program is not allowed to modify the contents of the region identified by WORD when its address become invalid as specified in 3.3.3.6 Other transient regions. In some systems this buffer's location is sliding, since it is offset from here, and compiled code may reside at past addresses of the buffer.
- string longer than a counted string returned by 6.1.2450 WORD;
would seem to only apply to those words longer than a counted string, not necessarily larger than the transient region for WORD.
The relevant ambiguous condition seems to actually be
- parsed string overflow;
which afaict can only apply to WORD, which makes sense. Just a little confusing as it does not seem to be mentioned anywhere but in the list of ambiguous conditions that parsing can overflow, not even in the section for parsing. Furthermore there's multiple passages that speak to WORD being limited by counted string length, which is fair as this will certainly be true for some systems, but won't be for minimal ones.
Correction: "worth nothing" should be read as "worth noting"
The relevant ambiguous condition seems to actually be
- parsed string overflow;
which afaict can only apply to WORD, which makes sense.
I cannot agree. Have a look at the following pairs:
- About parsed string:
- Implementation-defined option: maximum size of a parsed string (3.4.1 Parsing);
- Ambiguous condition: parsed string overflow;
- About
WORD:- Implementation-defined option: size of buffer at 6.1.2450
WORD(3.3.3.6 Other transient regions); - Ambiguous condition: string longer than a counted string returned by 6.1.2450
WORD;
- Implementation-defined option: size of buffer at 6.1.2450
The association of "parsed string overflow" with "size of buffer at 6.1.2450 WORD" seems incorrect.
Also, 3.4.1 Parsing says: "the number of characters parsed may be from zero to the implementation-defined maximum length of a counted string". I think, this is about any parsing string (including strings parsed with PARSE, PARSE-NAME, S", C", etc). But parsing with WORD just imposes stronger restrictions.
Just a little confusing as
Agreed. This should be fixed.
@AntonErtle wrote:
addr vs. c-addr
Yes, as far as the standard is concerned,
addrhas the least alignment requirements. But it is also used in practice as a stand-in for any kind of address, including addresses with stricter alignment requirements (I am sure I am not alone in this usage ofaddr); so usingc-addrmakes the intent of not requiring alignment clearer to the reader.
If this specification is a part of the standard, it shall be consistent with other parts of the standard. So we should either use addr (in accordance with the language of the standard), or use c-addr and replace addr with c-addr in all parts of the standard (i.e. change the language of the standard). Don't you agree?
Perhaps this change of the language of the standard should be presented as a separate proposal.
requestClarification - Clarification on what constitutes an ambiguous condition for this word.
In your example there are 4 items on the stack. You have to count the 2, too.